👲🏽 💏 🚔 डेल्फी के साथ क्रिंकर का उपयोग करना 👨🏿‍🌾 🤴🏼 👘

परिचय

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

इस लेख में व्यापक रूप से ज्ञात लिंकर क्रिंकर के बारे में चर्चा की जाएगी , जो कि डेल्फी परियोजना के निर्माण के लिए इस चमत्कार को अनुकूलित करने के लिए मुझे जिन समस्याओं का समाधान करना था।

यह कैसे काम करता है?

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

निष्पादन योग्य फ़ाइलों के कंप्रेशर्स अपने डिकंप्रेसन कोड को निष्पादन योग्य फ़ाइल में पेश करके कोड और आयात तालिका को संपीड़ित करने में सक्षम हैं। क्रिंकलर शाब्दिक रूप से मानव जाति (पैथोस) द्वारा संचित पीई संपीड़न के बारे में सभी ज्ञान एकत्र करता है और हड्डी को एक्सई कट देता है।

तैयारी और संकलन

इसलिए, हमने सिद्धांत को सुलझा लिया, अब हम व्यापार के लिए नीचे उतरते हैं और फिर हम ऑब्जेक्ट फ़ाइलों की पीढ़ी से संबंधित एक रैक में आते हैं। तथ्य यह है कि डेल्फी के आधुनिक संस्करण 5 से शुरू होकर ऑब्जेक्ट ऑब्जेक्ट्स के ओएमएफ प्रारूप का उपयोग करते हैं, जबकि सभी सी ++ कंपाइलर (जिसके लिए क्रिंकर डिज़ाइन किया गया है) कॉफ़ प्रारूप फ़ाइलों को उत्पन्न करते हैं। कुछ "सिंटैक्टिक शुगर" को छोड़ने के बाद, आप सुरक्षित रूप से डेल्फी 3 में वापस आ सकते हैं जो COFF बनाने में सक्षम था। लेकिन यह समस्या गायब नहीं होगी, क्योंकि यहां तक कि परिणामस्वरूप COFFs आवश्यक लोगों से बिल्कुल मेल नहीं खाते हैं। स्वरूपों में अंतर के विवरण में नहीं जाने के लिए, मैं सिर्फ यह कहूंगा कि Microsoft से एक मानक लिंकर है जो समझने में सक्षम है और सबसे महत्वपूर्ण बात, क्रिंकलर में उपयोग के लिए डेल्फी 3 COFF में संकलित लोगों को ठीक करें।

परिणामस्वरूप, संकलन और सुधार कुछ इस तरह दिखाई देंगे:

dcc32.exe myunit.pas -jP link.exe -edit myunit.obj

तो, आइए जानें कि वांछित प्रारूप की ऑब्जेक्ट फ़ाइलों को कैसे संकलित किया जाए। केवल 2 समस्याएं बाकी हैं: ट्रिमिंग सिस्टम मॉड्यूल और प्रवेश बिंदु के नामकरण में अंतर।

डेल्फी में सिस्टम मॉड्यूल System.pas और SysInit.pas के रूप में प्रस्तुत किए जाते हैं, वे प्रोग्राम में उपयोग किए जाने वाले लगभग सभी मौलिक कार्यक्षमता (स्ट्रिंग्स, डायनेमिक सरणियों, कक्षाएं, इंटरफेस और डेमोसीन द्वारा आवश्यक अन्य बकवास) होते हैं। यह वह जगह है जहां कार्यक्रम प्रवेश बिंदु स्थित है। कंपाइलर स्वयं उनकी सामग्री पर अत्यधिक निर्भर है, इसलिए एक सफल संकलन के लिए उनकी उपस्थिति आवश्यक है। यह ध्यान दिया जाना चाहिए कि डेल्फी संकलक प्रत्येक इकाई के लिए इनिशियलाइज़ेशन / फाइनलेशन कॉलिंग कोड को स्पष्ट रूप से बचाता है, भले ही वे पूरी तरह से खाली हों। इसलिए, निष्पादन योग्य फ़ाइल के आकार को बचाने के लिए, प्रोजेक्ट में एक और इकाई बनाने से पहले पास्कल डिमोस्कीन को कठिन सोचना चाहिए।

कई प्रयोगों के माध्यम से, मैं ऐसे खुशी के लिए System.pas को कम करने में कामयाब रहा:

unit System; 
      

        
        
        
      

     interface 
      

        
        
        
      

     type 
      

        
        
        
      

     TGUID = Byte; 
      

        
        
        
      

     var 
      

        
        
        
      

     _HandleFinally : Byte; 
      

        
        
        
      

     implementation 
      

        
        
        
      

     end .

संदर्भ के लिए, मैं कहूँगा कि मूल रूप से _HandleFin एक फ़ंक्शन है और इसका उपयोग कंपाइलर के बॉल्स में किया जाता है, लेकिन तब से हम नहीं चाहते कि हमारा लिंकर उनके लिए अज्ञात कार्यों की कसम खाए, हम एक चर के साथ ऐसी "हैक" करते हैं।

SysInit.pas में, मैं आपके डेमो दृश्य के लिए कोड को शामिल करने की सिफारिश करूंगा, ताकि यूनिट हीप के लिए अनावश्यक इनिशियलाइज़ेशन कोड का उत्पादन न हो। बेहतर अभी तक, अपने कोड को इनिशियलाइज़ेशन सेक्शन में सीधे शामिल करें।

unit SysInit; 
      

        
        
        
      

     interface 
      

        
        
        
      

     var 
      

        
        
        
      

     _HandleFinally : Byte; 
      

        
        
        
      

     procedure ExitProcess(uExitCode: Cardinal); stdcall; external 'kernel32.dll' name '_ExitProcess@4'; 
      

        
        
        
      

     implementation 
      

        
        
        
      

     initialization 
      

        
        
        
      

     //...  ... 
      

        
        
        
      

     ExitProcess(0); 
      

        
        
        
      

     end .

निश्चित रूप से पाठक की गहरी आंख बाहरी dll कार्यों के नामकरण की ख़ासियत पर ध्यान देती है। यदि अर्थ स्पष्ट नहीं है, तो बस शुरुआत में "_" और अंत में "@parameter_size" जोड़ें, या आप नोटपैड के साथ वांछित काम करने वाली फ़ाइल को खोल सकते हैं और फ़ंक्शन की परिभाषा पा सकते हैं। इसके अलावा, फिर से हम अपने नकली चर को देखते हैं।

यह मामला एक साधारण बल्लेबाजी द्वारा संकलित है:

 rm system.dcu rm system.obj rm sysinit.dcu rm sysinit.obj echo -------------- dcc32.exe system.pas sysinit.pas -jP link.exe -edit sysinit.obj crinkler.exe kernel32.lib sysinit.obj /OUT:test.exe /ENTRY:initialization$qqrv /PRINT:IMPORTS /PRINT:LABELS /SUBSYSTEM:WINDOWS /COMPMODE:SLOW /UNSAFEIMPORT /HASHSIZE:256 /HASHTRIES:1000 /ORDERTRIES:10000 /TRUNCATEFLOATS:8 pause

यदि आप चाहें, तो आप मापदंडों के साथ खेल सकते हैं और एक विशिष्ट स्थिति के लिए इससे कुछ लाभ प्राप्त कर सकते हैं।

संकलन के बाद, हमें 572 बाइट के आकार के साथ एक साफ फ़ाइल मिलती है। यदि अब एक डमी फाइल पर यह एक बड़ी उपलब्धि नहीं लगती है, तो जैसे-जैसे कोड बढ़ता है, इसके सभी फायदे के साथ एक कंप्रेसर प्ले हो जाएगा।

यह ध्यान में रखा जाना चाहिए कि क्रिंकर लिंकिंग प्रक्रिया में एक सभ्य समय लगता है, इसलिए डिबगिंग के लिए यह विधानसभा के लिए लिंक को अनुकूलित करने के लिए बहुत उपयोगी होगा:

 link.exe kernel32.lib user32.lib gdi32.lib opengl32.lib sysinit.obj /OUT:test_orig.exe /ENTRY:initialization$qqrv /MERGE:.rdata=.text /MERGE:_INIT_=.text /FILEALIGN:512 /SECTION:.text,ERWX /IGNORE:4078 /IGNORE:4108 /IGNORE:4089 /NODEFAULTLIB /SUBSYSTEM:WINDOWS

इस मामले में, हम तुरंत हमारे 1.5kb डमी एप्लिकेशन प्राप्त करते हैं।

डेमो उदाहरण के साथ पूर्ण गोला बारूद

डेल्फी के साथ क्रिंकर का उपयोग करना

परिचय

यह कैसे काम करता है?

तैयारी और संकलन

More articles: