Maglipat ng Mga Programa Mula 32 Bit Hanggang 64 Bit. 7 Hakbang

Inilalarawan ng artikulo ang mga pangunahing hakbang na dapat gawin ilipat ang mga programa mula sa 32 bit hanggang 64 bit. Ang mga pangunahing problemang kinakaharap ng mga developer na nagpaplanong ilipat ang mga 32-bit na programa sa 64-bit na mga sistema ay inilarawan. Siyempre, hindi kumpleto ang listahan ng mga isyung isinasaalang-alang, ngunit umaasa kaming makapagbigay ng mas detalyadong bersyon ng artikulong ito sa hinaharap.

Ilipat ang mga 32-bit na programa sa 64-bit

Ito ang mga hakbang upang matagumpay na mag-migrate ng mga application mula sa Windows mula sa 32-bit hanggang 64-bit na Windows system:

Hakbang 1: Maaaring iba ang 64-bit na mode. Ayusin natin

Sa konteksto ng isang arkitektura ng computer, ang terminong "64-bit" ay tumutukoy sa mga 64-bit na integer at iba pang mga uri ng data na may ganitong laki. Ang mga "64-bit" na system ay maaaring mangahulugan ng mga 64-bit na arkitektura ng microprocessor (hal. EM64T, IA-64) o 64-bit na mga arkitektura ng operating system (hal. Windows XP Professional x64 Edition).

AMD64 (o x86-64, Intel 64, EM64T, x64) ay isang 64-bit microprocessor architecture at kaukulang set ng pagtuturo na binuo ng kumpanya ng AMD. Ang set ng pagtuturo na ito ay lisensyado ng kumpanya ng Intel sa ilalim ng pangalang EM64T (Intel64). Ang arkitektura ng AMD64 ay isang extension ng arkitektura ng x86 na may ganap na backward compatibility.

Ang arkitektura ay naging laganap bilang batayan para sa mga personal na computer at workstation. Ang IA-64 ay isang 64-bit microprocessor architecture na pinagsama-samang binuo ng mga kumpanya ng Intel at Hewlett Packard. Ito ay ipinatupad sa Itanium at Itanium 2 microprocessors Ang arkitektura ay pangunahing ginagamit sa mga multiprocessor server at cluster system.

Siguro maaaring ikaw ay interesado: Paano mag-download ng PCI device para sa Windows 7 64 bit

Ang AMD64 at IA-64 ay dalawang magkaibang 64-bit na arkitektura, na hindi tugma sa isa't isa. Ito ang dahilan kung bakit dapat magpasya ang mga developer nang sabay-sabay kung kailangan nilang suportahan ang parehong mga arkitektura o isa lang. Sa karamihan ng mga kaso, kung hindi ka bumuo ng mataas na customized na software para sa mga cluster system, o hindi mo ipapatupad ang iyong sariling mataas na pagganap na DBMS, malamang na kailangan mong magpatupad ng suporta para lamang sa AMD64 architecture, na mas sikat kaysa sa IA. -64.

Lalo na itong software para sa PC market, na halos 100% ay inookupahan ng AMD64 architecture. Sa ibang pagkakataon sa artikulo ay pag-uusapan lamang natin ang tungkol sa arkitektura ng AMD64 (EM64T, x64), dahil ito ang pinakabago para sa mga developer ng application software ngayon. Ang pakikipag-usap tungkol sa iba't ibang mga arkitektura, dapat nating banggitin ang paniwala na "Data Model".

Por modelo ng data Naiintindihan namin ang mga ugnayan sa pagitan ng mga tinatanggap na laki ng font sa loob ng development environment. Maaaring may ilang mga tool sa pag-develop na sumusunod sa iba't ibang uri ng data para sa isang operating system. Ngunit kadalasan ay isang modelo lamang ang nangingibabaw na higit na tumutugma sa kapaligiran ng hardware at software.

Ang isang halimbawa nito ay ang 64-bit na Windows, na ang orihinal na modelo ng data ay LLP64. Ngunit para sa mga dahilan ng pagiging tugma, sinusuportahan ng 64-bit na Windows ang pagpapatakbo ng mga 32-bit na programa na gumagana sa ILP32LL data model mode. Ang talahanayan 1 ay nagbibigay ng impormasyon sa mga pangunahing modelo ng data.

Ang modelo ng data na ginamit ay lubos na nakakaimpluwensya sa proseso ng pagbuo ng 64-bit na mga aplikasyon, dahil ang laki ng data na ginamit sa code ng programa ay dapat isaalang-alang.

Hakbang 2: Alamin kung kailangan mo ang 64-bit na bersyon ng iyong produkto

Dapat mong simulan ang pag-master ng 64-bit system na may tanong na, "Kailangan ko ba talagang buuin ang aking proyekto para sa isang 64-bit system?" Nagbibigay ka ng sagot sa tanong na ito pagkatapos mong pag-isipang mabuti ito. Sa isang banda, maaari kang mahulog sa likod ng iyong mga karibal kung hindi ka nag-aalok ng mga 64-bit na solusyon. Sa kabilang banda, maaari kang matalo oras pagbuo ng 64-bit na application na hindi magbibigay ng anumang competitive na kalamangan. Ilista natin ang mga pangunahing salik na tutulong sa iyo na gumawa ng desisyon.

2.1. Tagal ng lifecycle ng application

Hindi ka dapat gumawa ng 64-bit na bersyon ng isang application na may maikling ikot ng buhay. Salamat sa WOW64 subsystem, ang mga lumang 32-bit na application ay gumagana nang maayos sa 64-bit na Windows system, at iyon ang dahilan kung bakit walang saysay na gumawa ng 64-bit na programa, dahil hindi ito susuportahan sa loob ng 2 taon.

Bilang karagdagan, ipinapakita ng kasanayan na ang paglipat sa mga 64-bit na bersyon ng Windows ay naantala, at marahil ang karamihan sa mga gumagamit nito ay gagamit lamang ng 32-bit na bersyon ng solusyon ng programa sa maikling panahon.

Kung nagpaplano ka ng pangmatagalang pagbuo at suporta ng isang produkto ng programa, dapat kang magsimulang magtrabaho kasama ang 64-bit na bersyon ng iyong solusyon. Magagawa mo ito nang hindi nagmamadali, ngunit tandaan na kapag mas matagal kang wala ng buong 64-bit na bersyon, mas maraming paghihirap ang iyong haharapin sa pagsuporta sa application na ito na naka-install sa 64-bit na bersyon ng Windows.

2.2. Masinsinang paggamit ng mapagkukunan ng isang application

Ang pag-recompile ng isang programa para sa isang 64-bit system ay magbibigay-daan sa iyo na gumamit ng malalaking sukat ng pangunahing memorya, at mapabilis din ang operasyon nito ng 5-15%. Ang pagtaas ng 5-10% ay makukuha dahil sa paggamit ng mga kakayahan sa arkitektura ng 64-bit na processor, halimbawa, isang mas mataas na bilang ng mga rehistro. Ang natitirang 1-5% na pagtaas ng bilis ay ipinaliwanag sa pamamagitan ng kawalan ng WOW64 layer, na nagsasalin ng mga tawag sa API sa pagitan ng 32-bit na mga application at isang 64-bit na operating system.

Kung ang iyong programa ay hindi gumagana sa malaking data (higit sa 2 GB) at ang bilis ng operasyon nito ay hindi mahalaga, ang paglipat sa isang 64-bit na sistema Hindi ito magiging ganoon ka-urgent sa malapit na hinaharap. Sa pamamagitan ng paraan, kahit na ang mga simpleng 32-bit na application ay maaaring makakuha ng mga benepisyo mula sa pagsisimula sa isang 64-bit na kapaligiran.

Maaaring alam mo na ang isang program na nilikha gamit ang / key LARGEADDRESSAWARE: OO Maaari kang maglaan ng hanggang 3 GB ng memorya, kung ang 32-bit na Windows ay sinimulan gamit ang susi. Ang 32-bit na programang ito na inilunsad sa isang 64-bit na sistema ay maaaring maglaan ng halos 4 GB ng memorya (sa pagsasagawa, mga 3,5 GB).

2.3. Pag-unlad ng aklatan

Kung bumuo ka ng mga library, bahagi, o iba pang elemento sa tulong ng mga third-party na developer na gumagawa ng sarili nilang software, dapat kang kumilos nang mabilis habang gumagawa ng 64-bit na bersyon ng iyong produkto. Kung hindi, ang mga customer na interesado sa paglulunsad ng mga 64-bit na bersyon ay kailangang maghanap ng mga alternatibong solusyon.

Halimbawa, ang ilang software at hardware security developer ay mabagal na tumugon sa pamamagitan ng paglabas ng mga 64-bit na programa, at naging dahilan iyon ng ilang mga customer na maghanap ng iba pang mga tool upang protektahan ang kanilang mga program.

Ang isang karagdagang bentahe ng paglabas ng 64-bit na bersyon ng isang library ay iyon maaari mo itong ibenta bilang isang hiwalay na produkto. Samakatuwid, ang iyong mga kliyente na gustong gumawa ng parehong 32-bit at 64-bit na application ay kailangang bumili ng 2 magkaibang lisensya.

2.4. Dependency ng iyong produkto sa mga third-party na library

Bago magplano ng paggawa sa 64-bit na bersyon ng iyong produkto, alamin kung 64-bit na bersyon ng mga library at bahagi ang ginagamit. Bilang karagdagan dito, alamin ang patakaran sa pagpepresyo ng 64-bit na bersyon ng isang library. Kung hindi ibinigay ang suporta, maghanap ng mga alternatibong solusyon na sumusuporta sa mga 64-bit na system bago pa man.

2.5. Gamit ang 16-bit na mga application

Kung ang iyong mga solusyon ay gumagamit pa rin ng 16-bit na mga drive, oras na upang alisin ang mga ito. Ang mga 16-bit na application sa 64-bit na bersyon ng Windows ay hindi suportado. Dapat nating ipaliwanag ang isang bagay dito tungkol sa paggamit ng 16-bit installer. Ginagamit pa rin ang mga ito upang mag-install ng ilang 32-bit na application.

Mayroong isang espesyal na mekanismo na pinapalitan ang ilan sa mga pinakasikat na 16-bit installer ng kanilang mga mas bagong bersyon. Maaari itong humantong sa maling ideya na ang mga 16-bit na programa ay gumagana pa rin sa 64-bit na kapaligiran. Tandaan: hindi ito ganoon.

2.6. Pagpupulong ng code

Huwag kalimutan na ang paggamit ng malaking assembly code ay maaaring makabuluhang tumaas ang gastos ng paglikha ng 64-bit na bersyon ng isang application. Pagkatapos pag-isipan ang lahat ng mga salik na nakalista at timbangin ang lahat ng mga kalamangan at kahinaan, magpasya kung kailangan mong i-port ang iyong proyekto sa mga 64-bit na system. Kung ang sagot ay oo, maaari tayong magpatuloy.

Hakbang 3: Tool Kit

Kung nagpasya kang bumuo ng 64-bit na bersyon ng iyong produkto at handa kang maglaan ng oras, hindi pa rin ito sapat upang magarantiya ang tagumpay. Ang punto ay dapat mong taglayin ang buong kinakailangang hanay ng mga tool, at dito maaari kang makaharap ng ilang mga paghihirap. Ang kawalan ng isang 64-bit compiler ay maaaring ang pinakasimpleng ngunit pinaka-hindi malulutas na problema.

Kung ang lahat ay malinaw tungkol sa kawalan ng isang 64-bit compiler, ang iba pang mga katulad na problema ay maaaring mukhang hindi gaanong transparent at nangyayari lamang sa yugto ng pag-port ng proyekto sa isang bagong arkitektura. Iyon ang dahilan kung bakit nais naming payuhan ka na alamin nang maaga kung umiiral ang lahat ng kinakailangang sangkap na kakailanganin mong ipatupad ang 64-bit na bersyon ng iyong produkto. Maaari kang makaharap ng mga hindi kasiya-siyang sorpresa.

Siyempre, imposibleng ilista dito ang lahat ng maaaring kailanganin mo para sa isang proyekto, ngunit ipagpapatuloy namin ang listahan upang matulungan kang i-orient ang iyong sarili, at marahil ay matandaan ang iba pang mga bagay na kinakailangan para sa ipatupad ang iyong 64-bit na proyekto:

3.1. Isang 64-bit compiler

Halos wala pang masasabi tungkol sa kahalagahan ng pagkakaroon ng 64-bit compiler. Ganyan lang dapat. Kung plano mong bumuo ng mga 64-bit na application gamit ang pinakabagong bersyon ng Visual Studio, ang sumusunod na Talahanayan 2 ay tutulong sa iyo na maunawaan kung aling edisyon ng Visual Studio ang kailangan mo.

3.2. 64-bit na mga computer sa ilalim ng kontrol ng isang 64-bit operating system

Syempre, maaari mong gamitin virtual machine upang simulan ang 64-bit na mga application sa 32-bit na mga computer, ngunit ito ay masyadong abala at hindi magbibigay ng antas ng pagsubok na kinakailangan. Ito ay kanais-nais na ang mga makina ay may hindi bababa sa 4-8 GB ng pangunahing memorya.

3.3. 64-bit na bersyon ng lahat ng library na ginamit

Kung ang mga aklatan ay ipinakita sa mga source code, dapat mayroong 64-bit na configuration ng proyekto. Maaari itong maging isang mahirap at walang pasasalamat na gawain na i-update ang library para sa isang 64-bit na sistema nang mag-isa, at ang resulta ay maaaring hindi mapagkakatiwalaan at naglalaman ng mga error. Bukod pa rito, maaari kang lumabag sa mga kasunduan sa lisensya sa mga pagkilos na ito. Kung gumagamit ka ng mga aklatan sa anyo ng mga binary drive, dapat mo ring malaman kung mayroong 64-bit drive.

Hindi ka maaaring gumamit ng 32-bit DLL sa loob ng 64-bit na application. Maaari kang lumikha ng isang espesyal na link sa pamamagitan ng COM, ngunit ito ay magiging isang hiwalay na malaki at mahirap na gawain. Tandaan din na maaaring kailanganin mong gumastos ng dagdag na pera upang bilhin ang 64-bit na bersyon ng library.

3.4. Kakulangan ng integrated assembly code

Hindi sinusuportahan ng Visual C++ ang isang 64-bit na inline na assembler. Dapat kang gumamit ng panlabas na 64-bit assembler (hal. MASM) o magkaroon ng pagpapatupad na may parehong functionality sa C/C++.

3.5. Pag-update ng pamamaraan ng pagsubok

Nangangahulugan ito ng malaking muling pagtatayo ng pamamaraan ng pagsubok, pag-update ng mga pagsubok sa unit, at paggamit ng mga bagong tool. Pag-uusapan natin ito nang mas detalyado sa ibang pagkakataon, ngunit huwag kalimutang isaalang-alang ito sa yugto ng pagsusuri sa mga gastos sa oras ng paglipat ng isang aplikasyon sa isang bagong system.

3.6. Bagong data na susuriin

Kung bubuo ka ng mga application na masinsinang mapagkukunan gamit ang isang malaking halaga ng pangunahing memorya, dapat kang magbigay ng muling pagdadagdag ng database ng input ng pagsubok. Kapag nag-load ng pagsubok sa mga 64-bit na application, magandang ideya na lumampas sa 4 GB na limitasyon ng ginamit na memorya. Maraming mga error ang maaaring mangyari lamang sa ilalim ng mga kundisyong ito.

3.7. 64-bit na mga sistema ng seguridad

Ang sistema ng seguridad na ginamit ay dapat magbigay ng ganap na pagkakatugma sa mga 64-bit na sistema. Walang awtomatikong sistema ng proteksyon para sa 64-bit binary file (Hasp Envelop program) sa mahabang panahon.

Samakatuwid, ang mekanismo ng seguridad ay kailangang ipatupad nang manu-mano sa loob ng code ng programa, at iyon ay isang mas mahirap na gawain na nangangailangan ng propesyonalismo at oras. Huwag kalimutan ang tungkol sa mga isyu na nauugnay sa seguridad, mga update sa system, bukod sa iba pa.

3.8. installer

Kailangan mo ng bagong installer na may kakayahang ganap na mag-install ng mga 64-bit na application. Nais ka naming bigyan ng babala tungkol sa isang pangkaraniwang error. Ito ay ang paglikha ng 64-bit installer upang mag-install ng 32/64-bit na mga produkto ng programa. Kapag naghahanda ng 64-bit na bersyon ng isang application, kadalasang gustong gawing ganap ng mga developer ang "64-bit mode" at lumikha ng 64-bit installer na nakakalimutang ang mga gumagamit ng 32-bit operating system ay hindi maaaring maglunsad ng naturang installation package.

Bigyang-pansin na hindi ito ang 32-bit na application na kasama sa distribution kit kasama ang 64-bit na isa, ngunit ang installer mismo. Dahil kung ang distribution kit ay isang 64-bit na application, siyempre hindi ito gagana sa isang 32-bit operating system. Ang pinaka-hindi kasiya-siyang bagay ay ang isang gumagamit ay hindi maaaring hulaan kung bakit ito nangyayari.

Hakbang 4: Pag-set up ng isang proyekto sa Visual Studio 2005/2008

Ang paglikha ng 64-bit na pagsasaayos ng isang proyekto sa Visual Studio ay tila sapat na simple. Magsisimula ang mga paghihirap sa yugto ng pagbuo ng bagong pagsasaayos at paghahanap ng mga error dito. Upang lumikha ng 64-bit na setup mismo, kailangan mong gawin ang sumusunod na 4 na hakbang:

Hakbang 1: Simulan ang configuration manager, tulad ng ipinapakita sa larawan 1:

Hakbang 2: Sa configuration manager, pumili ng bagong suporta sa platform:

Hakbang 3: piliin ang 64-bit (x64) na platform at, bilang base, ang 32-bit na bersyon ng configuration. Awtomatikong itatama ng Visual Studio ang mga setting na nakakaimpluwensya sa build mode.

Hakbang 4: Kumpleto na ang pagdaragdag ng bagong configuration at maaari mo na ngayong piliin ang 64-bit na bersyon ng configuration at magsimulang bumuo ng 64-bit na application. Ang pagpili ng 64-bit na configuration para sa build ay ipinapakita sa larawan 4 4.

Kung ikaw ay mapalad, hindi mo na kakailanganing mag-configure ng isang 64-bit na proyekto. Ngunit ito ay higit na nakadepende sa proyekto, sa pagiging kumplikado nito at sa bilang ng mga aklatan na ginamit. Ang tanging bagay na kailangan mong baguhin nang sabay-sabay ay ang laki ng stack. Kung ang laki ng heap sa iyong proyekto ay nakatakda bilang default, na 1 MB, dapat mong tukuyin ito bilang 2 MB para sa 64-bit na bersyon.

Ito ay hindi kinakailangan, ngunit ito ay mas mahusay na siguraduhin muna. Kung gagamit ka ng ibang laki kaysa sa default, makatuwirang dagdagan ito nang dalawang beses para sa 64-bit na bersyon. Upang gawin ito, hanapin at baguhin ang mga parameter Laki ng Stack Reserve y Laki ng Stack Commit sa mga setting ng proyekto.

Hakbang 5: Bumuo ng isang application

Dito dapat naming sabihin sa iyo ang tungkol sa mga tipikal na problema na nangyayari sa yugto ng compilation ng 64-bit na pagsasaayos, talakayin kung anong mga problema ang nangyayari sa mga aklatan ng third-party, sabihin sa iyo na sa code na nauugnay sa mga function ng WinAPI, hindi papayagan ng compiler ang paglalagay ng pointer sa uri ng LONG, at kakailanganin mong i-update ang iyong code at gamitin ang uri na LONG_PTG. At marami pang sasabihin.

Sa kasamaang palad, napakaraming mga problema at ang mga error ay nag-iiba-iba na hindi namin mailarawan ang lahat sa isang artikulo, o kahit sa isang libro. Kakailanganin mong suriin ang lahat ng mga error na ipinapakita sa iyo ng compiler at lahat ng mga bagong babala na wala pa noon at, sa bawat partikular na kaso, alamin kung paano i-update ang code.

Ilarawan lamang natin dito ang mga uri na maaaring interesado sa mga developer kapag nag-port ng mga application. Karamihan sa mga error sa recompilation ay nauugnay sa paggamit ng mga parehong uri na ito:

• Sa t 32 / 32: pangunahing uri. Sa 64-bit system ay 32-bit pa rin ito.
• Mahabang 32 / 32: pangunahing uri. Sa 64-bit na Windows system ay 32-bit pa rin ito. Mangyaring tandaan na sa mga system Linux 64-bit, ang ganitong uri ay pinalawig sa 64-bit. Huwag kalimutan ito kung bumuo ka ng code na dapat mag-compile para sa Windows at Linux system.
• laki_t 32 / 64: unsigned basic type. Ang laki ng uri ay pinili sa paraang maaari mong isulat dito ang maximum na laki ng isang array na theoretically posible. Maaari mong ligtas na maglagay ng pointer upang i-type ang size_t (maliban sa mga pointer sa mga function ng klase, ngunit ito ay isang espesyal na kaso).
• ptrdiff_t 32 / 64: katulad ng size_t type, ngunit isa itong signed type. Ang resulta ng expression kung saan ang isang pointer ay ibinabawas mula sa isa (ptr1-ptr2) ay magkakaroon ng uri na ptrdiff_t.
• Pointer 32/64: Ang laki ng pointer ay direktang nakasalalay sa laki ng platform. Mag-ingat kapag nagko-convert ng mga pointer sa iba pang mga uri.
• __int64 64 / 64: 64-bit na naka-sign na uri.
• DWORD 32/32: 32-bit unsigned type. Sa WinDef.h ito ay tinukoy bilang: typedef unsigned long DWORD;
• DWORDLONG 64/64: 64-bit unsigned type. Sa WinNT.h ito ay tinukoy bilang: typedef ULONGLONG DWORDLONG.
• DWORD_PTR 32/64: unsigned type kung saan maaaring ilagay ang pointer. Sa BaseTsd.h ito ay tinukoy bilang: typedef ULONG_PTR DWORD_PTR.
• DWORD32 32 / 32: 32-bit unsigned type. Sa BaseTsd.h ito ay tinukoy bilang: typedef unsigned int DWORD32.
• DWORD64 64 / 64: 64-bit unsigned type. Sa BaseTsd.h ito ay tinukoy bilang: typedef unsigned __int64 DWORD64.
• HALF_PTR 16 / 32: kalahating pointer. Sa Basetsd.h ito ay tinukoy bilang: #ifdef _WIN64. typedef int HALF_PTR; #else typedef maikling HALF_PTR; #endif
• INT_PTR 32 / 64: naka-sign na uri kung saan maaaring ilagay ang isang pointer. Sa BaseTsd.h ito ay tinukoy bilang: #if tinukoy (_WIN64) typedef __int64 INT_PTR; #else typedef int INT_PTR; #endif
• Mahabang 32 / 32: naka-sign na uri na nanatiling 32-bit. Samakatuwid, sa maraming pagkakataon, LONG_PTR na ang dapat gamitin. Sa WinNT.h ito ay tinukoy bilang: typedef long LONG;
• LONG_PTR 32 / 64: naka-sign na uri kung saan maaaring ilagay ang isang pointer. Sa BaseTsd.h ito ay tinukoy bilang: #if tinukoy (_WIN64) typedef __int64 LONG_PTR; #else typedef mahaba LONG_PTR; #endif.
• LPARAM 32 / 64: parameter upang magpadala ng mga mensahe. Sa WinNT.h ito ay tinukoy bilang: typedef LONG_PTR LPARAM.
• SIZE_T 32 / 64: analogue ng uri size_t. Sa BaseTsd.h ito ay tinukoy bilang: typedef ULONG_PTR SIZE_T.
• SSIZE_T 32/64: Analogue ng uri ptrdiff_t. Sa BaseTsd.h ito ay tinukoy bilang: typedef LONG_PTR SSIZE_T.
• ULONG_PTR 32 / 64: unsigned type kung saan maaaring ilagay ang pointer. Sa BaseTsd.h ito ay tinukoy bilang: #if tinukoy (_WIN64) typedef unsigned __int64 ULONG_PTR; #else typedef unsigned long ULONG_PTR; #endif.
• WORD 16/16: Hindi nalagdaan na 16-bit na uri. Sa WinDef.h ito ay tinukoy bilang: typedef unsigned short WORD.
• WPARAM 32 / 64: parameter upang magpadala ng mga mensahe. Sa WinDef.h ito ay tinukoy bilang: typedef UINT_PTR WPARAM.

Ito ang mga uri na dapat isaalang-alang kapag naglilipat ng mga 32-bit na programa sa 64-bit na Windows system.

Baka gusto mong malaman: Paano Gamitin ang Lahat ng Memorya ng RAM sa Windows 10

6. Diagnosis ng mga nakatagong error

Kung sa tingin mo na pagkatapos ayusin ang lahat ng mga error sa compilation ay makakakuha ka ng isang pinakahihintay na 64-bit na application, kailangan naming biguin ka. Ang pinakamahirap na bahagi ay darating pa. Sa yugto ng compilation, itatama nito ang mga pinaka tahasang error na nagawang makita ng compiler, at kadalasang nauugnay sa imposibilidad ng implicit type na conversion.

Ngunit ito ay isang maliit na bahagi lamang ng problema. Karamihan sa mga error ay nakatago. Mula sa punto ng view ng abstract na wika na C++, ang mga error na ito ay mukhang ligtas at disguised sa pamamagitan ng tahasang uri ng mga conversion. Ang bilang ng mga naturang error ay mas mataas kaysa sa bilang ng mga error na nakita sa yugto ng compilation.

Hindi mo dapat ilagay ang iyong pag-asa sa / Wp64 key. Ang susi na ito ay madalas na ipinakita bilang isang kahanga-hangang paraan ng paghahanap ng mga 64-bit na error. Sa totoo lang, pinapayagan ka lang ng /Wp64 key na makatanggap ng ilang mensahe ng babala tungkol sa hindi tama ng ilang mga seksyon ng code sa 64-bit na mode, habang ang 32-bit na code ay pinagsama-sama.

Kapag nag-compile ng 64-bit na code, ang mga babalang ito ay ipapakita pa rin. At iyon ang dahilan kung bakit binabalewala ang /Wp64 key kapag gumagawa ng 64-bit na application. At tiyak na hindi makakatulong ang key na ito sa paghahanap ng mga nakatagong error. Isaalang-alang natin ang ilang halimbawa ng mga nakatagong error.

6.1. Tiyak na uri ng conversion

Ang pinakasimpleng uri ng error (ngunit tiyak na hindi ang pinakamadaling matukoy) ay nauugnay sa tahasang uri ng mga conversion, kapag pinutol ang mga makabuluhang bit. Ang isang tanyag na halimbawa ay ang pag-convert ng mga pointer sa mga 32-bit na uri sa pamamagitan ng pagpasa sa mga ito sa mga function tulad ng SendMessage:

Dito, ang tahasang uri ng conversion ay ginagamit upang i-convert ang isang pointer sa isang numeric na uri. Para sa isang 32-bit na arkitektura, ang halimbawang ito ay tama dahil ang huling parameter ng SendMessage function ay may uri ng LPARAM, na tumutugma sa DWORD sa isang 32-bit na arkitektura. Para sa isang 64-bit na arkitektura, ang DWORD ay hindi tama at dapat palitan ng LPARAM. Ang uri ng LPARAM ay may mga sukat na 32 o 64 bits, depende sa arkitektura.

Ito ay isang simpleng kaso, ngunit ang uri ng conversion ay kadalasang tila mas kumplikado at imposibleng matukoy gamit ang mga babala ng compiler o paghahanap sa teksto ng programa. Pinipigilan ng mga tahasang uri ng conversion ang mga diagnostic ng compiler, dahil nilayon ang mga ito para sa mismong layuning ito: sinasabi sa compiler na tama ang uri ng conversion at ang programmer ay responsable para sa kaligtasan ng code.

Hindi rin makakatulong ang tahasang paghahanap. Ang mga uri ay maaaring magkaroon ng hindi karaniwang mga pangalan (tinukoy ng programmer sa pamamagitan ng typedef) at ang bilang ng mga pamamaraan upang maisagawa ang tahasang uri ng conversion ay malaki rin. Upang ligtas na ma-diagnose ang mga error na ito, dapat kang gumamit ng isang espesyal na hanay ng mga tool, gaya ng Viva64 o PC-Lint analyzers.

6.2. Implicit na uri ng conversion

Ang sumusunod na halimbawa ay nauugnay sa implicit na uri ng conversion, kapag ang mahahalagang bit ay nawala din. Binabasa ng fread function code ang file, ngunit hindi tama kapag sinusubukang magbasa ng higit sa 2 GB sa isang 64-bit system.

Ang __fread function ay nagbabalik ng size_t type, ngunit ang int type ay ginagamit upang iimbak ang bilang ng mga byte na nabasa. Bilang resulta, sa malalaking sukat ng data na nabasa, ang function ay maaaring magbalik ng maling bilang ng mga byte. Maaari mong sabihin na ito ay hindi marunong magbasa ng code para sa mga nagsisimula, na ang compiler ay mag-aanunsyo ng ganitong uri ng conversion, at ang code na ito ay talagang madaling hanapin at ayusin. Ito ay nasa teorya.

Sa pagsasagawa, ang lahat ay maaaring magkakaiba sa kaso ng malalaking proyekto. Ang halimbawang ito ay kinuha mula sa source code ng FreeBSD. Naayos ang bug noong Disyembre 2008! Tandaan na ang unang (pang-eksperimentong) 64-bit na bersyon ng FreeBSD ay inilabas noong Hunyo 2003.

6.3. Mga bit at pagbabago

Madaling magkamali sa iyong code habang nagtatrabaho sa magkahiwalay na mga piraso. Ang susunod na uri ng error ay nauugnay sa mga pagpapatakbo ng shift. Narito ang isang halimbawa:

Ang code na ito ay mahusay na gumagana sa isang 32-bit na arkitektura at nagbibigay-daan sa iyong magtakda ng mga bit na may mga numero mula 0 hanggang 31 hanggang sa pagkakaisa. Pagkatapos pag-port ng programa sa isang 64-bit na platform, kakailanganin mong magtakda ng mga bits 0 hanggang 63. Ngunit ang code na ito ay hindi kailanman magtatakda ng mga bits na 32-63.

Bigyang-pansin na ang "1" ay may uri int, at kapag naganap ang pagbabago sa 32 na posisyon, magkakaroon ng overflow tulad ng ipinapakita sa larawan. Kung makakakuha tayo ng 0 (Figure B) o 1 (Figure C) bilang resulta ay depende sa pagpapatupad ng compiler.

Upang ayusin ang code, kailangan nating gawing pare-pareho ang "1" ng parehong uri ng variable ng mask:

ptrdiff_t mask = ptrdiff_t(1) << bitNum;

Bigyang-pansin din ang katotohanan na ang masamang code ay humahantong sa isa pang error. Kapag nagtatakda ng 31 bits sa isang 64-bit system, ang magiging resulta ng function ay ang value na 0xffffffff80000000. Ang resulta ng 1 << 31 expression ay ang negatibong numero -2147483648. Sa isang 64-bit integer variable, ang numerong ito ay ipinakita bilang 0xffffffff80000000.

6.4. mga magic na numero

Ang magic constants, iyon ay, ang mga numero sa tulong ng na tumutukoy sa laki ng ganito o ganoong uri, maaaring magdulot ng maraming problema. Ang tamang desisyon ay ang paggamit ng sizeof() na mga operator para sa mga layuning ito, ngunit sa isang malaking programa, ang isang seksyon ng lumang code ay maaari pa ring maitago kung saan, gaya ng paniniwala ng mga programmer, ang laki ng pointer ay 4 bytes at sa size_t ito ay palaging 32 bits. Kadalasan, ganito ang hitsura ng mga error na ito:

Nasa ibaba ang mga pangunahing numero na dapat mong maging maingat kapag naglilipat ng mga programa mula sa 32-bit hanggang 64-bit.

Ang mga ito ay may mga pangunahing magic value na mapanganib kapag naglilipat ng mga application mula sa isang 32-bit hanggang 64-bit na platform.

6.5. Mga error na nauugnay sa paggamit ng mga 32-bit na variable bilang mga index

Sa mga program na nagpoproseso ng malaking data, maaaring mangyari ang mga error na nauugnay sa pag-index ng malalaking array o eternal loop. Ang sumusunod na halimbawa ay naglalaman ng 2 error:

Ang unang pagkakamali narito na kung ang laki ng data na pinoproseso ay lumampas sa 4 GB (0xFFFFFFFF), isang eternal loop ay maaaring mangyari dahil ang variable 'ako' may uri 'hindi naka -ignign' at hinding-hindi maaabot ang halagang 0xFFFFFFFF. Sinadya naming isulat na maaari itong mangyari ngunit hindi kinakailangan. Depende ito sa code na gagawin ng compiler.

Halimbawa, sa mode ng debug ang walang hanggang loop ay naroroon, at sa release code ay walang loop dahil ang compiler ay magpapasya na i-optimize ang code gamit ang isang 64-bit na rehistro para sa counter, at ang loop ay magiging tama. Ang lahat ng ito ay nagdaragdag ng maraming pagkalito, at ang code na gumana kahapon ay maaaring mabigo ngayon.

Ang pangalawang pagkakamali Ito ay may kaugnayan sa pagsusuri ng matris mula simula hanggang matapos upang matukoy kung aling mga negatibong halaga ng index ang ginagamit. Ang code na ito ay gagana nang maayos sa 32-bit mode, ngunit kapag tumakbo sa isang 64-bit na computer, ang out-of-bounds na access sa array ay magaganap sa unang pag-ulit ng loop at ang program ay mag-crash. Pag-aralan natin ang dahilan ng gayong pag-uugali. Ayon sa mga tuntunin ng C + +, ang expression na "-i - one" sa isang 32-bit na sistema ay kakalkulahin tulad ng sumusunod: (sa unang hakbang i = 0):

Ang expression na "-i" ay may unsigned type at isang value na 0x00000000u.

Ang variable 'isa' ay magpapalawak ng uri'int' sa unsigned type at magiging katumbas ng 0x00000001u. Tandaan: yung tipo int umaabot (ayon sa pamantayan ng C++) hanggang sa uri ng 'hindi naka -ignign' kung nakikilahok sa isang operasyon kung saan ang pangalawang argumento ay may uri na hindi pinirmahan. Ang isang operasyon ng pagbabawas ay isinasagawa kung saan lumahok ang dalawang halaga ng uri hindi naka -ignign, at ang resulta ng operasyon ay 0x00000000u – 0x00000001u = 0xFFFFFFFFu. Tandaan na ang resulta ay magkakaroon ng unsigned type.

Sa isang 32-bit system, ang pag-access sa array sa pamamagitan ng index 0xFFFFFFFFu ay kapareho ng paggamit ng index -1. Iyon ay tapusin [0xFFFFFFFFu], ay isang analogue ng dulo [-1]. Bilang resulta, ang mga elemento ng array ay mapoproseso nang tama. Sa isang 64-bit na sistema, ang sitwasyon ay lubos na naiiba mula sa huling punto.

Ang unsigned type ay papalawigin sa signed ptfdiff_t type, at ang array index ay magiging katumbas ng 0x00000000FFFFFFFFi64. Bilang resulta, magkakaroon ng overflow. Upang itama ang code, dapat mong gamitin ang mga uri ptrdiff_t at size_t.

6.6. Mga error na nauugnay sa pagbabago ng mga uri ng mga function na ginamit

May mga pagkakamali na walang kasalanan, ngunit ito ay pagkakamali pa rin. Isipin na matagal na ang nakalipas sa isang kalawakan na malayo (sa Visual Studio 6.0), isang proyekto ang binuo na naglalaman ng klase ng CSampleApp, isang kahalili sa CWinApp. Sa base class mayroong isang virtual function na WinHelp. Pinapatungan ng kapalit ang function na ito at ginagawa ang lahat ng kinakailangang aksyon. Ang prosesong ito ay ipinapakita sa sumusunod na figure.

Ang proyekto ay inilipat sa ibang pagkakataon sa Visual Studio 2005, kung saan ang prototype ng WinHelp function ay nagbago, ngunit walang nakapansin dahil sa 32-bit na mode ang mga uri ng DWORD at DWORD_PTR ay tumugma at ang programa ay patuloy na gumagana nang tama.

Ang bug ay naghihintay na maihayag sa isang 64-bit na sistema, kung saan ang mga uri ng DWORD at DWORD_PTR ay may iba't ibang laki. Kaya lumalabas na sa 64-bit na mode, ang mga klase ay naglalaman ng dalawang MAGKAIBANG function ng WinHelp, na tiyak na mali. Tandaan na ang mga traps na ito ay maaaring itago hindi lamang sa MFC, kung saan ang ilan sa mga function ay mayroon na ngayong iba pang mga uri ng argumento, ngunit pati na rin sa code ng iyong mga application at third-party na library.

6.7. Diagnosis ng mga nakatagong error

Mayroong maraming mga halimbawa ng mga ganitong uri ng 64-bit na mga error. Tulad ng nakikita mo, ang yugto ng paghahanap para sa mga nakatagong error ay hindi isang maliit na gawain at, higit pa rito, marami sa mga ito ay magaganap nang hindi regular at may malalaking data input lamang. Ang mga static na code analyzer ay mahusay sa pag-diagnose ng mga naturang error, dahil maaari nilang suriin ang buong code ng isang application anuman ang input data at ang dalas ng pagpapatupad ng mga seksyon nito sa totoong mga kondisyon.

Makatuwirang gumamit ng static analysis kapwa sa yugto ng pag-port ng isang application sa 64-bit na mga platform, upang mahanap ang karamihan sa mga error mula sa simula, at sa karagdagang pagbuo ng mga 64-bit na solusyon. Ang static na pagsusuri ay magbabala at magtuturo sa isang programmer na mas maunawaan ang mga kakaiba ng mga error na nauugnay sa isang 64-bit na arkitektura at magsulat ng mas mahusay na code.

Para sa kapakanan ng pagiging patas, dapat nating sabihin na ang Gimpel PC-Lint at Parasoft C++ test code analyzers ay may mga hanay ng mga panuntunan para sa pag-diagnose ng mga 64-bit na error. Ngunit una sa lahat, ito ay mga general-purpose analyzer at ang mga patakaran para sa pag-diagnose ng 64-bit na mga error ay hindi kumpleto. Pangalawa, sila dinisenyo pangunahin para sa ang LP64 data model na ginamit sa pamilya ng OS Linux, kaya hindi gaanong kapaki-pakinabang ang mga ito para sa mga Windows program na gumagamit ng LLP64 data model.

Hakbang 7 – Pag-update ng Proseso ng Pagsubok

Ang hakbang ng hanapin ang mga error sa program code na inilarawan sa nakaraang seksyon ay kinakailangan, ngunit hindi sapat. Wala sa mga pamamaraan, kabilang ang static code analysis, ang magagarantiya sa pagtuklas ng lahat ng mga error, at ang pinakamahusay na resulta ay makakamit lamang kapag ang iba't ibang mga pamamaraan ay pinagsama.

Kung ang iyong 64-bit na program ay nagpoproseso ng mas malaking laki ng data kaysa sa 32-bit na bersyon, dapat mong palawakin ang mga pagsubok upang maisama ang pagproseso ng data na mas malaki kaysa sa 4 GB. Ito ang limitasyon kung saan maraming 64-bit na error ang nagsisimulang mangyari. Maaaring magtagal ang mga pagsusulit na ito at dapat kang maging handa para dito.

Karaniwang isinusulat ang mga pagsubok sa paraang ang bawat pagsubok ay maaaring magproseso ng maliit na bilang ng mga elemento at sa gayon ay ginagawang posible na maisagawa ang lahat ng panloob na pagsusuri sa yunit sa ilang minuto, habang ang mga automated na pagsubok (hal. paggamit ng AutomatedQA TestComplete) ay maaaring makumpleto sa ilang oras.

Ang pag-uuri ng function na nag-uuri ng 100 item ay halos tiyak na gagana nang tama sa 100000 item sa isang 32-bit system. Ngunit ang parehong function ay maaaring mabigo sa isang 64-bit na sistema kapag sinusubukang iproseso ang 5 bilyong mga item. Ang bilis ng pagpapatupad ng isang unit test ay maaaring bawasan ng milyun-milyong beses.

Huwag kalimutan ang tungkol sa gastos ng pag-adapt ng mga pagsubok habang pinagkadalubhasaan ang 64-bit system. Ang isang magandang solusyon ay ang hatiin ang mga pagsubok sa unit sa mga mabilis (gumagawa sa maliliit na laki ng memorya) at mabagal na nagpoproseso ng mga gigabyte at tumatakbo, halimbawa, sa magdamag. Ang automated na pagsubok ng mga resource-intensive na 64-bit na programa ay maaaring isaayos batay sa mga ibinahagi na kalkulasyon.

Mga Babala

Doon isa pang hindi kasiya-siyang bagay. Halos hindi ka magtatagumpay sa paggamit ng mga tool tulad ng BoundsChecker upang suriin ang mga error sa 64-bit na mga programa na masinsinang mapagkukunan at kumonsumo ng maraming memorya. Ang dahilan ay isang malaking pagbagal ng mga programang sinusuri, na ginagawang napaka-abala sa diskarteng ito.

Sa mode ng pag-diagnose ng lahat ng mga error na may kaugnayan sa pagpapatakbo ng memorya, ang tool Parallel Inspector kasama sa Intel Parallel Studio, ay magpapabagal sa pagpapatupad ng isang aplikasyon ng 100 beses, sa karaniwan. Malamang na kailangan mong iwanan ang algorithm na sinusuri nang magdamag upang makita ang mga resulta sa susunod na araw, habang karaniwang gumagana ang algorithm na ito sa loob lamang ng 10 minuto.

Gayunpaman, sigurado kami na ang Parallel Inspector ay isa sa mga pinaka-kapaki-pakinabang at maginhawang tool kapag nagtatrabaho sa memory operation error finding mode. Kailangan mo lang na maging handa na baguhin ang iyong kasanayan sa pag-diagnose ng error at isaalang-alang ito kapag nagpaplanong makabisado ang mga 64-bit na system.

Tingnan ang: 10 Pinakamahusay na Mga Tool sa Pag-aayos ng Windows 10

Pensamientos finales

Huwag kalimutang magdagdag ng mga pagsubok na sumusuri sa pagiging tugma ng format ng data sa pagitan ng 32-bit at 64-bit na mga bersyon. Ang pagiging tugma ng data ay madalas na nilalabag sa panahon ng paglipat, dahil sa mga uri ng pagsulat tulad ng size_t o mahaba (sa mga Linux system) sa mga file. Ito ang aming buong tutorial kung paano maglipat ng mga programa mula sa 32-bit hanggang 64-bit. Umaasa kaming nagkaroon ka ng magandang karanasan sa pagkumpleto ng proseso.