لماذا يتعطل مساعد WinINet القديم للبروكسي في بناء 64-بت

يمكن لتحويل واحد أن يحوّل مساعدًا عاديًا لإعدادات البروكسي إلى عطل يعتمد على المعمارية:

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-بت أو فرض تخطيط مضغوط ليس إصلاحًا سليمًا.

استخدم حجم البنية بعد التمرير عند التجول في المصفوفة، وطابق تصريح ANSI أو Unicode باتساق، وتتبّع كل تخصيص على حدة. فتح كتلة بنى الخيارات لا يحرّر تلقائيًا سلاسل خُصصت في مكان آخر وتشير إليها تلك البنى.

أخيرًا، افصل مسألة نطاق الإعداد عن صحة الذاكرة. إصلاح تحويل لا يثبت أن خيار WinINet الذي اختاره مساعد ما يؤثر فقط على عنصر تحكم واحد أو عملية واحدة أو إعدادات المستخدم الحالي. تحقق من سلوك API ذلك قبل تبني بقية نموذج قديم. وإذا كان يرسل أيضًا إشعارات تحديث، فاخترها للنطاق المقصود.