64 ビットでは利用できないドライバーや有名なアプリケーションがたくさんあります。たとえば、Adobe は、Internet Explorer 用の 64 ビット Flash プレーヤー プラグインを提供していません。そのため、64 ビットの Vista を実行しているにもかかわらず、32 ビットの IE を実行する必要があります。Microsoft Office、Visual Studio も 64 ビット版では出荷されていません。
個人的には、アプリケーションを 64 ビットでビルドする際に大きな問題はありませんでした。文字列の長さなどには常に UINT32 の代わりに SIZE_T を使用するなど、いくつかの経験則を覚えておく必要があります。
私の質問は、人々が 64 ビット用にビルドするのを妨げているのは何ですか?
ゼロから始める場合、64 ビット プログラミングはそれほど難しくありません。ただし、あなたが言及したすべてのプログラムは新しいものではありません。
既存のコード ベースから移植するよりも、ゼロから 64 ビット アプリケーションを構築する方がはるかに簡単です。移植の際には多くの落とし穴があります。特に、ある程度の最適化が行われたアプリケーションに移行する場合はそうです。プログラマーは、速度を上げるために多くの小さな仮定を使用しますが、これらを 64 ビットにすばやく移植するのは必ずしも簡単ではありません。私が対処しなければならなかったいくつかの例：
long変わるため、ソケットを介して 64 ビットではない別のプログラムに値を渡す場合は、コードをリファクタリングする必要がありますC/C++ コードを 64 ビットに移植する際に遭遇した最大の問題は、サードパーティ ライブラリのサポートです。たとえば、現在、Lotus Notes API と MAPI の 32 ビット バージョンしかないため、それらに対してリンクすることさえできません。
また、32 ビット DLL を 64 ビット プロセスにロードできないため、動的にロードしようとすると、再びやけどを負います。64 ビットで Microsoft Access をサポートしようとしたときに、この問題が再び発生しました。ウィキペディアから：
Jet データベース エンジンは当面の間、32 ビットのままになります。Microsoft は、64 ビット バージョンの Windows で Jet をネイティブにサポートする予定はありません。
@jvasak の投稿にあるものに加えて、バグを引き起こす可能性のある主なもの:
"LARGE_ADDRESS_AWARE"非常に多くのアプリケーションがポインタをある時点で負の値になり、転倒します。
多くの企業が 64 ビット バージョンを作成する努力を行っていないもう 1 つの理由は、単にその必要がないことです。
Windows には WoW64 (Windows on Windows 64 ビット) があり、Linux には 64 ビットと共に 32 ビット ライブラリを使用できます。これらの両方により、64 ビット環境で 32 ビット アプリケーションを実行できます。
ソフトウェアがこの方法で実行できる限り、64 ビットに変換する大きなインセンティブはありません。
これに対する例外は、オペレーティング システムとより深く結びついているデバイス ドライバーなどであり、x86-64/AMD64 ベースの 64 ビット オペレーティング システムが提供する 32 ビット レイヤーでは実行できません (IA64 は、何からでもこれを行うことができません)。理解します）。
Flash Player については同意しますが、Adobe がこの製品を更新していないことに非常に失望しています。ご指摘のとおり、64 ビットでは正しく動作しないため、32 ビット版の Internet Explorer を実行する必要があります。
これはアドビ側の戦略的ミスだと思います。Flash Player 用に 32 ビット ブラウザを実行しなければならないことはユーザーにとって不便であり、多くの人はこの解決策を理解していません。これにより、開発者はフラッシュの使用に不安を感じるようになる可能性があります。Web サイトにとって最も重要なことは、誰もがサイトを閲覧できるようにすることです。ユーザーを遠ざけるような解決策は、一般的に人気のあるものではありません。Flash の人気は、それ自体の人気に支えられていました。Flash を使用するサイトが増えれば増えるほど、システムに Flash を搭載するユーザーが増え、システムに Flash を搭載するユーザーが増えるほど、Flash を使用するサイトが増えました。
小売市場はこれらのことを推し進めています。一般消費者が新しいコンピュータを購入するとき、64 ビット OS が必要ではないことを知りません。最新であると聞いて、64 ビット OS を手に入れます。最高のもの、コンピューティングの未来、または単に違いを知らないからです。
Vista は約 2 年前にリリースされ、Windows XP 64 ビットはその前にリリースされました。私の考えでは、市場を維持したいのであれば、Flash などの主要なテクノロジーをアップグレードしないには長すぎます。Adobe が Macromedia を買収したことが関係している可能性があり、これは Adobe が Flash を将来の一部とは考えていないことを示しています。Flash と Dreamweaver が Macromedia から得たものの上位にあると私は信じています。 、しかし、なぜ彼らはまだそれを更新していないのですか?
単なる推測ですが、その大部分はサポートになると思います.Adobeが64ビットバージョンをコンパイルする場合、彼らはそれをサポートする必要があります. 単純なコンパイル スイッチかもしれませんが、多くのテストなどを実行する必要があり、その後、サポート スタッフが正しく対応できるようにトレーニングする必要があります。 32 ビット バイナリやコード内の分岐などです。単純に見えますが、大規模なアプリケーションの場合は依然として多くのコストがかかる可能性があります。
コンパイラのスイッチを入れるだけという単純なものではありません。少なくとも、正しくやりたい場合はそうではありません。最も明白な例は、64 ビット データ型を使用してすべてのポインターを宣言する必要があることです。これらのポインタのサイズを仮定するコード (たとえば、ポインタごとに 4 バイトのメモリを割り当てるデータ型) がある場合は、それを変更する必要があります。これはすべて、使用するライブラリでも行う必要があります。さらに、ほんの少しでも見逃すと、ポインタがダウンキャストされ、間違った場所に配置されることになります。ポインタは唯一の厄介なポイントではありませんが、確かに最も明白です。
主にサポートと QA の問題です。64 ビット用にビルドするためのエンジニアリング作業は、ほとんどのコードにとってかなり簡単ですが、テスト作業とサポート コストは同じようにスケールダウンすることはできません。
テスト側では、合格する必要があることを「知っている」にもかかわらず、同じテストをすべて実行する必要があります。
多くのアプリケーションでは、64 ビット メモリ モデルに変換しても実際には何のメリットもありません (数 GB 以上の RAM が必要になることはないため)。実際には、ポインター サイズが大きくなるため、動作が遅くなる可能性があります (すべてのオブジェクト フィールドは 2 倍の大きさです)。
それに加えて、需要の欠如 (ニワトリが先か卵が先かの問題による) を考えると、ほとんどの開発者にとってそれが価値がない理由がわかります。
彼らのLinux/Flash ブログでは、なぜ 64 ビットの Flash Player がまだないのかを説明しています。Linux 固有のものもあれば、そうでないものもあります。