ເປັນຫຍັງຕົວຊ່ວຍ WinINet proxy ເກົ່າຈຶ່ງແຕກໃນການສ້າງ 64-ບິດ

ການ cast ຄັ້ງດຽວສາມາດເຮັດໃຫ້ຕົວຊ່ວຍການຕັ້ງຄ່າ proxy ທີ່ເບິ່ງຄືທຳມະດາ ກາຍເປັນຄວາມຜິດພາດທີ່ຂຶ້ນກັບສະຖາປັດຕະຍະກຳ:

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

ໂຄດນັ້ນຫຍໍ້ທີ່ຢູ່ພື້ນເມືອງໃຫ້ເປັນຈຳນວນເຕັມ 32-ບິດ ກ່ອນທີ່ຈະເພີ່ມຂະໜາດຂອງໂຄງສ້າງຕໍ່ໄປ. ຂະບວນການ 64-ບິດສາມາດຖືທີ່ຢູ່ທີ່ບໍ່ພໍດີ. ຂຶ້ນກັບການແປງ ແລະ ຄ່າ, ຜົນອາດເປັນຂໍ້ຍົກເວັ້ນການລົ້ນ ຫຼື ທີ່ຢູ່ທີ່ບໍ່ຖືກຕ້ອງ. ການກັບໄປ x86 ອາດຊ່ອນຄວາມຜິດ, ແຕ່ມັນເຮັດໃຫ້ການຈັດຕັ້ງ interop ຂຶ້ນກັບວິທີແກ້ຊົ່ວຄາວນັ້ນ.

ເກັບທີ່ຢູ່ໃນຮູບແບບຂະໜາດຕົວຊີ້. ຕົວຢ່າງ, ການເດີນຜ່ານອາລີທີ່ຈັດສັນແລ້ວສາມາດໃຊ້:

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

ອອບເຊັດຍັງເປັນຈຳນວນເຕັມ; ທີ່ຢູ່ເອງບໍ່ຖືກບີບຜ່ານມັນ. ຂະໜາດການຈັດສັນ ແລະ ດັດຊະນີຍັງຕ້ອງຖືກຕ້ອງ.

ຈາກນັ້ນກວດສອບການປະກາດອ້ອມຂ້າງ

ຕົວເລືອກ WinINet ຕໍ່ການເຊື່ອມຕໍ່ມີ union ທີ່ສະມາຊິກປະກອບມີ DWORD, ຕົວຊີ້ສະຕຣິງ ແລະ FILETIME. ຊ່ອງຕົວຊີ້ຕ້ອງການ IntPtr; ຊ່ອງ DWORD ຍັງ 32-ບິດ. ການຈັດລຽງແບບພື້ນເມືອງສຳຄັນ, ດັ່ງນັ້ນການປ່ຽນທຸກຈຳນວນເຕັມເປັນຈຳນວນເຕັມ 64-ບິດ ຫຼື ບັງຄັບການຈັດວາງແບບຫຸ້ມ ບໍ່ແມ່ນການແກ້ໄຂທີ່ເໝາະສົມ.

ໃຊ້ຂະໜາດໂຄງສ້າງຫຼັງ marshaling ເມື່ອເດີນຜ່ານອາລີ, ຈັບຄູ່ການປະກາດ ANSI ຫຼື Unicode ຢ່າງສອດຄ້ອງ, ແລະ ຕິດຕາມແຕ່ລະການຈັດສັນແຍກຕ່າງຫາກ. ການປ່ອຍບລັອກໂຄງສ້າງຕົວເລືອກບໍ່ໄດ້ປ່ອຍສະຕຣິງທີ່ຈັດສັນຢູ່ບ່ອນອື່ນ ແລະ ໂຄງສ້າງເຫຼົ່ານັ້ນອ້າງອີງໂດຍອັດຕະໂນມັດ.

ສຸດທ້າຍ, ແຍກຄຳຖາມກ່ຽວກັບຂອບເຂດການຕັ້ງຄ່າອອກຈາກຄວາມຖືກຕ້ອງຂອງຫນ່ວຍຄວາມຈຳ. ການແກ້ cast ບໍ່ໄດ້ພິສູດວ່າຕົວເລືອກ WinINet ທີ່ເລືອກມີຜົນຕໍ່ພຽງແຕ່ການຄວບຄຸມດຽວ, ຂະບວນການດຽວ ຫຼື ການຕັ້ງຄ່າຂອງຜູ້ໃຊ້ປັດຈຸບັນ. ກວດສອບພຶດຕິກຳ API ນັ້ນ ກ່ອນທີ່ຈະຮັບເອົາຕົວຢ່າງເກົ່າທີ່ເຫຼືອ. ຖ້າມັນສົ່ງການແຈ້ງເຕືອນການໂຫຼດຄືນດ້ວຍ, ເລືອກພວກມັນສຳລັບຂອບເຂດທີ່ຕັ້ງໃຈ.