विंडोज वास्तविक समय स्मृति प्रबंधन

हाल ही में, रेमंड चेन ने डेढ़ साल पहले पदों की एक श्रृंखला पूरी की, जो प्रोसेसर से किसी भी समर्थन के बिना वर्चुअल मेमोरी को प्रबंधित करने के लिए समर्पित है: विंडोज संस्करण 3.0 तक समावेशी समर्थित वास्तविक मोड 8086। इस मोड में, पते को "वर्चुअल" (दृश्यमान प्रोग्राम) से भौतिक में अनुवादित किया गया है। (सिस्टम बस पर जारी) खंड और ऑफसेट के सरल जोड़ द्वारा किया जाता है - कोई "अभिगम नियंत्रण", कोई "अवैध पते" नहीं। सभी पते सभी के लिए उपलब्ध हैं। उसी समय, कई प्रोग्राम विंडोज में एक साथ काम कर सकते थे और एक दूसरे के साथ हस्तक्षेप नहीं करते थे; विंडोज मेमोरी में अपने सेगमेंट को स्थानांतरित कर सकता है, अप्रयुक्तों को अनलोड कर सकता है, और उन्हें आवश्यक रूप से वापस लोड कर सकता है, संभवतः अन्य पते पर।

(दिलचस्प बात यह है कि इन विलक्षण क्षमताओं के बारे में जानने के लिए, कभी-कभी मौजूद होलिवोर्शिकी "यह एक ग्राफिकल शेल था, ऑपरेटिंग सिस्टम नहीं था?")

और उसने कैसे प्रबंधन किया?

डेटा प्रबंधन

रियल-टाइम विंडोज में कोई स्वैप नहीं था। अपरिवर्तनीय डेटा (उदाहरण के लिए, संसाधन) बस मेमोरी से हटा दिए गए थे और यदि आवश्यक हो, तो निष्पादन योग्य फ़ाइल से फिर से लोड किया गया। चर डेटा अनलोड नहीं किया जा सकता है, लेकिन (किसी भी अन्य डेटा की तरह) को स्थानांतरित किया जा सकता है: मेमोरी ब्लॉकों के साथ काम करने के लिए एप्लिकेशन पतों का उपयोग नहीं करता है, लेकिन संभालता है; और डेटा तक पहुंचने के समय के लिए, यह ब्लॉक को "ठीक" करता है, अपना पता प्राप्त करता है, और फिर इसे "जारी" करता है ताकि विंडोज आवश्यक होने पर इसे स्थानांतरित कर सके। कुछ ऐसा ही एक दर्जन साल बाद .NET में दिखाई दिया, जिसे पहले से ही पिनिंग कहा जाता है।

GlobalLock / GlobalUnlock और LockResource / FreeResource को उन प्राचीन समय के साथ संगतता के लिए FreeResource में संरक्षित किया गया था, हालांकि मेमोरी ब्लॉक (संसाधनों सहित) को कभी भी Win32API में स्थानांतरित नहीं किया गया था।

LockSegment और UnlockSegment (पते को UnlockSegment / फ़्री मेमोरी को हैंडल द्वारा नहीं, UnlockSegment करने के लिए) कुछ समय तक "अप्रचलित, उपयोग न करें" चिह्नित किए गए दस्तावेज़ में रहे, लेकिन अब उनके पास कोई मेमोरी नहीं बची है।

जिन लोगों को लंबे समय तक मेमोरी को ठीक करने की आवश्यकता होती है, उनके लिए एक GlobalWire फ़ंक्शन भी था - "ताकि ब्लॉक पता स्थान के बीच में GlobalWire न जाए, इसे मेमोरी के निचले किनारे पर ले जाएं और इसे ठीक करें"; यह GlobalUnwire मेल GlobalUnwire , पूरी तरह से GlobalUnlock बराबर है। फ़ंक्शंस की यह जोड़ी आश्चर्यजनक रूप से, कर्नेल 32.dll में अभी भी जीवित है, हालांकि उन्हें पहले ही प्रलेखन से हटा दिया गया है। अब वे GlobalLock / GlobalUnlock फिर से GlobalLock ।

संरक्षित मोड विंडोज में, GlobalLock फ़ंक्शन GlobalLock एक "स्टब" के साथ बदल दिया GlobalLock : अब विंडोज अपने "वर्चुअल एड्रेस" को एप्लिकेशन (चयनकर्ता: ऑफसेट) के लिए दृश्यमान बदले बिना मेमोरी ब्लॉकों को फेरबदल कर सकता है - जिसका अर्थ है कि एप्लिकेशन को अब गैर-अपलोड करने योग्य ऑब्जेक्ट को ठीक करने की आवश्यकता नहीं है। दूसरे शब्दों में, पिनिंग अब ब्लॉक को उतारने से रोकता है, लेकिन इसे (एप्लिकेशन के लिए अदृश्य) को बढ़ने से नहीं रोकता है। इसलिए, भौतिक स्मृति में "वास्तविक के लिए" डेटा को ठीक करने के लिए, उन लोगों के लिए जिन्हें बस (उदाहरण के लिए, बाहरी उपकरणों के साथ काम करने की आवश्यकता है), उन्होंने GlobalFix / GlobalUnfix की एक जोड़ी को जोड़ा। GlobalWire / GlobalUnwire तरह, Win32 में ये कार्य बेकार हो गए हैं; और उन्हें उसी तरह से प्रलेखन से भी हटा दिया जाता है, हालांकि वे GlobalLock में बने रहे और GlobalLock / GlobalUnlock पुनः GlobalLock ।

कोड प्रबंधन

यहाँ से ट्रिकिएस्ट शुरू होता है। कोड के ब्लॉक - साथ ही अपरिवर्तनीय डेटा - मेमोरी से हटा दिए गए थे, और फिर एक निष्पादन योग्य फ़ाइल से लोड किए गए थे। लेकिन विंडोज ने यह कैसे सुनिश्चित किया कि प्रोग्राम अनलोड किए गए ब्लॉकों में फ़ंक्शन को कॉल करने की कोशिश नहीं करते थे? हैंडल के माध्यम से फ़ंक्शन का उपयोग करना संभव होगा, और प्रत्येक फ़ंक्शन कॉल से पहले, एक काल्पनिक LockFunction कॉल करें; लेकिन याद रखें कि कई फ़ंक्शन "संदेश लूप" को मोड़ते हैं, उदाहरण के लिए, एक विंडो दिखाएं या DDE कमांड निष्पादित करें, और आप उन्हें इस समय के लिए अनलोड भी कर सकते हैं, क्योंकि वास्तव में, इस समय उनके कोड की आवश्यकता नहीं है। हालाँकि, "फ़ंक्शन हैंडल" का उपयोग करते समय, फ़ंक्शन सेगमेंट को तब तक मुक्त नहीं किया जाएगा जब तक कि यह कॉलिंग फ़ंक्शन पर नियंत्रण वापस नहीं करता है।

इसके बजाय, विंडोज यह मानकर शुरू होता है कि आप किसी भी फ़ंक्शन को अनलोड कर सकते हैं जो अभी नहीं चल रहा है; और चूंकि विंडोज मेमोरी मैनेजर कोड अभी चल रहा है, आप किसी भी फंक्शन को अनलोड कर सकते हैं। इस फ़ंक्शन के लिंक या तो प्रोग्राम कोड में या स्टैक पर बने रह सकते हैं यदि यह फ़ंक्शन अनलोडिंग के समय से पहले वापस आने का प्रबंधन नहीं करता है।

इसलिए विंडोज सभी चलने वाले कार्यों के ढेर से गुजरता है (विंडोज में तथाकथित निष्पादन संदर्भ जब तक वे प्रक्रियाओं और थ्रेड्स को अलग नहीं करते हैं), रिटर्न पते को अनलोड किए गए खंडों के अंदर ले जाता है, और उन्हें पुनः लोड थ्रॉक्स के पते के साथ बदल देता है - "स्टब्स" जो वांछित खंड को लोड करता है निष्पादन योग्य फ़ाइल से, और उसके अंदर स्थानांतरण नियंत्रण, जैसे कि कुछ भी नहीं हुआ था।

ताकि विंडोज स्टैक पर चल सके, प्रोग्राम्स को इसे सही फॉर्मेट में सपोर्ट करना चाहिए: नो एफपीओ, स्टैक फ्रेम को BP - पॉइंटर से कॉलिंग फंक्शन के फ्रेम से शुरू होना चाहिए। (चूंकि स्टैक में 16-बिट शब्द होते हैं, BP मान हमेशा समान होता है।) इसके अलावा, विंडोज को स्टैक में इंट्रा-सेगमेंट ("क्लोज़") और इंटर-सेगमेंट ("दूर") के बीच अंतर करना चाहिए, और यह क्लोज़ कॉल को अनदेखा कर सकता है - वे वास्तव में वे बिल्कुल अनलोड किए गए सेगमेंट में नहीं जाते हैं। इसलिए, उन्होंने तय किया कि स्टैक में BP के विषम मूल्य का मतलब एक दूर की कॉल है, अर्थात। हर INC BP; PUSH BP; MOV BP,SP फ़ंक्शन को INC BP; PUSH BP; MOV BP,SP प्रोपलॉग से शुरू होना चाहिए INC BP; PUSH BP; MOV BP,SP INC BP; PUSH BP; MOV BP,SP INC BP; PUSH BP; MOV BP,SP और एपिलॉग POP BP; DEC BP; RETF साथ समाप्त होता है POP BP; DEC BP; RETF POP BP; DEC BP; RETF POP BP; DEC BP; RETF (वास्तव में, प्रस्तावना और उपसंहार अधिक जटिल थे, लेकिन यह अब उसके बारे में नहीं है।)

हमने स्टैक से लिंक का पता लगाया, लेकिन अन्य कोड सेगमेंट के लिंक के बारे में क्या? बेशक, विंडोज पूरी मेमोरी के माध्यम से नहीं जा सकता है, सभी कॉल अनलोड किए गए फ़ंक्शन को ढूंढ सकता है, और उन सभी को पुनः लोड थ्रक्स के साथ बदल सकता है। इसके बजाय, अंतःविषय कॉल को इस तथ्य को ध्यान में रखते हुए संकलित किया जाता है कि तथाकथित फ़ंक्शन स्मृति में नहीं हो सकता है, और वास्तव में वे मॉड्यूल इनपुट तालिका में "स्टब" कहते हैं। इस स्टब में एक int 3fh इंस्ट्रक्शन होता है, और तीन और सर्विस बाइट्स यह दर्शाता है कि फंक्शन को कहां देखना है। int 3fh अपने वापसी पते पर इन सेवा बाइट्स पाता है; वांछित खंड को परिभाषित करता है; यदि इसे पहले से लोड नहीं किया गया है तो इसे मेमोरी में लोड करता है; और अंत में पूर्ण संक्रमण jmp xxxx:yyyy साथ इनपुट तालिका में स्टब को अधिलेखित करता है jmp xxxx:yyyy फ़ंक्शन बॉडी के लिए jmp xxxx:yyyy , ताकि एक ही फ़ंक्शन के अगले कॉल केवल एक इंटर-सेगमेंट संक्रमण द्वारा धीमा हो जाते हैं, बिना किसी रुकावट के।

अब, जब विंडोज फ़ंक्शन को अनलोड करता है, तो यह मॉड्यूल इनपुट तालिका में इसके लिए पर्याप्त संक्रमण को 3 int 3fh वापस डालने के लिए पर्याप्त होता है। सिस्टम को अनलोड किए गए फ़ंक्शन के सभी कॉल की खोज करने की आवश्यकता नहीं है - वे सभी संकलन पर भी पाए गए थे! मॉड्यूल की " WinMain टेबल" में सभी दूर के कार्य शामिल होते हैं जो कंपाइलर कॉल के अस्तित्व के बारे में जानता है (इसमें विशेष रूप से, निर्यात किए गए फ़ंक्शंस और WinMain ), साथ ही सभी दूर के फ़ंक्शंस जो पॉइंटर द्वारा पारित किए गए थे, जिसका अर्थ है कि वे कर सकते हैं कहीं से भी बुलाया जाता है, यहां तक ​​कि प्रोग्राम कोड के बाहर भी (इसमें WndProc , EnumFontFamProc और अन्य कॉलबैक फ़ंक्शन शामिल हैं)।

दूर के कार्यों के संकेत के बजाय, एक स्टब के लिए एक संकेतक हर जगह पारित किया जाता है; जिसका अर्थ है कि GetWindowLong(GWL_WNDPROC) और इसी तरह की कॉल से प्राप्त पते भी स्टब की ओर इशारा करते हैं, और फ़ंक्शन के शरीर को नहीं। यहां तक ​​कि GetProcAddress मुश्किल है, और फ़ंक्शन के पते के बजाय, यह DLL प्रविष्टि तालिका में अपने स्टब का पता देता है। (Win32 में, केवल DLL के लिए "एंट्री टेबल" का एनालॉग "एक्सपोर्ट टेबल" के नाम से बना रहा।) स्टैटिक इंटरमॉड्यूल कॉल (DLL से आयात किए गए फ़ंक्शंस पर कॉल) समान GetProcAddress का उपयोग करके हल करते हैं, और इसलिए, उसी तरह से वे स्टब कहते हैं। । किसी भी मामले में, यह पता चला है कि फ़ंक्शन को अनलोड करते समय, स्टब को ठीक करने के लिए पर्याप्त है, और आपको कॉलिंग कोड को छूने की आवश्यकता नहीं है।

Relocatable कोड सेगमेंट के साथ यह सभी ज्ञान डॉस के लिए ओवरले लिंकर से "विरासत द्वारा" विंडोज में आया था। जैसे, पहले पूरी स्कीम - ठीक इसी रूप में - ज़ोर्टेक सी कंपाइलर में दिखाई दी, और फिर माइक्रोसॉफ्ट सी में। जब विंडोज के लिए निष्पादन योग्य फ़ाइल प्रारूप बनाया गया था, तो डॉस के लिए मौजूदा ओवरले प्रारूप को आधार के रूप में लिया गया था।

लेकिन विंडोज किस सेगमेंट को अनलोड करने के लिए कैसे चुनता है? यादृच्छिक पर चयन करना जोखिम भरा होगा - हम उस कोड में आ सकते हैं जिसे अभी-अभी निष्पादित किया गया है, और जिसे वापस डाउनलोड करना होगा। इसलिए, विंडोज कोड सेगमेंट के लिए "एक्सेस बिट" की तरह कुछ का उपयोग करता है : यह जानकर कि फ़ंक्शन के सभी कॉल कॉल उसके स्टब से गुजरते हैं, उन्होंने निर्देश sar byte ptr cs:[xxx], 1 डालने का int 3fh ( sar byte ptr cs:[xxx], 1 int 3fh ( jmp इसे प्रतिस्थापित करने से पहले) sar byte ptr cs:[xxx], 1 , जो हर बार फ़ंक्शन कहे जाने वाले बाइट काउंटर को 1 से 0 तक रीसेट करता है। यह निर्देश सिर्फ पाँच बाइट्स लेता है: आप मौजूदा निष्पादन योग्य फ़ाइल प्रारूप को सहेज सकते हैं, और एक काउंटर निर्देश के साथ int 3fh गए एक के माध्यम से int 3fh लोड कर सकते हैं।

सभी कोड खंडों के लिए काउंटर मान 1 से प्रारंभ किए जाते हैं, और प्रत्येक 250ms में, Windows सभी मॉड्यूल को बायपास करता है, अद्यतन मान एकत्र करता है और कोड खंडों को अपनी LRU सूची में पुन: व्यवस्थित करता है। डेटा सेगमेंट की कॉल को बिना किसी ट्रिक के ट्रैक किया जा सकता है: ऐसी सभी कॉल GlobalLock से GlobalLock या इसी तरह के कार्यों के लिए एक स्पष्ट कॉल द्वारा चिह्नित हैं। इसलिए जब मेमोरी खाली करने के लिए एक सेगमेंट को अनलोड करने का समय आता है - विंडोज उस सेगमेंट को अनलोड करने की कोशिश करेगा जिसे सबसे लंबे समय तक एक्सेस नहीं किया गया है: या तो एक कोड सेगमेंट जिसका काउंटर 0 पर सबसे लंबे समय तक रीसेट नहीं किया गया है, या एक डेटा सेगमेंट जो सबसे लंबे समय तक नहीं चला है। तय किया गया था।

Windows विज्ञापन 1.0-2.1 GUIdebook पर लिया गया