爲什麼很難製作64位版本的軟件？

Question

在將軟件設計到64位環境中時，必須考慮哪些方面，以及爲什麼相同的代碼不適用於32位和64位（在討論應用程序時）？

驅動程序顯然是一個不同的野獸，缺少64位驅動程序是幾乎所有硬件的臭名昭着的問題。在這個領域有什麼不同，幾乎找不到司機？

爲什麼很難製作64位版本的軟件？

編輯：讓我們忘記舊的，奇怪的軟件與神奇的數字等基本缺陷，並認爲你會創建自己的軟件，以兼容兩者。你需要考慮哪些方面，以及目前編譯器設計無法克服的問題？所有缺少的64位軟件都不能簡單地因爲人們喜歡用神奇數字編碼？！ :)

結論：這似乎是關於人類的懶惰和歷史原因，而不是技術原因。

Answer 1

這可能很難的一個具體原因是指針大小會有所不同。而不是指針佔用32位，指針現在佔用64位。

這是一個問題，如果該軟件通過在C++中reinterpret_cast（可能在一些非常低級代碼發生）某處鞋拔的指針爲int，它發生，因爲int的大小工作和指針均在相同的尺寸。基本上，代碼假定指針具有一定的大小。

能咬回來的另一種方式是，如果代碼與幻數散落像4而不是sizeof(void*)，或0xffffffff代替INT_MAX或類似的東西。

如果軟件依賴於庫或64位不可用的函數，則可能沒有64位版本的軟件。您不能擁有32位和64位的應用程序。例如，在Windows中，有一個名爲SetWindowLong的函數，它只能接受32位數據，所以如果需要將指針傳遞給函數，它對於64位程序並不是很有用。這就是爲什麼有一個稱爲SetWindowLongPtr的函數可以處理64位程序中的64位和32位程序中的32位。

請注意，即使在64位窗口中，Internet Explorer默認運行32位，因爲絕大多數插件只能在32位上使用。一個很好的例子是the Adobe Flash Player，它只能用於32位。所以，即使是像Adobe這樣的大公司，顯然對於64位移植可能並不總是微不足道的。

移位操作可能會受到影響。例如，移位0x80000在32位中保留10次會得到0x0，但移位0x80000在64位中保留10次會產生0x200000000。

所有這些說法都沒有真正的技術原因，如果代碼寫得很好，爲什麼將應用程序移植到64位上太困難了。最好的情況是，一個簡單的項目重新配置和完全重建是所有需要的。

我憤世嫉俗的一面說，公司使用這種方式來實現計劃過時 - 強制或鼓勵人們升級到/購買最新的產品！

Answer 2

合理編寫的軟件通常很容易移植到另一個體繫結構。只需看看NetBSD，Debian或其他大型免費操作系統......許多開源軟件都可以在兩種以上的架構上運行。

問題是，許多軟件都是不顧良好的做法而編寫的。製作「它」通常是典型程序員認爲唯一的東西，而忽略了更多的問題。典型的解釋是：如果客戶沒有看到代碼，爲什麼還要用好實踐呢？它的工作原理是什麼？爲什麼要花更多時間在已經有效的東西上？

驅動程序在這裏略有不同。不同的體系結構可能以不同的方式處理低級別的東西。 Windows上的x86和amd64還有另一個問題：微軟爲amd64驅動程序設置了更嚴格的標準 - 硬件公司並不打算爲符合更嚴格要求的舊硬件生成驅動程序（再次說明：爲什麼打擾？客戶通常已經購買新硬件64位的盒子;如果他沒有，我們會通過不提供驅動程序的方式讓他做到這一點）。再次，開源驅動程序通常在amd64和x86上都可以工作。

我有一張聲卡，在Linux上的x86和amd64系統上都能很好地工作，但不適用於amd64正是因爲這個問題。所以爲它編寫amd64的驅動程序並不是不可能的;硬件公司只是不想。

因此，你的問題的最終答案是：金錢。

Answer 3

簡而言之：在最流行的語言家族中--C及其子類 - 數據類型的大小和結構都非常重要，並且實現定義的也是。事實上，C有很多依賴於實現的功能。這意味着編寫非易用代碼很容易。編寫不假定底層架構的代碼並不是不可能的，但是如果直到您嘗試在不同的環境中運行代碼，纔會依賴於x86特定的行爲，而不會意識到您已經完成了什麼。

它主要是這些使建築獨立性變得困難的低級特徵。在Python和C＃等更高級的語言中，它更容易。