Mengapa Helper Proxy WinINet Lama Rusak di Build 64-Bit

Satu cast dapat mengubah helper pengaturan proxy yang tampak biasa menjadi kegagalan yang bergantung pada arsitektur:

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

Kode itu menyempitkan alamat native menjadi bilangan bulat 32-bit sebelum menambahkan ukuran struktur berikutnya. Proses 64-bit dapat menampung alamat yang tidak muat. Bergantung pada konversi dan nilainya, hasilnya bisa berupa pengecualian luapan atau alamat yang tidak valid. Mengembalikan build ke x86 dapat menyembunyikan kesalahan, tetapi membuat implementasi interop bergantung pada akal-akalan itu.

Pertahankan alamat dalam bentuk seukuran pointer. Misalnya, untuk menelusuri array yang sudah dialokasikan dapat digunakan:

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

Offset tetap berupa bilangan bulat; alamatnya sendiri tidak diperas melewatinya. Ukuran alokasi dan indeks tetap harus valid.

Lalu periksa deklarasi di sekitarnya

Opsi per koneksi WinINet berisi union yang anggotanya mencakup DWORD, pointer string, dan FILETIME. Bidang pointer membutuhkan IntPtr; bidang DWORD tetap 32-bit. Penyelarasan native penting, jadi mengganti setiap bilangan bulat dengan bilangan bulat 64-bit atau memaksakan tata letak terpaket bukan perbaikan yang sehat.

Gunakan ukuran struktur setelah marshaling saat menelusuri array, cocokkan deklarasi ANSI atau Unicode secara konsisten, dan lacak setiap alokasi secara terpisah. Membebaskan blok struktur opsi tidak otomatis melepaskan string yang dialokasikan di tempat lain dan direferensikan oleh struktur tersebut.

Terakhir, pisahkan pertanyaan cakupan pengaturan dari kebenaran memori. Memperbaiki cast tidak membuktikan bahwa opsi WinINet yang dipilih helper hanya memengaruhi satu kontrol, satu proses, atau pengaturan pengguna saat ini. Periksa perilaku API itu sebelum mengadopsi sisa contoh lama. Jika juga mengirim notifikasi penyegaran, pilih untuk cakupan yang dimaksud.