John pan

  很多程式都還在32位元像是橘子遊戲的CSO，連Steam都是32bit你覺得呢?可能是成本因數只有少數是64位元？
  現在程式大多還是32位元是相容性較好，因64位元Win作業系統亦可相容32位元程式，但是32位元Win作業系統不可以跑64位元程式！
  你可以到C:\磁碟機裡看，有兩個Program Files資料夾，一個字尾綴有(x86)資料夾，另一個沒註明x86資料夾，各存放著你灌的程式和系統是32位元應用程式和另一個存放64位元應用程式。

  到了2038年那些32位元程式會全部刪除這是發生什麼事？就跟千禧年事件一樣，有事先準備不至於會造成電腦損失。

2038年問題 - 维基自由的百科全書(ZH.WIKIPEDIA.ORG)的解釋：【點我開維基百科解釋網頁】

2038年的不能跑32位元程式問題 - 维基自由的百科全書(ZH.WIKIPEDIA.ORG)的解釋：
  在電腦應用上，2038年問題可能會導致某些軟體在2038年1月19日3時14分07秒之後無法正常工作。所有使用POSIX時間表示時間的程式都將受其影響，因為它們以自1970年1月1日經過的秒數（忽略閏秒）來表示時間。這種時間表示法在類Unix（Unix-like）作業系統上是一個標準，並會影響以其C程式語言開發給其他大部份作業系統使用的軟體。在大部份的32位元作業系統上，此「time_t」資料模式使用一個有正負號的32位元整數（signed int32）儲存計算的秒數。依照此「time_t」標準，在此格式能被表示的最後時間是2038年1月19日03:14:07，星期二（UTC）。超過此一瞬間，時間將會「繞回」（wrap around）且在內部被表示為一個負數，並造成程式無法工作，因為它們無法將此時間辨識為2038年，而可能會依個別實作而跳回1970年或1901年。因此可能產生錯誤的計算及動作。
  有少數的情況下，在制定規格時，特別規定以無正負號的32位元整數（unsigned int32）儲存 POSIX 時間，因此錯誤會被延後到 2106 年。例如比特幣區段鏈中的區段時間戳記，就是以這種方法儲存。
  目前並沒有針對現有的CPU／作業系統搭配的簡單解決方案。直接將POSIX時間更改為64位元模式將會破壞對於軟體、資料儲存以及所有與二進位表示時間相關的部份的二進位相容性。更改成無符號的32位元整數則會影響許多與兩時間之差相關的程式。不過，那時使用32位元系統的電腦可能會很少。
  大部份64位元作業系統已經把time_t這個系統變數改為64位元寬。不過，其他現有架構的改動仍在進行中，不過預期「應該可以在2038年前完成」。然而，直到2006年，仍然有數以億計的32位元系統在運行中，特別是許多嵌入式系統。相對於一般電腦科技18至24個月的革命性更新，嵌入式系統可能直至使用壽命終結都不會改變。32位元time_t的使用亦被編碼於檔案格式，例如眾所周知的ZIP壓縮格式。其能存在的時間遠比受影響的機器長。

感謝痞客邦r97101527網友的指出內文錯誤的地方。

謝謝收看