विंडोज़ मेटाफ़ाइल

विंडोज़ मेटाफ़ाइल (डब्लूएमएफ) एक इमेज फाइल फॉर्मेट है जिसे मूल रूप से 1990 के दशक में माइक्रोसॉफ्ट विंडोज़ के लिए डिज़ाइन किया गया था। मूल विंडोज़ मेटाफ़ाइल प्रारूप डिवाइस-स्वतंत्र नहीं था (हालांकि प्लेसमेंट हेडर के साथ इसे और अधिक बनाया जा सकता था) और इसमें वेक्टर ग्राफिक्स और बिटमैप दोनों घटक सम्मिलित हो सकते हैं। यह एसवीजी फाइलों की तरह ही कार्य करता है। WMF फ़ाइलों को बाद में एन्हांस्ड मेटाफ़ाइल्स (EMF फ़ाइलें) द्वारा प्रतिस्थापित किया गया, जो डिवाइस की स्वतंत्रता प्रदान करती थी। EMF फ़ाइलों को फिर EMF+ फ़ाइलों के माध्यम से बढ़ाया गया।

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

मेटाफ़ाइल्स के तीन प्रमुख प्रकार हैं - WMF एक 16-बिट प्रारूप है जिसे विंडोज़ 3.0 में प्रस्तुत किया गया है। यह वर्ड, पावर पॉइंट और प्रकाशक जैसे माइक्रोसॉफ़्ट ऑफिस अनुप्रयोगों के लिए मूल वेक्टर प्रारूप है। 2017 के अनुसार विंडोज मेटाफ़ाइल प्रारूप विनिर्देश का संशोधन 14 ऑनलाइन पढ़ने या पीडीएफ के रूप में डाउनलोड करने के लिए उपलब्ध है। ईएमएफ फाइलें, जिन्होंने डब्लूएमएफ फाइलों को प्रतिस्थापित किया, उसी सिद्धांत पर काम करती हैं, केवल यह एक 32-बिट फ़ाइल प्रारूप है जो "टिप्पणी" रिकॉर्ड के भीतर निजी डेटा को एम्बेड करने की भी अनुमति देता है। ईएमएफ+ ईएमएफ फाइलों का एक विस्तार है और इन टिप्पणी रिकॉर्ड में एम्बेडेड है, जो विंडोज़ जीडीआई+ के समान कमांड, ऑब्जेक्ट और गुणों का उपयोग करके छवियों और टेक्स्ट की अनुमति देता है।

इतिहास
मूल 16-बिट WMF फ़ाइल स्वरूप 1992 के विंडोज़ 3.1 एसडीके प्रलेखन के खंड 4 में पूरी तरह से निर्दिष्ट किया गया था (कम से कम यदि अन्य खंडों में व्यक्तिगत कार्यों और संरचनाओं के विवरण के साथ जोड़ा जाए), लेकिन वह विनिर्देश कुछ विवरणों के बारे में अस्पष्ट था। इन मैनुअलों को किताबों की दुकानों में उपलब्ध मुद्रित पुस्तकों के रूप में प्रकाशित किया गया था, जिसमें कोई क्लिक-थ्रू ईयूएलए या अन्य असामान्य लाइसेंसिंग प्रतिबंध नहीं थे (केवल एक सामान्य चेतावनी है कि यदि सॉफ्टवेयर बंडल के हिस्से के रूप में खरीदा जाता है, तो सॉफ्टवेयर एक के अधीन होगा)।

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

माइक्रोसॉफ्ट ने बाद में 32-बिट ईएमएफ फाइलों के पक्ष में डब्लूएमएफ फाइलों को खारिज कर दिया क्योंकि डब्लूएमएफ फाइलों में डिवाइस स्वतंत्रता के साथ वास्तविक समस्याएं थीं, प्लेसेबल फ़ाइल हेडर के उपयोग के बावजूद जो मूलभूत डिवाइस स्वतंत्रता प्रदान करती थी। माइक्रोसॉफ्ट ने पाया कि जो डेवलपर्स प्रारूप का उपयोग करते हैं, वे मेटाफ़ाइल्स में एप्लिकेशन, स्थान, या स्केलिंग टिप्पणियां [एम्बेडिंग] कर रहे थे... अन्य ने मेटाफ़ाइल में हेडर जोड़े जो विभिन्न एप्लिकेशन-विशिष्ट जानकारी प्रदान करते थे, जिससे प्रमुख संगतता समस्याएं पैदा हुईं। एक प्रारूप जो Win32 API पर आधारित था और जिसके साथ उन्होंने डिवाइस की स्वतंत्रता अंतर्निहित की थी। इन्हें एनटी मेटाफ़ाइल्स के रूप में भी जाना जाता था। विंडोज़ एक्सपी और जीडीआई+ की रिलीज़ के साथ, रिकॉर्ड्स के सेट को काफी बढ़ाना पड़ा और इसलिए माइक्रोसॉफ्ट ने मौजूदा ईएमएफ फ़ाइल प्रारूप के विस्तार के रूप में ईएमएफ+ प्रभावशील किया था।

मेटाफ़ाइल संरचना
WMF, EMF और EMF+ फ़ाइलें सभी रिकॉर्ड की एक श्रृंखला से बनी होती हैं जिन्हें ग्राफिकल आउटपुट उत्पन्न करने के लिए चलाया जाता है। कुछ रिकॉर्ड वस्तुओं को परिभाषित करते हैं जो ग्राफिकल वस्तुओं को निर्दिष्ट कर सकते हैं जिनका उपयोग यह निर्धारित करने के लिए किया जाता है कि ग्राफिक्स कैसे बनाया जाना चाहिए (उदाहरण के लिए पेन लाइनों का रंग और चौड़ाई निर्दिष्ट करते हैं)। इनमें से प्रत्येक ऑब्जेक्ट को मेटाफ़ाइल्स में संग्रहीत किया जाता है और एक ऑब्जेक्ट तालिका में रखा जाता है, जो मेटाफ़ाइल को संसाधित करते समय ग्राफिक ऑब्जेक्ट्स के उपयोग को ट्रैक करता है। ऑब्जेक्ट तालिका मेटाफ़ाइल के भीतर परिभाषित ग्राफ़िकल ऑब्जेक्ट संरचनाओं के अनुक्रमितों की एक सहयोगी सरणी है।

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

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

बिटमैप रिकॉर्ड
बिटमैप रिकॉर्ड बिटमैप छवियों का प्रबंधन और आउटपुट करते हैं।

ड्राइंग रिकॉर्ड
ड्राइंग रिकॉर्ड ग्राफ़िक्स आउटपुट उत्पन्न करते हैं।

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

राज्य अभिलेख
राज्य रिकॉर्ड प्लेबैक डिवाइस संदर्भ के ग्राफ़िक्स गुणों का प्रबंधन करते हैं।

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

निम्नलिखित एस्केप रिकॉर्ड एक WMF फ़ाइल बनाते हैं।

एबॉर्ट एस्केप रिकॉर्ड के आसपास एस्केप रिकॉर्ड में एक विंडोज़ मेटाफ़ाइल भेद्यता पाई गई थी, जो एबॉर्ट प्रक्रिया कोड को रिकॉर्ड के भीतर ही संग्रहीत करता है। इससे विंडोज़ सिस्टम प्रभावित हुआ (देखें)। ) और वाइन (सॉफ़्टवेयर)  (देखें ). सिकुनिया के अनुसार, भेद्यता विशेष रूप से तैयार किए गए सेटबोर्टप्रोक 'एस्केप' रिकॉर्ड वाले विंडोज मेटाफ़ाइल फ़ाइलों ('.wmf') को संभालने में त्रुटि के कारण होती है। WMF फ़ाइल का रेंडरिंग विफल होने पर ऐसे रिकॉर्ड मनमाने उपयोगकर्ता-परिभाषित फ़ंक्शन को निष्पादित करने की अनुमति देते हैं। विंडोज़ 3.1 SDK प्रलेखन के अनुसार, WMF भेद्यता की खोज से बहुत पहले, सेटबोर्टप्रोक एस्केप अप्रचलित हो गया था और विंडोज़ 3.1 में उसी नाम के फ़ंक्शन द्वारा प्रतिस्थापित कर दिया गया था। हालाँकि, अप्रचलित एस्केप कोड को विंडोज 3.0 के लिए लिखे गए (या कम से कम बैकवर्ड संगत) 16 बिट प्रोग्राम के साथ संगतता के लिए बरकरार रखा गया था। यह परिवर्तन लगभग उसी समय हुआ जब माइक्रोसॉफ़्ट विंडोज़ NT के लिए GDI का 32 बिट पुनः कार्यान्वयन बना रहा था, और यह संभावना है कि इस प्रयास के दौरान भेद्यता उत्पन्न हुई।

स्टीव गिब्सन (कंप्यूटर प्रोग्रामर) द्वारा माइक्रोसॉफ्ट पर जानबूझकर उनके कोड में पिछले दरवाजे (कंप्यूटिंग) को लागू करने का आरोप लगाने के बाद, मार्क रुसिनोविच ने एक खंडन प्रदान किया, और कहा कि:

"...things were different when the format was architected. In the Windows 3.1 “large” memory model code is inherently location-independent and Windows was never patched, so both Windows and an application could simply copy an application function into the WMF file and assume it would work when played back by the same application in a later run session. In any case, its not clear that the developers envisioned applications creating on-disk metafiles with abort procedures. Also, as Microsoft’s Stephen Toulouse pointed out in Microsoft’s rebuttal to Steve’s claims, the security landscape in the early 1990s was very different than today and all code, including that stored in a WMF file, was inherently trusted.

...जब प्रारूप तैयार किया गया था तो चीजें अलग थीं। विंडोज़ 3.1 में "बड़ी" मेमोरी मॉडल कोड स्वाभाविक रूप से स्थान-स्वतंत्र है और विंडोज़ को कभी भी पैच नहीं किया गया था, इसलिए विंडोज़ और एक एप्लिकेशन दोनों बस एक एप्लिकेशन फ़ंक्शन को डब्लूएमएफ फ़ाइल में कॉपी कर सकते हैं और मान सकते हैं कि यह उसी एप्लिकेशन द्वारा चलाए जाने पर काम करेगा। बाद में चलने वाला सत्र। किसी भी मामले में, यह स्पष्ट नहीं है कि डेवलपर्स ने निरस्त प्रक्रियाओं के साथ ऑन-डिस्क मेटाफ़ाइल्स बनाने वाले अनुप्रयोगों की कल्पना की थी। इसके अलावा, जैसा कि माइक्रोसॉफ्ट के स्टीफन टूलूज़ ने [https://web.archive.org/web/20060116042756/http://blogs.technet.com/msrc/archive/2006/01/13/417431.aspx माइक्रोसॉफ्ट के खंडन में बताया है स्टीव के दावों के अनुसार, 1990 के दशक की प्रारम्भ में सुरक्षा परिदृश्य आज की तुलना में बहुत अलग था और WMF फ़ाइल में संग्रहीत सहित सभी कोड, स्वाभाविक रूप से भरोसेमंद थे"

सिमेंटेक सिक्योरिटी रिस्पांस, यूएसए के पीटर फेरी भी गिब्सन से असहमत थे, उन्होंने कहा:

"Gibson claimed that a thread is created to run the SetAbortProc handler. In fact, no thread is created to run the handler – it is a callback, which is called by the parser, and the parser has to wait until the callback returns, otherwise the whole point of the function (to abort the printing) is lost. By his own admission, Gibson did not read the documentation (in fact, he claimed that he couldn’t find it, although it is freely available on Microsoft’s Web site), and he claimed that the device context is not available to the function handler. Of course the device context is available to the function handler &mdash; it is one of the two parameters that is passed to it (see above), and it is required in order to abort the printing. Finally, Gibson claimed that the control flow could not return to Windows. It is simply a matter of the function returning and discarding the parameters that were passed on the stack. If the record is well formed, Windows will continue to parse the file, as before. ... Gibson admits that he was guessing about a number of things. Unfortunately, he guessed poorly. I guess we know better now.

गिब्सन ने दावा किया कि SetAbortProc हैंडलर को चलाने के लिए एक थ्रेड बनाया गया है। वास्तव में, हैंडलर को चलाने के लिए कोई थ्रेड नहीं बनाया गया है - यह एक कॉलबैक है, जिसे पार्सर द्वारा कॉल किया जाता है, और पार्सर को कॉलबैक वापस आने तक इंतजार करना पड़ता है, अन्यथा फ़ंक्शन का पूरा बिंदु (प्रिंटिंग को रद्द करने के लिए) खो जाता है. अपने स्वयं के प्रवेश से, गिब्सन ने दस्तावेज़ नहीं पढ़ा (वास्तव में, उन्होंने दावा किया कि वह इसे नहीं ढूंढ सके, हालांकि यह माइक्रोसॉफ्ट की वेब साइट पर मुफ्त में उपलब्ध है), और उन्होंने दावा किया कि डिवाइस संदर्भ फ़ंक्शन हैंडलर के लिए उपलब्ध नहीं है. बेशक डिवाइस संदर्भ फ़ंक्शन हैंडलर के लिए उपलब्ध है &mdash; यह उन दो मापदंडों में से एक है जो इसे पास किया गया है (ऊपर देखें), और प्रिंटिंग को रद्द करने के लिए यह आवश्यक है। अंत में, गिब्सन ने दावा किया कि नियंत्रण प्रवाह विंडोज़ पर वापस नहीं आ सका। यह केवल फ़ंक्शन के लौटने और स्टैक पर पारित किए गए पैरामीटर को त्यागने का मामला है। यदि रिकॉर्ड अच्छी तरह से बना है, तो विंडोज़ पहले की तरह फ़ाइल को पार्स करना जारी रखेगा। ... गिब्सन स्वीकार करते हैं कि वह कई चीजों के बारे में अनुमान लगा रहे थे। दुर्भाग्य से, उसने ख़राब अनुमान लगाया। मुझे लगता है कि हम अब बेहतर जानते हैं"

ईएमएफ
ईएमएफ फाइलों में हेडर के तीन संभावित संस्करण हैं। मूल हेडर केवल छवियों के लिए एक कंटेनर है, दूसरा और तीसरा संस्करण मूल हेडर को समाहित करता है और इसमें एक पिक्सेल प्रारूप रिकॉर्ड और ओपनजीएल रिकॉर्ड के लिए समर्थन सम्मिलित है, और तीसरा संस्करण दूसरे हेडर एक्सटेंशन को समाहित करता है और ईएमएफ की सटीकता और स्केलेबिलिटी को बढ़ाता है। मीट्रिक प्रणाली का उपयोग करके डिवाइस की सतहों की दूरी मापने की क्षमता जोड़ता है। प्रत्येक EMF हेडर एक EMR_HEADER रिकॉर्ड से प्रारंभ होता है, और उस डिवाइस के प्रासंगिक गुणों को रिकॉर्ड करता है जिस पर मेटाफ़ाइल छवि रिकॉर्ड की गई थी। मूल ईएमएफ हेडर में 80 बाइट हेडर और एक वैकल्पिक चर लंबाई विवरण स्ट्रिंग है। अन्य मेटाफ़ाइलों में एक्सटेंशन फ़ील्ड होते हैं, जो मूल हेडर को समाहित करते हैं।  एक रिकॉर्ड है जो सीधे मूल ईएमएफ हेडर के बाद डाला जाता है, यह निर्दिष्ट करता है कि हेडर के भीतर एक पिक्सेल प्रारूप डिस्क्रिप्टर और डिस्क्रिप्टर ऑब्जेक्ट का ऑफसेट है या नहीं, साथ ही एक फ़ील्ड जो निर्दिष्ट करता है कि मेटाफ़ाइल में ओपनजीएल रिकॉर्ड मौजूद हैं या नहीं। पिक्सेल प्रारूप डिस्क्रिप्टर ड्राइंग सतह की क्षमताओं को निर्दिष्ट करता है और क्या पिक्सेल आरजीबीए रंग मॉडल में एन्कोड किया गया है या रंग तालिका में एक सूचकांक है।   एक रिकॉर्ड है जो सीधे इसके बाद डाला जाता है   रिकॉर्ड करें, और इसमें डिवाइस की सतह को माइक्रोमीटर में मापने के लिए X और Y मान वाले दो फ़ील्ड सम्मिलित हैं। WMF फ़ाइलों की तरह, रिकॉर्ड को फ़ंक्शन द्वारा वर्गीकृत किया जा सकता है, हालाँकि WMF फ़ाइलों की तुलना में EMF फ़ाइलों में अधिक रिकॉर्ड प्रकार होते हैं। रिकॉर्ड्स को नियंत्रण, बिटमैप, क्लिपिंग, टिप्पणी, ड्राइंग, एस्केप, ऑब्जेक्ट निर्माण, ऑब्जेक्ट हेरफेर, ओपनजीएल, पथ ब्रैकेट, स्थिति और ट्रांसफ़ॉर्म रिकॉर्ड के रूप में वर्गीकृत किया जा सकता है।

ईएमएफ+
विंडोज़ XP की रिलीज़ के साथ, उन्नत मेटाफ़ाइल प्रारूप प्लस एक्सटेंशन (EMF+) प्रारूप प्रस्तुत किया गया था। EMF+ GDI+ API पर कॉल को उसी तरह क्रमबद्ध करने का एक तरीका प्रदान करता है जैसे WMF/EMF GDI पर कॉल को संग्रहीत करता है।

विंडोज़ मेटाफ़ाइल्स के संपीड़ित संस्करण भी हैं जिन्हें संपीड़ित विंडोज़ मेटाफ़ाइल (डब्लूएमजेड) और संपीड़ित विंडोज़ एन्हांस्ड मेटाफ़ाइल (ईएमजेड) के रूप में जाना जाता है। जो मूल रूप से gzip संपीड़ित WMF और EMF फ़ाइलें हैं।

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

यह भी देखें

 * परिशिष्ट भाग
 * वेक्टर मार्कअप भाषा (VML)
 * स्केलेबल वेक्टर ग्राफिक्स (एसवीजी)

बाहरी संबंध

 * विंडोज़ मेटाfile Format Specification from माइक्रोसॉफ़्ट
 * मेटाfiles – विंडोज़ applications
 * File Format Summary at fileformat.info
 * विंडोज़ मेटाfile FAQ