アカウント名:
パスワード:
……既存のソフトウェア資産どーすんだよ
iOS の元となった OS である Mac OS X でいえば、そもそも少し前のだって、x86 と PowerPC の混成バイナリだったし、今は 32bit と 64bit の2種類のバイナリがワンパッケージ化されていたりしますので。そういうユニバーサルなのは Apple の十八番です。
無論、ユニバーサルでないバイナリそのものを動かそうとしたらエミュがいるけど。そんな環境を用意しなくても、普通はあっという間に対応ソフトがそろう。
なぜならば、ほとんど、開発環境だけで吸収できる。ぶっちゃけビルドし直すだけなので。
一瞬でアプリ側で新しいCPUに対応できます。そして、Atom と ARM の両方に対応したパッケージとしてアプリをリリースできる。
全くなんの問題もなく、過去の資産を使えますよ。そういう事態が起きても心配無用。
Carbon で PowerPC だった人は、ビルドの前にまず Cocoa へ移行しなくてはいけなくて大変でしたけどね。フレームワークもさることながら、ネイティブで書くには言語も別だったし。ただ、基本、同じフレームワーク内ならば、正直それほど大変でもない。
昔、Windows 上でWin32な Intel コードと Alpha コードも書いていたけど、ハードウエアを直接叩くような事をしてない限り、普通に簡単です。Unix 環境も同様。SPARCやPOWERやSXなど妙ちくりんなCPUで同様に動くプログラムもいろいろ書いた。無論、いろいろとやっているとアーキテクチャにディペンドするコードも書くことになるが。それは自分でも判るし。それにあまり変なことするのは良いプログラムじゃない。良質なコードを心がけていれば「基本」ビルドし直すだけなのは事実。Mac はあまり関係ない。
ただ、Mac の良いところは(歴史的にいろいろなアーキテクチャを横断してきた結果)、異なるバイナリを一つのパッケージとしてまとめて一つのアプリとして動作させる仕組みがある事。そのためエンドユーザーにアーキテクチャを意識させずに、複数のアーキテクチャで同じく配布したパッケージで動作させられることかな。
過去の資産と新しい資産を意識させずに共存させる事が出来るこの仕組みが、アーキテクチャの移行を実にスムーズにする。そのあたりは非常によく出来ている。
開発者の側から見れば、多くのアプリ(無論例外はあるが、でも多くのアプリ)は、OSのバージョンが変わったり、開発環境のバージョンが変わったりしたのとほぼ同じ手間で、別アーキテクチャに移行できます。そして、リリース前にテストしない人はいないでしょう。
> 昔、Windows 上でWin32な Intel コードと Alpha コードも書いていたけど、ハードウエアを直接叩くような事をしてない限り、普通に簡単です。
ちゃんと動くことを保証することは普通に難しいですねデータサイズやエンディアンやアラインメントの違いなど、20年前に書いたコードを正確に把握していますか?処理系の都合でたまたま動いていただけなものも混じっているかもしれない
> データサイズやエンディアンやアラインメントの違いなど、20年前に書いたコードを正確に把握していますか?
普通はそのあたりの問題が起こらないようにポータブルなコードを当然のように書いてます。
横槍失礼。
>普通はそのあたりの問題が起こらないようにポータブルなコードを当然のように書いてます。
仕組み的には保証できないということでしょう。ポータビリティがあるようにコーディングしているつもりだとして、実際に異なるアーキテクチャ(X86)でテストしたわけじゃないんでしょ?
コードは書き捨てで、しかも自分で書いたものしか使わない人ですか?
元コメは昔に書いたコードの話ですし、それも自分が書いたものとは限りませんよ
書き捨てならポータビリティなど気にしませんが。
自分しかとか訳のわからないことをいっていますが、昔から組織的にそういうコードを書くようにしています。コードレビューの時もチェックしますよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stay hungry, Stay foolish. -- Steven Paul Jobs
Intel「今後のiPhoneもiPadも全部Atom採用にするなら作ってやるよ(ホジホジ」 (スコア:0)
……既存のソフトウェア資産どーすんだよ
Re: (スコア:1)
iOS の元となった OS である Mac OS X でいえば、そもそも少し前のだって、x86 と PowerPC の混成バイナリだったし、今は 32bit と 64bit の2種類のバイナリがワンパッケージ化されていたりしますので。そういうユニバーサルなのは Apple の十八番です。
無論、ユニバーサルでないバイナリそのものを動かそうとしたらエミュがいるけど。
そんな環境を用意しなくても、普通はあっという間に対応ソフトがそろう。
なぜならば、ほとんど、開発環境だけで吸収できる。
ぶっちゃけビルドし直すだけなので。
一瞬でアプリ側で新しいCPUに対応できます。
そして、Atom と ARM の両方に対応したパッケージとしてアプリをリリースできる。
全くなんの問題もなく、過去の資産を使えますよ。
そういう事態が起きても心配無用。
Re:Intel「今後のiPhoneもiPadも全部Atom採用にするなら作ってやるよ(ホジホジ」 (スコア:0)
Carbon で PowerPC だった人は、ビルドの前にまず Cocoa へ移行しなくてはいけなくて大変でしたけどね。フレームワークもさることながら、ネイティブで書くには言語も別だったし。ただ、基本、同じフレームワーク内ならば、正直それほど大変でもない。
昔、Windows 上でWin32な Intel コードと Alpha コードも書いていたけど、ハードウエアを直接叩くような事をしてない限り、普通に簡単です。Unix 環境も同様。SPARCやPOWERやSXなど妙ちくりんなCPUで同様に動くプログラムもいろいろ書いた。無論、いろいろとやっているとアーキテクチャにディペンドするコードも書くことになるが。それは自分でも判るし。それにあまり変なことするのは良いプログラムじゃない。良質なコードを心がけていれば「基本」ビルドし直すだけなのは事実。Mac はあまり関係ない。
ただ、Mac の良いところは(歴史的にいろいろなアーキテクチャを横断してきた結果)、異なるバイナリを一つのパッケージとしてまとめて一つのアプリとして動作させる仕組みがある事。そのためエンドユーザーにアーキテクチャを意識させずに、複数のアーキテクチャで同じく配布したパッケージで動作させられることかな。
過去の資産と新しい資産を意識させずに共存させる事が出来るこの仕組みが、アーキテクチャの移行を実にスムーズにする。そのあたりは非常によく出来ている。
開発者の側から見れば、多くのアプリ(無論例外はあるが、でも多くのアプリ)は、OSのバージョンが変わったり、開発環境のバージョンが変わったりしたのとほぼ同じ手間で、別アーキテクチャに移行できます。そして、リリース前にテストしない人はいないでしょう。
Re: (スコア:0)
> 昔、Windows 上でWin32な Intel コードと Alpha コードも書いていたけど、ハードウエアを直接叩くような事をしてない限り、普通に簡単です。
ちゃんと動くことを保証することは普通に難しいですね
データサイズやエンディアンやアラインメントの違いなど、20年前に書いたコードを正確に把握していますか?
処理系の都合でたまたま動いていただけなものも混じっているかもしれない
Re: (スコア:0)
> データサイズやエンディアンやアラインメントの違いなど、20年前に書いたコードを正確に把握していますか?
普通はそのあたりの問題が起こらないようにポータブルなコードを当然のように書いてます。
Re: (スコア:0)
横槍失礼。
>普通はそのあたりの問題が起こらないようにポータブルなコードを当然のように書いてます。
仕組み的には保証できないということでしょう。
ポータビリティがあるようにコーディングしているつもりだとして、
実際に異なるアーキテクチャ(X86)でテストしたわけじゃないんでしょ?
Re: (スコア:0)
コードは書き捨てで、しかも自分で書いたものしか使わない人ですか?
元コメは昔に書いたコードの話ですし、それも自分が書いたものとは限りませんよ
Re: (スコア:0)
書き捨てならポータビリティなど気にしませんが。
自分しかとか訳のわからないことをいっていますが、昔から組織的にそういうコードを書くようにしています。コードレビューの時もチェックしますよ。