32ビットのMicrosoft WindowsデスクトップOSを保持する正当な理由

この質問は2012年のものです。2019年以降にこれを読んでいる場合、答えは本当に次のとおりです。いいえ。32ビットのデスクトップオペレーティングシステムを維持する2019年には正当な理由はありません。

以下の元の質問：

サーバーソフトウェアは64ビットでしかありません（Windows用のServer 2008 R2以降、ExchangeおよびSharepointでも以前のものです）。また、Ubuntuでも、サーバーOSの32ビットバージョンから離れています。

しかし、32ビットのデスクトップオペレーティングシステムを維持し続けるには、定量化できる理由がありますか？私たちは、Windows 8のイメージを早期導入者になる（残念なことに？）少数のために準備しています。

私たちのデスクトップコンピューターの大部分は4GB以下のRAMを搭載していますが、32ビットのフレーバーオペレーティングシステムをサポートする必要はもうありません。

私がすべき理由は何ですか？

• 32ビットは、特定のユースケースでわずかに高速になる可能性があります。アドレスが小さいほど、見た目がコンパクトなコードになり、キャッシュ効率が向上します。私が見たベンチマークでは、計算効率の高い環境では、64ビットの計算効率が高いため、効率が低下する傾向があります。しかし、実際には32ビットがいくつかのベンチマークで勝つことがあります。YMMV。新しいビルドでは古いビルドでは得られない64ビットのものを利用するため、ソフトウェアの年齢は重要です。

• コードをコンパクトにすると、ディスク容量が少なくなります。64ビットと32ビットのフレーバーでお気に入りのOSのISOをダウンロードして、違いを確認してください。些細なことではありません。また、非常に多くのですより多くのあなたがバイナリを解凍したら。OrangeDogが指摘したように、このスペース消費の多くは、64ビットOSが64ビットライブラリに加えて32ビットライブラリを出荷しているという事実に起因しています。

• 32ビットのレガシーコンポーネントおよびソフトウェアとの互換性は引き続き向上します。これは、ホストマシンで動的にコンパイルするが、サードパーティのバイナリライブラリを同時に取り込むシステムで特に顕著です。Microsoftの.NETフレームワークはこれの優れた例です。プログラムは理論的にはアーキテクチャに依存しませんが、ネイティブバイナリにリンクするときはいつでも、いずれかのアーチに結び付けます。多くの開発者は、これが起こっていることすら知らず、64ビットシステムでの実行に失敗する製品コンポーネントを出荷します。32ビットモードで実行するように.NETに明示的に指示する調整はありません。ほとんどの人はこれを行う方法を知りません。

• 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年後、2004年に最初の64ビットXeon（Nocona）をリリースし、2006年までにほぼ全製品ラインに拡大しました。前述の初期のAtomチップを除けば、現在のIntelプロセッサはすべて64ビットです。

あなたが古代史に興味があるなら、ウィキペディアには壊れたプロセッサーリストがあります。

古代のソフトウェア/ハードウェアとの互換性。

すべてがx64で動作するのであれば、32ビットを気にしません。

64ビットマシンのメモリアドレスは、当然64ビットを使用します。これらの同じアドレスは、32ビットマシンで32ビットを使用します。非常に例外的な状況では、必要なビット数の「増加」は、メモリが制限されたマシンでのパフォーマンスの向上とパフォーマンスの低下の違いになります。

それを超えて、とにかく64ビットソフトウェアを実行できるマシンで32ビットソフトウェアを実行している可能性が高いため、32ビットサポートは64ビットマシン上で十分に機能するため、ハードウェア側の違いはゲームを変えるものではありません。64ビットのハードウェアドライバーを持たないレガシーデバイスを見つけることがありますが、64ビットのオペレーティングシステムが10年以上にわたって利用可能であるため、現在では非常にまれです。

考慮すべき1つのポイントは、多くの古い32ビットアプリケーションが、ビット数を超えて多くの点で古いことです。Windows OS側では、現在「Program Files（x86）」にある「Program Files」内のファイルを探している場合、32ビットアプリが混乱する可能性があります。同様に、特定のレジストリ項目には手動での注意が必要な場合があります。繰り返しになりますが、これはわずかに誤って記述されたアプリケーションの機能であり、マシンがたまたま32ビットだった場合に「機能した」ものを「見つける」ためにあなたの助けが必要です。

多くの人々は、64ビットのプログラムとライブラリが32ビットの同等物よりも多くのメモリを占有することを知りません。

たとえば、メモリの少ない仮想マシンを使用する場合、そのVM内のメモリの可用性を最大化するために32ビットオペレーティングシステムを使用することをお勧めします。

Ubuntuといえば、LTSPで64週間の12.04 LTSを数週間実行しています。

最初のベータテスターで苦労したのは、使用するLTSP端末（Dell GX2xx）に32ビットカーネルが必要なため、2番目のLTSPカーネルをコンパイルし、2つのアーキテクチャの2倍のパッケージを維持する必要があることです。

LTSPはまさにエッジケースであるため、特定のテストで欠陥が示されない限り、64ビットはかなり準備ができていると思います。

個人的には、できるだけ早く64ビットに移行することをお勧めしますが、弾丸を噛むのは遅めではなく早めにしますが、ITサポートチームに影響が及ぶことはありません。サポートチームの帯域幅が既に最大に拡張されている場合（つまり、既に人手不足の場合）、実際に待機することを検討します。

したがって、これはソフトウェアの互換性だけでなく、人的資源に関する1つの答えです。

もちろん、展開は慎重に計画する必要があります（一度にすべてを行うのではなく、段階的に行うことが望ましい）。ユーザーごとに解決するのに何時間もかかる「発見された」問題があります。より一般的な問題が特定されると、「ハウツー」は、サポートコールとセルフサービスの両方のより迅速な解決を導くことができます。

ほとんどの場合、（たとえば）OS、特定のソフトウェアパッケージ、および関連するプラグインの間のすべての32ビットおよび64ビット（非）互換性の問題を考えています。、単一の64ビットOSに32ビットと64ビットの両方のブラウザー（および/または複数のブラウザー）がインストールされている、「管理者として実行」と「通常ユーザーとして実行」のショートカット、32これらのブラウザ用の64ビットプラグイン（または、ブラウザの1つのバージョンでのみ動作する32ビットプラグインのみに制限される場合があります）-これらはすべて、それらのプラグインの上に構築されたアプリケーションとワークフローを破壊します。（「プラグイン」とは、Javaからフラッシュ、埋め込みpdfリーダー、Web会議ソフトウェアまでのすべてを意味します。社内で構築するか、商用および無料の両方で広く利用できます。）これらの問題をすべてテストすることができますが、ユーザーがプラグインAの前にプラグインBを誤ってインストールするかどうかを予測するのは困難です。これにより、プラグインBの前にプラグインAをインストールする別のユーザーとは異なる結果が生じます（基本的には

...の32ビットバージョンを維持する唯一の理由は、「レガシー」アプリケーションとシステムをサポートすることです。64ビットOSですべてを実行できる場合は、幸運を考えて先に進みます。XPからWindows 7へのユーザーベースからの移行計画が2014年第3四半期に開始される、非ハイテク企業の企業環境にいる貧しいSAのようになります。

< 泣き >

とにかく、Shift+ については知りません。Delおそらく、言葉にできないことが起こり、Windows XP何かを必要としていることに気付いた場合に備えて、環境のどこかでそれらを無視したままにします。それらの保守、更新、テスト、またはその他のことを行うのは絶対にやめますが、必要になった場合は保持してください。先日、クライアントがWindows 2000PoSのサポートを望んでいたことがありましたが、PoS をサポートしたかったのです。なぜならServer 2000、Server 2003出てきたときにすべての画像を吹き飛ばしたわけではなかったからです。

あなたが祈り、時が来ないことを願う限り、「万が一に備えて」そのようなものを持っていることは常に素晴らしいことです。

レガシーソフトウェアの問題によりかなりの問題が発生したため、実行するすべてが64ビットOSで実行できることを確認するしかありません。もしそうなれば、ライセンスが要因ではないと仮定して、移行しない理由はありません。

私の場合、すべての32ビットのみのアプリケーションが1台のマシンで実行できるようにシステムを再構成し、他のすべてのワークステーションを64ビットにすることができました。最終的に、その32ビットマシンをVirtualbox上のVMに移行し、Debianホストで実行しました。これは主に容量があり、ボックス数を減らしたいためです。

CPUが仮想化をサポートしていない場合（VT-x機能など）、上記のすべての仮想マシンおよびいくつかの仮想マシンはx64ビットコードを実行できません。

ただし、VT-xなどを欠いている安価な64ビットCPUのいくつかは、「自家製」クラスターにとって魅力的です。

ウィキペディアから：

Intelは、x86-64実装（Intel 64）にセグメンテーションサポートを追加しなかったため、Intel CPUでは64ビットソフトウェアのみの仮想化が不可能になりましたが、Intel VT-xサポートにより、Intelプラットフォームで64ビットハードウェア支援仮想化が可能になります