9 दिसंबर 2014 को प्रकाशित लेख
2018 के लिए अपडेट: RenéRebe ने इस लेख पर आधारित एक दिलचस्प वीडियो बनाया ( भाग 2 )

पिछले सप्ताहांत में मैंने लुडम डेयर # 31 में भाग लिया। लेकिन सम्मेलन की घोषणा होने से पहले ही, मेरे हालिया शौक के कारण, मैं डॉस के तहत एक पुराने स्कूल का खेल बनाना चाहता था। लक्ष्य मंच DOSBox है। यह डॉस अनुप्रयोगों को चलाने का सबसे व्यावहारिक तरीका है, इस तथ्य के बावजूद कि सभी आधुनिक x86 प्रोसेसर पुराने वाले के साथ पूरी तरह से पिछड़े हुए हैं, 16-बिट 8086 तक।

मैंने सफलतापूर्वक सम्मेलन में डॉस डिफेंडर गेम बनाया और दिखाया। कार्यक्रम 32-बिट 80386 के वास्तविक मोड में काम करता है। सभी संसाधनों को निष्पादन योग्य COM-फ़ाइल, किसी बाहरी निर्भरता में नहीं बनाया गया है, इसलिए पूरे खेल को 10 किलोबाइट बाइनरी में पैक किया गया है।

• https://github.com/skeeto/dosdefender-ld31
• DOSDEF.COM (10 KB, v1.1.0, DOSBox में काम करता है)

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

सबसे तकनीकी रूप से दिलचस्प हिस्सा यह है कि गेम बनाने के लिए किसी भी डॉस विकास उपकरण की आवश्यकता नहीं थी ! मैंने केवल नियमित लिनक्स सी कंपाइलर (जीसीसी) का उपयोग किया। वास्तव में, आप डॉस के लिए डॉस डिफेंडर भी नहीं बना सकते। मैं DOS को केवल एक एम्बेडेड प्लेटफॉर्म के रूप में देखता हूं, जो एकमात्र ऐसा रूप है जिसमें DOS आज भी मौजूद है । DOSBox और DOSEMU के साथ मिलकर, यह टूल का एक काफी सुविधाजनक सेट है।

यदि आप केवल विकास के व्यावहारिक भाग में रुचि रखते हैं, तो "जीसीसी पर धोखा" अनुभाग पर जाएं, जहां हम जीसीसी लिनक्स के साथ डॉस कॉम कार्यक्रम "हैलो, वर्ल्ड" लिखेंगे।

सही उपकरण ढूँढना

जब मैंने यह प्रोजेक्ट शुरू किया, तो मैंने जीसीसी के बारे में नहीं सोचा था। वास्तव में, मैं इस तरह से चला गया जब मैंने डेबियन के लिए बीसीसी पैकेज (ब्रूस सी कंपाइलर) की खोज की, जो 8086 के लिए 16-बिट बायनेरिज़ संकलित करता है। यह x86 बूट लोडर और अन्य चीजों को संकलित करने के लिए आयोजित किया जाता है, लेकिन बीओएस का उपयोग डॉस कॉम फ़ाइलों को संकलित करने के लिए भी किया जा सकता है। इसने मुझे दिलचस्पी दी।

संदर्भ के लिए: इंटेल 8086 16-बिट माइक्रोप्रोसेसर को 1978 में जारी किया गया था। इसमें आधुनिक प्रोसेसर की कोई विचित्र विशेषताएं नहीं थीं: कोई स्मृति सुरक्षा, कोई फ़्लोटिंग पॉइंट निर्देश, और केवल 1 एमबी पता योग्य रैम। सभी आधुनिक x86 डेस्कटॉप और लैपटॉप अभी भी इस 16-बिट प्रोसेसर 8086 चालीस साल पहले, एक ही सीमित पते और सभी के साथ होने का दिखावा कर सकते हैं। यह एक बहुत पिछड़ी संगतता है। ऐसे फ़ंक्शन को वास्तविक मोड कहा जाता है । यह वह मोड है जिसमें सभी x86 कंप्यूटर बूट होते हैं। आधुनिक ओएस तुरंत वर्चुअल एड्रेसिंग और सुरक्षित मल्टीटास्किंग के साथ संरक्षित मोड में चले जाते हैं। डॉस ने ऐसा नहीं किया।

दुर्भाग्य से, bcc एक ANSI C संकलक नहीं है। यह K & R C के उपसमूह का समर्थन करता है, साथ ही बिल्ट-इन x86 कोडांतरक कोड भी। अन्य 8086 सी कंपाइलरों के विपरीत, इसमें "दूर" या "लंबे" पॉइंटर्स की अवधारणा नहीं है, इसलिए अन्य मेमोरी सेगमेंट (वीजीए, घड़ियों, आदि) तक पहुंचने के लिए अंतर्निहित कोडांतरक कोड की आवश्यकता होती है। नोट: इन "लॉन्ग पॉइंटर्स" 8086 के अवशेष अभी भी Win32 API में संरक्षित हैं: LPSTR , LPWORD , LPDWORD , आदि जो बिल्ट-इन असेंबलर में बिल्ट-इन LPDWORD साथ तुलना नहीं करता है। कोडांतरक में, आपको मैन्युअल रूप से स्टैक से चर लोड करने की आवश्यकता होती है, और चूंकि बीसीसी दो अलग-अलग कॉलिंग सम्मेलनों का समर्थन करता है, कोड में चर एक या दूसरे सम्मेलन के अनुसार हार्ड-कोडित होना चाहिए।

इन सीमाओं को देखते हुए, मैंने विकल्पों की तलाश करने का निर्णय लिया।

DJGPP

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

डीजेजीपीपी के लिए आवश्यक उपकरण प्राप्त करना मुश्किल है, कम से कम कहने के लिए। सौभाग्य से, मुझे एक उपयोगी बिल्ड-डीजगप प्रोजेक्ट मिला जो कम से कम लिनक्स पर सब कुछ चलाता है।

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

तो यह और DPMI समस्या को देखते हुए, मैंने आगे देखना शुरू किया।

फुलिंग जीसीसी

मैं आखिरकार जिस पर बस गया वह वास्तविक मोड में डॉस कॉम फाइलों के निर्माण के लिए "धोखा" जीसीसी की मुश्किल चाल थी। यह ट्रिक 80386 तक काम करती है (जो कि आमतौर पर आपको चाहिए होती है)। 80386 प्रोसेसर 1985 में लॉन्च किया गया था और यह पहला 32-बिट x86 माइक्रोप्रोसेसर बन गया। जीसीसी अभी भी निर्देशों के इस सेट का पालन करता है, यहां तक ​​कि x86-64 वातावरण पर भी। दुर्भाग्य से, जीसीसी किसी भी तरह से 16-बिट कोड का उत्पादन नहीं कर सकता है, इसलिए मुझे 8086 के लिए गेम बनाने के मूल लक्ष्य को छोड़ना पड़ा। हालांकि, यह कोई फर्क नहीं पड़ता, क्योंकि लक्ष्य DOSBox मंच अनिवार्य रूप से एक 80386 एमुलेटर है।

सिद्धांत रूप में, ट्रिक को मिनगव कंपाइलर में भी काम करना चाहिए, लेकिन एक दीर्घकालिक त्रुटि है जो इसे सही तरीके से काम करने से रोकती है ("गैर पीई आउटपुट फ़ाइल पर पीई ऑपरेशन नहीं कर सकती")। हालाँकि, इसे बायपास किया जा सकता है, और मैंने इसे स्वयं किया था: आपको OUTPUT_FORMAT निर्देश निकालना चाहिए और एक अतिरिक्त objcopy चरण ( objcopy -O binary ) जोड़ना चाहिए।

नमस्ते विश्व डॉस पर

प्रदर्शन के लिए, हम लिनक्स पर जीसीसी का उपयोग करके डॉस कॉम कार्यक्रम "हैलो, वर्ल्ड" बनाएंगे।

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

डॉस के नौ इंटरप्ट हैं: 0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27, 0x2F। सबसे महत्वपूर्ण बात यह है कि हमारी रुचि 0x21 है, फ़ंक्शन 0x09 (एक लाइन प्रिंट करें)। डॉस और BIOS के बीच, इस पैटर्न के नाम पर हजारों फ़ंक्शन हैं । मैं x86 असेंबलर को समझाने की कोशिश नहीं कर रहा हूं, लेकिन संक्षेप में फ़ंक्शन संख्या ah रजिस्टर में फंस जाती है - और 0x21 इंटरप्ट फायर। फंक्शन 0x09 एक तर्क भी लेता है - प्रिंटिंग के लिए एक लाइन के लिए एक पॉइंटर, जो dx और ds रजिस्टरों में पास होता है।

यहाँ GCC इनलाइन असेंबलर का print() फ़ंक्शन है। इस फ़ंक्शन को दी गई लाइनें $ वर्ण के साथ समाप्त होनी चाहिए। क्यों? क्योंकि डी.ओ.एस.

 static void print(char *string) { asm volatile ("mov $0x09, %%ah\n" "int $0x21\n" : /* no output */ : "d"(string) : "ah"); } 

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

आपको कॉलिंग स्टेटमेंट का भी ध्यान रखना चाहिए, क्योंकि जीसीसी को पता नहीं है कि string द्वारा बताई गई मेमोरी कभी पढ़ी गई है। यह संभावना है कि स्ट्रिंग का समर्थन करने वाले एक सरणी को भी volatile घोषित किया जाएगा। यह सब अपरिहार्य को चित्रित करता है: ऐसे वातावरण में कोई भी कार्रवाई ऑप्टिमाइज़र के साथ एक अंतहीन संघर्ष में बदल जाती है। इन सभी लड़ाईयों को नहीं जीता जा सकता है।

अब मुख्य समारोह के लिए। सिद्धांत रूप में इसका नाम महत्वपूर्ण नहीं है, लेकिन मैं इसे main() कहने से बचता हूं main() , क्योंकि इस तरह के पात्रों को विशेष रूप से संसाधित करने के बारे में मिनजीडब्ल्यू के पास मजेदार विचार हैं, भले ही वे उससे नहीं पूछें।

 int dosmain(void) { print("Hello, World!\n$"); return 0; } 

COM फाइलें आकार में 65279 बाइट्स तक सीमित हैं। ऐसा इसलिए है क्योंकि x86 मेमोरी सेगमेंट 64 KB है, और DOS केवल COM फ़ाइलों को 0x0100 सेगमेंट पते पर डाउनलोड करता है और निष्पादित करता है। कोई शीर्षासन नहीं, बस एक स्वच्छ बाइनरी। चूंकि COM प्रोग्राम, सिद्धांत रूप में, एक महत्वपूर्ण आकार नहीं हो सकता है, तो कोई वास्तविक लेआउट (फ्रीस्टैंडिंग) नहीं होना चाहिए, पूरी चीज को एकल अनुवाद इकाई के रूप में संकलित किया गया है। यह मापदंडों के एक समूह के साथ एक जीसीसी कॉल होगा।

संकलक विकल्प

यहाँ मुख्य संकलक विकल्प हैं।

-std=gnu99 -Os -nostdlib -m32 -march=i386 -ffreestanding

चूंकि मानक पुस्तकालयों का उपयोग नहीं किया जाता है, इसलिए gnu99 और c99 के बीच एकमात्र अंतर डिस्कनेक्ट ट्रिग्राफ (जैसा होना चाहिए) है, और अंतर्निहित कोडांतरक को __asm__ बजाय asm लिखा जा सकता है। यह न्यूटन का बिन नहीं है। यह परियोजना जीसीसी से इतनी निकटता से संबंधित होगी कि मुझे अभी भी जीसीसी एक्सटेंशन के बारे में चिंता नहीं है।

-Os विकल्प जितना संभव हो उतना संकलन परिणाम को कम करता है। तो कार्यक्रम तेजी से काम करेगा। यह डॉसबॉक्स पर नज़र रखने के साथ महत्वपूर्ण है, क्योंकि डिफ़ॉल्ट एमुलेटर 80 के दशक की मशीन की तरह धीरे-धीरे चलता है। मैं इस सीमा में फिट होना चाहता हूं। यदि ऑप्टिमाइज़र समस्याएँ पैदा कर रहा है, तो अस्थायी रूप से -O0 यह निर्धारित करने के लिए कि आपकी त्रुटि या ऑप्टिमाइज़र यहाँ है।

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

अगला पैरामीटर -nostdlib , क्योंकि हम किसी भी मान्य पुस्तकालयों से लिंक नहीं कर पाएंगे, यहां तक ​​कि सांख्यिकीय रूप से भी।

Parameters -m32-march=i386 संकलक को 80386 कोड जारी करने का -m32-march=i386 अगर मैंने आधुनिक कंप्यूटर के लिए बूटलोडर लिखा है, तो 80686 पर दृष्टि भी सामान्य होगी, लेकिन DOSBox 80386 है।

-ffreestanding तर्क के लिए GCC को कोड जारी करने की आवश्यकता नहीं है जो अंतर्निहित मानक पुस्तकालय के सहायक कार्यों को एक्सेस करता है। कभी-कभी, वास्तव में काम करने वाले कोड के बजाय, यह एक अंतर्निहित फ़ंक्शन को लागू करने के लिए एक कोड का उत्पादन करता है, खासकर गणितीय ऑपरेटरों के साथ। मुझे bcc के साथ एक मुख्य समस्या थी, जहाँ यह व्यवहार अक्षम नहीं किया जा सकता था। बूट लोडर और OS कर्नेल लिखते समय इस विकल्प का सबसे अधिक उपयोग किया जाता है। और अब डॉस .com फाइलें।

लिंकर विकल्प

-Wl उपयोग लिंकर ( ld ) में तर्क पारित करने के लिए किया जाता है। हमें इसकी आवश्यकता है क्योंकि हम जीसीसी में एक कॉल में सब कुछ करते हैं।

 -Wl,--nmagic,--script=com.ld 

--nmagic अनुभाग पृष्ठ संरेखण को अक्षम करता है। सबसे पहले, हमें इसकी आवश्यकता नहीं है। दूसरे, यह कीमती जगह बर्बाद करता है। मेरे परीक्षणों में, यह एक आवश्यक उपाय नहीं लगता है, लेकिन सिर्फ मामले में, मैं इस विकल्प को छोड़ देता हूं।

--script पैरामीटर इंगित करता है कि हम एक विशेष लिंकर स्क्रिप्ट का उपयोग करना चाहते हैं। यह आपको हमारे प्रोग्राम के सेक्शन ( text , data , bss , rodata ) को सही जगह लगाने की अनुमति देता है। यहाँ com.ld । com.ld स्क्रिप्ट है।

 OUTPUT_FORMAT(binary) SECTIONS { . = 0x0100; .text : { *(.text); } .data : { *(.data); *(.bss); *(.rodata); } _heap = ALIGN(4); } 

OUTPUT_FORMAT(binary) आपको ईएलएफ फ़ाइल (या पीई, आदि) में इसे नहीं डालने के लिए कहता है। लिंकर को केवल स्वच्छ कोड रीसेट करना चाहिए। एक COM फाइल सिर्फ क्लीन कोड है, यानी हम लिंकर को COM फाइल बनाने के लिए कमांड देते हैं!

मैंने कहा कि COM फाइलें 0x0100 अपलोड की 0x0100 । चौथी पंक्ति बाइनरी को वहां स्थानांतरित करती है। COM फ़ाइल का पहला बाइट अभी भी कोड का पहला बाइट है, लेकिन इस मेमोरी ऑफ़सेट से लॉन्च किया जाएगा।

फिर सभी अनुभाग अनुसरण करते हैं: text (कार्यक्रम), data (स्थैतिक डेटा), bss (शून्य आरंभीकरण के साथ डेटा), rodata (तार)। अंत में, मैं _heap प्रतीक के साथ बाइनरी के अंत को चिह्नित करता हूं। यह बाद में काम आएगा जब sbrk() जब हम “Hello, World” के साथ होंगे। मैंने 4 बाइट्स के साथ _heap को संरेखित करने का संकेत दिया।

लगभग किया हुआ।

कार्यक्रम का शुभारंभ

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

इस तरह की चीजों के लिए लिंकर स्क्रिप्ट में एक STARTUP विकल्प है, लेकिन सादगी के लिए हम इसे सीधे कार्यक्रम में लागू करेंगे। आमतौर पर ऐसी चीजों को crt0.o या Boot.o कहा जाता है, यदि आप उन पर कहीं ठोकर खाते हैं। हमारे कोड को इस अंतर्निर्मित कोडांतरक के साथ शुरू होना चाहिए , किसी भी निष्कर्ष और पसंद से पहले। डॉस हमारे लिए ज्यादातर इंस्टॉलेशन करेगा, हमें बस एंट्री पॉइंट पर जाने की जरूरत है।

 asm (".code16gcc\n" "call dosmain\n" "mov $0x4C, %ah\n" "int $0x21\n"); 

.code16gcc बताता है कि हम वास्तविक मोड में काम करने जा रहे हैं, ताकि यह सही कॉन्फ़िगरेशन कर सके। नाम के बावजूद, यह 16-बिट कोड का उत्पादन नहीं करेगा! सबसे पहले, dosmain फ़ंक्शन, जिसे हमने पहले लिखा था, कहा जाता है। वह फिर 0x4C फ़ंक्शन ("रिटर्न कोड के साथ समाप्त") का उपयोग करके डॉस को बताता है कि हम 1-बाइट al रजिस्टर (पहले से dosmain द्वारा dosmain ) से बाहर निकलने वाले कोड को पारित करके किया जाता है। यह अंतर्निहित कोडक स्वचालित रूप से volatile क्योंकि इसमें कोई इनपुट और आउटपुट नहीं है।

सब एक साथ

यहाँ C में पूरा कार्यक्रम है।

 asm (".code16gcc\n" "call dosmain\n" "mov $0x4C,%ah\n" "int $0x21\n"); static void print(char *string) { asm volatile ("mov $0x09, %%ah\n" "int $0x21\n" : /* no output */ : "d"(string) : "ah"); } int dosmain(void) { print("Hello, World!\n$"); return 0; } 

मैं नहीं दोहराऊंगा। com.ld यहां जीसीसी चुनौती है।

 gcc -std=gnu99 -Os -nostdlib -m32 -march=i386 -ffreestanding \ -o hello.com -Wl,--nmagic,--script=com.ld hello.c 

और DOSBox में उसका परीक्षण:



फिर यदि आप सुंदर ग्राफिक्स चाहते हैं, तो एकमात्र सवाल रुकावट को कॉल करना और वीजीए मेमोरी में लिखना है । यदि आप ध्वनि चाहते हैं, तो पीसी स्पीकर इंटरप्ट का उपयोग करें। मुझे यह पता नहीं चला है कि साउंड ब्लास्टर को कैसे कॉल किया जाए। उस पल से, डॉस डिफेंडर बड़ा हुआ।

मेमोरी आवंटन

किसी अन्य विषय को कवर करने के लिए, याद रखें कि _heap ? हम इसे sbrk() को कार्यान्वित करने के लिए उपयोग कर सकते हैं और प्रोग्राम के मुख्य भाग में गतिशील रूप से मेमोरी आवंटित कर सकते हैं। यह एक वास्तविक मोड है और कोई वर्चुअल मेमोरी नहीं है, इसलिए हम किसी भी मेमोरी को लिख सकते हैं जिसे हम किसी भी समय एक्सेस कर सकते हैं। कुछ क्षेत्र उपकरण के लिए आरक्षित हैं (उदाहरण के लिए, निचली और ऊपरी मेमोरी)। इसलिए sbrk () का उपयोग करने की कोई वास्तविक आवश्यकता नहीं है, लेकिन यह कोशिश करना दिलचस्प है।

X86 पर हमेशा की तरह, आपका प्रोग्राम और विभाजन कम मेमोरी (इस मामले में 0x0100) में है, और स्टैक ऊपरी मेमोरी में है (हमारे मामले में, 0xffff क्षेत्र में)। यूनिक्स जैसी प्रणालियों पर, sbrk() द्वारा लौटाई गई मेमोरी दो स्थानों से आती है: sbrk() और mmap() । क्या sbrk() प्रोग्राम / डेटा सेगमेंट के ठीक ऊपर मेमोरी आवंटित करता है, यह स्टैक की ओर "अप" बढ़ाता है। प्रत्येक कॉल sbrk() इस स्थान को बढ़ाएगा (या इसे बिल्कुल उसी तरह छोड़ देगा)। यह मेमोरी malloc() और इस तरह से प्रबंधित की जाएगी।

COM प्रोग्राम में sbrk() को कैसे कार्यान्वित किया sbrk() यहां बताया गया है। कृपया ध्यान दें कि आपको अपने स्वयं के size_t को परिभाषित करने की आवश्यकता है, क्योंकि हमारे पास एक मानक पुस्तकालय नहीं है।

 typedef unsigned short size_t; extern char _heap; static char *hbreak = &_heap; static void *sbrk(size_t size) { char *ptr = hbreak; hbreak += size; return ptr; } 

यह बस पॉइंटर को _heap सेट करता है और आवश्यकतानुसार इसे बढ़ाता है। थोड़ा चालाक sbrk() भी संरेखण के साथ सावधान रहना होगा।

डॉस डिफेंडर के निर्माण के दौरान एक दिलचस्प बात हुई। मैंने (गलत तरीके से) माना कि मेरे sbrk() से मेमोरी रीसेट हो गई थी। तो यह पहले गेम के बाद था। हालाँकि, DOS प्रोग्राम के बीच इस मेमोरी को रीसेट नहीं करता है। जब मैंने फिर से खेल शुरू किया, तो यह ठीक उसी तरह से जारी रहा , जहां मैं रुका था , क्योंकि समान सामग्रियों के साथ समान डेटा संरचनाएं जगह में भरी हुई थीं। बहुत अच्छा संयोग! यह इस एम्बेडेड प्लेटफॉर्म को मज़ेदार बनाता है।