乍看下，這是一首在1960年代發行由著名的披頭四合唱團所唱紅的西洋歌曲，歌曲的內容是描述當他們64歲花甲之年可能會發生的事情。 不過程式開發人員看待此一字句則隨著64位元版Windows作業系統的出現則有了不同的解讀。到底這股64位世界新勢力會對現有的技術環境產生什麼影響而我們又應當如何來調整以因應它所帶來的改變。本篇將針對新上市的64位元Windows作業系統對目前使用32位元Windows作業系統使用者可能牽涉到影響進行概略性的討論。

的開發本質上是要加強對記憶體的使用能力，而目前64位元微軟作業系統也席捲了整個電腦市場，雖然應用軟體並沒有因此提高64倍的速度也沒有增加64倍的可靠度，但它卻能夠存取龐大的記憶體數量。

 那麼有那些問題是我們需要考慮的呢?首當其衝的當然是記憶體指標的問題—大家都喜歡使用對象或者物件，對吧?當指標變成問題時!那麼就會對應用軟體的動態或靜態的程式庫連結造成影響。64位元革命也同時影響了兩種基礎架構元件—軟體註冊(registry)以及系統動態連結程式庫(DLL)。

如果您並未使用動態或靜態的資料庫連結，也未使用Windows的註冊(registry)、COM以及也不打算在32和64位元的電腦上去支援同一套應用軟體的話，您就可以不需要往下看了，因為ACUCOBOL-GT在這種情況下已經能進行完整的支援。

您現在已經”64”了嗎?

64位元架構意味著微軟支援16TB的理論性限制，是的，沒錯—16 terra bytes，所以我們可以花錢買很多記憶體，而Windows作業系統也能夠使用這些記憶體，不過我們需要修改程式碼嗎? 根據程式是否有特別的處理而定，不過修改的幅度並不大。

 必需注意的是在程式中如果使用到記憶體指標，在微軟64位元作業系統出現之前DWORD格式資料項與指標，因為它們都是32位元(4個位元組)，現在則必須將它們分別出來，因為DWORD資料項仍然是32位元，但指標則變成64位元了(8個位元組)。

 那麼32位元的應用軟體能夠在64位元作業環境執行嗎? 微軟64位元作業環境經由我們所知道的Windows 32 bit on Windows 64bit或者WOW64架框(framework)是可以支援32位元應用軟體的。藉由者這一個界面層，所有系統的呼叫會在兩個系統間對應而將程序進行轉換並回應給使用者。

動態連結檔(DLL)又是如何呢?

之前，當微軟將16位元作業系統升級成32位元時，他們很簡單的在每一個檔案及目錄名的字尾上加上”32”以與原來是16位元版本的元件作為區別。而這時區分的工作是由作業系統上一個稱為檔案系統轉址(File System Redirection)的功能進行處理。64位元的DLL儲存於System32的目錄中，而32位元版本的DLL則儲存於SysWOW64目錄中(這是我們所知道的，並不是靠直覺判斷)。

 除此之外，DLL是否能使用虛擬位址區間(VAS)，VAS主要用於解決4-byte與8-byte指標的相容性問題，藉由VAS的啟動，只有指標的最後4位元才可以作為記憶體的存取之用。

 註冊登錄(Registry Entry)的問題?

WOW64使得兩個原有的登錄檢視(registry view)更加容易，其中一個是為32位元應用軟體所用，另一個當然是為64位元應用軟體所用。藉由檔案系統轉址WOW64將32位元註冊登錄轉址到一個新的Wow6432Node註冊元件。

 某些情況下，也許需要在32位元與64位元註冊中有一個相同的登錄值。 WOW64自動地使用一個稱為註冊轉址(Registry Reflection)或註冊映射(registry mirroring)的程序對這種登入進行同步處理。

DLL如何處理?

假設一個不是64位元的32位元DLL檔，我們想要把它當成64位元應用軟體來執行時，那會發生何種狀況呢? 其實它並不如我們想像的那麼複雜難解，COM物件可執行在Windows 32與Windows 64位元的環境中，而如果您對ACUCOBOL-GT Runtime中COM物件運作的情形熟悉的話，那麼其實對於您來說問題是很容易解決的。但如果您不熟悉ACUCOBOL-GT COM server的話，您可與我們連絡。

 COM呼叫64位元! 聽到請回答!

COM物件被設計成與平台無關，使得我們可以從64位元的應用軟體呼叫32位元的COM物件，反之亦然。因此我們開發一套32位元的COM伺服器以及64位元的應用軟體。

 根據此一重要訊息來思考COM，其實就是元件的註冊程序。

雖然這種註冊是鏡射方式以及全球唯一識別元(GUID)是跨越相同的平台，但仍應使用適當的工具來進行註冊程序。使用32位元版本的regsvr32工具程式對32位元元件進行註冊，而使用64位元版本的工具程式對64位元元件進行註冊，並注意不要以副檔名”.reg” 對32位元的COM伺服器進行自動註冊，這是因為它會引發64位元版本的註冊編輯器啟動。

當我們在考慮使用那個註冊程序時，這時必須區分出非註冊中COM伺服器與註冊中COM伺服器，當註冊中COM伺服器被使用時，COM元件與應用軟體的執行平台是必須相同的。那麼如此是不是阻礙了我們混用32與64位元的COM元件呢? 很幸運的，答案是 --不是，藉由非註冊中COM伺服器，客戶端不管是32或64位元都能夠自由的與32或64位元的COM元件進行互用。