👨🏽‍🎓 😒 🤠 C # में P / Invoke Sign Generate करें। इंटरफ़ेस परिभाषा भाषा और OLE स्वचालन प्रकार पुस्तकालयों का दुरुपयोग 🙆🏻 📂 😚

यह P / Invoke क्या है पर एक और लेख नहीं है।

तो, चलो एक गोलाकार C # परियोजना में कहते हैं कि कुछ ऐसी तकनीक का उपयोग करना आवश्यक है जो .NET में उपलब्ध नहीं है, और हमारे पास जो भी विंडोज एसडीके 8.1 है उसमें सी / सी ++ के लिए केवल हेडर फ़ाइलों का एक सेट है। आपको प्रकारों का एक गुच्छा घोषित करना होगा, संरचनाओं के संरेखण की जांच करना और विभिन्न आवरण लिखना होगा। यह बहुत से नियमित काम हैं, और गलती करने का जोखिम है। आप निश्चित रूप से एक हेडर फ़ाइल पार्सर लिख सकते हैं ... इसके लिए आवश्यक मानव-घंटे की संख्या को छोड़कर यहां सब कुछ सरल और स्पष्ट है। इसलिए, हम इस विकल्प को छोड़ देते हैं और अप्रबंधित कोड के साथ बातचीत के लिए आवश्यक क्रियाओं की संख्या को कम करने के लिए अन्यथा प्रयास करते हैं।

इसके अलावा, परिणामी कोड प्रक्रिया की क्षमता पर निर्भर नहीं करेगा, सख्त टाइपिंग संरक्षित की जाएगी, और स्वचालित परीक्षण लागू किया जाएगा।

प्रबंधित और अप्रबंधित कोड की सहभागिता।

जैसा कि आप जानते हैं, .NET में अप्रबंधित कोड के साथ बातचीत करने के 2 मुख्य तरीके हैं:

सी ++ / सीएलआई : आप रैपर लिख सकते हैं - प्रबंधित तरीकों में अप्रबंधित कॉल लपेटें, मैन्युअल रूप से प्रबंधित मूल संरचना, स्ट्रिंग्स और सरणियों को प्रबंधित ऑब्जेक्ट में कनवर्ट करें। निस्संदेह यह जितना संभव हो उतना लचीला है, लेकिन अधिक नुकसान हैं।
सबसे पहले, यह कोड का एक गुच्छा है, जिसमें मानव रहित, क्रमशः, गलती करने का संभावित जोखिम (केवल देवता और झूठ बिना बग के लिखते हैं)।
दूसरे, नाखूनों के परिणामस्वरूप परिणामी असेंबली को आर्किटेक्चर - x64, x86, आदि के लिए नामित किया गया है, अगर हमारे पास पूरी AnyCPU परियोजना है, तो हमें कई प्लेटफार्मों के लिए रैपर इकट्ठा करना होगा और उन सभी को हमारे साथ खींचना होगा, इंस्टॉलेशन या स्टार्टअप के अनुसार विधानसभा लोड करना। विन्यास।
~~तीसरा, यह C ++ है, लेकिन इसकी आवश्यकता नहीं है।~~
P / Invoke और COM : COM का उपयोग करके कई विंडोज़ घटक लागू किए जाते हैं। सामान्य तौर पर, .net इस तकनीक के साथ यथोचित काम करता है। आवश्यक इंटरफेस और संरचनाएं या तो स्वतंत्र रूप से मैन्युअल रूप से घोषित की जा सकती हैं, या, यदि एक प्रकार का पुस्तकालय है, तो उन्हें विशेष tbbimp उपयोगिता का उपयोग करके स्वचालित रूप से वहां से आयात करें।
और आप DllImport विशेषता के साथ बाह्य विधियों को घोषित करके डायनामिक लाइब्रेरी से निर्यात किए गए फ़ंक्शन को कॉल कर सकते हैं। यहां तक कि एक पूरी साइट है जहाँ विज्ञापन मुख्य winapi कार्यों के लिए पोस्ट किए जाते हैं।

हमें टाइप लाइब्रेरी पर रहने दें। प्रकार लाइब्रेरीज़, जैसा कि आप नाम से अनुमान लगा सकते हैं, प्रकारों के बारे में जानकारी रखते हैं, और IDL संकलित करके प्राप्त किए जाते हैं - एक इंटरफ़ेस परिभाषा भाषा - एक भाषा जिसका सिंटैक्स सी के समान सुंदर है। प्रकार लाइब्रेरी आमतौर पर या तो .lb एक्सटेंशन के साथ अलग-अलग फ़ाइलों के रूप में वितरित की जाती हैं या उसी में एम्बेडेड होती हैं। डीएलएल जहां वर्णित वस्तुएं स्थित हैं। ऊपर उल्लिखित tlbimp उपयोगिता .NET के लिए आवश्यक घोषणाओं वाले प्रकार पुस्तकालयों से एक विशेष इंटरोप असेंबली उत्पन्न करती है।
चूंकि आईडी हेडल सिंटैक्स सी हेडर फाइलों में घोषणाओं के समान है, इसलिए पहला विचार जो दिमाग में आता है वह यह है कि क्या भविष्य में इसे एक .net प्रोजेक्ट में आयात करने के लिए किसी भी तरह से एक प्रकार की लाइब्रेरी उत्पन्न की जाए? यदि IDL फ़ाइल में आप हेडर फ़ाइलों से सभी आवश्यक घोषणाओं को व्यावहारिक रूप से कॉपी कर सकते हैं, जैसे कि वे सभी प्रकार के DWORD को uint में परिवर्तित करने के बारे में सोचे बिना हैं, तो यह वही है जो आपको चाहिए। लेकिन कई समस्याएं हैं: सबसे पहले, IDL सब कुछ का समर्थन नहीं करता है, और दूसरी बात, tlbimp सब कुछ आयात नहीं करता है। विशेष रूप से:

आप IDL में फ़ंक्शन पॉइंटर्स का उपयोग नहीं कर सकते
बिट फ़ील्ड को IDL में घोषित नहीं किया जा सकता है
tlbimp असुरक्षित कोड का उपयोग नहीं करता है, इसलिए आउटपुट में अप्राप्त इंटप्रेट द्वारा अधिकांश विशाल बिंदुओं का प्रतिनिधित्व किया जाएगा
यदि किसी पद्धति के लिए एक तर्क के रूप में संदर्भ द्वारा एक संरचना पारित की जाती है, तो tlbimp रेफरी जैसे तर्क की घोषणा करेगा। और अगर सिद्धांत रूप में यह निहित है कि सरणी का पता वास्तव में वहां स्थानांतरित किया जाना चाहिए, तो हम जंगल से गुजरते हैं। बेशक, आप पिन किए गए सरणी के अशक्त तत्व को रेफ के रूप में पारित कर सकते हैं, यह काम भी करेगा, लेकिन यह कुछ हद तक हिंदू दिखता है। किसी भी मामले में, रेफ के कारण, हम एक अशक्त सूचक को पास नहीं कर पाएंगे यदि तर्क अचानक वैकल्पिक है
Tlbimp स्ट्रिंग को C- शैली के नल-टर्मिनेटेड स्ट्रिंग्स (a la LPWSTR) में पॉइंटर्स को कनवर्ट करता है, और यदि अचानक खराब COM ऑब्जेक्ट मेमोरी के इस टुकड़े पर कुछ लिखने का फैसला करता है, तो एप्लिकेशन "क्वैक" कहेगा
tlbimp केवल इंटरफेस और संरचनाओं का आयात करता है। DLL के तरीकों को मैन्युअल रूप से घोषित करना होगा
tlbimp असेंबली बनाता है, लेकिन कोड नहीं। हालांकि इतना महत्वपूर्ण नहीं है

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

आईडीएल

मैं इस भाषा के विवरण पर ध्यान केंद्रित नहीं करूंगा, लेकिन आईडीएल के प्रमुख तत्वों को संक्षेप में सूचीबद्ध करेगा, जिनका उपयोग किया जाएगा। IDL का पूरा विवरण msdn में है

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

[uuid(00000000-0000-0000-0000-000000000001)] library Import { }

लेकिन अगर आपको अभी भी ब्लॉक के बाहर घोषित प्रकार को मजबूर करने की आवश्यकता है, तो आप लाइब्रेरी के अंदर लिख सकते हैं

 typedef MY_TYPE MY_TYPE;

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

 typedef struct tagTEST { int i; } TEST;

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

इंटरफ़ेस ब्लॉक का उपयोग इंटरफेस घोषित करने के लिए किया जाता है। इस फ़ंक्शन ब्लॉक के अंदर:

 [uuid(38BF1A5B-65EE-4C5C-9BC3-0D8BE47E8A1F)] interface IXAudio2MasteringVoice : IXAudio2Voice { HRESULT GetChannelMask(DWORD* pChannelmask); };

सब कुछ बहुत स्पष्ट है। हमारे मामले में विशेषताओं में से, केवल यूआईडी, जो कि इंटरफ़ेस की पहचानकर्ता है, महत्वपूर्ण है।

एक मॉड्यूल ब्लॉक भी है। इसमें, उदाहरण के लिए, आप DLL, या कुछ स्थिरांक से कार्य कर सकते हैं।

 [dllname("kernel32.dll")] module NativeMethods_kernel32 { const UINT DONT_RESOLVE_DLL_REFERENCES = 0x00000001; [entry("RtlMoveMemory")] void RtlMoveMemory( void *Destination, const void *Source, SIZE_T Length); }

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

आईडीएल विज्ञापन

हेडर फ़ाइल से क्या लिया जाना चाहिए, इसकी एक सूची बनाते हैं:

संरचनाओं और संघों, सहित थोड़े खेतों के साथ
स्थानांतरण
डीएलएल से आयात किए गए कार्यों की घोषणा
इंटरफेस
स्थिरांक (मैक्रो #define के साथ घोषित)
कार्य बिंदु
एलियास टाइप्स के माध्यम से घोषित किए गए प्रकार (जैसे कि DWORDs के सभी प्रकार, आदि)

अब हमें यह तय करने की आवश्यकता है कि इसे आईडीएल में कैसे कॉपी किया जाए।

संरचना और संघ : जैसा कि वांछित है, नाम से केवल अनावश्यक उपसर्गों को हटाते हुए कॉपी करें।
गणना : संरचनाओं के समान।
डीएलएल से आयात किए गए कार्यों की घोषणा : इसी डीएलएल के लिए मॉड्यूल ब्लॉक में कॉपी करें। जाहिर है, प्रत्येक DLL के लिए आपको कम से कम एक मॉड्यूल ब्लॉक बनाने की आवश्यकता होती है।
स्थिरांक (#define के माध्यम से घोषित) : बेशक, यह बहुत अच्छी तरह से काम नहीं करता है - आपको एक प्रकार जोड़ना होगा, अर्थात् उपरोक्त उदाहरण से स्थिर वास्तव में है
```
 #define DONT_RESOLVE_DLL_REFERENCES 0x00000001 
```
कुछ विकल्प हैं - मैक्रोज़ स्वाभाविक रूप से किसी भी तरह से टाइप लाइब्रेरी में नहीं जा सकते हैं।
एक अन्य समस्या सभी प्रकार की संरचनाएं हैं जैसे GUIDs DEFINE_GUID के साथ घोषित की गई हैं। ठीक है, सटीक होने के लिए, वास्तव में ये स्थिरांक नहीं हैं, लेकिन वैश्विक चर हैं, लेकिन इन्हें आमतौर पर स्थिरांक के रूप में उपयोग किया जाता है। यहाँ, अफसोस, कुछ भी नहीं। हम अभी भी GUID को स्ट्रिंग्स के रूप में घोषित कर सकते हैं, लेकिन हमें बाकी के साथ मैन्युअल रूप से निपटना होगा।
टाइप के माध्यम से घोषित उपनाम प्रकार (यानी DWORDs के सभी प्रकार, आदि): जैसा है वैसा ही कॉपी करें।
इंटरफेस : चूंकि सी या सी ++, इंटरफेस का समर्थन नहीं करते हैं, ज्यादातर हेडर फाइलों में उन्हें दो तरह से सशर्त संकलन के माध्यम से घोषित किया जाता है - सी ++ के लिए एक वर्ग के रूप में __declspec (uuid (x)) के साथ एक रूप में या किसी अन्य के रूप में और संरचना के लिए फ़ंक्शन की सूची के साथ फ़ंक्शन के लिए। C. हम C ++ के लिए घोषणाओं में रुचि रखते हैं। वे आमतौर पर इस तरह दिखते हैं:
```
 MIDL_INTERFACE("0c733a30-2a1c-11ce-ade5-00aa0044773d") ISequentialStream : public IUnknown { public: virtual /* [local] */ HRESULT STDMETHODCALLTYPE Read( /* [annotation] */ _Out_writes_bytes_to_(cb, *pcbRead) void *pv, /* [annotation][in] */ _In_ ULONG cb, /* [annotation] */ _Out_opt_ ULONG *pcbRead) = 0; virtual /* [local] */ HRESULT STDMETHODCALLTYPE Write( /* [annotation] */ _In_reads_bytes_(cb) const void *pv, /* [annotation][in] */ _In_ ULONG cb, /* [annotation] */ _Out_opt_ ULONG *pcbWritten) = 0; }; 
```
यहां से सब कुछ साफ करना आवश्यक है ताकि इंटरफ़ेस इस तरह दिखे:
```
 [uuid(0c733a30-2a1c-11ce-ade5-00aa0044773d)] interface ISequentialStream : IUnknown { HRESULT Read( void *pv, ULONG cb, ULONG *pcbRead); HRESULT Write( void const *pv, ULONG cb, ULONG *pcbWritten); }; 
```
यदि आप चाहें, तो आप टिप्पणियों को नहीं छू सकते हैं, और [एनोटेशन (...)] विशेषता में SAL एनोटेशन छिपा सकते हैं।
हां, कई ऑपरेशन अभी भी किए जाने हैं, लेकिन प्रमुख बिंदु, साथ ही साथ लेख का मुख्य सार यह है कि हम फ़ंक्शन और रिटर्न मानों के तर्कों को नहीं छूते हैं । यानी हालांकि मूल घोषणा कुछ हद तक बदल जाती है, इसकी शुद्धता की गारंटी के लिए पर्याप्त आत्मविश्वास के साथ संभव है, क्योंकि सभी प्रकार और अप्रत्यक्ष स्तर के संकेत अपरिवर्तित रहते हैं। यदि हम कुछ साफ करना भूल जाते हैं, तो वह संकलन नहीं करेगा, लेकिन यदि वह संकलन करता है, तो परिणाम सही होगा क्योंकि "हस्ताक्षर" नहीं बदलते हैं।
कार्य करने के लिए संकेत : यहां बैसाखी शुरू होती है। हम एक विधि के साथ एक इंटरफ़ेस की घोषणा करेंगे, और एक प्रकार की लाइब्रेरी को परिवर्तित करते समय, हम ऐसे इंटरफेस को प्रतिनिधियों में बदल देंगे। इस प्रकार, पहले की तरह, हम तर्कों को नहीं छूएंगे, और इस सूचक का उपयोग करने वाले बाकी कोड संकलन त्रुटियों का उत्पादन नहीं करेंगे।
यानी उदाहरण के लिए यह:
```
 typedef LRESULT (CALLBACK* WNDPROC)(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam); 
```
इस तरह दिखेगा:
```
 [uuid(C17B0B13-6E49-4268-B699-2D083BAE88F9) interface WNDPROC : __Delegate { LRESULT WNDPROC(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam); } 
```
इस मामले में, __ डेलीगेट वह खाली इंटरफ़ेस है जिसे हमने घोषित किया था, जिसके द्वारा हम ऐसे "फंक्शन पॉइंटर" को साधारण इंटरफेस से अलग करेंगे। Uuid विशेषता में एक यादृच्छिक मूल्य होता है (इसलिए किसी भी चीज़ के साथ संघर्ष नहीं करना), यह बस इसके बिना संकलित नहीं किया जा सकता है। बेशक, सभी फ़ंक्शन पॉइंटर्स को शून्य * से बदलना संभव होगा, लेकिन इस हैक के लिए धन्यवाद हम मजबूत टाइपिंग रखेंगे, उदाहरण के लिए, टाइप लाइब्रेरी में WNDCLASSEX संरचना में WNDPROC lpfnWndProc फ़ील्ड को भी दृढ़ता से टाइप किया जाएगा, और हमें केवल टाइप के नाम और अप्रत्यक्ष स्तर के बारे में जानकारी चाहिए । तथ्य यह है कि इस इंटरफ़ेस से कोई फर्क नहीं पड़ता।
Bitfields : हालाँकि यह संरचनाओं पर लागू होता है, मैंने उन्हें एक अलग पैराग्राफ में रखा क्योंकि यहाँ मुझे भी ट्रिक करनी है। किसी तरह बिट्स की संख्या के बारे में जानकारी किसी तरह संलग्न करना आवश्यक है। उदाहरण के लिए, आप सरणियों का उपयोग करके ऐसा कर सकते हैं। और यह समझने के लिए कि यह एक प्रकार का फ़ील्ड है जब एक प्रकार की लाइब्रेरी को परिवर्तित करते हुए, कुछ अनावश्यक विशेषता जोड़ें। उदाहरण के लिए, यह:
```
 struct DWRITE_LINE_BREAKPOINT { UINT8 breakConditionBefore : 2; UINT8 breakConditionAfter : 2; UINT8 isWhitespace : 1; UINT8 isSoftHyphen : 1; UINT8 padding : 2; }; 
```
इस तरह घोषित करें:
```
 typedef struct DWRITE_LINE_BREAKPOINT { [replaceable] UINT8 breakConditionBefore[2]; [replaceable] UINT8 breakConditionAfter[2]; [replaceable] UINT8 isWhitespace[1]; [replaceable] UINT8 isSoftHyphen[1]; [replaceable] UINT8 padding[2]; } DWRITE_LINE_BREAKPOINT; 
```
और सादगी के लिए, हम इस बात से सहमत हैं कि यदि संरचना में कुछ क्षेत्र हैं, तो सामान्य क्षेत्र नहीं होना चाहिए। फिर ऐसी घोषणाएँ:
```
 typedef struct TEST { int i1 : 1; int i2 : 31; float f1; } TEST; 
```
इसे परिवर्तित करना आवश्यक होगा:
```
 typedef struct TEST { struct { int i1 : 1; int i2 : 31; }; float f1; } TEST; 
```
लेकिन बिट फ़ील्ड बहुत दुर्लभ हैं, इसलिए, सिद्धांत रूप में, वे पूरी तरह से असमर्थित हो सकते हैं, लेकिन आधार प्रकार के साथ बदल दिया गया है और पहले से ही मैन्युअल रूप से सी # में बाकी है:
```
 typedef struct TEST { int i; float f1; } TEST; 
```

देशी पुस्तकालयों के साथ काम करते समय जरूरत की हर चीज के बारे में IDL को जानकारी हस्तांतरित करने के लिए पर्याप्त होना चाहिए। बेशक, सी ++ के लिए विभिन्न वर्गों और टेम्पलेट्स को ध्यान में नहीं रखा गया है, लेकिन किसी भी मामले में, विंडोज एपीआई से हेडर फ़ाइलों की सामग्री का लगभग पचहत्तर प्रतिशत इस तरह से स्थानांतरित किया जा सकता है। कई गंदे हैक होने के बावजूद, IDL की प्रतिलिपि बनाना अभी भी आसान, तेज और CLI पर रैपर लिखने या मैन्युअल रूप से .NET में प्रकारों की घोषणा करने की तुलना में सुरक्षित है।

C # में विज्ञापन

अब आइए देखें कि यह सब C # में कैसे दिखना चाहिए।

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

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

इसके अलावा, आयातित घोषणाओं का उपयोग सी में जितना संभव हो उतना करीब होगा , जो पहले से लिखे गए कोड के हस्तांतरण को सुविधाजनक बनाने में सक्षम हो सकता है। यह तुरंत ध्यान दिया जाना चाहिए कि C # में एक चर का पता प्राप्त करने के लिए, यह एक धुंधला प्रकार होना चाहिए। हमारी सभी संरचनाएं इन आवश्यकताओं को पूरा करेंगी। हम एरो के साथ खेतों को तय घोषित करते हैं, हम तार के लिए चार * / बाइट * का उपयोग करेंगे, लेकिन बूल प्रकार प्रक्षालित नहीं है, इसलिए, हमारे मामले में, इसका प्रतिनिधित्व करने के लिए, हम एक इंट फील्ड के साथ एक संरचना का उपयोग करेंगे और ऑपरेटर्स को / से बूल तक डाली जाएगी। संरचनाओं के अंदर की सरणियों पर अधिक विस्तार से चर्चा की जानी चाहिए। सीमाएँ हैं: सबसे पहले, निश्चित कीवर्ड केवल आदिम प्रकारों के सरणियों पर लागू होता है, इसलिए संरचनाओं के सरणियों को इस तरह घोषित नहीं किया जा सकता है, और दूसरी बात, केवल एक आयामी सरणियों का समर्थन किया जाता है। नियमित सरणियों (मार्शलों की विशेषता और SizeConst विकल्प के साथ) में संरचनाएं हो सकती हैं, लेकिन वे एक प्रक्षालित प्रकार नहीं हैं, और इसके अलावा वे केवल एक-आयामी हो सकते हैं। इस समस्या को हल करने के लिए, सरणियों के लिए हम तत्वों की संख्या से निजी क्षेत्रों के साथ विशेष संरचना बनाएंगे। इस तरह की संरचनाओं में तत्वों तक पहुंचने के लिए एक अनुक्रमणिका संपत्ति होगी, साथ ही / से प्रबंधित सरणियों की नकल के लिए निहित ऑपरेटर भी होंगे। कई इंडेक्स पर पहुंच के माध्यम से छद्म आयाम प्रदान किया जाएगा। यानी 4x4 मैट्रिक्स 16 क्षेत्रों के साथ एक संरचना होगी, और इंडेक्सर संपत्ति पहले तत्व का पता लेगी और निम्नलिखित सूत्र का उपयोग करके ऑफ़सेट की गणना करेगी: index1 * length1 + index2, जहां length1 4 है, और दोनों सूचकांक 0 से 3 तक की संख्या हैं।

संरचनाओं और संघों: संरचनाओं के रूप में संरचनाएं, कुछ खास नहीं। सभी क्षेत्रों के लिए यूनियनों LayoutKind.Explicit और FieldOffset (0) के लिए। विशेष रूप से नोट संरचनाओं और संघों के साथ नामहीन क्षेत्र हैं। तथ्य यह है कि टाइप लाइब्रेरी इस का समर्थन नहीं करते हैं, इसके बजाय, उन्हें __MIDL__ से शुरू होने वाले उत्पन्न नाम दिए जाएंगे।
संरचना
```
 typedef struct TEST { struct { int i; }; } TEST; 
```
वास्तव में यह कुछ इस तरह होगा:
```
 typedef struct TEST { struct __MIDL___MIDL_itf_Win32_0001_0001_0001 { int i; } __MIDL____MIDL_itf_Win32_0001_00010000; } TEST; 
```
तदनुसार, यदि आप इसे C # के रूप में आयात करते हैं, तो हमें निम्नलिखित मिलेंगे:
```
 [StructLayout(LayoutKind.Sequential)] public unsafe struct TEST { [StructLayout(LayoutKind.Sequential)] public unsafe struct __MIDL___MIDL_itf_Win32_0001_0001_0001 { public int i; } public __MIDL___MIDL_itf_Win32_0001_0001_0001 __MIDL____MIDL_itf_Win32_0001_00010000; } 
```
सिद्धांत रूप में, इसके साथ नरक करने के लिए, लेकिन सी में फ़ील्ड i की पहुंच सीधे प्रदर्शन की जाती है, जैसे कि यह मुख्य संरचना का क्षेत्र है, अर्थात। myVar.i, और यहाँ डरावना myVar होगा। __MIDL ____ MIDL_itf_Win32_0001_00010000.i। उपयुक्त नहीं है, इसलिए, ऐसे मामलों के लिए हम नेस्टेड अनाम संरचनाओं के क्षेत्रों तक सीधे पहुंचने के लिए गुण उत्पन्न करेंगे:
```
 [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)] public unsafe struct TEST { [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)] public unsafe struct __MIDL___MIDL_itf_Win32_0001_0001_0001 { public int i; } public __MIDL___MIDL_itf_Win32_0001_0001_0001 __MIDL____MIDL_itf_Win32_0001_00010000; public int i { get { return __MIDL____MIDL_itf_Win32_0001_00010000.i; } set { __MIDL____MIDL_itf_Win32_0001_00010000.i = value; } } } 
```
शायद यह दृष्टिकोण कमियों के बिना नहीं है, लेकिन यह आपको अधिकतम विज्ञापन पत्राचार प्राप्त करने और ऐसी संरचनाओं को सही ढंग से संसाधित करने की अनुमति देता है, उदाहरण के लिए:
```
 typedef struct TEST { union { struct { int i1; int i2; }; struct { float f1; float f2; }; }; char c1; } TEST; 
```
गुणों के माध्यम से सीधी पहुंच आपको संरचना के साथ लगभग सी के रूप में काम करने की अनुमति देगा। एकमात्र अपवाद यह है कि जब नेस्टेड फ़ील्ड का पता आवश्यक है, तो आपको अभी भी पूर्ण पथ निर्दिष्ट करने की आवश्यकता है।
लिस्टिंग। यहां सब कुछ सरल है, सिंटैक्स में केवल मामूली अंतर है।
बिट क्षेत्र। वे इस तरह दिखेंगे - एक पूर्णांक निजी चर (प्रकार बिट क्षेत्रों के साथ संरचना के कुल आकार पर निर्भर करता है) और उत्पन्न गुण जो केवल संबंधित बिट्स को पढ़ने / सेट करने के लिए बिट संचालन करते हैं:
```
 [StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode, Pack = 1)] public unsafe struct DWRITE_LINE_BREAKPOINT { private byte __bit_field_value; public byte breakConditionBefore { get { return (byte)((__bit_field_value >> 8) & 3); } set { __bit_field_value = (byte)((value & 3) << 8); } } public byte breakConditionAfter { get { return (byte)((__bit_field_value >> 8) & 3); } set { __bit_field_value = (byte)((value & 3) << 8); } } ... } 
```
डीएलएल से आयात किए गए कार्यों की घोषणा: मूल रूप से, नेटिवमेथोड्स क्लास में डीएलआईएमपोर्ट विशेषता के साथ स्थिर बाहरी तरीके
टाइपियाफ के माध्यम से घोषित उपनाम प्रकार: यदि कोई अतिरिक्त विशेषताओं को गलती से आईडीएल में लपेटा नहीं गया था, तो टाइप लाइब्रेरी को संकलित करते समय उपनाम स्वयं बदल दिया जाएगा ( यहां देखें)। और अगर वे सभी वहां पहुंचते हैं, तो उस प्रकार का स्थानापन्न करें जो वे उनके बजाय प्रतिनिधित्व करते हैं।
स्थिरांक: मूल निवासी वर्ग में स्थिरांक। रेखाएँ या संख्याएँ।
कार्यों के लिए संकेत (जो विशेष इंटरफेस के रूप में हैं): हम 2 मुख्य प्रकार उत्पन्न करते हैं: एक प्रतिनिधि और एक संरचना, जो स्वयं सूचक होगी। प्रकार शून्य की संरचना में एक निजी क्षेत्र है *। और निहित संचालक के माध्यम से, प्रतिनिधि को मार्शल से कॉल करके / से प्रतिनिधि के लिए स्पष्ट रूप से टाइप किए गए ।GetFunctionPointerForDelegate और Mars.GetDelegateForFunctionPointer
इंटरफेस: यहां सब कुछ सरल लग रहा था - ComImport विशेषता के साथ इंटरफ़ेस घोषित किया गया था और बात टोपी में है, और अतिरिक्त कार्यक्षमता के लिए थोक तरीकों में मार्शल वर्ग में है।
लेकिन नहीं, यह केवल COM इंटरफेस के लिए काम करता है। और वे आसानी से कुछ वापस कर सकते हैं जो IUnogn विरासत में नहीं मिलता है। उदाहरण के लिए IXAudio2Voice। और यहां मानक .NET तंत्र आपको "क्वैक" बताएगा। खैर, यह डरावना नहीं है, स्टॉक में एक पेचीदा नाइट चाल है - हम खुद वर्चुअल विधि टेबल उत्पन्न करेंगे और उन्हें मार्शल के माध्यम से कॉल करेंगे। यहां कुछ खास नहीं है - इंटरफेस को संरचनाओं द्वारा दर्शाया जाएगा, जिसके अंदर बिंदुओं के एक सेट के साथ निजी संरचनाएं हैं। प्रत्येक इंटरफ़ेस फ़ंक्शन के लिए, मुख्य संरचना एक विधि उत्पन्न करती है जो मार्शल के माध्यम से संबंधित पॉइंटर को कॉल करती है। GetDelegateForFunctionPointer। साथ ही इंटरफ़ेस विरासत के मामले में प्रकार रूपांतरण का समर्थन करने के लिए निहित बयानों का एक सेट। इसे यहां लाने के लिए उदाहरण बहुत अधिक जगह ले जाएगा, इसलिए सब कुछ संलग्न संग्रह में देखा जा सकता है।

रूपांतरण उपयोगिता

यह सब सिद्धांत के साथ है। अभ्यास के लिए आगे बढ़ते हैं।

विंडोज एसडीके में शामिल मिडल कंपाइलर आईडीएल को एक प्रकार की लाइब्रेरी में परिवर्तित करने के लिए जिम्मेदार होगा।

C # में टाइप लाइब्रेरी के रूपांतरण के लिए, कोड को अपनी उपयोगिता से उत्तर दिया जाएगा (लेकिन हम इसे से कंपाइलर भी चलाएंगे)।

मैं दूसरे के साथ शुरू करूँगा। ITypeLib2 और ITypeInfo2 के मानक इंटरफ़ेस का उपयोग टाइप लाइब्रेरी की सामग्री को पढ़ने के लिए किया जाता है। प्रलेखन को यहाँ देखा जा सकता है । वे tlbimp उपयोगिता में भी उपयोग किए जाते हैं। कनवर्टर का कार्यान्वयन कुछ भी दिलचस्प नहीं है, इसलिए इसके बारे में बताने के लिए अधिक कुछ नहीं है। स्रोत कोड संलग्न संग्रह में है (और हां, मुझे पता है कि C # कोड उत्पन्न करने के लिए पुस्तकालय हैं, लेकिन उनके बिना यह आसान है)।

अब IDL संकलन के बारे में।

कंपाइलर फ़ाइलों को एक अलग फ़ोल्डर में कॉपी करें। सबसे पहले, क्योंकि आपको उन्हें संशोधित करना है, और दूसरी बात, विंडोज 8.1 एसडीके से छुटकारा पाने के लिए और सी: \ प्रोग्राम फाइल्स (x86) \ blablab जैसे कहीं भी पूर्ण पथ नहीं लिखना है।
निम्न फ़ाइलों की आवश्यकता होगी:
C: \ Program Files (x86) \ Microsoft विज़ुअल स्टूडियो 12.0 \ VC \ bin \ amd64 \ 1033 \ clui.dll
C: \ Program Files (x86) \ Microsoft दृश्य स्टूडियो 12.0 \ VC \ bin \ amd64 \ c1.dll
C: \ Program Files (x86) \ Microsoft Visual Studio 12.0 \ VC \ bin \ amd64 \ cl.exe
C: \ Program Files (x86) \ Microsoft विज़ुअल स्टूडियो 12.0 \ VC \ bin \ amd64 \ mspdb120.dll
C: \ Program Files (x86) \ Windows Kits \ 8.1 \ bin \ x64 \ midl.exe
C: \ Program Files (x86) \ Windows Kits \ 8.1 \ bin \ x64 \ midlc.exe
हम एक ढेर में clui.dll को छोड़कर सब कुछ डंप करते हैं। और clui.dll 1033 के सबफ़ोल्डर में स्थित होना चाहिए।

Midl.exe प्रक्रिया एक और प्रक्रिया शुरू करती है - midlc.exe, जो सभी काम करती है।

कंपाइलर को ओईडल.आईडीएल नाम की एक फाइल की मौजूदगी की आवश्यकता होती है, जो पहुंच के भीतर IUnogn इंटरफ़ेस द्वारा घोषित की गई है। सुविधा के लिए, हम इस फ़ाइल की एक प्रति बनाएंगे और मूल oaidl.idl से मुख्य घोषणाओं की प्रतिलिपि बनाएँ और जिन फ़ाइलों को यह संदर्भित करता है। यद्यपि आप अपने आप को केवल IUnogn इंटरफ़ेस तक सीमित कर सकते हैं, आप उनके उपयोग के रूप में अन्य विज्ञापन जोड़ सकते हैं। संकलित फ़ाइल को संकलक के बगल में रखें।
यह आवश्यक है कि सिस्टम प्रकारों के उस हिस्से को थोड़ा ठीक करना होगा। उदाहरण के लिए, हमें एक क्षेत्र के साथ संरचनाओं के रूप में BOOL और BOOLEAN की आवश्यकता होती है ताकि इंट और बाइट के साथ गड़बड़ न हो, लेकिन बूल को ऐसी संरचना का समर्थन करने के लिए (जो, जैसा कि ऊपर उल्लेख किया गया है, एक प्रक्षालित प्रकार नहीं है और इसलिए सीधे उपयोग नहीं किया जा सकता है)। आपको फ़ंक्शन इंटरफ़ेस को उसी स्थान पर टाइप करने के लिए आधार इंटरफ़ेस घोषित करने की भी आवश्यकता है।

संकलक में बाइंडिंग फिक्सिंग कंपाइलर प्रतिबंध

टार का बैरल निम्नलिखित विशेषता थी: http://support.microsoft.com/default.aspx?scid=kb=en-us-220137 ; Microsoft इसे एक सुविधा के रूप में स्थान दे रहा है। एक तरफ, यह तर्कसंगत है - प्रकार पुस्तकालयों का मुख्य उद्देश्य OLE स्वचालन है, जो केस-असंवेदनशील भाषाओं के लिए समर्थन का अर्थ है। दूसरी ओर, कार्यान्वयन यह है कि इसे हल्के ढंग से रखा जाए, यह अजीब है - तर्कों के नाम और तरीकों या विधियों के नामों के बीच कोई संबंध नहीं है, टाइप नामों के लिए अलग-अलग सूचियों के बजाय तार की एक वैश्विक सूची का उपयोग क्यों करें, प्रत्येक प्रकार में विधि के नाम के लिए अलग-अलग सूची इत्यादि? किसी भी मामले में, इस तरह के "डिजाइन द्वारा" हमें शोभा नहीं देता, क्योंकि परिणाम नामों में एक राक्षसी कचरा संग्रह है, और स्वचालित परीक्षण (नीचे देखें) के साथ समस्याएं होंगी, क्योंकि इसके लिए स्रोत फ़ाइलों में उन नामों के सटीक मिलान की आवश्यकता होती है।

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

डीबगर के साथ सशस्त्र, हम KB220137 में वर्णित व्यवहार की व्यावहारिक पुष्टि करते हैं:

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

इसके अलावा, oleaut32.dll (ICreateTypeLib, ICreateTypeInfo, आदि) से COM ऑब्जेक्ट, जो डुप्लिकेट नामों की जांच करने के लिए ComparStringA का भी उपयोग करते हैं, एक प्रकार की लाइब्रेरी के साथ एक फ़ाइल बनाने के लिए उपयोग किया जाता है।उदाहरण के लिए, फ़ंक्शन ICreateTypeInfo :: SetVarName उस परिणाम को TYPE_E_AMBIGUOUSNAME लौटाएगा जब संरचना में एक फ़ील्ड जोड़ने का प्रयास किया जाएगा जो केवल मौजूदा मामले से अलग है। यद्यपि वहाँ कोई वैश्विक शब्दकोश नहीं लगता है, और इस तरह के चेक केवल उन फ़ील्ड्स और विधियों के लिए किए जाते हैं जिनमें उन्हें टाइप किया जाता है।

ऊपर से, कार्य स्पष्ट हो जाता है - तुलनास्ट्रीमिंग कॉल को रोकना और dwCmpFlags तर्क से NORM_IGNORECASE ध्वज को हटाना।

Midlc.exe, कर्नेल 32.dll से तुलनाStringA को आयात करता है, जो बदले में karbase.dll से ComparStringA कॉल करता है, और oleaut32.dll तुरंत कर्नेलबेस.dll से ComparStringA का उपयोग करता है। चूंकि यह सिस्टम लाइब्रेरी को बदलने के लिए काम नहीं करेगा, इसलिए हम इसे रनटाइम में इंटरसेप्ट करेंगे।

यह एक प्राथमिक तरीके से किया जाता है: आपको प्रक्रिया में अपना कोड एम्बेड करना होगा और, फ़ंक्शन का पता प्राप्त करने के बाद, कोड को संशोधित करें ताकि इंटरसेप्टर पर नियंत्रण स्थानांतरित किया जा सके, जहां आवश्यक संचालन करने और नियंत्रण वापस स्थानांतरित करने के लिए। ऐसा करने के लिए, आप इस पुस्तकालय का उपयोग एक उदाहरण के रूप में कर सकते हैं: http://www.codeproject.com/Articles/44326/MinHook-The-Mimalimalistic-x86-x64-API-Hooking-Libra (संलग्न संग्रह में थोड़ा संशोधित संस्करण है - कोड को सामान्य रूप से फिर से लिखा गया है। भाषा और अतिरिक्त कार्यक्षमता से साफ)।

प्रक्रिया को लागू करने के लिए, एक DLL बनाएं और midlc.exe फ़ाइल के आयात तालिकाओं को संशोधित करें ताकि यह हमारी लाइब्रेरी को स्टार्टअप पर लोड करे। इंटरसेप्टर को DllMain प्रवेश बिंदु पर आरंभीकृत किया जाएगा।

आप आयात तालिकाओं को मैन्युअल रूप से संशोधित कर सकते हैं, लेकिन तैयार उपयोगिताओं का उपयोग करना बेहतर है, उदाहरण के लिए, यहां http://www.ntcore.com/exsuite.php । सीएफएफ एक्सप्लोरर उपयोगिता में, आपको हमारे पुस्तकालय को जोड़ने के लिए exe फ़ाइल को खोलने और बाईं ओर आयातकर्ता का चयन करने की आवश्यकता है।

फ़ाइलों को प्रोजेक्ट से कनेक्ट करें

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

 /* <#@ include file="..\InternalTools\TransformIDL.tt" #> */

और IDL फ़ाइल के गुणों में, TextTemplatingFileGenerator को कस्टम टूल के रूप में निर्दिष्ट करें।

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

इसके लिए धन्यवाद .id फ़ाइल में किसी भी परिवर्तन को सहेजने से स्वचालित रूप से पीढ़ी शुरू हो जाएगी और कोड अपडेट हो जाएगा।

यह ध्यान दिया जाना चाहिए कि टी 4 में पाठ के निरंतर ब्लॉकों के आकार (अफवाह ~ 64kb) पर प्रतिबंध हैं, इसलिए जब आप एक बहुत बड़ी फ़ाइल को बचाने की कोशिश करते हैं, तो आप त्रुटि को पकड़ सकते हैं "संकलन बदलना: एक अभिव्यक्ति संकलन के लिए बहुत लंबा या जटिल है"। इस स्थिति में, आपको समय-समय पर निम्न पंक्तियों को फ़ाइल में जोड़ना चाहिए:

 // <# #>

सेटिंग्स

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

परीक्षण

हम निम्नलिखित चीजों का परीक्षण करेंगे:

निर्दिष्ट DLL में कार्यों की उपस्थिति
संरचनाओं का आयाम
संरचनाओं में सभी क्षेत्रों के ऑफसेट

इसके अलावा, चूंकि वर्णित समाधान ओएस बिट गहराई से बंधा नहीं है, इसलिए 32-बिट और 64-बिट दोनों मोड में सब कुछ परीक्षण किया जाएगा।

आप गणना के आकार का परीक्षण भी कर सकते हैं। लेकिन 99% मामलों में वे 4 बाइट पर कब्जा कर लेते हैं। इसलिए, इंट के अलावा अन्य आधार प्रकार के साथ गणना करने की संभावना पर विचार नहीं किया जाता है।

देशी कोड से आकार और ऑफसेट के बारे में जानकारी प्राप्त की जानी चाहिए। ऐसा करने के लिए, CLI (32 और 64) पर दो असेंबली बनाएं। उपयोगिता द्वारा उत्पन्न प्रबंधित प्रकारों का उपयोग करके, हम आवश्यक डेटा प्राप्त करने के लिए एक कोड फ़ाइल उत्पन्न करते हैं। हम शुरुआती के साथ मैक्रोज़ उत्पन्न करेंगे:

 #define STRUCT_SIZES \ {\ { L"ARRAYDESC", sizeof(::ARRAYDESC) },\ { L"BLOB", sizeof(::BLOB) },\ { NULL, 0 }\ }\ #define STRUCT_OFFSETS \ {\ { L"ARRAYDESC.tdescElem", FIELD_OFFSET(::ARRAYDESC, tdescElem) },\ { L"ARRAYDESC.tdescElem.lptdesc", FIELD_OFFSET(::ARRAYDESC, tdescElem.lptdesc) },\ { NULL, 0 }\ }\

संरचनाओं की सरणियों के लिए:

 STRUCT_SIZE structSizes[] = STRUCT_SIZES; STRUCT_OFFSET structOffsets[] = STRUCT_OFFSETS;

संकलक पैच के बिना, यह चरण स्वचालित नहीं हो सकता है!

एक लूप में सरणियों के माध्यम से जाने पर, हम सामग्री को शब्दकोश <string> int> में बदल देते हैं। पहले मामले में, कुंजी संरचना का नाम और उसके आकार का मूल्य होगा। दूसरे में, कुंजी फ़ील्ड के लिए 'पूर्ण पथ' की तरह कुछ है, और मूल्य संरचना में इस फ़ील्ड की ऑफसेट है।

डेटा 32 और 64 बिट संस्करणों के लिए अलग-अलग होगा, यही कारण है कि हमें दो विधानसभाओं की आवश्यकता है। यह डेटा C # में परीक्षण कक्षाओं से लिया गया है। इसके बाद, परीक्षण इन आकारों और ऑफरों की तुलना मार्शल के साथ प्राप्त संरचनाओं के लिए समकक्षों के साथ करेगा।

हम LoadLibrary और GetProcAddress को कॉल करके dll में विधियों की उपलब्धता की जाँच करेंगे। यदि उन्होंने काम किया है, तो सब कुछ क्रम में है, यदि नहीं, तो ऐसा कोई फ़ंक्शन नहीं है या आईडीएल में विशेषताओं में गड़बड़ है।

इस प्रकार, नए विज्ञापन जोड़ते समय, परीक्षणों को बदलना नहीं पड़ता है। ठीक है, अधिक सटीक रूप से, कभी-कभी केवल फाइलों के साथ #include निर्देशों को जोड़ना आवश्यक होगा जहां स्रोत संरचनाएं घोषित की जाती हैं, ताकि परीक्षण संकलित हो।

लेकिन यहाँ एक और समस्या की प्रतीक्षा की जा रही है - VisualStudio 32-बिट और 64-बिट दोनों परीक्षणों के लिए एक साथ खोज नहीं कर सकता है। या तो एक या दूसरे से। इस कारण से, परीक्षण अलग-अलग प्रक्रियाएं शुरू करेंगे जो सभी परीक्षण तर्क को निष्पादित करेंगे, और परीक्षण कक्षाएं स्वयं ही निष्पादन का परिणाम दिखाएंगी।

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

 typedef struct SOCKET_ADDRESS_LIST { INT iAddressCount; SOCKET_ADDRESS Address[1]; } SOCKET_ADDRESS_LIST;

X64 में, पता सरणी में 8 का ऑफसेट होगा, अर्थात iAddressCount फ़ील्ड के बाद, 4 बाइट्स की पैडिंग आवश्यक है। X86 पर यह नहीं होना चाहिए। .NET में एक एनालॉग दोनों प्लेटफार्मों पर 4 बाइट्स द्वारा संरेखित किया जाएगा। घोड़े की मुश्किल चाल इस प्रकार है:

 typedef struct SOCKET_ADDRESS_LIST { union { INT iAddressCount; [hidden] void* ___padding000; }; SOCKET_ADDRESS Address[1]; } SOCKET_ADDRESS_LIST;

कोड में उपयोग के दृष्टिकोण से, संरचना समतुल्य है, लेकिन उत्पन्न .NET संरचनाओं में इसका आवश्यक प्रभाव पड़ेगा - एक अतिरिक्त फ़ील्ड 32-बिट मोड में 4 बाइट्स और 64-बिट मोड में 8 बाइट्स का स्थान लेगी, जिससे 4 बाइट्स द्वारा "शिफ्टिंग" सरणी होगी। केवल 64-बिट मोड में।
सशर्त संकलन के माध्यम से सीमांत संरेखण सेटिंग्स (x86 के लिए एक ला #pragma पैक (2) और x64 के लिए #pragma पैक (16)) पर विचार नहीं किया जाता है - 99% संरचनाएं डिफ़ॉल्ट रूप से या 1 बाइट द्वारा गठबंधन की जाती हैं, बाकी सब की जरूरत नहीं है।

कभी-कभी, संरचनाएँ x86 और x64 पर मूल रूप से भिन्न होती हैं, उदाहरण के लिए WSADATA। ऐसे मामलों के लिए, मेरे पास कोई समाधान नहीं है। उन्हें मैन्युअल रूप से निपटा जाना होगा, लेकिन ऐसी संरचनाएं अत्यंत दुर्लभ हैं।

वह सब है।संलग्न संग्रह में उपयोग के उदाहरण के साथ सभी स्रोत कोड।
किसी भी लाइसेंस समझौतों का उल्लंघन नहीं करने के लिए, मिडल कंपाइलर शामिल नहीं है। आप इसे VisualStudio स्थापित करके ले सकते हैं और इसे स्वयं पैच कर सकते हैं (64-बिट संस्करण का उपयोग किया गया था)।

लेख के लिए कोड

C # में P / Invoke Sign Generate करें। इंटरफ़ेस परिभाषा भाषा और OLE स्वचालन प्रकार पुस्तकालयों का दुरुपयोग