थंक: Difference between revisions
From Vigyanwiki
(Created page with "{{otheruses}}{{wiktionary}} {{short description|Computing term}} {{use dmy dates|date=January 2020|cs1-dates=y}} कंप्यूटर प्रोग्रामिं...") |
No edit summary |
||
| (9 intermediate revisions by 3 users not shown) | |||
| Line 2: | Line 2: | ||
{{short description|Computing term}} | {{short description|Computing term}} | ||
{{use dmy dates|date=January 2020|cs1-dates=y}} | {{use dmy dates|date=January 2020|cs1-dates=y}} | ||
[[कंप्यूटर प्रोग्रामिंग]] में, थंक एक [[सबरूटीन]] है जिसका उपयोग किसी गणना को दूसरे सबरूटीन में इंजेक्ट करने के लिए किया जाता है। थंक्स का उपयोग मुख्य रूप से किसी गणना में देरी करने के लिए किया जाता है, जब तक कि उसके परिणाम की आवश्यकता न हो, या अन्य सबरूटीन की सूत्रपात या अंत में संचालन सम्मिलित करने के लिए किया जाता है। उनके पास [[कोड जनरेशन (कंपाइलर)]] और [[मॉड्यूलर प्रोग्रामिंग]] में कई अन्य अनुप्रयोग हैं। | |||
इस शब्द की उत्पत्ति क्रिया के एक सनकी अनियमित रूप के रूप में हुई है। यह [[ALGOL 60|एल्गोल 60]] कंपाइलरों में थंक्स के मूल उपयोग को संदर्भित करता है, जिसे यह निर्धारित करने के लिए विशेष विश्लेषण (विचार) की आवश्यकता होती है कि किस प्रकार की दिनचर्या उत्पन्न की जाए।<ref> | |||
Eric Raymond rejects "a couple of onomatopoeic myths circulating about the origin of this term" and cites the inventors of the thunk recalling that the term "was coined after they realized (in the wee hours after hours of discussion) that the type of an argument in Algol-60 could be figured out in advance with a little compile-time thought [...] In other words, it had 'already been thought of'; thus it was christened a ''thunk'', which is 'the past tense of "think" at two in the morning'. See: {{cite book | Eric Raymond rejects "a couple of onomatopoeic myths circulating about the origin of this term" and cites the inventors of the thunk recalling that the term "was coined after they realized (in the wee hours after hours of discussion) that the type of an argument in Algol-60 could be figured out in advance with a little compile-time thought [...] In other words, it had 'already been thought of'; thus it was christened a ''thunk'', which is 'the past tense of "think" at two in the morning'. See: {{cite book | ||
| last1 = Raymond | | last1 = Raymond | ||
| Line 20: | Line 21: | ||
| access-date = 2015-05-25 | | access-date = 2015-05-25 | ||
}} | }} | ||
</ref><ref>See Ingerman (1961): "The translator knows what kind of thunk to create by considering the formation of the actual parameter and the previously scanned declarations.… [W]hen a procedure declaration is being compiled, the translator, again by observing syntax, knows what kind of address to expect from a thunk."</ref> | </ref><ref>See Ingerman (1961): "The translator knows what kind of thunk to create by considering the formation of the actual parameter and the previously scanned declarations.… [W]hen a procedure declaration is being compiled, the translator, again by observing syntax, knows what kind of address to expect from a thunk."</ref> | ||
==पृष्ठभूमि== | ==पृष्ठभूमि== | ||
[[संकलक]] अनुसंधान के प्रारंभिक वर्षों में विभिन्न [[मूल्यांकन रणनीति]] के साथ व्यापक प्रयोग देखा गया। एक महत्वपूर्ण प्रश्न यह था कि यदि तर्क स्थिरांक के बजाय मनमाने ढंग से गणितीय अभिव्यक्ति हो सकते हैं तो सबरूटीन कॉल को कैसे संकलित किया जाए। एक दृष्टिकोण, जिसे [[ | [[संकलक]] अनुसंधान के प्रारंभिक वर्षों में विभिन्न [[मूल्यांकन रणनीति]] के साथ व्यापक प्रयोग देखा गया। एक महत्वपूर्ण प्रश्न यह था कि यदि तर्क स्थिरांक के बजाय मनमाने ढंग से गणितीय अभिव्यक्ति हो सकते हैं तो सबरूटीन कॉल को कैसे संकलित किया जाए। एक दृष्टिकोण, जिसे [[Index.php?title=कॉल बाय वैल्यू|कॉल बाय वैल्यू]] के रूप में जाना जाता है, कॉल से पहले सभी तर्कों की गणना करता है और फिर परिणामी मानों को सबरूटीन में भेजता है। प्रतिद्वंद्वी [[Index.php?title=कॉल बाय नेम|"कॉल बाय नेम"]] दृष्टिकोण में, सबरूटीन को अमूल्यांकित तर्क अभिव्यक्ति प्राप्त होती है और उसे इसका मूल्यांकन करना चाहिए। | ||
"नेम से कॉल करें" का एक सरल कार्यान्वयन सबरूटीन में संबंधित पैरामीटर की प्रत्येक उपस्थिति के लिए एक तर्क अभिव्यक्ति के कोड को प्रतिस्थापित कर सकता है, लेकिन यह सबरूटीन के कई संस्करण और अभिव्यक्ति कोड की कई प्रतियां उत्पन्न कर सकता है। एक सुधार के रूप में, कंपाइलर एक सहायक सबरूटीन उत्पन्न कर सकता है, जिसे थंक कहा जाता है, जो तर्क के मूल्य की गणना करता है। इस सहायक सबरूटीन का पता और वातावरण{{efn|A thunk is an early limited type of [[Closure (computer programming)|closure]]. The environment passed for the thunk is that of the expression, not that of the called routine.<ref>{{cite journal | |||
| title = Comments on the Implementation of Recursive Procedures and Blocks in ALGOL | | title = Comments on the Implementation of Recursive Procedures and Blocks in ALGOL | ||
| author = E. T. Irons | | author = E. T. Irons | ||
| Line 40: | Line 39: | ||
|doi-access = free | |doi-access = free | ||
}} | }} | ||
</ref>}} | </ref>}} को पुनः मूल तर्क के स्थान पर मूल सबरूटीन में भेज दिया जाता है, जहां इसे आवश्यकतानुसार कई बार बुलाया जा सकता है। पीटर इंगरमैन ने सबसे पहले एल्गोल 60 प्रोग्रामिंग भाषा के संदर्भ में थंक्स का वर्णन किया, जो "कॉल-बाय-नेम" मूल्यांकन का समर्थन करता है।<ref>{{cite journal | last=Ingerman | first=P. Z. | title=Thunks: a way of compiling procedure statements with some comments on procedure declarations | journal=Communications of the ACM | publisher=Association for Computing Machinery (ACM) | volume=4 | issue=1 | date=1961-01-01 | issn=0001-0782 | doi=10.1145/366062.366084 | pages=55–58 | s2cid=14646332 | doi-access=free }}</ref> | ||
===कार्यात्मक प्रोग्रामिंग=== | ===कार्यात्मक प्रोग्रामिंग=== | ||
यदपि सॉफ्टवेयर उद्योग बड़े पैमाने पर कॉल-बाय-वैल्यू और [[Index.php?title=कॉल-बाय-रेफरेंस|कॉल-बाय-रेफरेंस]], मूल्यांकन पर मानकीकृत है,<ref>{{cite book|last=Scott|first=Michael|title=प्रोग्रामिंग भाषा व्यावहारिकता|year=2009|page=395}}</ref> [[कार्यात्मक प्रोग्रामिंग]] समुदाय में कॉल-बाय-नेम का सक्रिय अध्ययन प्रभावशील रहा। इस अनुसंधान ने [[आलसी मूल्यांकन]] प्रोग्रामिंग भाषाओं की एक श्रृंखला तैयार की जिसमें कॉल-बाय-नेम का कुछ प्रकार मानक मूल्यांकन रणनीति है। इन भाषाओं के लिए कंपाइलर, जैसे कि [[ग्लासगो हास्केल कंपाइलर]], ने थंक्स पर बहुत अधिक भरोसा किया है, इसके अतिरिक्त सुविधा यह है कि थंक्स अपने प्रारंभिक परिणाम को सहेजते हैं ताकि वे इसे पुनर्गणना करने से बच सकें;<ref>{{cite book|first=Simon|last=Marlow|title=हास्केल में समानांतर और समवर्ती प्रोग्रामिंग|year=2013|page=10}}</ref> इसे [[संस्मरण]] या कॉल बाय नीड के रूप में जाना जाता है। | |||
कार्यात्मक प्रोग्रामिंग भाषाओं ने प्रोग्रामर को स्पष्ट रूप से थंक्स उत्पन्न करने की भी अनुमति दी है। यह स्रोत कोड में एक अज्ञात फ़ंक्शन में एक तर्क अभिव्यक्ति को लपेटकर किया जाता है जिसका अपना कोई पैरामीटर नहीं होता है। यह अभिव्यक्ति को तब तक | कार्यात्मक प्रोग्रामिंग भाषाओं ने प्रोग्रामर को स्पष्ट रूप से थंक्स उत्पन्न करने की भी अनुमति दी है। यह स्रोत कोड में एक अज्ञात फ़ंक्शन में एक तर्क अभिव्यक्ति को लपेटकर किया जाता है जिसका अपना कोई पैरामीटर नहीं होता है। यह अभिव्यक्ति को मूल्यांकन तब तक रोकता है जब तक कि प्राप्तकर्ता फ़ंक्शन अज्ञात फ़ंक्शन को कॉल नहीं करता है, जिससे कॉल-बाय-नेम के समान प्रभाव प्राप्त होता है।<ref>{{cite book|first=Christian|last=Queinnec|title=छोटे टुकड़ों में लिस्प|year=2003|page=176}}</ref> अन्य प्रोग्रामिंग भाषाओं में अनाम फ़ंक्शंस को अपनाने से यह क्षमता व्यापक रूप से उपलब्ध हो गई है। | ||
निम्नलिखित जावास्क्रिप्ट ( | निम्नलिखित जावास्क्रिप्ट (ईएस6) में एक सरल प्रदर्शन है:<syntaxhighlight lang="js"> | ||
<syntaxhighlight lang="js"> | |||
// 'hypot' is a binary function | // 'hypot' is a binary function | ||
const hypot = (x, y) => Math.sqrt(x * x + y * y); | const hypot = (x, y) => Math.sqrt(x * x + y * y); | ||
| Line 68: | Line 63: | ||
===वस्तु-उन्मुख प्रोग्रामिंग=== | ===वस्तु-उन्मुख प्रोग्रामिंग=== | ||
थंक्स [[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ]] प्लेटफ़ॉर्म में उपयोगी होते हैं जो एक [[क्लास (कंप्यूटर प्रोग्रामिंग)]] को एकाधिक इनहेरिटेंस की अनुमति देते हैं, जिससे ऐसी स्थिति उत्पन्न होती है जहां एक ही [[विधि (कंप्यूटर प्रोग्रामिंग)]] को कई | थंक्स [[ ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग ]] प्लेटफ़ॉर्म में उपयोगी होते हैं जो एक [[क्लास (कंप्यूटर प्रोग्रामिंग)]] को एकाधिक इनहेरिटेंस की अनुमति देते हैं, जिससे ऐसी स्थिति उत्पन्न होती है जहां एक ही [[विधि (कंप्यूटर प्रोग्रामिंग)]] को कई अंतराफलक में से किसी एक के माध्यम से बुलाया जा सकता है। निम्नलिखित कोड [[C++|सी++]] में ऐसी स्थिति को दर्शाता है। | ||
<syntaxhighlight lang="cpp"> | <syntaxhighlight lang="cpp"> | ||
| Line 105: | Line 100: | ||
} | } | ||
</syntaxhighlight> | </syntaxhighlight> | ||
इस उदाहरण में, प्रत्येक वर्ग ए, बी और सी के लिए उत्पन्न कोड में एक [[प्रेषण तालिका]] | इस उदाहरण में, प्रत्येक वर्ग ए, बी और सी के लिए उत्पन्न कोड में एक [[प्रेषण तालिका]] सम्मिलित होगी जिसका उपयोग उसी प्रकार के संदर्भ के माध्यम से उस प्रकार की किसी वस्तु पर {{code|एक्सेस}} को कॉल करने के लिए किया जा सकता है। क्लास सी में एक अतिरिक्त डिस्पैच टेबल होगी, जिसका उपयोग प्रकार बी के संदर्भ के माध्यम से प्रकार सी की एक वस्तु पर {{code|एक्सेस}} को कॉल करने के लिए किया जाता है। अभिव्यक्ति {{code|बी->एक्सेस()}}प्रकार के आधार पर बी की अपनी प्रेषण तालिका या अतिरिक्त सी तालिका का उपयोग करेगा। ऑब्जेक्ट बी का संदर्भ देता है। यदि यह सी प्रकार के ऑब्जेक्ट को संदर्भित करता है, तो कंपाइलर को यह सुनिश्चित करना होगा कि सी {{code|एक्सेस}} कार्यान्वयन उस ऑब्जेक्ट के विरासत वाले बी भाग के बजाय संपूर्ण सी ऑब्जेक्ट के लिए [[यह (कंप्यूटर प्रोग्रामिंग)]] प्राप्त करता हो।<ref name=BS99>{{cite journal | ||
|last1 = Stroustrup | |last1 = Stroustrup | ||
|first1 = Bjarne | |first1 = Bjarne | ||
| Line 117: | Line 112: | ||
|access-date = 4 August 2014 | |access-date = 4 August 2014 | ||
}}</ref> | }}</ref> | ||
अभी वर्णित समाधान में पहले वर्णित कॉल-बाय- | इस सूचक समायोजन समस्या के प्रत्यक्ष दृष्टिकोण के रूप में, कंपाइलर प्रत्येक प्रेषण तालिका प्रविष्टि में एक पूर्णांक ऑफसेट सम्मिलित कर सकता है। यह ऑफसेट संदर्भ के पते और विधि कार्यान्वयन के लिए आवश्यक पते के बीच का अंतर है। इन प्रेषण तालिकाओं के माध्यम से प्रत्येक कॉल के लिए उत्पन्न कोड को ऑफसेट पुनर्प्राप्त करना होगा और विधि को कॉल करने से पहले इंस्टेंस पते को समायोजित करने के लिए इसका उपयोग करना होगा। | ||
अभी वर्णित समाधान में पहले वर्णित कॉल-बाय-नेम के सरल कार्यान्वयन के समान समस्याएं हैं: कंपाइलर एक तर्क (उदाहरण पता) की गणना करने के लिए कोड की कई प्रतियां उत्पन्न करता है, जबकि ऑफसेट को पकड़ने के लिए प्रेषण तालिका आकार भी बढ़ाता है। एक विकल्प के रूप में, कंपाइलर सी के कार्यान्वयन के साथ एक समायोजक थंक उत्पन्न कर सकता है {{code|एक्सेस}} जो इंस्टेंस एड्रेस को आवश्यक मात्रा से समायोजित करता है और फिर विधि को कॉल करता है। थंक बी के लिए सी की प्रेषण तालिका में दिखाई दे सकता है, जिससे कॉल करने वालों को पते को स्वयं समायोजित करने की आवश्यकता समाप्त हो जाती है।<ref name=DH01>{{cite conference | |||
|conference = 11th OOPSLA 1996: San Jose, California, USA | |conference = 11th OOPSLA 1996: San Jose, California, USA | ||
|book-title = Proceedings of the 1996 ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages & Applications, OOPSLA 1996, San Jose, California, USA, October 6-10, 1996 | |book-title = Proceedings of the 1996 ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages & Applications, OOPSLA 1996, San Jose, California, USA, October 6-10, 1996 | ||
| Line 133: | Line 129: | ||
|access-date = 24 February 2011 | |access-date = 24 February 2011 | ||
}}{{dead link|date=June 2023}}</ref> | }}{{dead link|date=June 2023}}</ref> | ||
===संख्यात्मक गणना के लिए कई बिंदुओं पर मूल्यांकन की आवश्यकता होती है=== | ===संख्यात्मक गणना के लिए कई बिंदुओं पर मूल्यांकन की आवश्यकता होती है=== | ||
एकीकरण जैसी गणनाओं के लिए कई बिंदुओं पर एक अभिव्यक्ति की गणना करने की आवश्यकता होती है। | एकीकरण जैसी गणनाओं के लिए कई बिंदुओं पर एक अभिव्यक्ति की गणना करने की आवश्यकता होती है। नेम से कॉल का उपयोग इस उद्देश्य के लिए उन भाषाओं में किया गया था जो [[ समापन (कंप्यूटर प्रोग्रामिंग) ]] या [[प्रक्रियात्मक पैरामीटर]] का समर्थन नहीं करते थे। | ||
===इंटरऑपरेबिलिटी=== | ===इंटरऑपरेबिलिटी=== | ||
सॉफ्टवेयर मॉड्यूल के बीच अंतरसंचालनीयता प्रदान करने के लिए थंक्स का व्यापक रूप से उपयोग किया गया है जिनकी दिनचर्या एक दूसरे को सीधे कॉल नहीं कर सकती है। ऐसा इसलिए हो सकता है क्योंकि रूटीन में अलग-अलग [[ सम्मलेन बुलाना ]] होते हैं, अलग-अलग [[सीपीयू मोड]] या [[ पता स्थान ]] में चलते हैं, या कम से कम एक [[ आभासी मशीन ]] में चलता है। एक कंपाइलर (या अन्य उपकरण) एक थंक उत्पन्न करके इस समस्या को हल कर सकता है जो लक्ष्य रूटीन को कॉल करने के लिए आवश्यक अतिरिक्त चरणों को स्वचालित करता है, चाहे वह तर्कों को बदलना हो, उन्हें किसी अन्य स्थान पर कॉपी करना हो, या सीपीयू मोड को स्विच करना हो। एक सफल थंक सामान्य कॉल की तुलना में कॉलर द्वारा किए जाने वाले अतिरिक्त काम को कम कर देता है। | सॉफ्टवेयर मॉड्यूल के बीच अंतरसंचालनीयता प्रदान करने के लिए थंक्स का व्यापक रूप से उपयोग किया गया है जिनकी दिनचर्या एक दूसरे को सीधे कॉल नहीं कर सकती है। ऐसा इसलिए हो सकता है क्योंकि रूटीन में अलग-अलग [[ सम्मलेन बुलाना ]] होते हैं, अलग-अलग [[सीपीयू मोड]] या [[ पता स्थान ]] में चलते हैं, या कम से कम एक [[ आभासी मशीन ]] में चलता है। एक कंपाइलर (या अन्य उपकरण) एक थंक उत्पन्न करके इस समस्या को हल कर सकता है जो लक्ष्य रूटीन को कॉल करने के लिए आवश्यक अतिरिक्त चरणों को स्वचालित करता है, चाहे वह तर्कों को बदलना हो, उन्हें किसी अन्य स्थान पर कॉपी करना हो, या सीपीयू मोड को स्विच करना हो। एक सफल थंक सामान्य कॉल की तुलना में कॉलर द्वारा किए जाने वाले अतिरिक्त काम को कम कर देता है। | ||
इंटरऑपरेबिलिटी थंक्स पर अधिकांश साहित्य [[MS-DOS]], | इंटरऑपरेबिलिटी थंक्स पर अधिकांश साहित्य [[MS-DOS|एमएस-डॉस]], ओएस/2 सहित विभिन्न [[विंटेल]] प्लेटफार्मों से संबंधित है।<ref name="Calcote_1995">{{cite journal |author-first=John |author-last=Calcote |title=थंकिंग: OS/2 2.0 में 16-बिट लाइब्रेरी का उपयोग करना|journal=OS/2 Developer Magazine |volume=7 |issue=3 |pages=48–56 |date=May 1995 |url=https://archive.org/details/Readme_20181018/OS2DevMag-V7N3/page/48/mode/2up}}</ref> [[ माइक्रोसॉफ़्ट विंडोज़ ]]़<ref name="King_1994">{{cite book |title=माइक्रोसॉफ्ट विंडोज 95 के अंदर|author-first=Adrian |author-last=King |publisher=[[Microsoft Press]] |edition=2nd |date=1994 |isbn=1-55615-626-X <!--|ISBN=978-1-55615-626-7 --> |location=Redmond, Washington, USA}}</ref><ref name="Microsoft_1995">{{cite book |title=माइक्रोसॉफ्ट विंडोज 95 के लिए प्रोग्रामर गाइड: माइक्रोसॉफ्ट विंडोज डेवलपमेंट टीम से विंडोज के लिए प्रोग्रामिंग पर मुख्य विषय|work=Technical Reference |author=<!-- staff writers --> |publisher=[[Microsoft Press]] |edition=1st |date=1995-07-01 |isbn=1-55615-834-3 <!--|ISBN=978-1-55615-834-6 --> |location=Redmond, Washington, USA |url=https://books.google.com/books?id=MLZQAAAAMAAJ |access-date=2016-05-26}}</ref><ref name="Hazzah_1997">{{cite book |title=विंडोज़ वीएक्सडी और डिवाइस ड्राइवर लिखना - वर्चुअल डिवाइस ड्राइवर्स के लिए प्रोग्रामिंग रहस्य|author-first=Karen |author-last=Hazzah |publisher=R&D Books / [[Miller Freeman, Inc.]] |location=Lawrence, Kansas, USA |edition=2nd printing, 2nd |date=1997 |isbn=0-87930-438-3 <!--|ISBN=978-0-87930-438-6 -->}}</ref><ref name="Kauler_1997">{{cite book |title=विंडोज असेंबली लैंग्वेज और सिस्टम प्रोग्रामिंग - पीसी और विंडोज के लिए 16- और 32-बिट लो-लेवल प्रोग्रामिंग|author-first=Barry |author-last=Kauler |author-link=Barry Kauler |publisher=R&D Books / [[Miller Freeman, Inc.]] |location=Lawrence, Kansas, USA |edition=2nd |date=August 1997 |isbn=0-87930-474-X <!--|ISBN=978-0-87930-474-4 -->}}</ref> और .नेट फ्रेमवर्क|.नेट, और [[16-बिट]] से [[32-बिट]] मेमोरी एड्रेसिंग में संक्रमण। चूँकि ग्राहक एक प्लेटफ़ॉर्म से दूसरे प्लेटफ़ॉर्म पर स्थानांतरित हो गए हैं, पुराने प्लेटफ़ॉर्म के लिए लिखे गए [[विरासत सॉफ्टवेयर]] का समर्थन करने के लिए थंक्स आवश्यक हो गए हैं। | ||
x86 पर 32-बिट से 64-बिट कोड में परिवर्तन भी थंकिंग (WoW64) के एक रूप का उपयोग करता है। | x86 पर 32-बिट से 64-बिट कोड में परिवर्तन भी थंकिंग (WoW64) के एक रूप का उपयोग करता है। यदपि, क्योंकि x86-64 पता स्थान 32-बिट कोड के लिए उपलब्ध स्थान से बड़ा है, पुराने जेनेरिक थंक तंत्र का उपयोग 32-बिट कोड से 64-बिट कोड को कॉल करने के लिए नहीं किया जा सकता है। रेफरी>{{cite web |title=आप 32-बिट और 64-बिट विंडोज़ के बीच विचार क्यों नहीं कर सकते?|url=https://devblogs.microsoft.com/oldnewthing/20081020-00/?p=20523 |website=पुरानी नई बात |date=20 अक्टूबर 2008}}<nowiki></ref></nowiki> 32-बिट कोड को 64-बिट कोड कॉल करने का एकमात्र घटना WoW64 द्वारा विंडोज एपीआई को 32-बिट में बदलना है। | ||
===ओवरले और | ===ओवरले और डायनेमिक लिंकिंग=== | ||
उन प्रणालियों पर जिनमें स्वचालित [[ आभासी मेमोरी ]] हार्डवेयर की कमी होती है, थंक्स वर्चुअल मेमोरी के एक सीमित रूप को लागू कर सकता है जिसे [[ओवरले (प्रोग्रामिंग)]] के रूप में जाना जाता है। ओवरले के साथ, एक डेवलपर प्रोग्राम के कोड को खंडों में विभाजित करता है जिन्हें स्वतंत्र रूप से लोड और अनलोड किया जा सकता है, और प्रत्येक खंड में [[प्रवेश बिंदु]]ओं की पहचान करता है। एक खंड जो दूसरे खंड में कॉल करता है उसे अप्रत्यक्ष रूप से [[शाखा तालिका]] के माध्यम से ऐसा करना होगा। जब कोई खंड मेमोरी में होता है, तो उसकी शाखा तालिका प्रविष्टियाँ खंड में चली जाती हैं। जब कोई खंड अनलोड किया जाता है, तो उसकी प्रविष्टियों को रीलोड थंक्स से बदल दिया जाता है जो मांग पर इसे पुनः लोड कर सकता है।<ref>{{cite journal|first=Walter|last=Bright|title=Virtual Memory For 640K DOS|journal=Dr. Dobb's Journal|date=1990-07-01|url=http://www.drdobbs.com/virtual-memory-for-640k-dos/184402189|access-date=2014-03-06}}</ref> | उन प्रणालियों पर जिनमें स्वचालित [[ आभासी मेमोरी ]] हार्डवेयर की कमी होती है, थंक्स वर्चुअल मेमोरी के एक सीमित रूप को लागू कर सकता है जिसे [[ओवरले (प्रोग्रामिंग)]] के रूप में जाना जाता है। ओवरले के साथ, एक डेवलपर प्रोग्राम के कोड को खंडों में विभाजित करता है जिन्हें स्वतंत्र रूप से लोड और अनलोड किया जा सकता है, और प्रत्येक खंड में [[प्रवेश बिंदु]]ओं की पहचान करता है। एक खंड जो दूसरे खंड में कॉल करता है उसे अप्रत्यक्ष रूप से [[शाखा तालिका]] के माध्यम से ऐसा करना होगा। जब कोई खंड मेमोरी में होता है, तो उसकी शाखा तालिका प्रविष्टियाँ खंड में चली जाती हैं। जब कोई खंड अनलोड किया जाता है, तो उसकी प्रविष्टियों को रीलोड थंक्स से बदल दिया जाता है जो मांग पर इसे पुनः लोड कर सकता है।<ref>{{cite journal|first=Walter|last=Bright|title=Virtual Memory For 640K DOS|journal=Dr. Dobb's Journal|date=1990-07-01|url=http://www.drdobbs.com/virtual-memory-for-640k-dos/184402189|access-date=2014-03-06}}</ref> | ||
इसी प्रकार, सिस्टम जो रन-टाइम पर किसी प्रोग्राम के मॉड्यूल को गतिशील रूप से जोड़ते हैं, मॉड्यूल को कनेक्ट करने के लिए थंक्स का उपयोग कर सकते हैं। प्रत्येक मॉड्यूल दूसरों को थंक्स की एक तालिका के माध्यम से कॉल कर सकता है जिसे लिंकर मॉड्यूल लोड करते समय भरता है। इस तरह मॉड्यूल पूर्व ज्ञान के बिना बातचीत कर सकते हैं कि वे मेमोरी में कहाँ स्थित हैं।<ref name="Levine_1999" /> | |||
==यह भी देखें== | ==यह भी देखें== | ||
===थंक टेक्नोलॉजीज=== | ===थंक टेक्नोलॉजीज=== | ||
* [[डॉस संरक्षित मोड इंटरफ़ेस]] ( | * [[डॉस संरक्षित मोड इंटरफ़ेस]] (डीपीएमआई) | ||
* [[डॉस संरक्षित मोड सेवाएँ]] ( | * [[डॉस संरक्षित मोड सेवाएँ]] (डीपीएमएस) | ||
* जे/डायरेक्ट | * जे/डायरेक्ट | ||
* यूनिकोड के लिए माइक्रोसॉफ्ट लेयर | * यूनिकोड के लिए माइक्रोसॉफ्ट लेयर | ||
* [[प्लेटफ़ॉर्म मंगलाचरण सेवाएँ]] | * [[प्लेटफ़ॉर्म मंगलाचरण सेवाएँ]] | ||
* [[Win32s]] | * [[Win32s|विंडो32एस]] | ||
* [[विंडोज़ पर विंडोज़]] | * [[विंडोज़ पर विंडोज़]] | ||
*[[वाह64]] | *[[वाह64]] | ||
* [[libffi]] | * [[libffi|लिब्फी]] | ||
===संबंधित अवधारणाएँ=== | ===संबंधित अवधारणाएँ=== | ||
* | * अनेम कार्य | ||
* [[वायदा और वादे]] | * [[वायदा और वादे]] | ||
* [[सुदूर प्रणाली संदेश]] | * [[सुदूर प्रणाली संदेश]] | ||
| Line 173: | Line 167: | ||
==टिप्पणियाँ== | ==टिप्पणियाँ== | ||
{{Notelist}} | {{Notelist}} | ||
==संदर्भ== | ==संदर्भ== | ||
{{reflist|refs= | {{reflist|refs= | ||
<ref name="Levine_1999">{{cite book |author-last=Levine |author-first=John R. |author-link=John R. Levine |title=Linkers and Loaders |date=2000 |orig-year=October 1999 |edition=1 |publisher=[[Morgan Kaufmann]] |series=The Morgan Kaufmann Series in Software Engineering and Programming |location=San Francisco, USA |isbn=1-55860-496-0 |oclc=42413382 |url=https://www.iecc.com/linker/ |access-date=2020-01-12 |url-status=live |archive-url=https://archive.today/20121205032107/http://www.iecc.com/linker/ |archive-date=2012-12-05}} Code: [https://archive.today/20200114225034/https://linker.iecc.com/code.html][ftp://ftp.iecc.com/pub/linker/] Errata: [https://linker.iecc.com/<!-- https://archive.today/20200114224817/https://linker.iecc.com/ 2020-01-14 -->]</ref> | <ref name="Levine_1999">{{cite book |author-last=Levine |author-first=John R. |author-link=John R. Levine |title=Linkers and Loaders |date=2000 |orig-year=October 1999 |edition=1 |publisher=[[Morgan Kaufmann]] |series=The Morgan Kaufmann Series in Software Engineering and Programming |location=San Francisco, USA |isbn=1-55860-496-0 |oclc=42413382 |url=https://www.iecc.com/linker/ |access-date=2020-01-12 |url-status=live |archive-url=https://archive.today/20121205032107/http://www.iecc.com/linker/ |archive-date=2012-12-05}} Code: [https://archive.today/20200114225034/https://linker.iecc.com/code.html][ftp://ftp.iecc.com/pub/linker/] Errata: [https://linker.iecc.com/<!-- https://archive.today/20200114224817/https://linker.iecc.com/ 2020-01-14 -->]</ref> | ||
}} | }} | ||
[[Category: | [[Category:All articles with dead external links]] | ||
[[Category:Articles with dead external links from June 2023]] | |||
[[Category:Articles with hatnote templates targeting a nonexistent page]] | |||
[[Category:CS1 errors]] | |||
[[Category:Created On 11/07/2023]] | [[Category:Created On 11/07/2023]] | ||
[[Category:Lua-based templates]] | |||
[[Category:Machine Translated Page]] | |||
[[Category:Pages with script errors]] | |||
[[Category:Templates Vigyan Ready]] | |||
[[Category:Templates that add a tracking category]] | |||
[[Category:Templates that generate short descriptions]] | |||
[[Category:Templates using TemplateData]] | |||
[[Category:Use dmy dates from January 2020]] | |||
[[Category:कंप्यूटिंग शब्दावली]] | |||
[[Category:कार्यात्मक प्रोग्रामिंग]] | |||
Latest revision as of 11:05, 27 July 2023
Look up थंक in Wiktionary, the free dictionary.
कंप्यूटर प्रोग्रामिंग में, थंक एक सबरूटीन है जिसका उपयोग किसी गणना को दूसरे सबरूटीन में इंजेक्ट करने के लिए किया जाता है। थंक्स का उपयोग मुख्य रूप से किसी गणना में देरी करने के लिए किया जाता है, जब तक कि उसके परिणाम की आवश्यकता न हो, या अन्य सबरूटीन की सूत्रपात या अंत में संचालन सम्मिलित करने के लिए किया जाता है। उनके पास कोड जनरेशन (कंपाइलर) और मॉड्यूलर प्रोग्रामिंग में कई अन्य अनुप्रयोग हैं।
इस शब्द की उत्पत्ति क्रिया के एक सनकी अनियमित रूप के रूप में हुई है। यह एल्गोल 60 कंपाइलरों में थंक्स के मूल उपयोग को संदर्भित करता है, जिसे यह निर्धारित करने के लिए विशेष विश्लेषण (विचार) की आवश्यकता होती है कि किस प्रकार की दिनचर्या उत्पन्न की जाए।[1][2]
पृष्ठभूमि
संकलक अनुसंधान के प्रारंभिक वर्षों में विभिन्न मूल्यांकन रणनीति के साथ व्यापक प्रयोग देखा गया। एक महत्वपूर्ण प्रश्न यह था कि यदि तर्क स्थिरांक के बजाय मनमाने ढंग से गणितीय अभिव्यक्ति हो सकते हैं तो सबरूटीन कॉल को कैसे संकलित किया जाए। एक दृष्टिकोण, जिसे कॉल बाय वैल्यू के रूप में जाना जाता है, कॉल से पहले सभी तर्कों की गणना करता है और फिर परिणामी मानों को सबरूटीन में भेजता है। प्रतिद्वंद्वी "कॉल बाय नेम" दृष्टिकोण में, सबरूटीन को अमूल्यांकित तर्क अभिव्यक्ति प्राप्त होती है और उसे इसका मूल्यांकन करना चाहिए।
"नेम से कॉल करें" का एक सरल कार्यान्वयन सबरूटीन में संबंधित पैरामीटर की प्रत्येक उपस्थिति के लिए एक तर्क अभिव्यक्ति के कोड को प्रतिस्थापित कर सकता है, लेकिन यह सबरूटीन के कई संस्करण और अभिव्यक्ति कोड की कई प्रतियां उत्पन्न कर सकता है। एक सुधार के रूप में, कंपाइलर एक सहायक सबरूटीन उत्पन्न कर सकता है, जिसे थंक कहा जाता है, जो तर्क के मूल्य की गणना करता है। इस सहायक सबरूटीन का पता और वातावरण[lower-alpha 1] को पुनः मूल तर्क के स्थान पर मूल सबरूटीन में भेज दिया जाता है, जहां इसे आवश्यकतानुसार कई बार बुलाया जा सकता है। पीटर इंगरमैन ने सबसे पहले एल्गोल 60 प्रोग्रामिंग भाषा के संदर्भ में थंक्स का वर्णन किया, जो "कॉल-बाय-नेम" मूल्यांकन का समर्थन करता है।[4]
कार्यात्मक प्रोग्रामिंग
यदपि सॉफ्टवेयर उद्योग बड़े पैमाने पर कॉल-बाय-वैल्यू और कॉल-बाय-रेफरेंस, मूल्यांकन पर मानकीकृत है,[5] कार्यात्मक प्रोग्रामिंग समुदाय में कॉल-बाय-नेम का सक्रिय अध्ययन प्रभावशील रहा। इस अनुसंधान ने आलसी मूल्यांकन प्रोग्रामिंग भाषाओं की एक श्रृंखला तैयार की जिसमें कॉल-बाय-नेम का कुछ प्रकार मानक मूल्यांकन रणनीति है। इन भाषाओं के लिए कंपाइलर, जैसे कि ग्लासगो हास्केल कंपाइलर, ने थंक्स पर बहुत अधिक भरोसा किया है, इसके अतिरिक्त सुविधा यह है कि थंक्स अपने प्रारंभिक परिणाम को सहेजते हैं ताकि वे इसे पुनर्गणना करने से बच सकें;[6] इसे संस्मरण या कॉल बाय नीड के रूप में जाना जाता है।
कार्यात्मक प्रोग्रामिंग भाषाओं ने प्रोग्रामर को स्पष्ट रूप से थंक्स उत्पन्न करने की भी अनुमति दी है। यह स्रोत कोड में एक अज्ञात फ़ंक्शन में एक तर्क अभिव्यक्ति को लपेटकर किया जाता है जिसका अपना कोई पैरामीटर नहीं होता है। यह अभिव्यक्ति को मूल्यांकन तब तक रोकता है जब तक कि प्राप्तकर्ता फ़ंक्शन अज्ञात फ़ंक्शन को कॉल नहीं करता है, जिससे कॉल-बाय-नेम के समान प्रभाव प्राप्त होता है।[7] अन्य प्रोग्रामिंग भाषाओं में अनाम फ़ंक्शंस को अपनाने से यह क्षमता व्यापक रूप से उपलब्ध हो गई है।
निम्नलिखित जावास्क्रिप्ट (ईएस6) में एक सरल प्रदर्शन है:
// 'hypot' is a binary function
const hypot = (x, y) => Math.sqrt(x * x + y * y);
// 'thunk' is a function that takes no arguments and, when invoked, performs a potentially expensive
// operation (computing a square root, in this example) and/or causes some side-effect to occur
const thunk = () => hypot(3, 4);
// the thunk can then be passed around without being evaluated...
doSomethingWithThunk(thunk);
// ...or evaluated
thunk(); // === 5
वस्तु-उन्मुख प्रोग्रामिंग
थंक्स ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग प्लेटफ़ॉर्म में उपयोगी होते हैं जो एक क्लास (कंप्यूटर प्रोग्रामिंग) को एकाधिक इनहेरिटेंस की अनुमति देते हैं, जिससे ऐसी स्थिति उत्पन्न होती है जहां एक ही विधि (कंप्यूटर प्रोग्रामिंग) को कई अंतराफलक में से किसी एक के माध्यम से बुलाया जा सकता है। निम्नलिखित कोड सी++ में ऐसी स्थिति को दर्शाता है।
class A {
public:
virtual int Access() const { return value_; }
private:
int value_;
};
class B {
public:
virtual int Access() const { return value_; }
private:
int value_;
};
class C : public A, public B {
public:
int Access() const override { return better_value_; }
private:
int better_value_;
};
int use(B *b) { return b->Access(); }
int main() {
// ...
B some_b;
use(&some_b);
C some_c;
use(&some_c);
}
इस उदाहरण में, प्रत्येक वर्ग ए, बी और सी के लिए उत्पन्न कोड में एक प्रेषण तालिका सम्मिलित होगी जिसका उपयोग उसी प्रकार के संदर्भ के माध्यम से उस प्रकार की किसी वस्तु पर एक्सेस को कॉल करने के लिए किया जा सकता है। क्लास सी में एक अतिरिक्त डिस्पैच टेबल होगी, जिसका उपयोग प्रकार बी के संदर्भ के माध्यम से प्रकार सी की एक वस्तु पर एक्सेस को कॉल करने के लिए किया जाता है। अभिव्यक्ति बी->एक्सेस()प्रकार के आधार पर बी की अपनी प्रेषण तालिका या अतिरिक्त सी तालिका का उपयोग करेगा। ऑब्जेक्ट बी का संदर्भ देता है। यदि यह सी प्रकार के ऑब्जेक्ट को संदर्भित करता है, तो कंपाइलर को यह सुनिश्चित करना होगा कि सी एक्सेस कार्यान्वयन उस ऑब्जेक्ट के विरासत वाले बी भाग के बजाय संपूर्ण सी ऑब्जेक्ट के लिए यह (कंप्यूटर प्रोग्रामिंग) प्राप्त करता हो।[8]
इस सूचक समायोजन समस्या के प्रत्यक्ष दृष्टिकोण के रूप में, कंपाइलर प्रत्येक प्रेषण तालिका प्रविष्टि में एक पूर्णांक ऑफसेट सम्मिलित कर सकता है। यह ऑफसेट संदर्भ के पते और विधि कार्यान्वयन के लिए आवश्यक पते के बीच का अंतर है। इन प्रेषण तालिकाओं के माध्यम से प्रत्येक कॉल के लिए उत्पन्न कोड को ऑफसेट पुनर्प्राप्त करना होगा और विधि को कॉल करने से पहले इंस्टेंस पते को समायोजित करने के लिए इसका उपयोग करना होगा।
अभी वर्णित समाधान में पहले वर्णित कॉल-बाय-नेम के सरल कार्यान्वयन के समान समस्याएं हैं: कंपाइलर एक तर्क (उदाहरण पता) की गणना करने के लिए कोड की कई प्रतियां उत्पन्न करता है, जबकि ऑफसेट को पकड़ने के लिए प्रेषण तालिका आकार भी बढ़ाता है। एक विकल्प के रूप में, कंपाइलर सी के कार्यान्वयन के साथ एक समायोजक थंक उत्पन्न कर सकता है एक्सेस जो इंस्टेंस एड्रेस को आवश्यक मात्रा से समायोजित करता है और फिर विधि को कॉल करता है। थंक बी के लिए सी की प्रेषण तालिका में दिखाई दे सकता है, जिससे कॉल करने वालों को पते को स्वयं समायोजित करने की आवश्यकता समाप्त हो जाती है।[9]
संख्यात्मक गणना के लिए कई बिंदुओं पर मूल्यांकन की आवश्यकता होती है
एकीकरण जैसी गणनाओं के लिए कई बिंदुओं पर एक अभिव्यक्ति की गणना करने की आवश्यकता होती है। नेम से कॉल का उपयोग इस उद्देश्य के लिए उन भाषाओं में किया गया था जो समापन (कंप्यूटर प्रोग्रामिंग) या प्रक्रियात्मक पैरामीटर का समर्थन नहीं करते थे।
इंटरऑपरेबिलिटी
सॉफ्टवेयर मॉड्यूल के बीच अंतरसंचालनीयता प्रदान करने के लिए थंक्स का व्यापक रूप से उपयोग किया गया है जिनकी दिनचर्या एक दूसरे को सीधे कॉल नहीं कर सकती है। ऐसा इसलिए हो सकता है क्योंकि रूटीन में अलग-अलग सम्मलेन बुलाना होते हैं, अलग-अलग सीपीयू मोड या पता स्थान में चलते हैं, या कम से कम एक आभासी मशीन में चलता है। एक कंपाइलर (या अन्य उपकरण) एक थंक उत्पन्न करके इस समस्या को हल कर सकता है जो लक्ष्य रूटीन को कॉल करने के लिए आवश्यक अतिरिक्त चरणों को स्वचालित करता है, चाहे वह तर्कों को बदलना हो, उन्हें किसी अन्य स्थान पर कॉपी करना हो, या सीपीयू मोड को स्विच करना हो। एक सफल थंक सामान्य कॉल की तुलना में कॉलर द्वारा किए जाने वाले अतिरिक्त काम को कम कर देता है।
इंटरऑपरेबिलिटी थंक्स पर अधिकांश साहित्य एमएस-डॉस, ओएस/2 सहित विभिन्न विंटेल प्लेटफार्मों से संबंधित है।[10] माइक्रोसॉफ़्ट विंडोज़ ़[11][12][13][14] और .नेट फ्रेमवर्क|.नेट, और 16-बिट से 32-बिट मेमोरी एड्रेसिंग में संक्रमण। चूँकि ग्राहक एक प्लेटफ़ॉर्म से दूसरे प्लेटफ़ॉर्म पर स्थानांतरित हो गए हैं, पुराने प्लेटफ़ॉर्म के लिए लिखे गए विरासत सॉफ्टवेयर का समर्थन करने के लिए थंक्स आवश्यक हो गए हैं।
x86 पर 32-बिट से 64-बिट कोड में परिवर्तन भी थंकिंग (WoW64) के एक रूप का उपयोग करता है। यदपि, क्योंकि x86-64 पता स्थान 32-बिट कोड के लिए उपलब्ध स्थान से बड़ा है, पुराने जेनेरिक थंक तंत्र का उपयोग 32-बिट कोड से 64-बिट कोड को कॉल करने के लिए नहीं किया जा सकता है। रेफरी>"आप 32-बिट और 64-बिट विंडोज़ के बीच विचार क्यों नहीं कर सकते?". पुरानी नई बात. 20 अक्टूबर 2008. {{cite web}}: Check date values in: |date= (help)</ref> 32-बिट कोड को 64-बिट कोड कॉल करने का एकमात्र घटना WoW64 द्वारा विंडोज एपीआई को 32-बिट में बदलना है।
ओवरले और डायनेमिक लिंकिंग
उन प्रणालियों पर जिनमें स्वचालित आभासी मेमोरी हार्डवेयर की कमी होती है, थंक्स वर्चुअल मेमोरी के एक सीमित रूप को लागू कर सकता है जिसे ओवरले (प्रोग्रामिंग) के रूप में जाना जाता है। ओवरले के साथ, एक डेवलपर प्रोग्राम के कोड को खंडों में विभाजित करता है जिन्हें स्वतंत्र रूप से लोड और अनलोड किया जा सकता है, और प्रत्येक खंड में प्रवेश बिंदुओं की पहचान करता है। एक खंड जो दूसरे खंड में कॉल करता है उसे अप्रत्यक्ष रूप से शाखा तालिका के माध्यम से ऐसा करना होगा। जब कोई खंड मेमोरी में होता है, तो उसकी शाखा तालिका प्रविष्टियाँ खंड में चली जाती हैं। जब कोई खंड अनलोड किया जाता है, तो उसकी प्रविष्टियों को रीलोड थंक्स से बदल दिया जाता है जो मांग पर इसे पुनः लोड कर सकता है।[15]
इसी प्रकार, सिस्टम जो रन-टाइम पर किसी प्रोग्राम के मॉड्यूल को गतिशील रूप से जोड़ते हैं, मॉड्यूल को कनेक्ट करने के लिए थंक्स का उपयोग कर सकते हैं। प्रत्येक मॉड्यूल दूसरों को थंक्स की एक तालिका के माध्यम से कॉल कर सकता है जिसे लिंकर मॉड्यूल लोड करते समय भरता है। इस तरह मॉड्यूल पूर्व ज्ञान के बिना बातचीत कर सकते हैं कि वे मेमोरी में कहाँ स्थित हैं।[16]
यह भी देखें
थंक टेक्नोलॉजीज
- डॉस संरक्षित मोड इंटरफ़ेस (डीपीएमआई)
- डॉस संरक्षित मोड सेवाएँ (डीपीएमएस)
- जे/डायरेक्ट
- यूनिकोड के लिए माइक्रोसॉफ्ट लेयर
- प्लेटफ़ॉर्म मंगलाचरण सेवाएँ
- विंडो32एस
- विंडोज़ पर विंडोज़
- वाह64
- लिब्फी
संबंधित अवधारणाएँ
- अनेम कार्य
- वायदा और वादे
- सुदूर प्रणाली संदेश
- शिम (कंप्यूटिंग)
- ट्रैम्पोलिन (कंप्यूटिंग)
- कम करने योग्य अभिव्यक्ति
टिप्पणियाँ
संदर्भ
- ↑ Eric Raymond rejects "a couple of onomatopoeic myths circulating about the origin of this term" and cites the inventors of the thunk recalling that the term "was coined after they realized (in the wee hours after hours of discussion) that the type of an argument in Algol-60 could be figured out in advance with a little compile-time thought [...] In other words, it had 'already been thought of'; thus it was christened a thunk, which is 'the past tense of "think" at two in the morning'. See: Raymond, Eric S. (1996). Raymond, Eric S. (ed.). The New Hacker's Dictionary. MIT Press. p. 445. ISBN 9780262680929. Retrieved 2015-05-25.
- ↑ See Ingerman (1961): "The translator knows what kind of thunk to create by considering the formation of the actual parameter and the previously scanned declarations.… [W]hen a procedure declaration is being compiled, the translator, again by observing syntax, knows what kind of address to expect from a thunk."
- ↑ E. T. Irons (1961-01-01). "Comments on the Implementation of Recursive Procedures and Blocks in ALGOL". Communications of the ACM. Association for Computing Machinery (ACM). 4 (1): 65–69. doi:10.1145/366062.366084. ISSN 0001-0782. S2CID 14646332.
- ↑ Ingerman, P. Z. (1961-01-01). "Thunks: a way of compiling procedure statements with some comments on procedure declarations". Communications of the ACM. Association for Computing Machinery (ACM). 4 (1): 55–58. doi:10.1145/366062.366084. ISSN 0001-0782. S2CID 14646332.
- ↑ Scott, Michael (2009). प्रोग्रामिंग भाषा व्यावहारिकता. p. 395.
- ↑ Marlow, Simon (2013). हास्केल में समानांतर और समवर्ती प्रोग्रामिंग. p. 10.
- ↑ Queinnec, Christian (2003). छोटे टुकड़ों में लिस्प. p. 176.
- ↑ Stroustrup, Bjarne (Fall 1989). "Multiple Inheritance for C++" (PDF). Computing Systems. USENIX. 1 (4). Retrieved 2014-08-04.
- ↑ Driesen, Karel; Hölzle, Urs (1996). "The Direct Cost of Virtual Function Calls in C++" (PDF). Proceedings of the 1996 ACM SIGPLAN Conference on Object-Oriented Programming Systems, Languages & Applications, OOPSLA 1996, San Jose, California, USA, October 6-10, 1996. 11th OOPSLA 1996: San Jose, California, USA. ACM. ISBN 0-89791-788-X. Retrieved 2011-02-24.[dead link]
- ↑ Calcote, John (May 1995). "थंकिंग: OS/2 2.0 में 16-बिट लाइब्रेरी का उपयोग करना". OS/2 Developer Magazine. 7 (3): 48–56.
- ↑ King, Adrian (1994). माइक्रोसॉफ्ट विंडोज 95 के अंदर (2nd ed.). Redmond, Washington, USA: Microsoft Press. ISBN 1-55615-626-X.
- ↑ माइक्रोसॉफ्ट विंडोज 95 के लिए प्रोग्रामर गाइड: माइक्रोसॉफ्ट विंडोज डेवलपमेंट टीम से विंडोज के लिए प्रोग्रामिंग पर मुख्य विषय. 1995-07-01. ISBN 1-55615-834-3. Retrieved 2016-05-26.
{{cite book}}:|work=ignored (help) - ↑ Hazzah, Karen (1997). विंडोज़ वीएक्सडी और डिवाइस ड्राइवर लिखना - वर्चुअल डिवाइस ड्राइवर्स के लिए प्रोग्रामिंग रहस्य (2nd printing, 2nd ed.). Lawrence, Kansas, USA: R&D Books / Miller Freeman, Inc. ISBN 0-87930-438-3.
- ↑ Kauler, Barry (August 1997). विंडोज असेंबली लैंग्वेज और सिस्टम प्रोग्रामिंग - पीसी और विंडोज के लिए 16- और 32-बिट लो-लेवल प्रोग्रामिंग (2nd ed.). Lawrence, Kansas, USA: R&D Books / Miller Freeman, Inc. ISBN 0-87930-474-X.
- ↑ Bright, Walter (1990-07-01). "Virtual Memory For 640K DOS". Dr. Dobb's Journal. Retrieved 2014-03-06.
- ↑ Levine, John R. (2000) [October 1999]. Linkers and Loaders. The Morgan Kaufmann Series in Software Engineering and Programming (1 ed.). San Francisco, USA: Morgan Kaufmann. ISBN 1-55860-496-0. OCLC 42413382. Archived from the original on 2012-12-05. Retrieved 2020-01-12. Code: [1][2] Errata: [3]
