32ビットのMicrosoft WindowsデスクトップOSを維持する理由
この質問は2012年からのものです。2019年以降にこれを読んでいる場合、答えは本当に次のとおりです。いいえ。2019年に32ビットデスクトップオペレーティングシステムを維持する正当な理由はありません。
以下の元の質問：
サーバーソフトウェアはしばらくの間64ビットでしかありません（WindowsのServer 2008 R2以降、ExchangeとSharepointの以前のバージョンでも）。Ubuntuでも、サーバーOSの32ビットバージョンから離れています。
しかし、32ビットのデスクトップオペレーティングシステムを維持し続けるための、定量的で十分な理由はありますか？早期導入者となる（残念なことに）数少ないWindows 8イメージを準備しています。
私たちのデスクトップコンピューターの大部分は4 GB以下のRAMを搭載していますが、32ビットフレーバーオペレーティングシステムのサポートに煩わされる必要はもうありません。
私がすべき理由は何ですか？
32ビットの方が特定の使用例ではわずかに高速になる可能性があります。アドレスが小さいほどコードがコンパクトに見えるため、キャッシュの効率が向上します。私が見たベンチマークでは、その効率は、重い計算環境での64ビットの高い計算効率によって影を落とされる傾向があります。しかし、実際には、32ビットが時々いくつかのベンチマークで勝つことがあります。 YMMV。新しいビルドは64ビットのものを利用するため、ソフトウェアの時代は重要です。古いビルドはそうではありません。
コードがコンパクトになるほど、ディスク容量が少なくなります。 64ビットと32ビットのフレーバーでお気に入りのOSのISOをダウンロードして、違いを確認してください。それは簡単ではありません。また、バイナリを解凍すると、かなり多くmoreになります。 OrangeDogによって指摘されたように：この領域の消費の多くは、64ビットOSが64ビットに加えて32ビットライブラリを出荷するという事実に起因しますもの。
32ビットのレガシーコンポーネントおよびソフトウェアとの互換性はさらに向上します。これは、ホストマシンで動的にコンパイルされるが、サードパーティのバイナリライブラリを同時に取り込むシステムで特に顕著です。 Microsoftの.NETフレームワークはこの良い例です。プログラムは理論的にはアーキテクチャに依存しませんが、ネイティブバイナリにリンクするときはいつでも、Archまたは他のArchに関連付けます。多くの開発者はこれが起こっていることさえ知らず、32ビットモードで実行するように.NETに明示的に指示するための微調整なしに64ビットシステムで実行できないプロダクションコンポーネントを出荷します。ほとんどの人はこれを行う方法を知りません。
Daniel Bが指摘したように：64ビットマシンでのWindows .NET開発では、 フラストレーションの不整合 が発生します特定の状況の例外はOSによってマスクされます。
レガシーハードウェア。 64ビットカーネルで32ビットドライバーを実行することはできません。
これは、ほとんどの人にとってショーストッパーにはなりません。それでも、これらの要因が環境にどのように影響するかを決定する必要があります。
32ビットのデスクトップオペレーティングシステムを維持するために考えられる唯一の理由は、古い16ビット（DOSなど）プログラムを使用していて、Windows Virtual PCをサポートするWindowsバージョンがない場合です。
（それでも、64ビットOSをインストールして、DOSboxのようなものを使用します）。
編集：実際には別の理由があります：4GBを超えるアドレス空間に対応できないハードウェア。例えば。 FireWireがDMAを実行しようとしています。または、64ビットドライバーのない（古い）ハードウェア。
Windows 8を実行するものはすべて、64ビット対応です。ただし、偶然に第1世代のIntel Atomネットブックを使用している場合を除きます（そして、私はそれが疑わしいと思います）。のことを考える。
AMDは2003年に最初の64ビット対応Opteronをリリースしました。それ以来、彼らが作ったほぼすべてのプロセッサは64ビット対応でした。
Intelは1年後、最初の64ビットXeon（Nocona）を2004年にリリースし、2006年までに製品ライン全体を拡大しました。前述の初期のAtomチップは別として、すべてのIntel今日のプロセッサは64ビットです。
古代の歴史 に興味がある場合は、Wikipediaにプロセッサリストが含まれています。
古代のソフトウェア/ハードウェアとの互換性。
すべてがx64で動作する場合、32ビットでは問題ありません。
64ビットマシンのメモリアドレスは当然64ビットです。これらの同じアドレスは、32ビットマシンで32ビットを使用します。かなり例外的な状況下では、必要なビット数の「増加」は、メモリ制限のあるマシンでの良好なパフォーマンスと劣ったパフォーマンスの違いになる可能性があります。
さらに、64ビットソフトウェアを実行できるマシンで32ビットソフトウェアを実行している可能性が高く、64ビットマシンで32ビットサポートが適切に機能するため、ハードウェア側の違いはゲームを変えるものではありません。 64ビットのハードウェアドライバーを備えていないレガシーデバイスが見つかることもありますが、64ビットのオペレーティングシステムが10年以上利用可能であるため、これは非常にまれです。
考慮すべき1つの点は、多くの古い32ビットアプリケーションは、ビット数を超えて多くの点で古いということです。 Windows OS側では、「Program Files（x86）」に配置されている「Program Files」内のファイルを検索すると、32ビットアプリが混乱する可能性があります。同様に、特定のレジストリアイテムは、手動による注意が必要な場合があります。繰り返しになりますが、これは、マシンがたまたま32ビットであった場合に「正常に機能した」ものを「見つける」ためにあなたの助けを必要とするわずかに誤って作成されたアプリケーションの機能です。
多くの人は、64ビットのプログラムとライブラリが32ビットの同等のものより多くのメモリを占有することを知りません。
たとえば、メモリの少ない仮想マシンを使用する場合は、32ビットオペレーティングシステムを使用して、そのVM内のメモリの可用性を最大化することをお勧めします。
Ubuntuといえば、LTSPの下で64ビット12.04 LTSを数週間実行しています。
最初のベータテスターが直面する唯一の手間は、使用するLTSP端末（Dell GX2xx）に32ビットカーネルが必要であるため、2番目のLTSPカーネルをコンパイルし、2つのアーキテクチャに対して2倍のパッケージを維持する必要があることです。 。
LTSPはEdgeケースとして非常に優れているので、特定のテストで欠陥が示されない限り、64ビット版はかなり準備ができていると思います。
個人的にはできるだけ早く64ビットに移行し、後でではなく、すぐに弾丸を噛むことをお勧めしますが、ITサポートチームに影響がないわけではありません。サポートチームの帯域幅がすでに最大に拡張されている場合（つまり、人員不足の場合）、実際に待機することを検討します。
したがって、これは、ソフトウェアの非互換性だけでなく、人的資源に関する問題の1つです。
もちろん、展開は慎重に計画する必要があります（一度にすべてではなく段階的に行うのが望ましい）。ユーザーごとに解決するのに何時間もかかる「発見された」問題があるでしょう。より一般的な問題が特定されると、「ハウツー」は、サポートコールとセルフサービスの両方の解決をより迅速に導くことができます。
ほとんどの場合（たとえば）、OS、特定のソフトウェアパッケージ、および関連するプラグインの間の32ビットと64ビットの（非）互換性の問題すべてを考えています。単一の64ビットOSにインストールされた64ビットブラウザー（または複数のブラウザー）、「管理者として実行」と「通常のユーザーとして実行」のショートカット、これらのブラウザーの32ビットと64ビットの両方のプラグインのオプション（または、場合によっては、ブラウザの1つのバージョンでのみ機能する32ビットプラグインのみに制限されることがあります）-これらのプラグインの上に構築されたアプリケーションとワークフローを破壊するものすべて。 （「プラグイン」とは、Javaからフラッシュ、埋め込みPDFリーダー、Web会議ソフトウェアに至るまで、社内で構築されているか、商用および無料の両方で広く利用可能です）を意味します。これらすべての問題をテストしますが、ユーザーが誤ってプラグインAの前にプラグインBをインストールするかどうかを予測することは困難であり、プラグインAをプラグインBの前にインストールする別のユーザーとは異なる結果を引き起こします（ユーザーがどのような損害を与えるかを予測することは常に困難です彼らの行動がシステムの状態を変更したときに行います。）
32ビットバージョンを維持する唯一の理由は、「レガシー」アプリケーションおよびシステムをサポートすることです。すべてを64ビットOSで実行できる場合は、幸運を祈って次へ進んでください。非技術系企業の企業環境にいる貧弱なSAのようで、XPからユーザーベースからWindows 7に移行する計画は、2014年の第3四半期に開始されます。
<叫び声>
とにかく、私は知りません Shift+Del、そして私はおそらく話せないことが起こり、あなた自身がWindows XP 何かのため。それらの保守、更新、テスト、その他の作業に煩わされることは絶対に避けてください。先日、クライアントが私にいくつかのサポートを望んでいたことがありましたWindows 2000 PoS。すべての私の吹き飛ばしをしなかったので、可能でしたServer 2000画像の場合Server 2003が出た（そして私も本当にやりたかった）。
あなたが祈り、時が来ないことを望んでいる限り、「念のため」にそのようなものを持っていることは常にいいことです、そしてそれを維持するコストは非常に小さいので、私は愚かではないと思います。
レガシーソフトウェアの問題が原因でかなりの問題が発生したため、確認できるのはすべて 64ビットOSで実行できることだけです。その場合は、ライセンスが要因ではないと想定して、移行しない理由はありません。
私の場合、1台のマシンで32ビットのみのアプリケーションをすべて実行できるようにシステムを再構成して、他のすべてのワークステーションを64ビットにすることができました。最終的に私は32ビットマシンをVMで、Debianホスト上で動作するVirtualboxに移行しました。主に容量があり、ボックス数を減らしたかったためです。