פתרון יצירת קוד וחוזה המכונה

ההוראות עד offset 4 מכינות את המחסנית. ההוראה בoffset 4 מעתיקה את הארגומנט הראשון, ובoffset 6 מתחילה פעולת החשבון. לכן הcontext המדומה מתאר מצב אחרי הprologue ולפני חזרה, והunwinder צריך לבטל הקצאה של 40 bytes ואז לשלוף return address.

השינוי לXOR מחליף את הזוג 0x03,0xc2 בזוג 0x33,0xc2. התוצאה להשוואה היא a ^ b. אורך ההוראות והפעולות במחסנית נשארו זהים, ולכן הטבלה אינה משתנה. עדיין בודקים disassembly במקום לסמוך על המספרים שהוקלדו.

הפרסום לכמה threadים יכול להשתמש באובייקט קוד בלתי משתנה שבעלותו משותפת. מסיימים כתיבה, שינוי הרשאות, flush ורישום unwind לפני פרסום reference עם הסנכרון המתאים. כל קריאה מחזיקה reference לאורך כל הביצוע. החלפה מוציאה את האובייקט הישן ממקור הרכישות החדשות, והפריקה ממתינה גם למנגנוני האבחון שהמערכת מאפשרת במקביל.

הפתרון הזה אינו מתיר לשנות bytes של פונקציה שthread אחר מבצע. כדי להוסיף patching חי צריך פרוטוקול אחר, עם הוכחה לגבי instruction boundaries, cache וביצוע מקביל. במעבדה נעדיף גרסה חדשה באזור חדש, כי כך אפשר להבין את גבול הבעלות.

המעבר לARM64 דורש backend נפרד. את סדר ההוראות ואת metadata הunwind בודקים מול תיעוד Windows לאותה ארכיטקטורה, ואת ההתנהגות מריצים במכונה מתאימה. קומפילציה מוצלחת של מעטפת C++ על host של x64 אינה בדיקה כזאת.