Överför program från 32 bitar till 64 bitar. 7 steg

Artikeln beskriver de viktigaste stegen som måste tas till överföra program från 32 bitar till 64 bitar. De huvudsakliga problemen för utvecklare som planerar att migrera 32-bitarsprogram till 64-bitarssystem beskrivs. Naturligtvis är listan över övervägda problem inte komplett, men vi hoppas kunna tillhandahålla en mer detaljerad version av den här artikeln i framtiden.

Överför 32-bitars program till 64-bitars

Det här är stegen för att framgångsrikt migrera applikationer från Windows från 32-bitars till 64-bitars Windows-system:

Steg 1: 64-bitarsläget kan vara annorlunda. Låt oss fixa det

I samband med en datorarkitektur avser termen "64-bitars" 64-bitars heltal och andra datatyper av denna storlek. "64-bitars" system kan betyda 64-bitars mikroprocessorarkitekturer (t.ex. EM64T, IA-64) eller 64-bitars operativsystemarkitekturer (t.ex. Windows XP Professional x64 Edition).

AMD64 (eller x86-64, Intel 64, EM64T, x64) är en 64-bitars mikroprocessorarkitektur och motsvarande instruktionsuppsättning utvecklad av AMD-företaget. Denna instruktionsuppsättning licensierades av Intel-företaget under namnet EM64T (Intel64). AMD64-arkitekturen är en förlängning av x86-arkitekturen med full bakåtkompatibilitet.

Arkitekturen fick stor spridning som grund för persondatorer och arbetsstationer. IA-64 är en 64-bitars mikroprocessorarkitektur utvecklad gemensamt av Intel och Hewlett Packard-företag. Den är implementerad på Itanium- och Itanium 2-mikroprocessorerna. Arkitekturen används främst i multiprocessorservrar och klustersystem.

Kanske kan du vara intresserad: Hur man laddar ner PCI-enhet för Windows 7 64 bit

AMD64 och IA-64 är två olika 64-bitars arkitekturer, som är inkompatibla med varandra. Det är därför utvecklare måste bestämma sig på en gång om de behöver stödja båda arkitekturerna eller bara en. I de flesta fall, om du inte utvecklar mycket anpassad programvara för klustersystem, eller inte implementerar ditt eget högpresterande DBMS, kommer du troligen att behöva implementera stöd endast för AMD64-arkitekturen, som är mycket mer populär än IA. -64.

Detta är speciellt mjukvara för PC-marknaden, som nästan 100% upptas av AMD64-arkitekturen. Senare i artikeln kommer vi bara att prata om arkitekturen AMD64 (EM64T, x64), eftersom den är den mest aktuella för applikationsutvecklare idag. På tal om olika arkitekturer måste vi nämna begreppet "Data Model".

Por datamodell Vi förstår sambanden mellan accepterade teckensnittsstorlekar inom utvecklingsmiljön. Det kan finnas flera utvecklingsverktyg som följer olika typer av data för ett operativsystem. Men oftast dominerar bara en modell som motsvarar mer miljön av hårdvara y programvara.

Ett exempel på detta är 64-bitars Windows, vars ursprungliga datamodell är LLP64. Men av kompatibilitetsskäl stöder 64-bitars Windows körning av 32-bitarsprogram som fungerar i ILP32LL-datamodellläget. Tabell 1 ger information om de grundläggande datamodellerna.

Datamodellen som används påverkar i hög grad utvecklingsprocessen för 64-bitars applikationer, eftersom storleken på data som används i programkoden måste beaktas.

Steg 2: Ta reda på om du behöver 64-bitarsversionen av din produkt

Du bör börja bemästra 64-bitars system med frågan "Behöver jag verkligen bygga om mitt projekt för ett 64-bitarssystem?" Du ger ett svar på denna fråga först efter att ha tänkt igenom det noga. Å ena sidan kan du hamna efter dina rivaler om du inte erbjuder 64-bitarslösningar. Å andra sidan kan du förlora el tiempo utveckla en 64-bitarsapplikation som inte kommer att ge några konkurrensfördelar. Låt oss lista de grundläggande faktorerna som hjälper dig att fatta ett beslut.

2.1. Applikationens livscykellängd

Du bör inte skapa 64-bitarsversionen av ett program med kort livscykel. Tack vare WOW64-undersystemet fungerar gamla 32-bitars applikationer ganska bra på 64-bitars Windows-system, och det är därför det är ingen idé att göra ett 64-bitarsprogram, eftersom det inte kommer att stödjas om 2 år.

Dessutom visar praxis att migreringen till 64-bitarsversioner av Windows har försenats, och kanske kommer de flesta av dess användare att använda endast 32-bitarsversionen av programlösningen på kort sikt.

Om du planerar långsiktig utveckling och support av en programprodukt bör du börja arbeta med 64-bitarsversionen av din lösning. Du kan göra detta utan att förhasta dig, men tänk på att ju längre du inte har en fullständig 64-bitarsversion, desto större svårigheter kommer du att möta med att stödja den här applikationen installerad på 64-bitarsversioner av Windows.

2.2. Intensiv resursanvändning av en applikation

Om du kompilerar ett program för ett 64-bitarssystem kan du använda stora storlekar av huvudminnet och kommer också att påskynda dess drift med 5-15%. En ökning med 5-10 % kommer att erhållas på grund av användningen av 64-bitars processorns arkitektoniska kapacitet, till exempel ett högre antal register. Resten av hastighetsökningen på 1-5 % förklaras av frånvaron av WOW64-lagret, som översätter API-anrop mellan 32-bitars applikationer och ett 64-bitars operativsystem.

Om ditt program inte fungerar med stora data (mer än 2 GB) och hastigheten på dess drift inte är avgörande, migrering till ett 64-bitarssystem Det kommer inte att vara så akut inom en snar framtid. Förresten, även enkla 32-bitars applikationer kan dra fördelar av att börja i en 64-bitars miljö.

Du kanske vet att ett program skapat med /-tangenten LARGEADDRESSAWARE: JA Du kan tilldela upp till 3 GB minne om 32-bitars Windows startas med nyckeln. Detta 32-bitarsprogram som lanseras på ett 64-bitarssystem kan allokera nästan 4 GB minne (i praktiken cirka 3,5 GB).

2.3. Biblioteksutveckling

Om du utvecklar bibliotek, komponenter eller andra element med hjälp av tredjepartsutvecklare som skapar sin egen programvara, måste du agera snabbt när du skapar 64-bitarsversionen av din produkt. Annars måste kunder som är intresserade av att lansera 64-bitarsversioner leta efter alternativa lösningar.

Till exempel reagerade vissa säkerhetsutvecklare för mjukvara och hårdvara långsamt genom att släppa 64-bitarsprogram, och det fick vissa kunder att leta efter andra verktyg för att skydda sina program.

En ytterligare fördel med att släppa 64-bitarsversionen av ett bibliotek är att du kan sälja den som en separat produkt. Därför kommer dina kunder som vill skapa både 32-bitars och 64-bitars applikationer att behöva köpa 2 olika licenser.

2.4. Din produkts beroende av tredjepartsbibliotek

Innan du planerar arbetet med att skapa 64-bitarsversionen av din produkt, ta reda på om 64-bitarsversioner av bibliotek och komponenter används. Utöver detta, känna till prispolicyn för 64-bitarsversionen av ett bibliotek. Om support inte tillhandahålls, leta efter alternativa lösningar som stöder 64-bitarssystem i förväg.

2.5. Använder 16-bitars applikationer

Om dina lösningar fortfarande använder 16-bitars enheter är det dags att bli av med dem. 16-bitarsprogram på 64-bitarsversioner av Windows stöds inte. Vi bör förklara en sak här om att använda 16-bitars installationsprogram. De används fortfarande för att installera vissa 32-bitars applikationer.

Det finns en speciell mekanism som ersätter några av de mest populära 16-bitarsinstallatörerna med deras nyare versioner. Det kan leda till falsk idé att 16-bitarsprogram fortfarande fungerar i 64-bitarsmiljön. Kom ihåg: det är inte så.

2.6. Kodmontering

Glöm inte att användning av stor monteringskod avsevärt kan öka kostnaderna för att skapa 64-bitarsversionen av en applikation. Efter att ha tänkt på alla faktorer som anges och vägt alla för- och nackdelar, bestäm dig om du behöver porta ditt projekt till 64-bitarssystem. Om svaret är ja kan vi gå längre.

Steg 3: Verktygssats

Om du har bestämt dig för att utveckla 64-bitarsversionen av din produkt och är villig att lägga ner tid, är det fortfarande inte tillräckligt för att garantera framgång. Poängen är att du måste ha hela den nödvändiga uppsättningen verktyg, och här kan du möta vissa svårigheter. Frånvaron av en 64-bitars kompilator kan vara det enklaste men mest oöverstigliga problemet.

Om allt är klart om frånvaron av en 64-bitars kompilator, kan andra liknande problem verka mindre genomskinliga och uppstå först i det skede då projektet portas till en ny arkitektur. Det är därför vi skulle vilja råda dig att ta reda på i förväg om alla nödvändiga komponenter finns som du behöver för att implementera 64-bitarsversionen av din produkt. Du kan möta obehagliga överraskningar.

Naturligtvis är det omöjligt att här lista allt du kan behöva för ett projekt, men vi fortsätter listan för att hjälpa dig att orientera dig, och kanske komma ihåg andra saker som behövs för implementera ditt 64-bitars projekt:

3.1. En 64-bitars kompilator

Det finns knappast mer att säga om vikten av att ha en 64-bitars kompilator. Det måste helt enkelt vara så. Om du planerar att utveckla 64-bitarsapplikationer med den senaste versionen av Visual Studio, kommer följande tabell 2 att hjälpa dig att förstå vilken utgåva av Visual Studio du behöver.

3.2. 64-bitars datorer under kontroll av ett 64-bitars operativsystem

Självklart, du kan använda virtuella maskiner för att starta 64-bitarsapplikationer på 32-bitars datorer, men det är för obekvämt och ger inte den testnivå som behövs. Det är önskvärt att maskinerna har inte mindre än 4-8 GB huvudminne.

3.3. 64-bitarsversioner av alla använda bibliotek

Om bibliotek presenteras i källkoder måste det finnas en 64-bitars konfiguration av projektet. Det kan vara en svår och otacksam uppgift att uppdatera biblioteket för ett 64-bitarssystem på egen hand, och resultatet kan bli opålitligt och innehålla buggar. Dessutom kan du bryta mot licensavtal med dessa åtgärder. Om du använder bibliotek i form av binära enheter bör du också ta reda på om det finns 64-bitars enheter.

Du kan inte använda en 32-bitars DLL i en 64-bitars applikation. Du kan skapa en speciell länk via COM, men det blir en separat stor och svår uppgift. Tänk också på att du kan behöva spendera lite extra pengar för att köpa 64-bitarsversionen av biblioteket.

3.4. Avsaknad av integrerad monteringskod

Visual C++ stöder inte en 64-bitars inline assembler. Du måste använda en extern 64-bitars assembler (t.ex. MASM) eller ha en implementering med samma funktionalitet i C/C++.

3.5. Uppdatering av testmetod

Det innebär en avsevärd ombyggnad av testmetoden, uppdatering av enhetstester och användning av nya verktyg. Vi kommer att prata om detta mer i detalj senare, men glöm inte att ta hänsyn till det vid utvärderingen av tidskostnaderna för att migrera en applikation till ett nytt system.

3.6. Ny data att testa

Om du utvecklar resurskrävande applikationer som använder en stor mängd huvudminne, bör du tillhandahålla påfyllning av testdatabas. När du testar 64-bitars applikationer är det en bra idé att överskrida gränserna på 4 GB för använt minne. Många fel kan bara uppstå under dessa förhållanden.

3.7. 64-bitars säkerhetssystem

Säkerhetssystemet som används måste ge full kompatibilitet med 64-bitarssystem. Det har inte funnits något automatiskt skyddssystem för 64-bitars binära filer (Hasp Envelop-programmet) på länge.

Därför var säkerhetsmekanismen tvungen att implementeras manuellt i programkoden, och det var en svårare uppgift som krävde professionalism och tid. Glöm inte frågor relaterade till säkerhet, systemuppdateringar, bland annat.

3.8. Installatör

Du behöver ett nytt installationsprogram som kan installera 64-bitarsapplikationer fullt ut. Vi vill varna dig för ett mycket typiskt fel. Det är skapandet av 64-bitars installatörer för att installera 32/64-bitars programprodukter. När man förbereder 64-bitarsversionen av en applikation vill utvecklare ofta göra "64-bitarsläge" absolut och skapa ett 64-bitars installationsprogram och glömmer bort att de som använder ett 32-bitars operativsystem helt enkelt inte kan starta ett sådant installationspaket.

Observera att det inte är 32-bitarsprogrammet som ingår i distributionspaketet tillsammans med 64-bitarsprogrammet, utan själva installationsprogrammet. För om distributionssatsen är en 64-bitars applikation så fungerar den naturligtvis inte på ett 32-bitars operativsystem. Det mest obehagliga är att en användare inte kommer att kunna gissa varför det händer.

Steg 4: Konfigurera ett projekt i Visual Studio 2005/2008

Att skapa 64-bitarskonfigurationen för ett projekt i Visual Studio verkar enkelt nog. Svårigheter kommer att börja i skedet av att bygga en ny konfiguration och hitta fel i den. För att skapa själva 64-bitarskonfigurationen måste du utföra följande 4 steg:

Steg 1: Starta konfigurationshanteraren, som visas i bild 1:

Steg 2: Välj ny plattformssupport i konfigurationshanteraren:

Steg 3: välj 64-bitars (x64)-plattformen och, som bas, 32-bitarsversionskonfigurationen. Visual Studio kommer automatiskt att korrigera inställningar som påverkar byggläget.

Steg 4: Att lägga till en ny konfiguration är klar och du kan nu välja 64-bitars konfigurationsversion och börja bygga en 64-bitars applikation. Att välja 64-bitarskonfigurationen för bygget visas i bild 4 4.

Om du har tur behöver du inte konfigurera ett 64-bitars projekt. Men det beror till stor del på projektet, dess komplexitet och antalet bibliotek som används. Det enda du behöver ändra på en gång är stackstorleken. Om högstorleken i ditt projekt är inställd som standard, vilket är 1 MB, du måste definiera den som 2 MB för 64-bitarsversionen.

Det är inte nödvändigt, men det är bättre att se till i förväg. Om du använder en annan storlek än standard är det vettigt att öka den två gånger för 64-bitarsversionen. För att göra detta, hitta och ändra parametrarna Stack reservstorlek y Stack Commit Storlek i projektinställningarna.

Steg 5: Bygg en applikation

Här bör vi berätta om de typiska problemen som uppstår i kompileringsstadiet av 64-bitars konfiguration, diskutera vilka problem som uppstår i tredjepartsbibliotek, berätta att kompilatorn i koden relaterad till WinAPI-funktioner inte tillåter att en pekare placeras skriv LONG, och du måste uppdatera din kod och använda typen LONG_PTG. Och det finns mycket mer att säga.

Tyvärr finns det så många problem och felen varierar så mycket att vi inte kan beskriva dem alla i en artikel, eller ens i en bok. Du måste granska alla fel som kompilatorn visar dig och alla nya varningar som inte fanns där tidigare och, i varje enskilt fall, ta reda på hur du uppdaterar koden.

Låt oss här endast beskriva de typer som kan vara av intresse för utvecklare vid portering av applikationer. De flesta omkompileringsfel kommer att relatera till användning av samma typer:

• Vid t 32/32: grundläggande typ. På 64-bitars system är det fortfarande 32-bitars.
• Längd 32/32: grundläggande typ. På 64-bitars Windows-system är det fortfarande 32-bitars. Observera att i system Linux 64-bitars, denna typ utökades till 64-bitars. Glöm inte detta om du utvecklar kod som ska kompileras för Windows- och Linux-system.
• storlek_t 32/64: osignerad grundtyp. Storleken på typen är vald på ett sådant sätt att du kan skriva den maximala storleken på en array som är teoretiskt möjlig. Du kan säkert lägga en pekare till typen size_t (förutom pekare till klassfunktioner, men detta är ett specialfall).
• ptrdiff_t 32 / 64: liknar size_t-typen, men det här är en signerad typ. Resultatet av uttrycket där en pekare subtraheras från den andra (ptr1-ptr2) kommer att ha typen ptrdiff_t.
• Pekare 32/64: Storleken på pekaren beror direkt på plattformens storlek. Var försiktig när du konverterar pekare till andra typer.
• __int64 64 / 64: 64-bitars signerad typ.
• DWORD 32/32: 32-bitars osignerad typ. I WinDef.h är det definierat som: typedef unsigned long DWORD;
• DWORDLONG 64/64: 64-bitars osignerad typ. I WinNT.h definieras det som: typedef ULONGLONG DWORDLONG.
• DWORD_PTR 32/64: osignerad typ i vilken en pekare kan placeras. I BaseTsd.h är det definierat som: typedef ULONG_PTR DWORD_PTR.
• DWORD32 32 / 32: 32-bitars osignerad typ. I BaseTsd.h är det definierat som: typedef unsigned int DWORD32.
• DWORD64 64 / 64: 64-bitars osignerad typ. I BaseTsd.h är det definierat som: typedef unsigned __int64 DWORD64.
• HALF_PTR 16/32: en halv pekare. I Basetsd.h är det definierat som: #ifdef _WIN64. typedef int HALF_PTR; #else typedef kort HALF_PTR; #endif
• INT_PTR 32/64: signerad typ till vilken en pekare kan placeras. I BaseTsd.h är det definierat som: #if defined (_WIN64) typedef __int64 INT_PTR; #else typedef int INT_PTR; #endif
• Längd 32/32: signerad typ som förblev 32-bitars. Därför bör nu LONG_PTR i många fall användas. I WinNT.h definieras det som: typedef long LONG;
• LONG_PTR 32/64: signerad typ till vilken en pekare kan placeras. I BaseTsd.h är det definierat som: #if defined (_WIN64) typedef __int64 LONG_PTR; #else typedef long LONG_PTR; #endif.
• LPARAM 32/64: parameter för att skicka meddelanden. I WinNT.h är det definierat som: typedef LONG_PTR LPARAM.
• SIZE_T 32/64: analog av typen size_t. I BaseTsd.h är det definierat som: typedef ULONG_PTR SIZE_T.
• SSIZE_T 32/64: Analog av typen ptrdiff_t. I BaseTsd.h är det definierat som: typedef LONG_PTR SSIZE_T.
• ULONG_PTR 32/64: osignerad typ i vilken en pekare kan placeras. I BaseTsd.h är det definierat som: #if defined (_WIN64) typedef unsigned __int64 ULONG_PTR; #else typedef osignerad lång ULONG_PTR; #endif.
• ORD 16/16: Osignerad 16-bitars typ. I WinDef.h är det definierat som: typedef unsigned short WORD.
• WPARAM 32/64: parameter för att skicka meddelanden. I WinDef.h är det definierat som: typedef UINT_PTR WPARAM.

Det här är typerna att tänka på när du migrerar 32-bitarsprogram till 64-bitars Windows-system.

Kanske vill du veta: Hur man använder allt RAM-minne i Windows 10

6. Diagnos av dolda fel

Om du tror att efter att ha åtgärdat alla kompileringsfel kommer du att få en efterlängtad 64-bitarsapplikation, måste vi göra dig besviken. Det svåraste är ännu att komma. I kompileringsstadiet kommer den att korrigera de mest explicita fel som kompilatorn har lyckats upptäcka, och som mestadels är relaterade till omöjligheten av implicit typkonvertering.

Men detta är bara en liten del av problemet. De flesta fel är dolda. Ur det abstrakta språket C++s synvinkel verkar dessa fel säkra och är förtäckta av explicita typkonverteringar. Antalet sådana fel är mycket högre än antalet fel som upptäckts vid kompileringsstadiet.

Du bör inte sätta dina förhoppningar på / Wp64-tangenten. Denna nyckel presenteras ofta som ett underbart sätt att söka efter 64-bitars fel. Egentligen låter /Wp64-nyckeln dig helt enkelt få några varningsmeddelanden om felaktigheten i vissa kodavsnitt i 64-bitarsläge, medan 32-bitarskoden kompileras.

När du kompilerar 64-bitars kod kommer dessa varningar fortfarande att visas. Och det är därför /Wp64-nyckeln ignoreras när man bygger ett 64-bitarsprogram. Och säkerligen kommer den här nyckeln inte att hjälpa till att hitta dolda fel. Låt oss överväga flera exempel på dolda fel.

6.1. Explicit typkonvertering

Den enklaste typen av fel (men absolut inte den lättaste att upptäcka) relaterar till explicita typkonverteringar, när betydande bitar skärs av. Ett populärt exempel är att konvertera pekare till 32-bitarstyper genom att skicka dem till funktioner som SendMessage:

Här används explicit typkonvertering för att konvertera en pekare till en numerisk typ. För en 32-bitars arkitektur är detta exempel korrekt eftersom den sista parametern i SendMessage-funktionen har typen LPARAM, som matchar DWORD på en 32-bitars arkitektur. För en 64-bitars arkitektur är DWORD felaktig och bör ersättas med LPARAM. LPARAM-typen har storlekar på 32 eller 64 bitar, beroende på arkitekturen.

Detta är ett enkelt fall, men typkonvertering verkar ofta mer komplicerat och är omöjligt att upptäcka med hjälp av kompilatorvarningar eller genom att söka i programtexten. Explicita typkonverteringar undertrycker kompilatordiagnostik, eftersom de är avsedda för just detta syfte: tala om för kompilatorn att typkonverteringen är korrekt och att programmeraren är ansvarig för kodens säkerhet.

Explicit sökning hjälper inte heller. Typer kan ha icke-standardiserade namn (definierade av programmeraren via typedef) och antalet metoder för att utföra explicit typkonvertering är också stort. För att säkert diagnostisera dessa fel måste du använda en speciell uppsättning verktyg, såsom Viva64 eller PC-Lint analysatorer.

6.2. Implicit typkonvertering

Följande exempel avser implicit typkonvertering, när viktiga bitar också går förlorade. Fread-funktionskoden läser filen, men är felaktig när man försöker läsa mer än 2 GB på ett 64-bitarssystem.

Funktionen __fread returnerar typen size_t, men typen int används för att lagra antalet lästa byte. Som ett resultat kan funktionen returnera ett falskt antal byte vid stora data som läses. Man kan säga att det är analfabet kod för nybörjare, att kompilatorn kommer att meddela denna typ av konvertering, och att den här koden är väldigt lätt att hitta och fixa. Detta är i teorin.

I praktiken kan allt vara ganska annorlunda när det gäller stora projekt. Detta exempel är hämtat från FreeBSD-källkoden. Felet fixades i december 2008! Observera att den första (experimentella) 64-bitarsversionen av FreeBSD släpptes i juni 2003.

6.3. Bitar och förändringar

Det är lätt att göra fel i din kod när du arbetar med separata bitar. Nästa typ av fel hänför sig till skiftoperationer. Här är ett exempel:

Denna kod fungerar bra på en 32-bitars arkitektur och låter dig ställa in bitar med nummer från 0 till 31 till unity. Efter porta programmet till en 64-bitars plattform, måste du ställa in bitarna 0 till 63. Men den här koden kommer aldrig att ställa in bitarna 32-63.

Var uppmärksam på att "1" har typ int, och när en förändring sker i 32 positioner, kommer ett överflöde att inträffa som visas i bilden. Om vi ​​får 0 (Figur B) eller 1 (Figur C) som ett resultat beror på kompilatorns implementering.

För att fixa koden måste vi göra "1" konstant av samma typ som maskvariabeln:

ptrdiff_t mask = ptrdiff_t(1) << bitNum;

Var också uppmärksam på att dålig kod leder till ytterligare ett fel. När du ställer in 31 bitar på ett 64-bitarssystem blir resultatet av funktionen värdet 0xffffffff80000000. Resultatet av uttrycket 1 << 31 är det negativa talet -2147483648. I en 64-bitars heltalsvariabel presenteras detta nummer som 0xffffffff80000000.

6.4. magiska siffror

De magiska konstanterna, det vill säga siffrorna med hjälp av som definierar storleken av den eller den typen, kan orsaka många problem. Det korrekta beslutet skulle vara att använda sizeof()-operatorer för dessa ändamål, men i ett stort program kan en del av gammal kod fortfarande döljas där, som programmerare tror, ​​storleken på pekaren är 4 byte och i size_t är den alltid 32 bitar. Vanligtvis ser dessa fel ut så här:

Nedan följer de grundläggande siffrorna du bör vara försiktig med när du överför program från 32-bitars till 64-bitars.

Dessa med de grundläggande magiska värdena som är farliga när man migrerar applikationer från en 32-bitars till 64-bitars plattform.

6.5. Fel relaterade till att använda 32-bitarsvariabler som index

I program som bearbetar stora data kan fel uppstå relaterade till indexering av stora arrayer eller eviga loopar. Följande exempel innehåller 2 fel:

Det första misstaget här är att om storleken på data som bearbetas överstiger 4 GB (0xFFFFFFFF), kan en evig loop uppstå eftersom variabeln 'I' har typen 'unsigned' och kommer aldrig att nå värdet 0xFFFFFFFF. Vi skriver medvetet att det kan hända men inte nödvändigtvis. Det beror på koden som kompilatorn kommer att bygga.

Till exempel, i felsökningsläge kommer den eviga slingan att finnas, och i releasekoden kommer det inte att finnas någon slinga eftersom kompilatorn kommer att bestämma sig för att optimera koden med hjälp av ett 64-bitars register för räknaren, och slingan blir korrekt. Allt detta skapar mycket förvirring och kod som fungerade igår kan misslyckas idag.

Det andra misstaget Det är relaterat till att analysera matris från början till slut för att avgöra vilka negativa indexvärden som används. Denna kod kommer att fungera bra i 32-bitarsläge, men när den körs på en 64-bitars dator kommer out-of-bound åtkomst till arrayen att ske vid den första iterationen av slingan och programmet kommer att krascha. Låt oss studera orsaken till ett sådant beteende. Enligt reglerna för C + +, kommer uttrycket "-i - en" i ett 32-bitarssystem att beräknas enligt följande: (i det första steget i = 0):

Uttrycket "-i" har en osignerad typ och ett värde 0x00000000u.

Variabeln 'ett' kommer att förlängas av typ 'int' till den osignerade typen och kommer att vara lika med 0x00000001u. Obs: typen int utökar (enligt C++-standarden) upp till typen 'unsigned' om du deltar i en operation där det andra argumentet har typen unsigned. En subtraktionsoperation utförs där två värden av typen deltar unsigned, och resultatet av operationen är 0x00000000u – 0x00000001u = 0xFFFFFFFFu. Observera att resultatet kommer att ha osignerad typ.

På ett 32-bitarssystem är åtkomst till arrayen med index 0xFFFFFFFFu detsamma som att använda index -1. Som är slut [0xFFFFFFFFu], är en analog till end[-1]. Som ett resultat kommer arrayelementen att bearbetas korrekt. På ett 64-bitarssystem kommer situationen att vara helt annorlunda än den sista punkten.

Den osignerade typen kommer att utökas till den signerade ptfdiff_t-typen, och arrayindexet kommer att vara lika med 0x00000000FFFFFFFFi64. Som ett resultat kommer ett spill att inträffa. För att korrigera koden måste du använda typerna ptrdiff_t och size_t.

6.6. Fel relaterade till att ändra de typer av funktioner som används

Det finns misstag som inte är någons fel, men de är ändå misstag. Föreställ dig att för länge, länge sedan i en galax långt borta (i Visual Studio 6.0), utvecklades ett projekt innehållande klassen CSampleApp, en efterföljare till CWinApp. I basklassen finns en virtuell WinHelp-funktion. Efterträdaren lägger över denna funktion och utför alla nödvändiga åtgärder. Denna process visas i följande figur.

Projektet flyttades senare till Visual Studio 2005, där prototypen för WinHelp-funktionen har ändrats, men ingen märkte det eftersom DWORD- och DWORD_PTR-typerna matchade i 32-bitarsläge och programmet fortsatte att fungera korrekt.

Felet väntar på att avslöjas på ett 64-bitarssystem, där DWORD- och DWORD_PTR-typerna har olika storlekar. Så det visar sig att i 64-bitarsläge innehåller klasserna två OLIKA WinHelp-funktioner, vilket säkert är fel. Observera att dessa fällor kan döljas inte bara i MFC, där vissa av funktionerna nu har andra typer av argument, utan även i koden för dina applikationer och tredjepartsbibliotek.

6.7. Diagnos av dolda fel

Det finns många exempel på dessa typer av 64-bitars fel. Som du kan se är steget att söka efter dolda fel inte en trivial uppgift och dessutom kommer många av dem att inträffa oregelbundet och bara med stora dataingångar. Statiska kodanalysatorer är bra på att diagnostisera sådana fel, eftersom de kan kontrollera hela koden för en applikation oavsett indata och frekvensen av exekvering av dess sektioner under verkliga förhållanden.

Det är vettigt att använda statisk analys både vid porteringen av en applikation till 64-bitars plattformar, för att hitta de flesta felen från första början och i vidareutvecklingen av 64-bitarslösningar. Statisk analys kommer att varna och lära en programmerare att bättre förstå särdragen hos fel relaterade till en 64-bitars arkitektur och att skriva mer effektiv kod.

För rättvisans skull bör vi säga att testkodanalysatorerna Gimpel PC-Lint och Parasoft C++ har uppsättningar regler för att diagnostisera 64-bitars fel. Men först och främst är dessa analysatorer för allmänna ändamål och reglerna för att diagnostisera 64-bitars fel är ofullständiga. För det andra är de det designad främst för LP64-datamodellen som används i familjen av OS Linux, så de är inte lika användbara för Windows-program som använder LLP64-datamodellen.

Steg 7 – Testprocessuppdatering

Steget av leta efter fel i programkoden som beskrivs i föregående avsnitt är nödvändigt, men otillräckligt. Ingen av metoderna, inklusive statisk kodanalys, kan garantera upptäckten av alla fel, och det bästa resultatet kan endast uppnås när olika metoder kombineras.

Om ditt 64-bitarsprogram bearbetar en större datastorlek än 32-bitarsversionen, bör du utöka testerna till att omfatta bearbetningsdata som är större än 4 GB. Detta är gränsen över vilken många 64-bitars fel börjar uppstå. Dessa tester kan ta mycket längre tid och du bör vara beredd på detta.

Tester skrivs vanligtvis på ett sådant sätt att varje test kan bearbeta ett litet antal element och därmed göra det möjligt att utföra alla interna enhetstester på flera minuter, medan automatiserade tester (t.ex. med hjälp av AutomatedQA TestComplete) skulle kunna genomföras på flera timmar.

Sorteringsfunktionen som sorterar 100 objekt kommer nästan säkert att fungera korrekt på 100000 32 objekt på ett 64-bitarssystem. Men samma funktion kan misslyckas på ett 5-bitarssystem när man försöker bearbeta XNUMX miljarder objekt. Exekveringshastigheten för ett enhetstest kan minskas med miljontals gånger.

Glöm inte kostnaden för att anpassa tester samtidigt som du behärskar 64-bitars system. En bra lösning är att dela upp enhetstester i snabba (att arbeta med små minnesstorlekar) och långsamma som bearbetar gigabyte och körs till exempel över natten. Automatisk testning av resurskrävande 64-bitarsprogram kan organiseras baserat på distribuerade beräkningar.

Varningar

Hay en till obehaglig sak. Du kommer knappast att lyckas använda verktyg som BoundsChecker för att leta efter fel i 64-bitarsprogram som är resurskrävande och drar mycket minne. Anledningen är en stor avmattning av programmen som testas, vilket gör detta tillvägagångssätt mycket obekvämt.

I läget för att diagnostisera alla fel relaterade till minnesdrift, verktyget Parallellinspektör ingår i Intel Parallel Studio, kommer att sakta ner exekveringen av en applikation med 100 gånger i genomsnitt. Du kommer sannolikt att behöva lämna algoritmen som testas över natten för att se resultaten först nästa dag, medan normalt den här algoritmen fungerar på bara 10 minuter.

Ändå är vi säkra på att Parallel Inspector är ett av de mest användbara och bekväma verktygen när du arbetar i minnesoperationsfelsökningsläge. Du behöver bara vara beredd att ändra din praxis för feldiagnostik och ta hänsyn till det när du planerar att bemästra 64-bitars system.

Ta en titt på: De 10 bästa reparationsverktygen för Windows 10

Pensamientos finales

Glöm inte att lägga till tester som kontrollerar dataformatkompatibilitet mellan 32-bitars och 64-bitarsversioner. Datakompatibilitet kränks ofta under migrering, på grund av skrivtyper som size_t eller long (på Linux-system) till filer. Det här har varit hela vår handledning om hur man överför program från 32-bitars till 64-bitars. Vi hoppas att du hade en bra upplevelse när du slutförde processen.