پرانا WinINet پراکسی مددگار 64-بٹ بلڈ میں کیوں ٹوٹتا ہے
C# پراکسی interop مثالوں میں پوائنٹر کٹوتی کی شناخت کریں اور دوبارہ استعمال سے پہلے ساخت کی ترتیب اور میموری کی ملکیت کا جائزہ لیں۔
ایک کاسٹ بظاہر معمولی پراکسی سیٹنگز مددگار کو آرکیٹیکچر پر منحصر ناکامی میں بدل سکتا ہے:
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 رویے کی جانچ کریں۔ اگر یہ ریفریش اطلاعات بھی بھیجتا ہے تو انہیں مطلوبہ دائرہ کار کے لیے منتخب کریں۔