विंडोज एपीआई

विंडोज एपीआई, अनौपचारिक रूप से विनएपीआई, माइक्रोसॉफ़्ट विंडोज़ ऑपरेटिंग सिस्टम में उपलब्ध एपीआई (एपीआई) का माइक्रोसॉफ्ट का कोर सेट है। Windows API नाम सामूहिक रूप से कई अलग-अलग प्लेटफ़ॉर्म कार्यान्वयनों को संदर्भित करता है जिन्हें अक्सर उनके अपने नामों से संदर्भित किया जाता है (उदाहरण के लिए, Win32 API); #संस्करण अनुभाग देखें। लगभग सभी विंडोज प्रोग्राम विंडोज एपीआई के साथ इंटरैक्ट करते हैं। ऑपरेटिंग सिस्टम की विंडोज एनटी लाइन पर, एक छोटी संख्या (जैसे कि विंडोज एनटी स्टार्टअप प्रक्रिया के शुरू में शुरू होने वाले प्रोग्राम) देशी एपीआई का उपयोग करते हैं। डेवलपर समर्थन सॉफ़्टवेयर विकास किट, Microsoft Windows SDK के रूप में उपलब्ध है, जो Windows API और संबद्ध Windows इंटरफ़ेस पर आधारित सॉफ़्टवेयर बनाने के लिए आवश्यक दस्तावेज़ और टूल प्रदान करता है।

Windows API (Win32) मुख्य रूप से प्रोग्रामिंग भाषा C (प्रोग्रामिंग भाषा) पर केंद्रित है इसमें इसके खुला कार्यों और डेटा संरचनाओं को इसके प्रलेखन के हाल के संस्करणों में उस भाषा में वर्णित किया गया है। हालाँकि, एपीआई का उपयोग किसी भी प्रोग्रामिंग लैंग्वेज संकलक या असेंबलर (कंप्यूटिंग) द्वारा किया जा सकता है, जो कॉल और कॉलबैक (कंप्यूटर प्रोग्रामिंग) के लिए निर्धारित कॉलिंग कन्वेंशन के साथ-साथ (अच्छी तरह से परिभाषित) निम्न-स्तरीय डेटा संरचनाओं को संभालने में सक्षम है। इसी तरह, एपीआई के कार्य का आंतरिक कार्यान्वयन ऐतिहासिक रूप से कई भाषाओं में विकसित किया गया है। इस तथ्य के बावजूद कि C एक वस्तु-उन्मुख प्रोग्रामिंग भाषा नहीं है, Windows API और Windows दोनों को ऐतिहासिक रूप से वस्तु-उन्मुख के रूप में वर्णित किया गया है। ऑब्जेक्ट-ओरिएंटेड भाषाओं के लिए कई रैपर क्लासेस और एक्सटेंशन (माइक्रोसॉफ्ट और अन्य से) भी हैं जो इस वस्तु उन्मुख कार्यकर्म को अधिक स्पष्ट (माइक्रोसॉफ्ट फाउंडेशन क्लास लाइब्रेरी (एमएफसी), विजुअल कंपोनेंट लाइब्रेरी (वीसीएल), जीडीआई+ +, आदि) बनाते हैं।. उदाहरण के लिए, विंडोज 8 विंडोज एपीआई और विनआरटी एपीआई प्रदान करता है, जिसे सी ++ में लागू किया गया है और डिज़ाइन द्वारा ऑब्जेक्ट-ओरिएंटेड है।

सिंहावलोकन
विंडोज एपीआई द्वारा प्रदान किए गए कार्यों को आठ श्रेणियों में बांटा जा सकता है:
 * आधार सेवाएं: विंडोज सिस्टम के लिए उपलब्ध बुनियादी संसाधनों तक पहुंच प्रदान करें। फाइल सिस्टम, संगणक धातु सामग्री, प्रक्रिया (कंप्यूटिंग), थ्रेड (कंप्यूटर साइंस) और त्रुटि प्रबंधन जैसी चीजें शामिल हैं। ये कार्य 16-बिट विंडोज़ पर kernel.exe, krnl286.exe या krnl386.exe फ़ाइलों और kernel32.dll में रहते हैं और 32 और 64 बिट विंडोज़ पर KernelBase.dll । ये फ़ाइलें विंडोज़ के सभी संस्करणों पर फोल्डर \Windows\System32 में रहती हैं।
 * उन्नत सेवाएं
 * कर्नेल से परे कार्यों तक पहुंच प्रदान करें। विंडोज रजिस्ट्री, शटडाउन/सिस्टम को पुनरारंभ करना (या निरस्त करना), विंडोज़ सेवा शुरू/रोकना/बनाना, उपयोगकर्ता खातों का प्रबंधन जैसी चीजें शामिल हैं। ये कार्य 32-बिट विंडोज़ पर advapi32.dll और advapires32.dll में रहते हैं।


 * ग्राफिक्स डिवाइस इंटरफ़ेस: कंप्यूटर प्रदर्शन, संगणक मुद्रक, और अन्य आउटपुट डिवाइस के लिए ग्राफिक्स सामग्री को आउटपुट करने के लिए कार्य प्रदान करता है। यह 16-बिट विंडोज़ पर gdi.exe में रहता है, और उपयोगकर्ता-मोड में 32-बिट विंडोज़ पर gdi32.dll में रहता है। कर्नेल-मोड GDI समर्थन द्वारा प्रदान किया जाता है  जो सीधे ग्राफिक्स ड्राइवर के साथ संचार करता है।
 * विंडोज़ उपयोगकर्ता: स्क्रीन विंडो (कम्प्यूटिंग) और बटन (कंप्यूटिंग) और स्क्रॉल बार जैसे सबसे बुनियादी नियंत्रण, माउस और कीबोर्ड इनपुट प्राप्त करने और विंडोज के ग्राफिकल यूज़र इंटरफ़ेस (जीयूआई) से जुड़े अन्य कार्यों को बनाने और प्रबंधित करने के लिए कार्य प्रदान करता है। यह कार्यात्मक इकाई 16-बिट विंडोज़ पर user.exe और 32-बिट विंडोज़ पर user32.dll में रहती है। Windows XP संस्करणों के बाद से, सामान्य नियंत्रण (कॉमन कंट्रोल लाइब्रेरी) के साथ, मूल नियंत्रण comctl32.dll में रहते हैं।
 * कॉमन डायलॉग बॉक्स लाइब्रेरी: फ़ाइलों को खोलने और सहेजने, रंग और फ़ॉन्ट चुनने आदि के लिए एप्लिकेशन को मानक संवाद बॉक्स प्रदान करता है। लाइब्रेरी 16-बिट विंडोज़ पर commdlg.dll नामक फ़ाइल में रहती है, और comdlg32.dll< /samp> 32-बिट विंडोज पर। इसे एपीआई के यूजर इंटरफेस श्रेणी के तहत समूहीकृत किया गया है।
 * सामान्य नियंत्रण पुस्तकालय: एप्लिकेशन को ऑपरेटिंग सिस्टम द्वारा प्रदान किए गए कुछ उन्नत नियंत्रणों तक पहुंच प्रदान करता है। इनमें स्टेटस बार, प्रोगेस बार, उपकरण पट्टी और टैब (जीयूआई) जैसी चीजें शामिल हैं। लाइब्रेरी 16-बिट विंडोज़ पर commctrl.dll और 32-बिट विंडोज़ पर comctl32.dll नामक डायनेमिक-लिंक लाइब्रेरी (DLL) फ़ाइल में रहती है। इसे एपीआई के यूजर इंटरफेस श्रेणी के तहत समूहीकृत किया गया है।
 * विंडोज़ शैल: विंडोज एपीआई का घटक अनुप्रयोगों को ऑपरेटिंग सिस्टम खोल द्वारा प्रदान किए गए कार्यों तक पहुंचने और इसे बदलने और बढ़ाने की अनुमति देता है। घटक 16-बिट विंडोज़ पर shell.dll में, और 32-बिट विंडोज़ पर shell32.dll में रहता है। शेल लाइटवेट यूटिलिटी फंक्शन shlwapi.dll में हैं। इसे एपीआई के यूजर इंटरफेस श्रेणी के तहत समूहीकृत किया गया है।
 * नेटवर्क सेवाएं: ऑपरेटिंग सिस्टम की विभिन्न कंप्यूटर नेटवर्क क्षमताओं तक पहुँच प्रदान करें। इसके उप-घटकों में NetBIOS, Winsock, NetDDE, दुरस्तह प्रकिया कॉल (RPC) और कई अन्य शामिल हैं। यह घटक 32-बिट विंडोज़ पर netapi32.dll में रहता है।

वेब
इंटरनेट एक्स्प्लोरर (आईई) वेब ब्राउजर भी कई एपीआई को उजागर करता है जो अक्सर अनुप्रयोगों द्वारा उपयोग किया जाता है, और इस तरह इसे विंडोज एपीआई का एक हिस्सा माना जा सकता है। IE को विंडोज 95 OSR2 के बाद से ऑपरेटिंग सिस्टम के साथ शामिल किया गया है और विंडोज 98 के बाद से अनुप्रयोगों के लिए वेब-संबंधित सेवाएं प्रदान की हैं। विशेष रूप से, यह प्रदान करने के लिए प्रयोग किया जाता है:
 * एम्बेड करने योग्य वेब ब्राउज़र नियंत्रण, shdocvw.dll और Trident (लेआउट इंजन)|mshtml.dll में निहित है।
 * URL मॉनीकर सेवा, urlmon.dll में आयोजित की जाती है, जो URL को हल करने के लिए एप्लिकेशन को घटक वस्तु मॉडल ऑब्जेक्ट प्रदान करती है। एप्लिकेशन दूसरों के उपयोग के लिए अपने स्वयं के URL हैंडलर भी प्रदान कर सकते हैं।
 * एक HTTP क्लाइंट लाइब्रेरी जो सिस्टम-वाइड प्रॉक्सी सेटिंग्स (wininet.dll) को भी ध्यान में रखती है; हालाँकि, Microsoft ने winhttp.dll नामक एक अन्य HTTP क्लाइंट लाइब्रेरी जोड़ी है जो कुछ अनुप्रयोगों के लिए छोटी और अधिक उपयुक्त है।
 * बहु-भाषा और अंतर्राष्ट्रीय पाठ समर्थन (mlang.dll) की सहायता के लिए एक पुस्तकालय।
 * डायरेक्टएक्स ट्रांसफॉर्म, छवि फ़िल्टर घटकों का एक सेट।
 * XML समर्थन (MSXML घटक, msxml*.dll में रखे जाते हैं)।
 * विंडोज एड्रेस बुक्स तक पहुंच।

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

इसके अलावा, विंडोज 95 OSR2 के बाद से प्रत्येक विंडोज संस्करण के हिस्से के रूप में, माइक्रोसॉफ्ट ने डायरेक्टएक्स एपीआई प्रदान किया है - ग्राफिक्स और गेमिंग सेवाओं का एक शिथिल संबंधित सेट, जिसमें शामिल हैं:
 * हार्डवेयर-त्वरित 2D वेक्टर ग्राफिक्स के लिए Direct2D।
 * हार्डवेयर-त्वरित 3डी ग्राफिक्स के लिए Direct3D।
 * निम्न-स्तरीय हार्डवेयर-त्वरित साउंड कार्ड एक्सेस के लिए सीधी आवाज।
 * जॉयस्टिक और गेमपैड जैसे इनपुट उपकरणों के साथ संचार के लिए DirectInput।
 * मल्टीप्लेयर गेमिंग इंफ्रास्ट्रक्चर के रूप में डायरेक्टप्ले। इस घटक को DirectX 9 के रूप में बहिष्कृत कर दिया गया है, और Microsoft अब गेम के विकास के लिए इसके उपयोग की अनुशंसा नहीं करता है।
 * पिछले DirectX संस्करणों में 2D ग्राफ़िक्स के लिए DirectDraw, अब हटा दिया गया है और Direct2D के साथ बदल दिया गया है।
 * विंडोज 3.x संस्करणों के लिए लिखे गए 16-बिट गेम में 2डी ग्राफिक्स के लिए विनजी। विंडोज 95 रिलीज के साथ पदावनत।

Microsoft मीडिया एन्कोडिंग और प्लेबैक के लिए कई API भी प्रदान करता है:
 * DirectShow, जो सामान्य मल्टीमीडिया पाइपलाइन बनाता और चलाता है। यह जीस्ट्रीमर ढांचे के बराबर है और अक्सर इन-गेम वीडियो प्रस्तुत करने और मीडिया प्लेयर बनाने के लिए उपयोग किया जाता है (विंडोज़ मीडिया प्लेयर इस पर आधारित है)। गेम डेवलपमेंट के लिए अब DirectShow की अनुशंसा नहीं की जाती है।
 * मीडिया फाउंडेशन, एक नया डिजिटल मीडिया एपीआई, जिसका उद्देश्य डायरेक्टशो को बदलना है।

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

शब्दों की विविधता मूल रूप से सॉफ्टवेयर तंत्र के समूहीकरण का परिणाम है जो सॉफ्टवेयर विकास के एक दिए गए पहलू से संबंधित है। स्वचालन विशेष रूप से एक एप्लिकेशन या घटक (अप्लिकेशन प्रोग्रामिंग अंतरफलक (एपीआई) के रूप में) के कार्य को निर्यात करने से संबंधित है ताकि इसे केवल मानव उपयोगकर्ताओं के बजाय अन्य अनुप्रयोगों द्वारा नियंत्रित किया जा सके, .NET एक स्व-निहित सामान्य पद्धति और तकनीक है विभिन्न प्रकार के समय-समय पर संकलन|जस्ट-इन-टाइम (JIT) संकलित भाषाओं में लिखे गए डेस्कटॉप और वेब एप्लिकेशन विकसित करें।

Windows.pas एक पास्कल (प्रोग्रामिंग भाषा)/डेल्फ़ी (प्रोग्रामिंग भाषा) इकाई है जिसमें Microsoft Windows-विशिष्ट API घोषणाएँ शामिल हैं। यह पास्कल windows.h के समतुल्य है, जिसका उपयोग C में किया जाता है।

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

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

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

उदाहरण के लिए, एक शुरुआत सी प्रोग्रामर अक्सर सरल हैलो वर्ल्ड को अपने पहले असाइनमेंट के रूप में लिखेंगे। कार्यक्रम का कामकाजी हिस्सा मुख्य सबरूटीन के भीतर केवल एक प्रिंटफ लाइन है। मानक I/O लाइब्रेरी से लिंक करने के लिए ओवरहेड भी केवल एक पंक्ति है:

विंडोज संस्करण अभी भी कोड की केवल एक कामकाजी लाइन थी लेकिन इसके लिए ओवरहेड की कई और अधिक लाइनों की आवश्यकता थी। विंडोज एपीआई के लिए प्रोग्रामिंग के बारे में कई किताबें लिखने वाले चार्ल्स पेटज़ोल्ड ने कहा: विंडोज 1.0 एसडीके में मूल हैलो वर्ल्ड प्रोग्राम थोड़ा सा घोटाला था। HELLO.C लगभग 150 लाइन लंबी थी, और HELLO.RC संसाधन स्क्रिप्ट में 20 या उससे अधिक लाइनें थीं। (...) वयोवृद्ध प्रोग्रामर अक्सर विंडोज हैलो-वर्ल्ड प्रोग्राम का सामना करते समय डरावनी या हँसी में डूब जाते हैं। इन वर्षों में, विंडोज सिस्टम में कई बदलाव और परिवर्धन किए गए, और इसे दर्शाने के लिए विंडोज एपीआई बदल गया और बढ़ा। विंडोज 1.0 के लिए विंडोज एपीआई 450 से कम सबरूटीन का समर्थन करता है, जबकि विंडोज एपीआई के आधुनिक संस्करण हजारों का समर्थन करते हैं। हालाँकि, सामान्य तौर पर, इंटरफ़ेस काफी सुसंगत रहा, और एक पुराना विंडोज 1.0 एप्लिकेशन अभी भी एक प्रोग्रामर से परिचित होगा जो आधुनिक विंडोज एपीआई के लिए उपयोग किया जाता है। Microsoft ने पश्च संगतता बनाए रखने का प्रयास किया है। इसे प्राप्त करने के लिए, विंडोज़ के नए संस्करण विकसित करते समय, माइक्रोसॉफ्ट ने कभी-कभी वर्कअराउंड लागू किया तृतीय-पक्ष सॉफ़्टवेयर के साथ संगतता की अनुमति देने के लिए जिसने पूर्व संस्करण का उपयोग बिना दस्तावेज या यहां तक ​​कि अनुचित तरीके से किया था। रेमंड चेन (माइक्रोसॉफ्ट), एक माइक्रोसॉफ्ट डेवलपर जो विंडोज एपीआई पर काम करता है, ने कहा है: मैं शायद महीनों तक पूरी तरह से खराब चीजों के बारे में लिख सकता हूं जो ऐप्स करते हैं और उन्हें फिर से काम करने के लिए हमें क्या करना था (अक्सर खुद के बावजूद). यही कारण है कि जब लोग माइक्रोसॉफ्ट पर ओएस अपग्रेड के दौरान दुर्भावनापूर्ण रूप से तोड़ने वाले अनुप्रयोगों का आरोप लगाते हैं तो मैं विशेष रूप से उग्र हो जाता हूं। यदि विंडोज 95 पर कोई भी एप्लिकेशन चलने में विफल रहता है, तो मैंने इसे व्यक्तिगत विफलता के रूप में लिया। Windows API में सबसे बड़े परिवर्तनों में से एक Win16 (Windows 3.1 और पुराने में भेज दिया गया) से Win32 (Windows NT और Windows 95 और ऊपर) में संक्रमण था। जबकि Win32 को मूल रूप से Windows NT 3.1 के साथ पेश किया गया था और Win32s ने Windows 95 से पहले Win32 सबसेट के उपयोग की अनुमति दी थी, यह Windows 95 तक नहीं था कि Win32 के लिए अनुप्रयोगों की व्यापक पोर्टिंग शुरू हुई। संक्रमण को आसान बनाने के लिए, खिड़कियाँ 95 में, माइक्रोसॉफ्ट के बाहर और अंदर के डेवलपर्स के लिए, एपीआई थंक (संगतता मानचित्रण) की एक जटिल योजना का उपयोग किया गया था जो 32-बिट कोड को 16-बिट कोड में कॉल करने की अनुमति दे सकता है (अधिकांश Win16 एपीआई के लिए) और विपरीतता से। फ्लैट थंक्स ने 32-बिट कोड को 16-बिट पुस्तकालयों में कॉल करने की अनुमति दी, और पूरे ओएस को एक बैच में Win32 में पोर्ट करने से बचने के लिए योजना का उपयोग विंडोज 95 के पुस्तकालयों के अंदर बड़े पैमाने पर किया गया था। विंडोज एनटी में, ओएस शुद्ध 32-बिट था, 16-बिट अनुप्रयोगों के साथ संगतता के लिए भागों को छोड़कर, और विंडोज 95 के लिए Win16 से Win32 तक थंक करने के लिए केवल जेनेरिक थंक्स उपलब्ध थे। प्लेटफ़ॉर्म एसडीके एक कंपाइलर के साथ भेज दिया गया जो उत्पादन कर सकता था इन थैंक्स के लिए आवश्यक कोड। 64-बिट विंडोज़ के संस्करण भी वाह64 के माध्यम से 32-बिट अनुप्रयोगों को चलाने में सक्षम हैं। OS ड्राइव पर Windows फ़ोल्डर में स्थित SysWOW64 फ़ोल्डर में 32-बिट अनुप्रयोगों का समर्थन करने के लिए कई उपकरण हैं।

संस्करण
Microsoft Windows के लगभग हर नए संस्करण ने Windows API में अपने स्वयं के परिवर्धन और परिवर्तन पेश किए हैं। हालांकि, एपीआई का नाम विंडोज के विभिन्न संस्करणों के बीच एक जैसा बना रहा और नाम परिवर्तन को विंडोज के लिए प्रमुख वास्तुशिल्प और प्लेटफॉर्म परिवर्तनों तक सीमित रखा गया। Microsoft ने अंततः तत्कालीन वर्तमान Win32 API परिवार का नाम Windows API में बदल दिया और इसे पिछले और भविष्य के दोनों API संस्करणों के लिए कैच-ऑल टर्म में बदल दिया।


 * Win16 पहले, 16-बिट कंप्यूटिंग के लिए API है|Microsoft Windows के 16-बिट संस्करण। इन्हें शुरू में केवल 'विंडोज एपीआई' के रूप में संदर्भित किया गया था, लेकिन बाद में उन्हें विंडोज एपीआई के नए, 32-बिट संस्करण से अलग करने के प्रयास में विन 16 का नाम बदल दिया गया। Win16 API के कार्य मुख्य रूप से OS की कोर फाइलों में रहते हैं: kernel.exe (या krnl286.exe या krnl386.exe), user.exe और ' 'gdi.exe''। exe के दस्तावेज़ विस्तारण के बावजूद, ये वास्तव में डायनामिक-लिंक लाइब्रेरी|डायनामिक-लिंक लाइब्रेरी हैं।
 * Win32 32-बिट कंप्यूटिंग है | 32-बिट एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस (API) विंडोज के 32-बिट संस्करणों (NT, 95 और बाद के संस्करणों) के लिए है। एपीआई में सिस्टम डीएलएल में विन 16 के साथ लागू किए गए कार्य शामिल हैं। Win32 के मुख्य DLL हैं- kernel32.dll, Windows USER|user32.dll, और gdi32.dll। Win32 को Windows NT के साथ पेश किया गया था। विंडोज 95 के साथ शिप किए गए Win32 के संस्करण को शुरू में Win32c के रूप में संदर्भित किया गया था, जिसमें  c  का अर्थ  अनुकूलता  था। यह शब्द बाद में Microsoft द्वारा Win32 के पक्ष में छोड़ दिया गया था।
 * Win32s विंडोज 3.1x#विंडोज 3.1 | माइक्रोसॉफ्ट विंडोज के विंडोज 3.1x परिवार के लिए एक एक्सटेंशन है जिसने इन सिस्टमों के लिए Win32 एपीआई का एक सबसेट लागू किया है। एस सबसेट के लिए खड़ा है।
 * Win64 64-बिट कंप्यूटिंग पर कार्यान्वित API का संस्करण है|64-बिट Windows NT#Windows NT ऑपरेटिंग सिस्टम लाइन के आर्किटेक्चर के समर्थित प्लेटफ़ॉर्म (, x86-64 और AArch64)। किसी एप्लिकेशन के 32-बिट और 64-बिट दोनों संस्करणों को अभी भी एक codebase से संकलित किया जा सकता है, हालांकि कुछ पुराने एपीआई को पदावनत कर दिया गया है, और कुछ एपीआई जो पहले से ही Win32 में बहिष्कृत थे, हटा दिए गए थे। सभी मेमोरी पॉइंटर (कंप्यूटर प्रोग्रामिंग) डिफ़ॉल्ट रूप से 64-बिट (एलएलपी64 64 मॉडल) हैं, इसलिए 64-बिट पॉइंटर अंकगणित के साथ संगतता के लिए स्रोत कोड की जांच की जानी चाहिए और आवश्यकतानुसार फिर से लिखा जाना चाहिए।
 * WinCE, Windows CE ऑपरेटिंग सिस्टम के लिए Windows API का कार्यान्वयन है।

अन्य कार्यान्वयन
शराब (सॉफ्टवेयर) प्रोजेक्ट यूनिक्स जैसे प्लेटफॉर्म के लिए लिनक्स कर्नेल एपीआई और विंडोज एपीआई के लिए लिखे गए प्रोग्राम के बीच एक Win32 एपीआई संगतता परत प्रदान करता है। रिएक्टोस एक कदम और आगे जाता है और कोड पुन: उपयोग और अनुकूलता को बढ़ावा देने के लिए वाइन प्रोजेक्ट के साथ मिलकर काम करते हुए पूर्ण विंडोज ऑपरेटिंग सिस्टम को लागू करने का लक्ष्य रखता है। DosWin32 और HX DOS एक्सटेंडर अन्य प्रोजेक्ट हैं जो DOS कमांड लाइन से सरल विंडोज प्रोग्राम को निष्पादित करने की अनुमति देने के लिए Windows API का अनुकरण करते हैं। ओडिन (कोड रूपांतरण सॉफ्टवेयर) ओएस/2 पर विन32 का अनुकरण करने के लिए एक परियोजना है, जो माइक्रोसॉफ्ट कोड पर आधारित मूल विन-ओएस/2 अनुकरण का स्थान लेती है। अन्य छोटे कार्यान्वयन में MEWEL और जिंक एप्लीकेशन फ्रेमवर्क लाइब्रेरी शामिल हैं, जिनका उद्देश्य DOS पर Win16 API के एक सबसेट को लागू करना था (प्लेटफ़ॉर्म-स्वतंत्र जीयूआई पुस्तकालयों की सूची देखें)।

विंडोज इंटरफ़ेस स्रोत पर्यावरण (WISE) माइक्रोसॉफ्ट का एक लाइसेंसिंग प्रोग्राम था, जिसने डेवलपर्स को यूनिक्स और मैकिनटोश प्लेटफॉर्म पर विंडोज-आधारित एप्लिकेशन को फिर से कंपाइल और चलाने की अनुमति दी थी। WISE SDKs Windows API के एक एमुलेटर पर आधारित थे जो उन प्लेटफॉर्म पर चल सकते थे। मानकीकरण के प्रयासों में Win16 के लिए सन का सार्वजनिक विंडोज इंटरफ़ेस (PWI) शामिल है (यह भी देखें: सन विंडोज एप्लीकेशन बाइनरी इंटरफेस (Wabi (सॉफ्टवेयर))), Win16 और Win32 के लिए विलो सॉफ्टवेयर का विंडोज के लिए एप्लीकेशन प्रोग्रामिंग इंटरफेसAPIW) के लिए (यह भी देखें: Willows TWIN) ), और ECMA-234, जिसने Windows API को बाध्यकारी रूप से मानकीकृत करने का प्रयास किया।

संकलक समर्थन
Windows API का उपयोग करने वाले सॉफ़्टवेयर को विकसित करने के लिए, एक कंपाइलर ऊपर सूचीबद्ध Microsoft-विशिष्ट DLL का उपयोग करने में सक्षम होना चाहिए (COM-ऑब्जेक्ट्स Win32 के बाहर हैं और एक निश्चित व्यवहार्य लेआउट मानते हैं)। कंपाइलर को या तो हेडर फाइलों को संभालना चाहिए जो आंतरिक एपीआई फ़ंक्शन नामों को उजागर करता है, या ऐसी फाइलों की आपूर्ति करता है।

C++ भाषा के लिए, ज़ोर्टेक (बाद में नॉर्टनलाइफ लॉक, फिर डिजिटल मंगल), वाटकॉम और बोरलैंड ने सभी प्रसिद्ध व्यावसायिक संकलक तैयार किए हैं जिनका उपयोग अक्सर Win16, Win32s और Win32 के साथ किया जाता है। उनमें से कुछ ने मेमोरी एक्सटेंडर की आपूर्ति की, जिससे Win32 प्रोग्राम को Microsoft के पुनर्वितरण योग्य Win32s DLL के साथ Win16 पर चलने की अनुमति मिली। Microsoft के पास C++ कंपाइलर होने से पहले, Zortech कंपाइलर शायद Windows प्रोग्रामिंग के लिए पहले स्थिर और प्रयोग करने योग्य C++ कंपाइलरों में से एक था।

एप्लिकेशन के कुछ वर्गों के लिए, कंपाइलर सिस्टम को इंटरफ़ेस विवरण भाषा (IDL) फ़ाइलों को संभालने में भी सक्षम होना चाहिए। सामूहिक रूप से, इन पूर्वापेक्षाओं (कंपाइलर, टूल, लाइब्रेरी और हेडर) को Microsoft प्लेटफ़ॉर्म SDK के रूप में जाना जाता है। एक समय के लिए, Microsoft विजुअल स्टूडियो और बोरलैंड की एकीकृत विकास प्रणाली एकमात्र एकीकृत विकास वातावरण (IDEs) थी जो इसे प्रदान कर सकती थी (हालाँकि, SDK पूरे IDE सुइट से अलग से मुफ्त में डाउनलोड करने योग्य है, microsoft.com/download/en/details.aspx?displaylang=en&id=8279 विंडोज 7 और .NET फ्रेमवर्क 4 के लिए माइक्रोसॉफ्ट विंडोज एसडीके)।

, MinGW और Cygwin प्रोजेक्ट भी जीएनयू संकलक संग्रह (GCC) पर आधारित एक ऐसा वातावरण प्रदान करते हैं, जो Win32-विशिष्ट DLL के विरुद्ध लिंकिंग को सरल बनाने के लिए स्टैंड-अलोन हेडर फ़ाइल सेट का उपयोग करता है। LCC-Win32 जैकब नविया द्वारा अनुरक्षित एक C संकलक है, जो गैर-व्यावसायिक उपयोग के लिए फ्रीवेयर है। Pelles C, Pelle Orinius द्वारा अनुरक्षित एक फ्रीवेयर C संकलक है। फ़्री पास्कल एक मुफ्त सॉफ्टवेयर वस्तु पास्कल कंपाइलर है जो विंडोज एपीआई को सपोर्ट करता है। MASM32 पैकेज एक परिपक्व परियोजना है जो प्लेटफ़ॉर्म SDK से कस्टम मेड या परिवर्तित हेडर और लाइब्रेरी का उपयोग करके Microsoft मैक्रो असेंबलर (MASM) के तहत Windows API के लिए समर्थन प्रदान करता है। फ्लैट असेंबलर FASM लिनक्स पर चलने पर भी बाहरी लिंकर का उपयोग किए बिना विंडोज प्रोग्राम बनाने की अनुमति देता है।

माइक्रोसॉफ्ट-विशिष्ट अपवाद हैंडलिंग तंत्र # संरचित अपवाद हैंडलिंग (एसईएच) के लिए विंडोज़ विशिष्ट कंपाइलर समर्थन की भी आवश्यकता है। यह सिस्टम दो उद्देश्यों को पूरा करता है: यह एक सब्सट्रेट प्रदान करता है जिस पर भाषा-विशिष्ट अपवाद हैंडलिंग को लागू किया जा सकता है, और यह है कि कैसे कर्नेल असाधारण स्थितियों के अनुप्रयोगों को सूचित करता है जैसे कि एक अमान्य सूचक या ढेर अतिप्रवाह को संदर्भित करना। Microsoft/Borland C++ कंपाइलर्स में विंडोज 95 और NT में पेश होते ही इस सिस्टम का उपयोग करने की क्षमता थी, हालांकि वास्तविक कार्यान्वयन अनियंत्रित था और वाइन प्रोजेक्ट और फ्री कंपाइलर्स के लिए रिवर्स इंजीनियर होना था। एसईएच अपवाद हैंडलर फ्रेम को स्टैक पर धकेलने पर आधारित है, फिर उन्हें थ्रेड-लोकल स्टोरेज (थ्रेड एनवायरनमेंट ब्लॉक का पहला फील्ड) में स्टोर की गई लिंक्ड लिस्ट में जोड़ा जाता है। जब एक अपवाद फेंका जाता है, तो कर्नेल और बेस लाइब्रेरी स्टैक चल रहे हैंडलर और फ़िल्टर को खोलते हैं, जैसा कि उनका सामना होता है। आखिरकार, एप्लिकेशन द्वारा बिना हैंडल किए गए हर अपवाद को डिफ़ॉल्ट बैकस्टॉप हैंडलर द्वारा निपटाया जाएगा, जो विंडोज कॉमन क्रैश डायलॉग को पॉप अप करता है।

यह भी देखें

 * ओएस/2 के लिए विंडोज लाइब्रेरी
 * इंटरिक्स
 * लिनक्स कर्नेल एपीआई
 * Microsoft Windows लाइब्रेरी फ़ाइलें
 * विंडोज विरासत ऑडियो घटक
 * C++/WinRT, एक लाइब्रेरी जो विंडोज रनटाइम तक पहुंच प्रदान करती है

बाहरी संबंध

 * MSDN Windows API index
 * Windows API Microsoft Code Samples
 * ECMA-234 – ECMA standard for a subset of the Windows API
 * Advanced Win32 API newsgroup
 * French Win32 API newsgroup