Hvorfor en gammel WinINet-proxyhjelper knekker i et 64-bit bygg

Én cast kan gjøre en tilsynelatende vanlig hjelper for proxyinnstillinger om til en arkitekturavhengig feil:

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

Den koden snevrer en opprinnelig adresse inn til et 32-bit heltall før størrelsen på neste struktur legges til. En 64-bit prosess kan holde adresser som ikke passer. Avhengig av konverteringen og verdien kan resultatet være et overflytsunntak eller en ugyldig adresse. Å bygge for x86 igjen kan skjule feilen, men gjør interop-implementasjonen avhengig av den omveien.

Hold adresser i pekerstørrelse. For eksempel kan gjennomgang av en allerede allokert matrise bruke:

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

Forskyvningen forblir et heltall; selve adressen presses ikke gjennom ett. Allokeringsstørrelsen og indeksen må fortsatt være gyldige.

Undersøk deretter deklarasjonene rundt

WinINet-innstillingene per tilkobling inneholder en union der medlemmene omfatter en DWORD, en strengpeker og en FILETIME. Pekefelt trenger IntPtr; DWORD-felt forblir 32-bit. Innebygd justering betyr noe, så å erstatte hvert heltall med et 64-bit heltall eller tvinge et pakket layout er ikke en solid reparasjon.

Bruk den marshallede strukturstørrelsen når du går gjennom matrisen, match ANSI- eller Unicode-deklarasjonen konsekvent, og spor hver allokering separat. Frigjøring av blokken med innstillingsstrukturer frigjør ikke automatisk strenger som er allokert andre steder og referert av disse strukturene.

Til slutt, hold spørsmålet om innstillingenes omfang atskilt fra minnekorrekthet. Reparasjon av en cast beviser ikke at en hjelpers valgte WinINet-innstilling bare påvirker én kontroll, én prosess eller den gjeldende brukerens innstillinger. Kontroller den API-atferden før du tar i bruk resten av et gammelt eksempel. Hvis den også sender oppdateringsvarsler, velg dem for det tiltenkte omfanget.