Hvorfor en gammel WinINet-proxyhjælper går i stykker i et 64-bit-build

Én cast kan gøre en tilsyneladende almindelig proxyindstillingshjælper til en arkitekturafhængig fejl:

current = (IntPtr)((int)current + optionSize);

Den kode indsnævrer en oprindelig adresse til et 32-bit heltal, før størrelsen på den næste struktur lægges til. En 64-bit proces kan rumme adresser, der ikke passer. Afhængigt af konverteringen og værdien kan resultatet være en overløbsundtagelse eller en ugyldig adresse. At skifte buildet tilbage til x86 kan skjule fejlen, men efterlader interop-implementeringen afhængig af den omvej.

Hold adresser i pointerstørrelse. For eksempel kan gennemløb af et allerede allokeret array bruge:

IntPtr item = IntPtr.Add(buffer, checked(index * optionSize));

Forskydningen forbliver et heltal; selve adressen bliver ikke presset gennem et. Allokeringens størrelse og indekset skal stadig være gyldige.

Undersøg derefter de omkringliggende deklarationer

WinINets indstillinger pr. forbindelse indeholder en union, hvis medlemmer omfatter en DWORD, en strengpointer og en FILETIME. Pointerfelter kræver IntPtr; DWORD-felter forbliver 32-bit. Indbygget justering betyder noget, så det er ikke en holdbar reparation at erstatte hvert heltal med et 64-bit heltal eller tvinge et pakket layout.

Brug den marshalerede strukturstørrelse, når du går gennem arrayet, match ANSI- eller Unicode-deklarationen konsekvent, og følg hver allokering separat. Frigivelse af blokken med indstillingsstrukturer frigiver ikke automatisk strenge, der er allokeret andre steder og refereret af disse strukturer.

Endelig bør spørgsmålet om indstillingernes omfang holdes adskilt fra hukommelseskorrekthed. Reparation af en cast beviser ikke, at en hjælpers valgte WinINet-indstilling kun påvirker én kontrol, én proces eller den aktuelle brugers indstillinger. Kontroller den API-adfærd, før du overtager resten af et gammelt eksempel. Hvis den også sender opdateringsmeddelelser, vælg dem for det tilsigtede omfang.