ทำไมตัวช่วยพร็อกซี WinINet เก่าจึงพังในการบิลด์ 64 บิต

การแคสต์ครั้งเดียวสามารถเปลี่ยนตัวช่วยตั้งค่าพร็อกซีที่ดูธรรมดาให้กลายเป็นความล้มเหลวที่ขึ้นกับสถาปัตยกรรม:

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

โค้ดนั้นบีบที่อยู่เนทีฟให้เป็นจำนวนเต็ม 32 บิตก่อนบวกขนาดของโครงสร้างถัดไป โพรเซส 64 บิตสามารถเก็บที่อยู่ที่ไม่พอดีได้ ขึ้นอยู่กับการแปลงและค่า ผลลัพธ์อาจเป็นข้อยกเว้นโอเวอร์โฟลว์หรือที่อยู่ที่ไม่ถูกต้อง การกลับไปบิลด์เป็น x86 อาจซ่อนข้อผิดพลาดไว้ แต่ทำให้การใช้งาน interop ต้องพึ่งพาวิธีเลี่ยงนั้น

เก็บที่อยู่ในรูปขนาดพอยน์เตอร์ ตัวอย่างเช่น การไล่ผ่านอาร์เรย์ที่จัดสรรไว้แล้วสามารถใช้:

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

ออฟเซตยังคงเป็นจำนวนเต็ม ที่อยู่เองไม่ได้ถูกบีบผ่านมัน ขนาดการจัดสรรและดัชนียังต้องถูกต้อง

จากนั้นตรวจสอบการประกาศโดยรอบ

ตัวเลือก WinINet ต่อการเชื่อมต่อมียูเนียนที่มีสมาชิกเป็น DWORD พอยน์เตอร์สตริง และ FILETIME ฟิลด์พอยน์เตอร์ต้องใช้ IntPtr ฟิลด์ DWORD ยังคงเป็น 32 บิต การจัดแนวแบบเนทีฟมีความสำคัญ ดังนั้นการแทนที่จำนวนเต็มทุกตัวด้วยจำนวนเต็ม 64 บิตหรือบังคับเลย์เอาต์แบบแพ็กจึงไม่ใช่การซ่อมที่ถูกต้อง

ใช้ขนาดโครงสร้างหลัง marshaling เมื่อไล่ผ่านอาร์เรย์ จับคู่การประกาศ ANSI หรือ Unicode อย่างสม่ำเสมอ และติดตามการจัดสรรแต่ละครั้งแยกกัน การคืนบล็อกของโครงสร้างตัวเลือกไม่ได้คืนสตริงที่จัดสรรไว้ที่อื่นและถูกอ้างอิงโดยโครงสร้างเหล่านั้นโดยอัตโนมัติ

สุดท้าย แยกคำถามเรื่องขอบเขตของการตั้งค่าออกจากความถูกต้องของหน่วยความจำ การซ่อมการแคสต์ไม่ได้พิสูจน์ว่าตัวเลือก WinINet ที่ตัวช่วยเลือกมีผลเพียงกับตัวควบคุมเดียว โพรเซสเดียว หรือการตั้งค่าของผู้ใช้ปัจจุบัน ตรวจสอบพฤติกรรม API นั้นก่อนนำตัวอย่างเก่าส่วนที่เหลือมาใช้ หากมันส่งการแจ้งเตือนรีเฟรชด้วย ให้เลือกตามขอบเขตที่ต้องการ