Wêrom't in âlde WinINet-proxyhelper brekt yn in 64-bit-build

Ien cast kin in skynber gewoane proxy-ynstellingshelper feroarje yn in arsjitektuer-ôfhinklike flater:

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

Dy koade ferneaut in native adres nei in 32-bits hiel getal foar't de grutte fan 'e folgjende struktuer tafoege wurdt. In 64-bits proses kin adressen hâlde dy't net passe. Ofhinklik fan 'e konverzje en wearde kin it resultaat in oerfloed-útsûndering of in ûnjildich adres wêze. It weromsetten fan 'e build nei x86 kin de flater ferbergje, mar lit de interop-ymplemintaasje ôfhinklik fan dy omwei.

Hâld adressen yn wizerformaat. Bygelyks, foar it trochrinnen fan in al tawiisd array kin dit brûkt wurde:

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

De offset bliuwt in hiel getal; it adres sels wurdt net troch ien yndrukt. De grutte fan 'e tawizing en de yndeks moatte noch jildich wêze.

Undersykje dan de omlizzende ferklearrings

WinINet syn opsjes per ferbining befetsje in union dêr't de leden in DWORD, in snaarwizer en in FILETIME yn sitte. Wizerfjilden hawwe IntPtr nedich; DWORD-fjilden bliuwe 32-bits. Native rjochtsjen is fan belang, dus elk hiel getal ferfange troch in 64-bits hiel getal of in ynpakt útlizzen ôftwinge is gjin goed repaaraasje.

Brûk de grutte fan 'e struktuer nei marshaljen by it trochrinnen fan 'e array, lis de ANSI- of Unicode-ferklearring konsekwint fêst en folgje elke tawizing apart. It frijjaan fan it blok opsjestruktueren befrijt net automatysk snaren dy't earne oars tawiisd binne en troch dy struktueren ferwiisd wurde.

Ta beslút, hâld de fraach fan ynstellingsberik skieden fan ûnthâldkorrektens. It reparearjen fan in cast bewiist net dat in keazen WinINet-opsje fan in helper allinnich ien bedieningselem, ien proses of de ynstellingen fan 'e hjoeddeiske brûker beynfloedet. Kontrolearje dat API-gedrach foar't jo de rest fan in âld foarbyld oernimme. As it ek ferfarskingsnotifikaasjes stjoert, kies se foar it bedoelde berik.