De ce un vechi ajutor proxy WinINet se rupe într-o compilare pe 64 de biți

O singură conversie poate transforma un ajutor de setări proxy aparent obișnuit într-o defecțiune dependentă de arhitectură:

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

Acest cod îngustează o adresă nativă la un întreg pe 32 de biți înainte de a adăuga dimensiunea structurii următoare. Un proces pe 64 de biți poate ține adrese care nu încap. În funcție de conversie și valoare, rezultatul poate fi o excepție de depășire sau o adresă invalidă. Revenirea compilării la x86 poate ascunde eroarea, dar lasă implementarea interop dependentă de acel ocol.

Păstrați adresele în forma dimensiunii unui pointer. De exemplu, pentru a parcurge un tablou deja alocat se poate folosi:

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

Deplasarea rămâne un întreg; adresa în sine nu este strânsă printr-unul. Dimensiunea alocării și indexul trebuie să fie în continuare valide.

Apoi examinați declarațiile din jur

Opțiunile WinINet pe conexiune conțin o uniune ale cărei membre includ un DWORD, un pointer la șir și un FILETIME. Câmpurile pointer au nevoie de IntPtr; câmpurile DWORD rămân pe 32 de biți. Alinierea nativă contează, așa că înlocuirea fiecărui întreg cu un întreg pe 64 de biți sau impunerea unei machete ambalate nu este o reparație solidă.

Folosiți dimensiunea structurii după marshaling când parcurgeți tabloul, potriviți consecvent declarația ANSI sau Unicode și urmăriți fiecare alocare separat. Eliberarea blocului de structuri de opțiuni nu eliberează automat șirurile alocate în altă parte și referite de aceste structuri.

În final, păstrați separată problema domeniului setărilor de corectitudinea memoriei. Repararea unei conversii nu dovedește că opțiunea WinINet aleasă afectează doar un singur control, un singur proces sau setările utilizatorului curent. Verificați acel comportament al API-ului înainte de a adopta restul unui exemplu vechi. Dacă trimite și notificări de reîmprospătare, selectați-le pentru domeniul dorit.