למה עוזר פרוקסי 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 הזו לפני אימוץ שאר הדוגמה הישנה. אם היא גם שולחת התראות רענון, בחרו אותן עבור ההיקף המיועד.