जब आप कोई प्रोग्राम खोलते हैं तो क्या कोई ऑपरेटिंग सिस्टम अपने स्वयं के मशीन कोड को इंजेक्ट करता है?


32

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

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

क्या मैं कठोर सोच रहा हूँ? मैं सीएस का छात्र नहीं हूं, बल्कि वास्तव में गणित का छात्र हूं। यदि संभव हो तो, मैं इस बारे में एक अच्छी किताब चाहता हूं, क्योंकि मुझे कोई नहीं मिला जो बताता है कि ओएस सीपीयू में चलने वाले कोड का एक गुच्छा भी है, तो ओएस एक प्रक्रिया का प्रबंधन कैसे कर सकता है, और यह उसी पर नहीं चल सकता है कार्यक्रम का समय। पुस्तकें केवल बताती हैं कि ओएस चीजों को प्रबंधित कर सकता है, लेकिन अब कैसे।


7
देखें: संदर्भ स्विच ओएस ऐप के लिए एक संदर्भ स्विच करता है। ऐप फिर ओएस सेवाओं का अनुरोध कर सकता है जो ओएस के संदर्भ में वापस करते हैं। जब एप्लिकेशन समाप्त होता है तो संदर्भ OS पर वापस आ जाता है।
गाइ कोडर

4
"Syscall" भी देखें।
राफेल


1
यदि टिप्पणियाँ और उत्तर आपकी समझ या संतुष्टि के लिए आपके प्रश्न का उत्तर नहीं देते हैं, तो कृपया टिप्पणी के रूप में अधिक जानकारी के लिए पूछें और समझाएं कि आप क्या सोच रहे हैं या आप कहां खो गए हैं, या विशेष रूप से आपको और अधिक विस्तार की आवश्यकता है।
गाय कोडर

2
मुझे लगता है कि बाधा , हुकिंग (एक रुकावट), हार्डवेयर टाइमर ( शेड्यूलिंग -हैंडलिंग हुक के साथ) और पेजिंग (निषिद्ध स्मृति पर आपकी टिप्पणी का आंशिक उत्तर) आपके लिए आवश्यक मुख्य कीवर्ड हैं। ओएस को अपने कोड को चलाने के लिए प्रोसेसर के साथ वास्तव में निकटता से सहयोग करने की आवश्यकता होती है। इस प्रकार अधिकांश सीपीयू शक्ति का उपयोग वास्तविक कम्प्यूटेशन पर किया जा सकता है, इसके प्रबंधन पर नहीं।
पालिक

जवाबों:


35

नहीं। ऑपरेटिंग सिस्टम प्रोग्राम के कोड को नए कोड को इंजेक्ट करने में गड़बड़ी नहीं करता है। इससे कई नुकसान होंगे।

  1. यह समय लेने वाला होगा, क्योंकि OS को अपने परिवर्तन करने वाले संपूर्ण निष्पादन योग्य के माध्यम से स्कैन करना होगा। आम तौर पर, निष्पादन योग्य का हिस्सा केवल आवश्यकतानुसार लोड किया जाता है। इसके अलावा, सम्मिलित करना महंगा है क्योंकि आपको सामान का एक लोड बाहर ले जाना होगा।

  2. रुकने की समस्या की अवांछनीयता के कारण, यह जानना असंभव है कि अपने "कूदो वापस ओएस" निर्देशों में कहां डालें। उदाहरण के लिए, यदि कोड में कुछ शामिल है while (true) {i++;}, तो आपको निश्चित रूप से उस लूप के अंदर एक हुक सम्मिलित करने की आवश्यकता है लेकिन लूप पर स्थिति ( trueयहां,) मनमाने ढंग से जटिल हो सकती है, इसलिए आप यह तय नहीं कर सकते कि यह कितनी देर तक चलता है। दूसरी ओर, हर लूप में हुक डालने के लिए यह बहुत अक्षम होगा : उदाहरण के लिए, ओएस के दौरान वापस बाहर कूदने for (i=0; i<3; i++) {j=j+i;}से प्रक्रिया बहुत धीमी हो जाएगी। और, उसी कारण से, आप उन्हें छोड़ने के लिए छोटे छोरों का पता नहीं लगा सकते हैं।

  3. रुकने की समस्या की अनिच्छा के कारण, यह जानना असंभव है कि क्या कोड इंजेक्शन ने कार्यक्रम का अर्थ बदल दिया है। उदाहरण के लिए, मान लें कि आप अपने C प्रोग्राम में फ़ंक्शन पॉइंटर्स का उपयोग करते हैं। नए कोड को इंजेक्ट करने से फ़ंक्शंस के स्थान बदल जाएंगे, इसलिए जब आप पॉइंटर के माध्यम से एक को कॉल करते हैं, तो आप गलत जगह पर कूद जाएंगे। यदि प्रोग्रामर कंपीटिड जंप का उपयोग करने के लिए पर्याप्त बीमार था, तो वे भी असफल हो जाएंगे।

  4. यह किसी भी एंटी-वायरस सिस्टम के साथ मीरा नर्क खेलता है, क्योंकि यह वायरस कोड को बदल देगा, और आपके सभी चेकसम को भी टकरा देगा।

आप कोड की नकल करके और किसी निश्चित लूप से अधिक बार निष्पादित करने वाले हुक में सम्मिलित करके समस्या को हल कर सकते हैं। हालाँकि, इसे निष्पादित करने की अनुमति देने से पहले पूरे कार्यक्रम के अत्यंत महंगे अनुकरण की आवश्यकता होगी।

दरअसल, यदि आप कोड इंजेक्ट करना चाहते हैं, तो संकलक इसे करने के लिए प्राकृतिक स्थान होगा। इस तरह, आपको इसे केवल एक बार करना होगा, लेकिन यह अभी भी ऊपर दिए गए दूसरे और तीसरे कारणों के लिए काम नहीं करेगा। (और कोई ऐसा संकलक लिख सकता है जो साथ नहीं खेलता था।)

तीन मुख्य तरीके हैं जो ओएस प्रक्रियाओं से नियंत्रण प्राप्त करता है।

  1. सहकारी (या गैर-निवारक) प्रणालियों में, एक yieldफ़ंक्शन है जो एक प्रक्रिया ओएस पर नियंत्रण वापस देने के लिए कॉल कर सकती है। बेशक, अगर यह आपका एकमात्र तंत्र है, तो आप अच्छी तरह से व्यवहार करने वाली प्रक्रियाओं पर निर्भर हैं और एक प्रक्रिया जो उपज नहीं देती है वह सीपीयू को समाप्त कर देगी जब तक कि यह समाप्त न हो जाए।

  2. उस समस्या से बचने के लिए, एक टाइमर इंटरप्ट का उपयोग किया जाता है। सीपीयू ओएस को सभी विभिन्न प्रकार के व्यवधानों के लिए कॉलबैक को पंजीकृत करने की अनुमति देता है जो सीपीयू लागू करता है। ओएस इस तंत्र का उपयोग समय-समय पर निकाल दिए जाने वाले टाइमर अवरोध के लिए कॉलबैक को पंजीकृत करने के लिए करता है, जो इसे अपने कोड को निष्पादित करने की अनुमति देता है।

  3. जब भी कोई प्रक्रिया किसी फ़ाइल से पढ़ने या किसी अन्य तरीके से हार्डवेयर के साथ इंटरैक्ट करने की कोशिश करती है, तो वह OS को इसके लिए काम करने के लिए कहती है। जब OS को किसी प्रक्रिया के द्वारा कुछ करने के लिए कहा जाता है, तो वह उस प्रक्रिया को रोक कर रखने का निर्णय ले सकता है और एक अलग चलना शुरू कर सकता है। यह थोड़ा मैकियावेलियन लग सकता है लेकिन यह करने के लिए सही बात है: डिस्क I / O धीमा है, इसलिए आप प्रक्रिया बी को चला सकते हैं जबकि प्रक्रिया ए सही जगह पर जाने के लिए धातु के कताई गांठ की प्रतीक्षा कर रही है। नेटवर्क I / O और भी धीमा है। कीबोर्ड I / O हिमनद है क्योंकि लोग गीगाहर्ट्ज़ प्राणी नहीं हैं।


5
क्या आप पिछले 2. बिंदु पर अधिक विकसित कर सकते हैं? मैं इस प्रश्न के बारे में उत्सुक हूं, और मैं यह महसूस कर रहा हूं कि स्पष्टीकरण यहां छोड़ दिया गया है। यह मुझे ऐसा लगता है जैसे प्रश्न "कैसे ओएस प्रक्रिया से सीपीयू को वापस लेता है" और आपका उत्तर बताता है "ओएस इसे संभालता है"। पर कैसे? अपने पहले उदाहरण में अनंत लूप लें: यह कंप्यूटर को फ्रीज कैसे नहीं करता है?
BiAiB

3
कुछ OS करते हैं, अधिकांश OS कम से कम "लिंकिंग" करने के लिए कोड के साथ गड़बड़ करते हैं, इसलिए कार्यक्रम को किसी भी पते पर लोड किया जा सकता है
इयान रिंगरोज

1
@BiAiB यहाँ महत्वपूर्ण शब्द "व्यवधान" है। सीपीयू सिर्फ एक ऐसी चीज नहीं है जो किसी निर्देश की एक धारा को संसाधित करता है, यह एक अलग स्रोत से अतुल्यकालिक रूप से बाधित भी हो सकता है - सबसे महत्वपूर्ण बात यह है कि हमारे लिए, I / O और घड़ी बीच में आती है। चूंकि केवल कर्नेल-स्पेस कोड इंटरप्ट को संभाल सकता है, विंडोज किसी भी समय किसी भी चल रही प्रक्रिया से "चोरी" करने में सक्षम होना सुनिश्चित कर सकता है। बाधा हैंडलर जो भी कोड चाहते हैं, उसे निष्पादित कर सकते हैं, जिसमें "सीपीयू के रजिस्टरों को कहीं स्टोर करें और उन्हें यहां से (एक और थ्रेड)" बहाल करें। अत्यंत सरलीकृत, लेकिन यह संदर्भ स्विच है।
लुआयन

1
इस उत्तर को जोड़ना; अंक 2 और 3 में संदर्भित मल्टीटास्किंग की शैली को "प्रीमेप्टिव मल्टीटास्किंग" कहा जाता है, यह नाम ओएस की एक चलने वाली प्रक्रिया को पूर्व निर्धारित करने की क्षमता को संदर्भित करता है। पुराने ऑपरेटिंग सिस्टम पर अक्सर सहकारी मल्टीटास्किंग का उपयोग किया जाता था; विंडोज़ पर कम से कम प्रीमेप्टिव मल्टीटास्किंग को विंडोज 95 तक पेश नहीं किया गया था। मैंने आज कम से कम एक औद्योगिक नियंत्रण प्रणाली का उपयोग करने के बारे में पढ़ा है जो अभी भी अपने वास्तविक समय के सहकारी मल्टीटास्किंग व्यवहार के लिए केवल विंडोज 3.1 का उपयोग करता है।
जेसन सी

3
@BiAiB वास्तव में, आप गलत हैं। डेस्कटॉप CPUs i486 के बाद से क्रमिक रूप से और सिंक्रोनाइज़ नहीं करते हैं। हालाँकि, पुराने CPU में अभी भी एसिंक्रोनस इनपुट थे - इंटरप्ट। केवल सीपीयू पर एक पिन की तरह एक हार्डवेयर अवरोध अनुरोध (आईआरक्यू) की कल्पना करें - जब यह मिलता है 1, तो सीपीयू जो कुछ भी कर रहा है उसे रोक देता है, और बाधा को संसाधित करना शुरू कर देता है (जिसका मूल रूप से मतलब है "स्थिति को संरक्षित करें और स्मृति में एक पते पर कूदें")। व्यवधान को संभालने वाला स्वयं x86या कोई भी कोड नहीं है, यह शाब्दिक रूप से हार्डवेर है। कूदने के बाद, यह फिर से (किसी भी) x86कोड को निष्पादित करता है । धागे एक तरह से उच्च अमूर्त हैं।
लुआँ

12

जबकि डेविड रिचेर्बी का जवाब एक अच्छा है, यह इस बात पर संदेह करता है कि आधुनिक ऑपरेटिंग सिस्टम मौजूदा कार्यक्रमों को कैसे रोकते हैं। मेरा जवाब x86 या x86_64 आर्किटेक्चर के लिए सटीक होना चाहिए, जो कि डेस्कटॉप और लैपटॉप के लिए आमतौर पर उपयोग होने वाला एकमात्र है। अन्य आर्किटेक्चर के पास इसे प्राप्त करने के समान तरीके होने चाहिए।

जब ऑपरेटिंग सिस्टम शुरू हो रहा है, तो यह एक बाधा तालिका स्थापित करता है। टेबल की प्रत्येक प्रविष्टि ऑपरेटिंग सिस्टम के अंदर कोड के एक बिट की ओर इशारा करती है। जब इंटरप्ट होता है, जो सीपीयू द्वारा नियंत्रित होता है, तो यह इस तालिका को देखता है और कोड को कॉल करता है। विभिन्न व्यवधान हैं, जैसे शून्य से विभाजित करना, अमान्य कोड और कुछ ऑपरेटिंग सिस्टम परिभाषित।

यह है कि उपयोगकर्ता प्रक्रिया कर्नेल से कैसे बात करती है, जैसे कि यह डिस्क को पढ़ना / लिखना चाहता है या कुछ और जिसे ऑपरेटिंग सिस्टम कर्नेल नियंत्रित करता है। एक ऑपरेटिंग सिस्टम एक टाइमर भी सेट करेगा जो समाप्त होने पर एक बाधा को बुलाता है, इसलिए चल रहे कोड को उपयोगकर्ता प्रोग्राम से ऑपरेटिंग सिस्टम कर्नेल में जबरन बदल दिया जाता है, और कर्नेल अन्य प्रोग्राम को चलाने के लिए कतार जैसे अन्य कार्य कर सकता है।

मेमोरी से, जब ऐसा होता है, तो ऑपरेटिंग सिस्टम कर्नेल को कोड को सहेजना होता है, और जब कर्नेल ने ऐसा करना समाप्त कर दिया है जिसे उसे करने की आवश्यकता है, तो वह प्रोग्राम की पिछली स्थिति को पुनर्स्थापित करता है। इस प्रकार कार्यक्रम यह भी नहीं जानता कि यह बाधित था।

प्रक्रिया दो कारणों से इंटरप्ट टेबल को नहीं बदल सकती है, पहला यह है कि यह एक संरक्षित वातावरण में चल रहा है, इसलिए यदि यह कुछ संरक्षित विधानसभा कोड को कॉल करने की कोशिश करता है तो सीपीयू एक और रुकावट को ट्रिगर करेगा। दूसरा कारण वर्चुअल मेमोरी है। वास्तविक मेमोरी में इंटरप्ट टेबल का स्थान 0x0 से 0x3FF पर होता है, लेकिन उपयोगकर्ता प्रक्रियाओं के साथ वह स्थान आमतौर पर मैप नहीं किया जाता है, और अनमैप मेमोरी को पढ़ने की कोशिश करने से एक और रुकावट आ जाएगी, इसलिए संरक्षित फ़ंक्शन और वास्तविक रैम पर लिखने की क्षमता के बिना। , उपयोगकर्ता प्रक्रिया इसे बदल नहीं सकती है।


4
व्यवधान को ऑपरेटिंग सिस्टम द्वारा परिभाषित नहीं किया जाता है, वे हार्डवेयर द्वारा दिए जाते हैं। और अधिकांश वर्तमान आर्किटेक्चर के पास ऑपरेटिंग सिस्टम को कॉल करने के लिए विशेष निर्देश हैं। i386 ने इसके लिए एक (सॉफ्टवेयर जनरेट किया हुआ) रुकावट का इस्तेमाल किया, लेकिन यह अब उसके उत्तराधिकारियों पर ऐसा नहीं किया गया है।
वॉनब्रांड

2
मुझे पता है कि इंटरप्ट को सीपीयू द्वारा परिभाषित किया गया है, लेकिन कर्नेल पॉइंटर्स सेट करता है। मैंने संभवतः इसे बुरी तरह समझाया। मैंने यह भी सोचा कि लाइनक्स ने अभी भी कर्नेल से बात करने के लिए int 9 का उपयोग किया है, लेकिन शायद अब बेहतर तरीके हैं।
प्रोग्राममेउड

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

(साथ ही असली मोड इंटरप्ट टेबल को भी स्थानांतरित कर दिया गया है - मेमोरी के पहले पेज पर लॉक नहीं किया गया है - 8086 के बाद से।)
जेसन C

1
यह उत्तर एक महत्वपूर्ण विवरण याद करता है। जब एक बाधा आग जाती है, तो सीपीयू सीधे कर्नेल पर नहीं जाता है। इसके बजाय, यह पहले मौजूदा रजिस्टरों को बचाता है, फिर दूसरे स्टैक पर स्विच करता है, और उसके बाद ही कर्नेल कहा जाता है। एक यादृच्छिक प्रोग्राम से एक यादृच्छिक स्टैक के साथ कर्नेल को कॉल करना एक बुरा विचार होगा। साथ ही, अंतिम भाग भ्रामक है। बिना पढ़े मेमोरी को पढ़ने के लिए आपको "कोशिश करना" में बाधा नहीं आएगी; यह बस असंभव है। आप वर्चुअल एड्रेस से पढ़ते हैं और अनमैन्ड मेमोरी में सिर्फ वर्चुअल एड्रेस नहीं होता है।
एमएसलटर्स

5

सीपीयू घड़ी इंटरप्ट हैंडलर की वजह से ओएस कर्नेल चालू प्रक्रिया से वापस नियंत्रित हो जाता है, न कि इस प्रक्रिया में कोड इंजेक्ट करके।

वे कैसे काम करते हैं और ओएस गुठली उन्हें कैसे संभालती है और विभिन्न विशेषताओं को लागू करने के बारे में अधिक स्पष्टीकरण प्राप्त करने के लिए इंटरप्ट के बारे में पढ़ना चाहिए ।


केवल घड़ी का अवरोध नहीं: कोई भी व्यवधान नहीं। और निर्देशों को बदलने का तरीका भी।
गिल्स एसओ- बुराई को रोकना '

3

वहाँ है : एक विधि है कि तुम क्या वर्णन करने के लिए इसी तरह की सहकारी मल्टीटास्किंग । ओएस निर्देश सम्मिलित नहीं करता है, लेकिन प्रत्येक कार्यक्रम को ओएस कार्यों को कॉल करने के लिए लिखा जाना चाहिए जो सहकारी प्रक्रियाओं में से एक को चलाने के लिए चुन सकते हैं। इसके आपके द्वारा वर्णित नुकसान हैं: एक कार्यक्रम दुर्घटनाग्रस्त होने से पूरी प्रणाली बाहर हो जाती है। 3.0 तक और सहित विंडोज ने इस तरह काम किया; 3.0 "संरक्षित मोड" में और ऊपर नहीं किया।

प्री-इप्टिव मल्टीटास्किंग (इन दिनों सामान्य प्रकार) इंटरप्ट के एक बाहरी स्रोत पर निर्भर करता है। व्यवधान नियंत्रण के सामान्य प्रवाह को ओवरराइड करता है और आमतौर पर रजिस्टरों को कहीं बाहर सहेजता है, इसलिए सीपीयू कुछ और कर सकता है और फिर पारदर्शी रूप से कार्यक्रम को फिर से शुरू कर सकता है। बेशक, ऑपरेटिंग सिस्टम "जब आप यहां इंटरप्ट को फिर से शुरू करते हैं तो छोड़ देते हैं" रजिस्टर को बदल सकते हैं, इसलिए यह एक अलग प्रक्रिया के अंदर फिर से शुरू होता है।

(कुछ प्रणालियों कर कार्यक्रम लोड पर एक सीमित रास्ते, "thunking" कहा जाता है में फिर से लिखने के निर्देश, और Transmeta प्रोसेसर गतिशील अपनी ही अनुदेश सेट के लिए फिर कंपाइल)


AFAICR 3.1 सहकारी था। Win95 वह जगह थी जहां प्रीमेप्टिव मल्टीटास्किंग आती थी। संरक्षित मोड में मुख्य रूप से एड्रेस स्पेस का अलगाव (जो स्थिरता में सुधार करता है, लेकिन मोटे तौर पर असंबंधित कारणों के लिए) होता है।
cHao

Thunking एप्लिकेशन में कोड को फिर से नहीं लिखता है या न ही इंजेक्ट करता है। लोडर जो संशोधित है, वह ओएस आधारित है और एप्लिकेशन का उत्पाद नहीं है। व्याख्यात्मक भाषाएं जो संकलित हैं जैसे कि जेआईटी संकलक कोड का उपयोग नहीं करते हैं, न ही कोड में कुछ भी इंजेक्ट करते हैं। वे स्रोत कोड को एक निष्पादन योग्य में अनुवाद करते हैं। दोबारा, यह एक आवेदन में कोड को इंजेक्ट करने के समान नहीं है।
डेव गॉर्डन

Transmeta ने अपने स्रोत के रूप में x86 निष्पादन योग्य कोड लिया, न कि एक व्याख्यात्मक भाषा। और मैं एक मामला है जिसमें कोड के बारे में सोचा गया है है एक डिबगर के तहत चल रहा: इंजेक्शन। X86 सिस्टम आमतौर पर "INT 03" के साथ ब्रेकपाइंट पर निर्देश को ओवरराइट करता है, जो डिबगर में फंस जाता है। फिर से शुरू करने पर मूल ओपकोड पुनः स्थापित किया जाता है।
pjc50

डिबगिंग शायद ही किसी को कैसे एक आवेदन चलाता है; उस एप्लिकेशन के डेवलपर से परे। इसलिए मुझे नहीं लगता कि यह वास्तव में ओपी की मदद करता है।
डेव गॉर्डन

3

मल्टी-टास्किंग में कोड इंजेक्शन जैसी किसी चीज की जरूरत नहीं होती है। विंडोज की तरह एक ऑपरेटिंग सिस्टम में, शेड्यूलर नामक ऑपरेटिंग सिस्टम कोड का एक घटक होता है जो एक हार्डवेयर टाइमर द्वारा ट्रिगर किए गए हार्डवेयर अवरोध पर निर्भर करता है। इसका उपयोग ऑपरेटिंग सिस्टम द्वारा विभिन्न कार्यक्रमों और स्वयं के बीच स्विच करने के लिए किया जाता है, जिससे यह सब हमारी मानवीय धारणा के अनुरूप प्रतीत होता है।

असल में, ऑपरेटिंग सिस्टम हार्डवेयर टाइमर को हर बार बंद करने के लिए प्रोग्राम करता है ... शायद एक सेकंड में 100 गुना। जब टाइमर बंद हो जाता है, तो यह एक हार्डवेयर रुकावट उत्पन्न करता है - एक सिग्नल जो सीपीयू को बताता है कि वह क्या कर रहा है, स्टैक पर अपनी स्थिति को बचाने के लिए, इसके मोड को कुछ और विशेषाधिकार प्राप्त करें, और कोड को निष्पादित करें जो इसे विशेष रूप से नामित में मिलेगा स्मृति में जगह। यह कोड शेड्यूलर का हिस्सा होता है, जो यह तय करता है कि आगे क्या किया जाना चाहिए। यह किसी अन्य प्रक्रिया को फिर से शुरू करने के लिए हो सकता है, जिस स्थिति में इसे "संदर्भ स्विच" के रूप में जाना जाता है - दूसरी प्रक्रिया के साथ इसकी वर्तमान स्थिति (आभासी मेमोरी टेबल सहित) की संपूर्णता को बदलना होगा। एक प्रक्रिया के बदले में, उसे उस प्रक्रिया के सभी संदर्भों को पुनर्स्थापित करना होगा,

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

इसमें से कोई भी "कोड इंजेक्शन" शामिल नहीं है ... यह सीपीयू की हार्डवेयर विशेषताओं और इसके सहायक सर्किटरी के साथ-साथ ऑपरेटिंग सिस्टम में निहित कोड पर आधारित है।


2

मुझे लगता है कि आप जो वर्णन करते हैं उसके निकटतम वास्तविक दुनिया उदाहरण वीएमवेयर द्वारा उपयोग की जाने वाली तकनीकों में से एक है , बाइनरी अनुवाद का उपयोग करके पूर्ण वर्चुअलाइजेशन ।

VMware एक ही हार्डवेयर पर ऑपरेटिंग सिस्टम निष्पादित करने के साथ एक या एक से अधिक परत के नीचे कार्य करता है।

निष्पादित किए जाने वाले अधिकांश निर्देशों (जैसे सामान्य अनुप्रयोगों में) को हार्डवेयर का उपयोग करके वर्चुअलाइज्ड किया जा सकता है, लेकिन एक ओएस कर्नेल खुद उन निर्देशों का उपयोग करता है, जिन्हें वर्चुअलाइज नहीं किया जा सकता है, क्योंकि यदि अनुमान ओएस के मशीन कोड को अनमॉडिफाइड किया गया था, तो यह टूट जाएगा "VMware होस्ट के नियंत्रण के लिए। उदाहरण के लिए, एक अतिथि ओएस को सबसे विशेषाधिकार प्राप्त सुरक्षा रिंग में चलने की जरूरत है, और इंटरप्ट टेबल की स्थापना की जाएगी। अगर ऐसा करने की अनुमति दी जाती, तो VMware हार्डवेयर का नियंत्रण खो देता।

VMware इसे लागू करने से पहले OS कोड में उन निर्देशों को फिर से लिखता है, उन्हें VMware कोड में कूदता है जो वांछित प्रभाव का अनुकरण करता है।

तो यह तकनीक कुछ हद तक आपके द्वारा वर्णित के अनुरूप है।


2

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

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


एआरएम प्रोसेसर पर एफपी विधि अभी भी उपयोग में है, जो कि x86 सीपीयू के विपरीत अभी भी एफपी-कम वेरिएंट है। लेकिन यह सबसे दुर्लभ है क्योंकि एआरएम का उपयोग समर्पित उपकरणों में होता है। उन वातावरणों में यह आमतौर पर जाना जाता है कि सीपीयू में एफपी क्षमताएं होंगी या नहीं।
एमएसलेट्स

इनमें से किसी भी मामले में ओएस ने एप्लिकेशन में कोड इंजेक्ट नहीं किया। ओएस को कोड इंजेक्ट करने के लिए, इसे प्राप्त नहीं होने वाले एप्लिकेशन को "संशोधित" करने के लिए सॉफ़्टवेयर विक्रेता द्वारा लाइसेंस की आवश्यकता होगी। OS का कोड इंजेक्ट न करें।
डेव गॉर्डन

@DaveGordon फंस गए निर्देशों को यथोचित रूप से कहा जा सकता है कि आवेदन में ओएस इंजेक्शन कोड है।
गाइल्स का SO- बुराई से रोकना '

@MSalters फंसे हुए निर्देश आमतौर पर आभासी मशीनों में होते हैं।
गिल्स एसओ- बुराई को रोकना '
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.