ความเข้ากันได้ของแอป Windows ทำงานอย่างไร — โหมดความเข้ากันได้ ชิม และ Compatibility Administrator

«แอปธุรกิจอายุสิบปีที่ซอร์สโค้ดหายไปแล้ว ไม่เริ่มบนพีซี Windows 11 เครื่องใหม่ ผมติ๊ก “Windows XP” ที่แท็บความเข้ากันได้ของกล่องโต้ตอบคุณสมบัติ แล้วมันก็ทำงาน — นั่นทำอะไรจริง ๆ จะพึ่งสิ่งนี้ต่อไปได้ไหม» นั่นคือคำปรึกษาที่เราได้ยินบ่อย

เมื่อช่องติ๊กเดียวทำให้อะไรสักอย่างทำงาน ความไม่สบายใจเป็นเรื่องธรรมชาติ ตัวตนจริงของโหมดความเข้ากันได้ที่ดูเหมือนเวทมนตร์ คือชุดชิ้นโค้ดเล็ก ๆ ที่เรียกว่า ชิม ซึ่งนั่งระหว่างแอปกับ Windows API แล้วคืน «คำโกหก» Windows เองใช้ทางแก้ชั่วคราวนี้ในวงกว้างเพื่อให้แอปหลายรุ่นยังวิ่ง และเปิดกลไกบางส่วนให้ผู้ใช้กับผู้ดูแลระบบ

ใช้โดยไม่เข้าใจกลไก การยืดอายุกลายเป็น «ห้ามแตะเพราะไม่รู้ว่าทำไมมันวิ่ง» ที่ไม่เสถียร เข้าใจกลไกแล้วคุณจะตัดสินได้ด้วยเหตุผลว่า พึ่งได้อย่างปลอดภัยแค่ไหน อะไรจะทำให้พัง และเมื่อไรควรเขียนใหม่

flowchart TB
    accTitle: การเข้าใจกลไกเปลี่ยนคุณภาพของการยืดอายุ
    accDescr: ใช้โหมดความเข้ากันได้โดยไม่เข้าใจกลไกจะนำไปสู่การยืดอายุที่ไม่เสถียรและไม่กล้าแตะ เข้าใจกลไกแล้วจึงตัดสินด้วยเหตุผลว่าพึ่งได้แค่ไหน อะไรจะทำให้พัง และเมื่อไรควรเขียนใหม่
    unknown["ใช้โดยไม่เข้าใจกลไก"] --> fear["ยืดอายุไม่เสถียร ไม่กล้าแตะ"]
    known["ใช้หลังเข้าใจกลไก"] --> judge["การตัดสินที่มีเหตุผล"]
    judge -.-> j1["พึ่งได้แค่ไหน"]
    judge -.-> j2["อะไรจะทำให้พัง"]
    judge -.-> j3["เมื่อไรควรเขียนใหม่"]

ภาพ 1: แม้เป็นการยืดอายุเดียวกัน คุณภาพต่างกันระหว่างความกังวลเพราะไม่รู้กลไกกับการตัดสินบนความเข้าใจ

มุ่งที่เจ้าหน้าที่ไอทีของธุรกิจขนาดกลางและเล็ก และนักพัฒนาแอป Windows ที่ดูแลแอปธุรกิจเก่า บทความนี้จัดจากแหล่งปฐมภูมิ Microsoft Learn กลไกชิมซึ่งเป็นตัวตนจริงของโหมดความเข้ากันได้ สิ่งที่ชิมตัวแทนทำได้ วิธีใส่ในองค์กรด้วย Compatibility Administrator ขีดจำกัดที่ชิมช่วยไม่ได้ และการตัดสินระหว่างยืดอายุกับย้ายระบบ

1. สรุปก่อน

• ตัวตนจริงของโหมดความเข้ากันได้คือชิม (ชั้นความเข้ากันได้) การตั้งค่าจากแท็บความเข้ากันได้ถูกเขียนไปที่ HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers และมัดชิมถูกใส่ให้โพรเซสตอนเริ่ม¹²
• ชิมคือฮุก API ในโหมดผู้ใช้ที่เขียนตารางที่อยู่นำเข้า (IAT) ใหม่ มันดักเส้นทางที่แอปเรียก Windows API แล้วคืนคำตอบเดียวกับที่ Windows เก่าเคยให้ ไม่ได้เปลี่ยนตัว OS³
• สิ่งที่ชิมทำได้มีขอบเขตเดียวกับสิ่งที่การแก้โค้ดในแอปทำได้ มันเลี่ยงกลไกความปลอดภัยไม่ได้ และแก้ปัญหาโหมดเคอร์เนล (ไดรเวอร์อุปกรณ์) ไม่ได้³
• Microsoft ส่งชิมสำเร็จรูปจำนวนมาก — โกหกเวอร์ชัน แมปพาธไฟล์ใหม่ ปลอมรีจิสทรี ปลอมการตรวจผู้ดูแล และอื่น ๆ คุณใส่ให้ EXE แต่ละตัวจาก Compatibility Administrator ได้⁴
• Windows เองใช้ชิมเป็นค่าเริ่มต้น ฐานข้อมูลความเข้ากันได้มาตรฐานของ OS (.sdb) ถูกจับคู่ทุกครั้งที่เปิด และ PCA (Program Compatibility Assistant) อาจตรวจปัญหาแล้วใส่การตั้งค่าความเข้ากันได้อัตโนมัติ¹⁵
• «ตอบราวกับว่าเป็น Windows ที่เก่ากว่า» ตอนนี้เป็นค่าเริ่มต้น ตั้งแต่ Windows 8.1 GetVersionEx ไม่คืนเวอร์ชัน OS ที่แอปไม่ได้ประกาศในแมนิเฟสต์ โหมดความเข้ากันได้คือส่วนขยายของกลไกนั้น⁶⁷
• ชิมใช้ไม่ได้กับแอป 16 บิต การพึ่งไดรเวอร์เคอร์เนล หรือการเข้าถึงฮาร์ดแวร์โดยตรง โดยเฉพาะแอป 16 บิตรันบน Windows 64 บิตไม่ได้เลย⁸
• สำหรับแอปที่ «ขอผู้ดูแลแต่จริง ๆ ไม่ต้องการ» RunAsInvoker คือท่ามาตรฐาน __COMPAT_LAYER=RunAsInvoker กดคำขอสิทธิ์สูงแล้วให้แอปวิ่งใต้สิทธิ์มาตรฐาน⁹
• วิ่งใต้ชิมแปลว่ายืดอายุได้ตอนนี้ แต่ทางจริงคือ «ทำให้วิ่งโดยไม่มีชิม» ถ้าตัดสินใจยืดอายุ จดว่าชิมใดทำให้วิ่ง และจัดการเป็นวัสดุตัดสินใจเขียนใหม่

2. ภาพรวมความเข้ากันได้ของแอป — ชั้นความเข้ากันได้ย้อนหลังที่ Windows มีอยู่แล้ว

ก่อนพูดถึงชิม นี่คือรายการกลไกที่ Windows มีอยู่แล้วสำหรับแอปเก่า แม้คนจะพูดว่า «เริ่มทำงานในโหมดความเข้ากันได้» สิ่งที่จริง ๆ ช่วยแอปคือชั้นใดชั้นหนึ่งเหล่านี้ หรือหลายชั้นรวมกัน

การจำลอง UAC เป็นมาตรการชั่วคราวสำหรับโพรเซสโต้ตอบ 32 บิตที่ไม่มีแมนิเฟสต์ และ Microsoft เองระบุว่าเป็น «เทคโนโลยีชั่วคราวที่เราตั้งใจจะถอดจาก Windows รุ่นอนาคต»¹⁰ ความเสียหายจริงจากการเปลี่ยนเส้นทาง Wow6432Node และ VirtualStore รวมถึงวิธีรับมือ อธิบายละเอียดใน «Registry 32-bit/64-bit Redirection and Virtualization Pitfalls» บทความนี้วางชิมเป็นศูนย์กลางและกล่าวถึงชั้นอื่นเท่าที่จำเป็น

flowchart TB
    accTitle: ตำแหน่งของการจำลอง UAC
    accDescr: การจำลอง UAC เป็นมาตรการชั่วคราวสำหรับโพรเซสโต้ตอบ 32 บิตที่ไม่มีแมนิเฟสต์ มันเปลี่ยนเส้นทางการเขียนไปยัง VirtualStore ต่อผู้ใช้ แต่ Microsoft เองระบุว่าเป็นเทคโนโลยีชั่วคราวที่ตั้งใจจะถอดจาก Windows ในอนาคต
    proc["โพรเซสโต้ตอบ 32 บิตที่ไม่มีแมนิเฟสต์"] --> uacv["การจำลอง UAC ถูกใส่"]
    uacv --> vs["ถูกเปลี่ยนเส้นทางไปยัง VirtualStore ต่อผู้ใช้"]
    uacv -.-> tmp["เทคโนโลยีชั่วคราวที่ตั้งใจจะถอดภายหลัง"]

ภาพ 2: การจำลอง UAC เป็นมาตรการชั่วคราวสำหรับโพรเซส 32 บิตที่ไม่มีแมนิเฟสต์ และพึ่งถาวรไม่ได้

หมายเหตุข้างเรื่องการจำลอง DPI แอปที่ไม่ได้ประกาศการรับรู้ DPI ถูกถือว่าวาดที่ 96 DPI (100%) และ Windows ยืดบิตแมปเพื่อแสดง นั่นคือเหตุที่แอปเก่าดู «เบลอ» บนจอ DPI สูง และ «แทนที่พฤติกรรมการปรับสเกล DPI สูง» ของแท็บความเข้ากันได้คือสวิตช์ที่เปลี่ยนพฤติกรรมการจำลองนี้¹¹

flowchart TB
    accTitle: การจำลอง DPI ทำงานอย่างไร
    accDescr: แอปที่ไม่ได้ประกาศการรับรู้ DPI ถูกถือว่าวาดที่ 96 DPI Windows ยืดบิตแมปจึงดูเบลอ และการแทนที่การตั้งค่า DPI สูงของแท็บความเข้ากันได้สลับพฤติกรรมการจำลองนี้
    app["แอปที่ไม่ประกาศการรับรู้ DPI"] --> treat["ถูกถือว่าวาดที่ 96 DPI"]
    treat --> stretch["บิตแมปถูกยืดเพื่อแสดง"]
    stretch --> blur["ดูเบลอบนจอ DPI สูง"]
    tab["แทนที่พฤติกรรมการปรับสเกล DPI สูง"] -.->|สลับพฤติกรรมการจำลอง| treat

ภาพ 3: แอปที่ไม่รู้ DPI ถูกถือเป็น 96 DPI และถูกยืด การแทนที่บนแท็บความเข้ากันได้คือสวิตช์ของการจำลองนี้

3. ชิมคืออะไรจริง ๆ — ดักระหว่าง API โดยเขียน IAT ใหม่

3.1. «ล่าม» ที่ยืนระหว่างแอปกับ OS

ไฟล์ปฏิบัติการ Windows (รูปแบบ PE) เรียก API ใน DLL ภายนอกผ่าน ตารางที่อยู่นำเข้า (IAT) เมื่อแอปเรียก GetVersionEx มันแค่กระโดดไปที่อยู่ที่เขียนใน IAT กลไกชิมใช้จุดนั้น ตอนโหลดมันเขียนรายการ IAT ของ API เป้าหมายไปที่อยู่ของโค้ดชิม แล้วแทรกตัวเองระหว่างแอปกับ Windows API ที่ได้แบบไดนามิกผ่าน GetProcAddress จัดการโดยฮุก GetProcAddress เอง³

เมื่อดักแล้ว ชิมอาจคืนหมายเลขเวอร์ชันเก่าให้ «เวอร์ชัน OS ปัจจุบันคืออะไร» หรือแมปการเข้าถึงไฟล์ไปยังตำแหน่งที่เขียนไม่ได้ไปที่อื่น แล้วเรียก API จริงถ้าจำเป็น จากมุมแอปดูเหมือน «วิ่งบน Windows เก่า» จากมุม OS ดูเหมือน «แอปที่ประพฤติดีกำลังวิ่ง» — ชิมคือล่ามระหว่างทั้งสอง

flowchart TB
    accTitle: เส้นทางที่ชิมดักการเรียก API
    accDescr: การเรียก API ของแอปผ่าน IAT การเขียนรายการ IAT ไปยังชิมตอนโหลดให้ชิมดัก ปลอมคำตอบเดียวกับที่ Windows เก่าเคยให้ แล้วเรียก API จริงถ้าจำเป็น
    app["แอป"] -->|การเรียก API| iat["รายการ IAT"]
    iat -->|เขียนใหม่ไปยังชิมตอนโหลด| shim["ชิม (ล่าม)"]
    shim -->|ถ้าจำเป็น| api["Windows API จริง"]
    shim -.-> lie["ปลอมคำตอบเดียวกับที่ Windows เก่าเคยให้"]
    gpa["เรียกผ่าน GetProcAddress"] -.->|จัดการด้วยฮุก| shim

ภาพ 4: ชิมดักระหว่างแอปกับ Windows API สิ่งที่ถูกเขียนใหม่คือ IAT ฝั่งแอป ตัว OS ไม่เปลี่ยน

คุณสมบัติสำคัญสามอย่างตามมาจากออกแบบนี้³

1. ชิมรันเป็นโค้ดฝั่งแอป ไม่ใช่ส่วนของ OS จึงอยู่ภายใต้ข้อจำกัดความปลอดภัยเดียวกับแอป ชิมเลี่ยงกลไกความปลอดภัยของ OS ไม่ได้ และไม่ต้องคลายการตั้งค่าความปลอดภัยเพื่อใช้ชิม
2. สิ่งที่ชิมแก้ได้ การแก้โค้ดฝั่งแอปก็แก้ได้ ชิมเป็นตัวแทนกรณี «ไม่มีซอร์ส / แก้ไม่ได้» ไม่ได้ทรงพลังกว่าการแก้โค้ด
3. โหมดผู้ใช้เท่านั้น ปัญหาความเข้ากันได้ของไดรเวอร์อุปกรณ์ที่รันในโหมดเคอร์เนล ชิมแก้ไม่ได้

3.2. ฐานข้อมูลชิม (.sdb) และการจับคู่

ตารางคู่ «จะใส่ชิมใดให้ EXE ใด» คือ ฐานข้อมูลชิม ไฟล์ไบนารีสกุล .sdb ไฟล์ปฏิบัติการแอปเป้าหมายถูกลงทะเบียนในฐานด้วยแอตทริบิวต์อย่างชื่อไฟล์ ขนาด เช็กซัม และเวอร์ชัน (แอตทริบิวต์จับคู่) และถูกจับคู่ตอนโพรเซสเริ่ม ทางแก้รวม Appfix (ชิม) ซึ่งฉีดฮุก API และ Apphelp ซึ่งแสดงข้อความ «แอปนี้มีปัญหาความเข้ากันได้» มัดชิมและแฟล็กหลายตัวคือ ชั้นความเข้ากันได้ (โหมดความเข้ากันได้)¹

พลาดง่าย การจับคู่นี้ไม่ใช่แค่แอปที่ตั้งโหมดความเข้ากันได้ แต่ ทุกครั้งที่โพรเซสเปิด Windows ส่งฐานมาตรฐานของ OS ที่มีการแก้สำหรับแอปที่รู้จักนับพัน (ไฟล์อยู่ใต้ %WINDIR%\AppPatch) และบนพีซีของคุณวันนี้เกือบแน่มีแอปเก่าเริ่มพร้อมชิมติดโดยไม่มีใครสังเกต การแก้ความเข้ากันได้ที่ Microsoft ให้มาถูกส่งเป็นส่วนหนึ่งของ Windows และอัปเดตผ่าน Windows Update³

flowchart TB
    accTitle: การจับคู่ฐานข้อมูลชิมตอนโพรเซสเริ่ม
    accDescr: ทุกครั้งที่โพรเซสเปิดจะถูกจับคู่กับฐานข้อมูลชิม ถ้าการลงทะเบียนตรงกับแอตทริบิวต์จับคู่ Appfix จะฉีดชิมหรือ Apphelp จะแสดงข้อความ มิฉะนั้นโพรเซสเริ่มตามเดิม
    start["โพรเซสเริ่ม"] --> db["จับคู่กับ .sdb"]
    db -.-> attr["ชื่อไฟล์ ขนาด ฯลฯ"]
    db --> hit{"มีการลงทะเบียน?"}
    hit -->|ใช่| appfix["Appfix: ฉีดชิม"]
    hit -->|ใช่| apphelp["Apphelp: ข้อความ"]
    hit -->|ไม่| plain["เริ่มตามเดิม"]
    layer["ชั้นความเข้ากันได้"] -.->|มัดชิมและแฟล็ก| appfix

ภาพ 5: การจับคู่รันทุกครั้งที่โพรเซสเปิด ไม่ใช่แค่แอปที่ตั้งโหมดความเข้ากันได้

3.3. PCA — กลไกที่ใส่ชิมอัตโนมัติ

อีกเส้นทางที่ชิมอาจถูกใส่โดยที่ผู้ดูแลไม่ได้ตั้งใจคือ PCA (Program Compatibility Assistant) PCA เฝ้าการทำงานของแอป และเมื่อตรวจสัญญาณปัญหาความเข้ากันได้ที่รู้จัก จะเสนอให้ผู้ใช้ใส่การแก้ หรือในบางกรณีใส่การตั้งค่าความเข้ากันได้อัตโนมัติ เช่น แอปที่แครชเพราะเรียกโค้ดใน DLL ที่ปล่อยแล้วถูกกำหนด PINDLL และแอปที่เขียนไฟล์ Windows ที่ถูกป้องกันไม่สำเร็จถูกกำหนด WRPMITIGATION⁵

flowchart TB
    accTitle: วิธีที่ PCA ใส่การตั้งค่าความเข้ากันได้อัตโนมัติ
    accDescr: PCA เฝ้าการทำงานของแอป และเมื่อตรวจสัญญาณปัญหาความเข้ากันได้ที่รู้จัก จะเสนอให้ผู้ใช้ใส่การแก้ หรือในบางกรณีใส่การตั้งค่าความเข้ากันได้อัตโนมัติ
    run["การทำงานของแอป"] --> pca["PCA เฝ้า"]
    pca --> sign{"สัญญาณปัญหาที่รู้จัก?"}
    sign -->|ใช่| resp{"กรณีใด?"}
    resp -->|จัดการด้วยข้อเสนอ| suggest["เสนอให้ใส่การแก้"]
    resp -->|บางกรณี| auto["ใส่การตั้งค่าความเข้ากันได้อัตโนมัติ"]
    sign -->|ไม่| none["รันตามเดิม"]
    auto -.-> ex["ตัวอย่าง: PINDLL หรือ WRPMITIGATION"]

ภาพ 6: PCA เฝ้าการทำงานของแอป และเมื่อตรวจสัญญาณปัญหาที่รู้จัก จะเสนอการแก้หรือใส่อัตโนมัติ

ตัวตนของ «ฉันไม่เคยตั้งอะไร แต่ถึงจุดหนึ่งช่องติ๊กโหมดความเข้ากันได้เปิดอยู่» ในหลายกรณีคือสิ่งนี้ ไม่ใช่ความผิดพลาดหรือคลิกพลาด Windows ประพฤติตามออกแบบ

4. สิ่งที่ชิมตัวแทนทำได้

จากชิมสำเร็จรูปที่ Microsoft เผยแพร่ นี่คือชุดที่จริง ๆ เจอบ่อยเมื่อยืดอายุแอปธุรกิจ⁴

ดูรายการแล้ว ชิมส่วนใหญ่คือ «คำโกหกที่คืนคำตอบที่แอปเก่าคาดหวัง» ดิสก์อย่างมาก 2GB OS คือ XP คุณคือผู้ดูแล — พวกมันสร้างโลกทัศน์ยุคที่แอปเกิด ภายในโพรเซสนั้นเท่านั้น

การปลอมเวอร์ชันกลายเป็น «พฤติกรรมเริ่มต้นอย่างเป็นทางการ»

การปลอมเวอร์ชันไม่ใช่แฮกพิเศษ ตั้งแต่ Windows 8.1 ค่าที่ GetVersionEx คืนขึ้นกับแมนิเฟสต์ของแอป แอปที่ไม่มีประกาศ <supportedOS> ในส่วน <compatibility> ของแมนิเฟสต์ได้รับเทียบเท่า Windows 8 (6.2) เสมอ ไม่ว่า OS จริงจะเป็นอะไร เมื่อมีประกาศ ค่าจนถึง OS สูงสุดในบรรดาที่ประกาศ จะถูกคืน (เช่น ถ้าประกาศถึง GUID ของ Windows 8.1 คุณได้ 6.3 แม้บน Windows 11)⁶⁷

ดังนั้น «เวอร์ชัน Windows ที่แอปเห็น» ถูกตัดสินในขั้นที่ซ้อนกันเหล่านี้

1. ค่าจนถึง OS ที่ประกาศในแมนิเฟสต์ถูกคืน (6.2 ถ้าไม่มีประกาศ)
2. ถ้าโหมดความเข้ากันได้ (ชิมตระกูล VersionLie) ถูกใส่ เวอร์ชันของ OS ที่เลือกจะถูกคืน⁶

flowchart TB
    accTitle: วิธีตัดสินเวอร์ชัน OS ที่แอปเห็น
    accDescr: ค่าที่ GetVersionEx คืนถูกตัดสินด้วยว่ามีประกาศ supportedOS ในแมนิเฟสต์หรือไม่ ไม่มีประกาศจะคืนเทียบเท่า Windows 8 6.2 มีประกาศจะคืนค่าจนถึง OS สูงสุดที่ประกาศ และถ้าชิมตระกูล VersionLie ถูกใส่ จะถูกทับด้วยเวอร์ชัน OS ที่เลือก
    q["การถาม GetVersionEx"] --> m{"มีประกาศ supportedOS?"}
    m -->|ไม่| v62["คืนเทียบเท่า Windows 8 (6.2)"]
    m -->|ใช่| decl["ค่าจนถึง OS สูงสุดที่ประกาศ"]
    v62 --> lie{"ชิมตระกูล VersionLie ถูกใส่?"}
    decl --> lie
    lie -->|ใช่| fake["ค่า OS ที่เลือกในโหมดความเข้ากันได้"]
    lie -->|ไม่| asis["ค่าถูกคืนตามเดิม"]

ภาพ 7: เวอร์ชัน Windows ที่แอปเห็นถูกตัดสินเป็นขั้นซ้อนโดยแมนิเฟสต์และโดยชิม

ถ้าแอปในบ้าน «แยกตามเวอร์ชัน OS แล้วถูกตัดสินเป็น 8 ทั้งที่เป็น Windows 11» ให้สงสัยประกาศ supportedOS ในแมนิเฟสต์ก่อน พูดกลับกัน แอปเก่าที่ปฏิเสธเริ่มเพราะตรวจเวอร์ชัน มีโอกาสสูงที่จะผ่านด้วยชิม VersionLie ในหลายกรณีมันดูแค่หมายเลขเวอร์ชัน และพฤติกรรมจริงบน OS ใหม่กว่าก็ใช้ได้

flowchart TB
    accTitle: สองอาการจากเวอร์ชันและวิธีรับมือ
    accDescr: ถ้าแอปในบ้านถูกตัดสินเป็น 8 ทั้งที่เป็น Windows 11 ให้สงสัยประกาศ supportedOS ในแมนิเฟสต์ แอปเก่าที่ปฏิเสธเริ่มเพราะตรวจเวอร์ชัน มีโอกาสสูงที่จะผ่านด้วยชิม VersionLie
    sym1["ถูกตัดสินเป็น 8 ทั้งที่เป็น Windows 11"] --> fix1["สงสัยประกาศ supportedOS"]
    sym2["ปฏิเสธเริ่มเพราะตรวจเวอร์ชัน"] --> fix2["ลองผ่านด้วย VersionLie"]
    fix2 -.-> why["พฤติกรรมจริงบน OS ใหม่กว่ามักใช้ได้"]

ภาพ 8: เมื่อการตัดสินเก่า ให้สงสัยแมนิเฟสต์ เมื่อปฏิเสธเริ่ม ให้สงสัย VersionLie

5. ช่องติ๊กโหมดความเข้ากันได้ทำอะไร

การตั้งค่าจากคุณสมบัติ → แท็บความเข้ากันได้ถูกเก็บในคีย์รีจิสทรี AppCompatFlags\Layers การตั้งค่าความเข้ากันได้ของแอป DXGI และคล้ายกันใช้คีย์เดียวกันเป็นที่ระบุชั้นความเข้ากันได้² มาดูจริง

reg query "HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers"

สำหรับ EXE ที่คุณตั้ง «Windows XP (Service Pack 3)» «รันโปรแกรมนี้ในฐานะผู้ดูแลระบบ» และ «แทนที่พฤติกรรมการปรับสเกล DPI สูง» ที่แท็บความเข้ากันได้ คุณจะเห็นค่าประมาณดังนี้

HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers
    C:\LegacyApp\Gyomu.exe    REG_SZ    ~ WINXPSP3 RUNASADMIN HIGHDPIAWARE

คู่แทนระหว่างรายการช่องติ๊กกับค่า (ยืนยันบน Windows 11 ชื่อรายการและค่าอาจเปลี่ยนตามเวอร์ชัน OS)

สามจุดที่ต้องจำ

• «รันโปรแกรมนี้ในฐานะผู้ดูแลระบบ» ถูกเขียนที่เดียวกัน โหมดความเข้ากันได้กับแฟล็กสิทธิ์สูงอยู่ด้วยกันในคีย์ Layers เดียวกัน และนั่นคือที่มาของความสับสน «ตั้งโหมดความเข้ากันได้แล้วสิทธิ์สูงตามมา / หายไป» การดูค่าตรง ๆ แยกทั้งสองออก
• สิ่งที่เขียนใน HKCU คือ «การตั้งค่าของผู้ใช้นั้น» ถ้าตั้งจาก «เปลี่ยนการตั้งค่าสำหรับผู้ใช้ทั้งหมด» ของแท็บ จะถูกเขียนไปคีย์ชื่อเดียวกันฝั่ง HKLM และใช้กับผู้ใช้ทั้งหมด เมื่อแจกใน imaging ให้รู้ว่าเขียนฝั่งใด
• ช่องติ๊กเป็นเพียงทางเข้าชั้นสำเร็จรูป แท็บให้เลือกได้แค่ชั้นตัวแทน คุณเลือกชิมทีละตัวแล้วรวมไม่ได้ นั่นคือสิ่งที่ Compatibility Administrator ในบทถัดไปทำ

flowchart TB
    accTitle: เส้นทางจากการตั้งค่าแท็บความเข้ากันได้จนมีผล
    accDescr: การตั้งค่าแท็บความเข้ากันได้ถูกเก็บเป็นพาธ EXE และค่าในคีย์ AppCompatFlags Layers ครั้งถัดไปที่ EXE นั้นเริ่ม ตัวโหลดอ่านค่าแล้วใส่ชั้นความเข้ากันได้ที่ตรงกันให้โพรเซส
    tab["ตั้งที่แท็บความเข้ากันได้"] --> reg["เก็บพาธ EXE และค่าในคีย์ Layers"]
    reg --> boot["การเริ่ม EXE ครั้งถัดไป"]
    boot --> loader["ตัวโหลดอ่านค่า"]
    loader --> apply["ใส่ชั้นความเข้ากันได้ให้โพรเซส"]
    reg -.-> hkcu["HKCU เฉพาะผู้ใช้นั้น"]
    reg -.-> hklm["HKLM ใช้กับผู้ใช้ทั้งหมด"]

ภาพ 9: ช่องติ๊กในความเป็นจริงคือการเขียนคีย์ Layers และการใส่เกิดตอนเริ่มครั้งถัดไป

6. Compatibility Administrator ในทางปฏิบัติ — สร้างและแจก .sdb ที่กำหนดเอง

6.1. วิธีได้มา และข้อควรระวัง

Compatibility Administrator เป็นเครื่องมือใน Windows ADK (Windows Assessment and Deployment Kit)¹² หลังติดตั้งมีทั้งรุ่น 32 บิตและ 64 บิต และ คุณต้องใช้รุ่น 32 บิตกับแอป 32 บิต และรุ่น 64 บิตกับแอป 64 บิต¹³

มีข้อควรระวังสำคัญอีกข้อ ถ้าเริ่ม Compatibility Administrator ในสถานะยกสิทธิ์ (ในฐานะผู้ดูแล) แล้วทดสอบ การจำลอง UAC และการเปลี่ยนเส้นทางจะไม่ประพฤติเหมือนผู้ใช้จริง และคุณอาจตัดสินผิดว่า «แก้แล้ว» ยืนยันผลของการแก้ด้วยบัญชีและสิทธิ์เดียวกับผู้ใช้จริงเสมอ⁴

flowchart TB
    accTitle: สองข้อควรระวังเมื่อใช้ Compatibility Administrator
    accDescr: ใช้รุ่น 32 บิตกับแอป 32 บิต และรุ่น 64 บิตกับแอป 64 บิต และยืนยันผลของการแก้ด้วยบัญชีและสิทธิ์เดียวกับผู้ใช้จริง ไม่ใช่ในสถานะยกสิทธิ์
    app32["แอป 32 บิต"] --> tool32["ใช้รุ่น 32 บิต"]
    app64["แอป 64 บิต"] --> tool64["ใช้รุ่น 64 บิต"]
    elev["ทดสอบในสถานะยกสิทธิ์"] -.-> wrong["อาจตัดสินการแก้ผิด"]
    user["ทดสอบด้วยสิทธิ์เดียวกับผู้ใช้จริง"] --> ok["ยืนยันผล"]

ภาพ 10: การเลือกรุ่น 32 หรือ 64 บิต และการยืนยันด้วยสิทธิ์เดียวกับผู้ใช้จริง คือข้อควรระวังที่ทางเข้า

6.2. ขั้นตอนสร้างฐานข้อมูลความเข้ากันได้ที่กำหนดเอง

โครงดังนี้¹⁴

1. ในบานซ้ายของ Compatibility Administrator สร้างฐานใหม่ใต้ «Custom Databases» แล้วเลือก «Create New» → «Application Fix»
2. ใส่ชื่อแอปและชื่อผู้ขาย แล้วระบุไฟล์ EXE เป้าหมาย
3. เลือกโหมดความเข้ากันได้ (ชั้น) ที่จะใส่ — ลองมัดอย่าง «ความเข้ากันได้ Windows XP» ก่อนเป็นทางสั้น
4. ถ้าจำเป็น เพิ่มการแก้ความเข้ากันได้ทีละตัว (ชิม) — คุณจำกัดเหลือชุดน้อยสุดอย่างแค่ VersionLie หรือแค่ CorrectFilePaths ได้
5. ยืนยันเงื่อนไขจับคู่ (ขนาดไฟล์ เช็กซัม เวอร์ชัน และอื่น ๆ) แล้วบันทึก

เงื่อนไขจับคู่คือกุญแจของ «ใส่สิ่งนี้เฉพาะ EXE นี้» เงื่อนไขพื้นฐานเริ่มต้นมักพอ แต่เราแนะนำให้ เหลือเงื่อนไขที่ระบุเวอร์ชันแอปได้ นั่นกันอุบัติเหตุคำโกหกเก่าถูกใส่กับเวอร์ชันใหม่ต่อไปเมื่อผู้ขายส่งรุ่นที่แก้แล้วในภายหลัง¹⁴¹⁵

flowchart TB
    accTitle: ขั้นตอนสร้างฐานข้อมูลความเข้ากันได้ที่กำหนดเอง
    accDescr: สร้าง Application Fix ในฐานใหม่ ระบุชื่อแอปและ EXE เป้าหมาย ลองมัดโหมดความเข้ากันได้ก่อน แล้วจำกัดเหลือชิมทีละตัวถ้าจำเป็น ยืนยันเงื่อนไขจับคู่แล้วบันทึก
    new["สร้างฐานใหม่"] --> fix["เลือก Application Fix"]
    fix --> info["ระบุชื่อแอปและ EXE เป้าหมาย"]
    info --> layer["ลองมัดโหมดความเข้ากันได้"]
    layer --> single["ถ้าจำเป็น จำกัดเหลือชิมทีละตัว"]
    single --> match["ยืนยันเงื่อนไขจับคู่แล้วบันทึก"]
    match -.-> ver["เหลือเงื่อนไขที่ระบุเวอร์ชัน"]

ภาพ 11: สำหรับ Application Fix ลองมัดโหมดความเข้ากันได้ก่อน จำกัดเหลือชุดน้อยสุด และจำกัดเป้าหมายด้วยเงื่อนไขจับคู่

ทดสอบ .sdb ที่สร้างบนเครื่องตรวจสอบก่อน เมื่อทำงานตามที่ตั้งใจ จึงกระจายสู่องค์กร

6.3. แจกด้วย sdbinst

คำสั่งที่ใส่ .sdb ที่กำหนดเองให้แต่ละพีซีคือ sdbinst.exe (ต้องมีสิทธิ์ผู้ดูแล)¹⁵

:: Install (-q is silent with no confirmation)
sdbinst -q "C:\Deploy\MyCorpFixes.sdb"

:: Uninstall (by file)
sdbinst -q -u "C:\Deploy\MyCorpFixes.sdb"

:: Uninstall (by database GUID)
sdbinst -q -u -g {database GUID}

ในฐานะกลยุทธ์การกระจายองค์กร Microsoft แนะนำให้ รวมเป็นฐานที่กำหนดเองหนึ่งชุดทั้งบริษัท (หรือต่อแผนก) แล้วจัดการจากศูนย์กลาง แทนการส่ง .sdb แยกกับตัวติดตั้งของแต่ละแอป ยิ่งมีการแก้มาก ยิ่งอัปเดตและแจกฐานเดียวง่ายกว่าแจกฐานบรรทัดเดียวจำนวนมาก ฐานที่กำหนดเองมี GUID ของตัวเอง และ การติดตั้งเวอร์ชันใหม่ด้วย GUID เดียวกันจะแทนเวอร์ชันเก่าอัตโนมัติ ดังนั้นงานอัปเดตก็เรียบง่าย วางการแจกเองบนเส้นทางที่มีอยู่ที่รันด้วยสิทธิ์ผู้ดูแลได้ เช่น แพ็กเป็น MSI หรือสคริปต์เริ่มต้น¹⁵

flowchart TB
    accTitle: เส้นทางจากการสร้าง .sdb ที่กำหนดเองจนถึงการแจก
    accDescr: สร้างฐานข้อมูลความเข้ากันได้ที่กำหนดเองใน Compatibility Administrator ทดสอบบนเครื่องตรวจสอบ ใส่ให้แต่ละพีซีด้วย sdbinst และตอนอัปเดตติดตั้งเวอร์ชันใหม่ด้วย GUID เดียวกันเพื่อให้เวอร์ชันเก่าถูกแทนอัตโนมัติ
    make["สร้างใน Compatibility Administrator"] --> test["ทดสอบบนเครื่องตรวจสอบ"]
    test --> deploy["ใส่ให้แต่ละพีซีด้วย sdbinst"]
    deploy --> update["ติดตั้งเวอร์ชันใหม่ด้วย GUID เดียวกัน"]
    update -.-> replace["เวอร์ชันเก่าถูกแทนอัตโนมัติ"]
    deploy -.-> inv["ลงทะเบียนใน Programs and Features"]

ภาพ 12: .sdb ที่กำหนดเองถูกกระจายผ่านสร้าง ตรวจ และแจกด้วย sdbinst และการอัปเดตจัดการด้วย GUID

ฐานที่กำหนดเองที่ติดตั้งแล้วถูกลงทะเบียนเป็นรายการใน «Programs and Features (แอปที่ติดตั้ง)» ดังนั้นคุณยืนยันสินค้าคงคลังและการถอดจากที่นั่นได้ พีซีใดมี .sdb ใดเป็นข้อมูลที่อยู่ในบัญชีจัดการสินทรัพย์

7. กรณีที่ใช้ไม่ได้ และขีดจำกัด

ชิมไม่ใช่กระสุนเงิน ตามออกแบบ พวกมันใช้ไม่ได้ในกรณีต่อไปนี้

• ปัญหาโหมดเคอร์เนล ชิมรันในโพรเซสโหมดผู้ใช้ จึงแก้ความไม่เข้ากันของไดรเวอร์อุปกรณ์ไม่ได้ ถ้าไดรเวอร์ของเครื่องมือวัดเก่า ดองเกิล USB หรือเครื่องพิมพ์ไม่รองรับ Windows 11 สิ่งใดที่คุณใส่ฝั่งแอปก็ไม่แก้ โค้ดที่รันในเคอร์เนล เช่น ส่วนของซอฟต์แวร์แอนตี้ไวรัส ก็เช่นกัน³
• แอป 16 บิต Windows 64 บิตไม่รองรับการรันแอป 16 บิต แฮนเดิลมีบิตที่ใช้ได้ 32 บิตบน Windows 64 บิต และตัดส่งให้แอป 16 บิตไม่ได้ จึงเริ่มล้มด้วย ERROR_BAD_EXE_FORMAT⁸ แม้แอปเองจะเป็น 32 บิต ก็มีแพ็กเกจยุคนั้นที่ สตับตัวติดตั้งเป็น 16 บิต และปรากฏเป็น «แอปจะวิ่ง แต่ติดตั้งไม่ได้»
• การเข้าถึงฮาร์ดแวร์โดยตรง แอปอุตสาหกรรมที่สมมติว่าแตะพอร์ต I/O หรือหน่วยความจำกายภาพโดยตรงได้ ไม่ได้รับอนุญาตจากโหมดผู้ใช้บน Windows สมัยใหม่ และนั่นเกินขอบเขตที่ชิมปลอมได้
• การเลี่ยงกลไกความปลอดภัย เพราะชิมรันใต้ข้อจำกัดความปลอดภัยเดียวกับแอป มันทำให้ «สิ่งที่ทำไม่ได้เพราะขาดสิทธิ์» เป็นไปไม่ได้ ForceAdminAccess และ WRPMitigation เพียง ปลอมความสำเร็จของการตรวจหรือการเขียนเพื่อให้แอปไปต่อ ไม่ได้เขียนทรัพยากรที่ถูกป้องกันจริง³⁴
• แอปที่ตรวจความสมบูรณ์ของตัวเอง แอปที่มีการป้องกันการคัดลอกเก่าหรือการตรวจการดัดแปลงอาจถือฮุก API เองว่าผิดปกติแล้วหยุดทำงาน

flowchart TB
    accTitle: กรณีที่ชิมใช้ไม่ได้
    accDescr: ชิมรันในโพรเซสโหมดผู้ใช้ จึงใช้ไม่ได้กับปัญหาไดรเวอร์โหมดเคอร์เนล แอป 16 บิต การเข้าถึงฮาร์ดแวร์โดยตรง หรือการเลี่ยงกลไกความปลอดภัย
    shim["ชิม (รันในโหมดผู้ใช้)"] -->|ใช้ไม่ได้| drv["ไดรเวอร์เคอร์เนล"]
    shim -->|ใช้ไม่ได้| b16["แอป 16 บิต"]
    shim -->|ใช้ไม่ได้| hw["การเข้าถึงฮาร์ดแวร์โดยตรง"]
    shim -->|ใช้ไม่ได้| sec["การเลี่ยงกลไกความปลอดภัย"]
    b16 -.-> fmt["บน 64 บิต การเริ่มเองล้ม"]
    sec -.-> fake["ปลอมแค่ความสำเร็จเพื่อให้แอปไปต่อ"]

ภาพ 13: ชิมเป็นโหมดผู้ใช้เท่านั้น และไม่ถึงเคอร์เนล แอป 16 บิต การเข้าถึงฮาร์ดแวร์โดยตรง หรือการเลี่ยงความปลอดภัย

และขีดจำกัดแกนร่วมของทุกชิมคือ มันเป็นทางแก้ชั่วคราว ชิมคือคำโกหกที่ตัดให้เข้ากับการใช้ API แบบหนึ่ง และถ้าการทำให้จริงฝั่ง OS เปลี่ยน สมมติฐานพัง ชิมที่ Microsoft ให้ถูกดูแลเป็นส่วนหนึ่งของ Windows ผ่าน Windows Update³ แต่การดูแลคำโกหกที่คุณใส่ด้วยฐานที่กำหนดเองคืองานขององค์กรคุณ กำหนดงบ เป็นต้นทุนการยืดอายุ สำหรับการปฏิบัติที่ตรวจ «รายการแอปที่ชิมพยุงชีวิต» ทุกครั้งที่มีอัปเดตฟีเจอร์

flowchart TB
    accTitle: ชิมในฐานะทางแก้ชั่วคราว และใครรับผิดชอบดูแล
    accDescr: ชิมคือคำโกหกที่ตัดให้เข้ากับการใช้ API แบบหนึ่ง และสมมติฐานพังถ้าการทำให้จริงฝั่ง OS เปลี่ยน ชิมของ Microsoft ถูกดูแลผ่าน Windows Update แต่การดูแลคำโกหกที่ใส่ด้วยฐานที่กำหนดเองคืองานขององค์กร และการตรวจทุกอัปเดตฟีเจอร์คือต้นทุนการยืดอายุ
    shim["ชิม = คำโกหกชั่วคราว"] --> break["การเปลี่ยน OS ทำให้พัง"]
    ms["ชิมของ Microsoft"] --> wu["ผ่าน Windows Update"]
    own["คำโกหกของฐานที่กำหนดเอง"] --> self["องค์กรดูแล"]
    self --> cost["ตรวจทุกอัปเดตคือต้นทุนการยืดอายุ"]

ภาพ 14: ความรับผิดชอบดูแลคำโกหกของชิมแยกเป็นชุดที่ Microsoft ให้กับชุดที่องค์กรกำหนดเอง

8. คุณค่าเชิงปฏิบัติของ RunAsInvoker — ทำให้คำขอสิทธิ์สูงเงียบเท่านั้น

ในบรรดาชิม สิ่งที่โผล่บ่อยสุดในงานไอทีประจำวันคือ RunAsInvoker

แอปธุรกิจเก่าบางตัวประกาศ requireAdministrator ในแมนิเฟสต์ หรือถูกตรวจผิดเป็นตัวติดตั้งจากชื่อหรือเนื้อหา EXE แล้วขอสิทธิ์สูง UAC ทุกครั้งที่เริ่ม แต่หลายตัวขอผู้ดูแลเพียงเพราะแรงเฉื่อยยุค XP และไม่ได้ใช้สิทธิ์ผู้ดูแลจริง การใส่ชิม RunAsInvoker ทับทั้งการตรวจตัวติดตั้งและแมนิเฟสต์ และ แอปเริ่มด้วยโทเคนที่สืบทอดจากโพรเซสแม่ (= สิทธิ์ผู้ใช้มาตรฐาน)⁹

flowchart TB
    accTitle: วิธีที่ RunAsInvoker กดคำขอสิทธิ์สูง
    accDescr: ประกาศ requireAdministrator ในแมนิเฟสต์หรือการตรวจผิดเป็นตัวติดตั้งทำให้เกิดคำขอสิทธิ์สูง UAC ตอนเริ่ม แต่การใส่ RunAsInvoker ทับทั้งสองและแอปเริ่มด้วยโทเคนที่สืบทอดจากแม่
    manifest["ประกาศ requireAdministrator"] --> shim{"ใส่ RunAsInvoker แล้ว?"}
    detect["ถูกตรวจผิดเป็นตัวติดตั้ง"] --> shim
    shim -->|ไม่| uac["คำขอสิทธิ์สูง UAC ทุกครั้งที่เริ่ม"]
    shim -->|ใช่| token["เริ่มด้วยโทเคนของแม่"]
    token -.-> limit["งานที่ต้องการผู้ดูแลจริงล้มในแอป"]

ภาพ 15: RunAsInvoker ทับแค่สาเหตุของคำขอสิทธิ์สูง สิทธิ์ไม่เพิ่ม

แม้ไม่สร้าง .sdb ใน Compatibility Administrator คุณใส่ชั้นเดียวกันชั่วคราวด้วยตัวแปรสภาพแวดล้อม __COMPAT_LAYER ได้

:: Apply RunAsInvoker to child processes started from this command prompt
set __COMPAT_LAYER=RunAsInvoker
start "" "C:\LegacyApp\Gyomu.exe"

# In PowerShell
$env:__COMPAT_LAYER = 'RunAsInvoker'
Start-Process 'C:\LegacyApp\Gyomu.exe'

ถ้าคุณแปลงสองบรรทัดนั้นเป็นไฟล์แบตช์แล้วแจกเป็นทางลัด คุณเลี่ยงการมอบสิทธิ์ผู้ดูแลท้องถิ่นให้ผู้ใช้มาตรฐานได้ และไอทีไม่ถูกเรียกทุกครั้งเพราะรหัสผ่าน UAC นี่คือเทคนิคความเข้ากันได้ที่ทำให้แนวรับแข็ง ตามสิทธิ์น้อยสุด

flowchart TB
    accTitle: ผลของการแจกแบตช์ RunAsInvoker
    accDescr: การแจกแบตช์สองบรรทัดที่ตั้ง RunAsInvoker เป็นทางลัดแปลว่าคุณเลี่ยงการมอบสิทธิ์ผู้ดูแลท้องถิ่นให้ผู้ใช้มาตรฐานได้ ไอทีไม่ถูกเรียกเพราะรหัสผ่าน UAC และการปฏิบัติตามสิทธิ์น้อยสุด
    bat["แจกแบตช์สองบรรทัด"] --> noadmin["เลี่ยงการมอบสิทธิ์ผู้ดูแลได้"]
    bat --> nocall["ไอทีไม่ถูกเรียกเพราะ UAC"]
    noadmin --> lp["การปฏิบัติที่ตามสิทธิ์น้อยสุด"]
    nocall --> lp

ภาพ 16: การแจกแบตช์อย่างเดียวลดทั้งการมอบสิทธิ์ผู้ดูแลและการถูกเรียกเพราะ UAC ได้

ข้อควรระวังด้วย ให้ชัด

• สิทธิ์ไม่เพิ่ม งานที่ต้องการสิทธิ์ผู้ดูแลจริง (เขียน HKLM อัปเดตใต้ Program Files เป็นต้น) จะผิดพลาดในแอป หรือถ้าเงื่อนไขครบ จะถูกการจำลอง UAC เปลี่ยนเส้นทางไป VirtualStore¹⁰ ถ้าการบันทึกการตั้งค่า «หยุดทำงาน» ทันที ให้สงสัยการจำลอง
• วิธีตัวแปรสภาพแวดล้อมใช้กับโพรเซสลูกเท่านั้น สำหรับการใส่ถาวร การตั้งตรงในคีย์ Layers (RUNASINVOKER ไม่มีรายการบนแท็บ) หรือการแจกผ่าน .sdb เชื่อถือได้
• การแก้ปลายทางการเขียนคือทางจริง ถ้าเปลี่ยนแอปได้ ให้ย้ายไฟล์ตั้งค่าไปใต้ %APPDATA% และประกาศ asInvoker ในแมนิเฟสต์ — นั่นคือรูปที่ถูกต้อง⁹

flowchart TB
    accTitle: การใส่ชั่วคราวและถาวรของ RunAsInvoker
    accDescr: การใส่ผ่านตัวแปรสภาพแวดล้อม COMPAT_LAYER ใช้กับโพรเซสลูกที่เริ่มจากที่นั่นเท่านั้น สำหรับการใส่ถาวรให้ตั้งตรงในคีย์ Layers หรือแจกผ่าน .sdb
    env["ตั้งผ่านตัวแปรสภาพแวดล้อม"] --> child["ใช้กับโพรเซสลูกเท่านั้น"]
    child -.-> tmp["การใส่ชั่วคราว"]
    layers["ตั้งตรงในคีย์ Layers"] --> always["การใส่ถาวร"]
    sdb["แจกผ่าน sdb"] --> always

ภาพ 17: วิธีตัวแปรสภาพแวดล้อมเป็นการใส่ชั่วคราวที่จำกัดที่โพรเซสลูก การทำให้ถาวรทำด้วยคีย์ Layers หรือ .sdb

9. การตัดสินระหว่างยืดอายุกับย้ายระบบ — คิดอะไรหลังวิ่งใต้ชิม

วินาทีที่วิ่งใต้ชิมคือความโล่ง แต่สำคัญคืออย่าหยุดคิดตรงนั้น การวิ่งใต้ชิมแปลแค่ว่าบังเอิญเข้ากับเบ้าที่ Windows เตรียมไว้ แกนการตัดสิน ในตาราง

ถ้าตัดสินใจยืดอายุ ให้ใส่สามจุดต่อไปนี้ในการปฏิบัติเป็นชุด

1. บันทึก EXE ใด ชิม/ชั้นใด และทำไม เหลือค่าคีย์ Layers และ GUID ของ .sdb ในบัญชี «ไม่มีใครรู้ว่าทำไมมันวิ่ง» คือหนี้ใหญ่สุดที่คุณทิ้งให้คนถัดไป นี่คือกรอบคิดการรักษาแบบเดียวกับ «When You Inherit a System With No Source Code and No Documentation»
2. ตรวจ รวมการเริ่มและการทำงานหลักของแอปที่ชิมพยุงชีวิตไว้ในรายการตรวจของอัปเดตฟีเจอร์ Windows ผูกกับแผนเปลี่ยน OS ด้วย (Practical Options After Windows 10 End of Support)
3. กำหนดเส้นตาย ตัดสินจุดจบของการยืดอายุ — «จนถึงการปรับระบบหลักครั้งถัดไป» «จนถึงมีนาคม 2028» — และพิจารณาการย้ายระบบคู่ขนาน

flowchart TB
    accTitle: ชุดปฏิบัติสามจุดเมื่อตัดสินใจยืดอายุ
    accDescr: จดในบัญชีว่าชิมใดทำให้วิ่ง ตรวจพฤติกรรมของแอปที่ชิมพยุงชีวิตทุกอัปเดตฟีเจอร์ กำหนดเส้นตายจุดจบของการยืดอายุ และพิจารณาการย้ายระบบคู่ขนาน
    decide["ตัดสินใจยืดอายุ"] --> rec["บันทึก: ชิมใดทำให้วิ่ง ใส่บัญชี"]
    rec --> verify["ตรวจ: ยืนยันพฤติกรรมทุกอัปเดตฟีเจอร์"]
    verify --> deadline["เส้นตาย: ตัดสินจุดจบของการยืดอายุ"]
    deadline --> mig["พิจารณาการย้ายระบบคู่ขนาน"]

ภาพ 18: การยืดอายุถูกปฏิบัติเป็นชุดสามจุด บันทึก ตรวจ และเส้นตาย รวมการพิจารณาการย้ายระบบคู่ขนาน

ฝั่งย้ายระบบ ทางเลือกมาตรฐานเปลี่ยนตามเทคโนโลยีของแอป สำหรับ VB6 คือทางสามแพร่ง เขียนใหม่ทั้งก้อน แปลงอัตโนมัติ และย้ายเป็นขั้น ที่จัดใน «How Long Will VB6 Apps Keep Running?» สำหรับการพึ่ง ActiveX/OCX คือตารางตัดสิน คงไว้ / ห่อ / แทน ที่ «How to Handle ActiveX / OCX Today» วิธีวางชิมอย่างมีสุขภาพคือการซื้อเวลาให้ช่วงพิจารณาและเตรียมของโครงการย้ายระบบนั้นวิ่งอย่างปลอดภัย

flowchart TB
    accTitle: ทางเลือกฝั่งย้ายระบบ และที่นั่งของชิม
    accDescr: ทางเลือกย้ายระบบมาตรฐานเปลี่ยนตามเทคโนโลยีของแอป สำหรับ VB6 ทางสามแพร่งคือเขียนใหม่ แปลงอัตโนมัติ และย้ายเป็นขั้น สำหรับการพึ่ง ActiveX ใช้ตารางคงไว้ / ห่อ / แทน และชิมถูกวางเป็นการซื้อเวลาให้การพิจารณาและเตรียมโครงการย้ายระบบ
    tech{"เทคโนโลยีของแอปคืออะไร?"} -->|VB6| vb["เขียนใหม่ แปลงอัตโนมัติ หรือย้ายเป็นขั้น"]
    tech -->|การพึ่ง ActiveX| ax["คงไว้ ห่อ หรือแทน"]
    shim["ยืดอายุผ่านชิม"] -.->|ซื้อเวลาให้การพิจารณาและเตรียม| tech

ภาพ 19: ทางเลือกย้ายระบบมาตรฐานถูกตัดสินด้วยเทคโนโลยีของแอป และชิมถูกวางเป็นการซื้อเวลาให้การพิจารณานั้น

10. สรุป

• ตัวตนจริงของโหมดความเข้ากันได้คือชิม การตั้งค่าจากแท็บความเข้ากันได้ถูกเขียนไปที่คีย์ AppCompatFlags\Layers และถูกฉีดเข้าโพรเซสตอนเริ่มเป็นฮุก API ผ่านการเขียน IAT ใหม่
• ชิมคือชุด «คำโกหกที่คืนคำตอบที่แอปเก่าคาดหวัง» มีชิมสำเร็จรูปสำหรับการปลอมเวอร์ชัน การแมปพาธใหม่ การปลอมรีจิสทรี การปลอมการตรวจผู้ดูแล และคล้ายกัน
• Windows เองใช้ชิมจำนวนมากเป็นค่าเริ่มต้น และ PCA อาจใส่อัตโนมัติ การพึ่งโหมดความเข้ากันได้เองเป็นทางเลือกที่สมเหตุสมผลซึ่งขี่กลไกอย่างเป็นทางการของ OS
• มีขีดจำกัดหลัก โหมดผู้ใช้เท่านั้น และไม่มีการเลี่ยงความปลอดภัย และไดรเวอร์เคอร์เนล แอป 16 บิต และการเข้าถึงฮาร์ดแวร์โดยตรงช่วยไม่ได้
• การกระจายองค์กรคือการสร้าง .sdb ที่กำหนดเองใน Compatibility Administrator (Windows ADK) แล้วแจกด้วย sdbinst การเลือกรุ่น 32/64 บิต การทดสอบด้วยบัญชีผู้ใช้จริง และการจัดการอัปเดตด้วย GUID คือจุดปฏิบัติ
• แอปที่ «ขอผู้ดูแลแต่จริง ๆ ไม่ต้องการ» ลดลงมาที่สิทธิ์มาตรฐานได้ด้วย __COMPAT_LAYER=RunAsInvoker นี่คือเทคนิคเชิงรับที่ทำให้คำขอสิทธิ์สูงเงียบ แทนการแจกสิทธิ์
• การวิ่งใต้ชิมคือการยืดอายุ ไม่ใช่ทางแก้ การจดว่าอะไรทำให้วิ่ง การตรวจทุกอัปเดตฟีเจอร์ และการกำหนดเส้นตายให้การย้ายระบบวิ่งคู่ขนาน — ชุดสามจุดนั้นรวมอยู่ในการตัดสิน «พึ่งโหมดความเข้ากันได้»

ครั้งหน้าเมื่อแอปเก่าเริ่มทำงานหลังช่องติ๊กโหมดความเข้ากันได้ จงถามอีกครั้ง «แอปนี้วิ่งด้วยคำโกหกใด คำโกหกนั้นจะใช้ได้นานแค่ไหน» ถ้าตอบได้ การยืดอายุคือกลยุทธ์ที่น่าเคารพ

บทความที่เกี่ยวข้อง

• Registry 32-bit/64-bit Redirection and Virtualization Pitfalls — Wow6432Node and the “The Value I Wrote Isn’t There” Problem
• How Long Will VB6 Apps Keep Running? — Runtime Support Status and a Practical Path to .NET Migration
• How to Handle ActiveX / OCX Today - A Keep / Wrap / Replace Decision Table
• Practical Options After Windows 10 End of Support — A Decision Table for ESU, LTSC, and Replacement
• When You Inherit a System With No Source Code and No Documentation — A Practical Playbook for Keeping It Running
• การผสานเชลล์ Windows วันนี้ — เมนูบริบท การเชื่อมโยงไฟล์ และสิ่งที่เปลี่ยนใน Windows 11

ด้านให้คำปรึกษาที่เกี่ยวข้อง

KomuraSoft LLC รับการสืบสวนพฤติกรรมของแอปธุรกิจเก่าที่ไม่มีซอร์สโค้ด และการออกแบบการยืดอายุ (เลือกชิมและโหมดความเข้ากันได้ สร้างและกระจาย .sdb ที่กำหนดเอง) การตรวจความเข้ากันได้ของแอปที่มีอยู่สำหรับการย้ายไป Windows 11 และการวางแผนการเขียนใหม่หรือย้ายระบบที่วิ่งคู่กับการยืดอายุ การปรึกษาตั้งแต่ขั้น «เริ่มทำงานในโหมดความเข้ากันได้ แต่ปล่อยแบบนี้ได้ไหม» ก็ได้

• ใช้ประโยชน์และย้ายสินทรัพย์เดิม
• พัฒนาแอป Windows
• ที่ปรึกษาเทคนิคและรีวิวการออกแบบ
• ติดต่อเรา

ลิงก์อ้างอิง

บทความที่เกี่ยวข้อง

บทความล่าสุดที่มีแท็กเดียวกัน เพื่อเจาะลึกหัวข้อใกล้เคียง

หัวข้อที่เกี่ยวข้อง

หน้าเหล่านี้วางหัวข้อไว้ในบริบทที่กว้างขึ้นของบริการและการตัดสินใจ

บริการที่เกี่ยวข้องกับหัวข้อนี้

บทความนี้เกี่ยวข้องโดยตรงกับบริการต่อไปนี้

คำถามที่พบบ่อย

คำถามที่มักพบในการปรึกษาเกี่ยวกับหัวข้อของบทความนี้

ถ้าแอปเริ่มทำงานหลังติ๊กโหมดความเข้ากันได้ จะใช้ต่อไปแบบนั้นได้ไหม

เพื่อให้ธุรกิจเดินต่อในระยะสั้น ได้ โหมดความเข้ากันได้คือฮุก API ในโหมดผู้ใช้ที่เรียกว่าชิม เป็นกลไกอย่างเป็นทางการที่ระบบปฏิบัติการจัดให้ แต่ชิมยังเป็นทางแก้ชั่วคราวเพื่อให้แอปวิ่งโดยไม่แก้ และอัปเดต OS อีกครั้งอาจเปลี่ยนสมมติฐานแล้วพังอีก จดข้อเท็จจริงว่ามันวิ่งใต้โหมดความเข้ากันได้ไว้ในบัญชี และถือบันทึกนั้นเป็นส่วนของการตัดสินใจว่าจะเขียนแอปใหม่หรือยืดอายุอย่างมีแผน

ช่องติ๊กโหมดความเข้ากันได้ทำอะไรจริง ๆ

เมื่อคุณบันทึกการตั้งค่าที่แท็บความเข้ากันได้ของกล่องโต้ตอบคุณสมบัติ Windows จะเขียนพาธของ EXE เป้าหมายและค่าอย่าง "WINXPSP3" หรือ "HIGHDPIAWARE" ใต้คีย์ HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers ครั้งถัดไปที่ EXE นั้นเริ่ม ตัวโหลด Windows อ่านค่าแล้วใส่ชั้นความเข้ากันได้ที่ตรงกัน (มัดชิม) ให้โพรเซส โหมดความเข้ากันได้ Windows XP เช่น สวมรอยเวอร์ชัน OS โดยคืนค่าเก่าจาก API ที่ถามเวอร์ชัน ตัว OS ไม่ได้ถูกเปลี่ยน มีเพียงโพรเซสนั้นที่ถูกแสดง Windows เก่าปลอม

แอปยุค 16 บิตจะรันใต้โหมดความเข้ากันได้บน Windows 64 บิตได้ไหม

ไม่ได้ Windows 64 บิตรันแอป 32 บิตผ่าน WOW64 แต่ไม่รองรับการรันแอป 16 บิต และการพยายามเริ่มจะล้มด้วย ERROR_BAD_EXE_FORMAT นั่นคือขีดจำกัดทางสถาปัตยกรรมที่ชิมเลี่ยงไม่ได้ แพ็กเกจเก่าที่สตับตัวติดตั้งเป็น 16 บิตก็ล้มด้วยเหตุเดียวกัน ถ้าจำเป็นจริงต้องมองนอกโหมดความเข้ากันได้ เช่น เครื่องเสมือนที่มี Windows 32 บิต

จะรันแอปที่ "ไม่เริ่มถ้าไม่รันในฐานะผู้ดูแลระบบ" ใต้บัญชีผู้ใช้มาตรฐานได้ไหม

RunAsInvoker น่าลอง ถ้าคุณรัน set __COMPAT_LAYER=RunAsInvoker ที่พรอมต์คำสั่งแล้วเริ่มแอป คำขอสิทธิ์สูงจากแมนิเฟสต์ requireAdministrator หรือจากการตรวจจับตัวติดตั้งจะถูกกด และแอปเริ่มด้วยสิทธิ์เดียวกัน (ผู้ใช้มาตรฐาน) กับผู้เรียก สำหรับแอปที่ขอสิทธิ์ผู้ดูแลอย่างเดียวและไม่เคยใช้จริง สิ่งนี้พอจะเอาสิทธิ์สูงออกจากงานประจำวัน สิทธิ์ไม่เพิ่ม ดังนั้นงานที่ต้องการสิทธิ์ผู้ดูแลจริงจะล้มในแอป รับมาใช้หลังตรวจพฤติกรรมแล้วเท่านั้น

หา Compatibility Administrator ได้ที่ไหน

อยู่ใน Windows ADK (Windows Assessment and Deployment Kit) ดาวน์โหลด ADK จากไซต์ Microsoft และตอนติดตั้งเลือกฟีเจอร์ Application Compatibility Tools ทั้งรุ่น 32 บิตและ 64 บิตถูกติดตั้ง คุณต้องใช้รุ่น 32 บิตกับแอป 32 บิต และรุ่น 64 บิตกับแอป 64 บิต ใส่ฐานข้อมูลความเข้ากันได้ที่สร้างเอง (.sdb) โดยรันคำสั่ง sdbinst บนแต่ละพีซี

โปรไฟล์ผู้เขียน

หน้าแนะนำผู้เขียนบทความ

Go Komura

ผู้แทนของ KomuraSoft LLC

เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ Windows ที่ปรึกษาเทคนิค และการตรวจสอบบั๊ก โดยเฉพาะโปรเจกต์ที่มีระบบเดิมและบั๊กที่ทำซ้ำได้ยาก