פתרון קישור דינמי וזהות סימבולית

הלקוח המקושר מכיל import שמצהיר מראש על הצורך ב־scale_checked. הלקוח הדינמי מכיל את שם הסמל כמחרוזת, אך פתרון הכתובת נעשה רק כשהקוד מפעיל GetProcAddress. אלה שני חוזי כשל שונים.

החלפת המכפיל משנה התנהגות בלי לשנות ABI. הלקוח הישן עדיין יכול לקרוא לפונקציה, אבל השאלה אם השינוי תואם מבחינת המוצר תלויה בחוזה שהובטח. עצם הצלחת הטעינה אינה אישור לשנות משמעות.

אפשר להוסיף לספרייה את הפונקציה הבאה.

extern "C" __declspec(dllexport)
unsigned __cdecl api_version() noexcept {
    return 1;
}

הלקוח הדינמי פותר קודם את הסמל הזה באמצעות typedef מתאים. אם הוא חסר או מחזיר מספר לא נתמך, הלקוח משחרר את ה־module ומסיים בלי לקרוא ל־scale_checked. בדיקת הגרסה אינה מבטלת צורך בחתימות יציבות עבור פונקציית הגרסה עצמה.

במקרה של שינוי שם export, לקוח בעל import סטטי יכול להיכשל בזמן טעינה לפני main. הלקוח הדינמי יכול לטעון את ה־DLL ואז לקבל null בחיפוש הסמל. צריך לבדוק כל return value, ולא לנסות לקרוא דרך כתובת ריקה.

הסדר של shutdown הוא עצירת יצירת עבודה חדשה, ביטול רישום callbacks לפי חוזה ה־API, המתנה לכך שלא נשאר callback פעיל, שחרור מצב שהספרייה מחזיקה ולבסוף FreeLibrary. אם מערכת הרישום אינה מספקת פעולת drain, צריך לבנות מנגנון חיים מתאים ולא להניח שביטול רישום מסיים קריאה שכבר התחילה.

כשל LoadLibraryExW אינו מוכיח שהקובץ שהעברנו חסר. ייתכן שהוא קיים אך אחת התלויות שלו לא נמצאה. בודקים imports, ארכיטקטורה ונתיבי טעינה בפועל. כלים כמו Process Monitor יכולים להראות ניסיונות פתיחה, אך צריך לשייך את האירועים לאותו תהליך ולאותו ניסיון.

ה־cast ל־typedef אינו מנגנון בדיקה. אם המימוש החדש מחליף פרמטר int* ב־double*, המצביע עדיין יכול להיות לא ריק והקריאה עדיין תהיה שגויה. הפתרון הוא ממשק חדש או הסכם גרסה שמונע את הקריאה.