क्या यह अभी भी कम स्तर की WinAPI प्रोग्रामिंग सीखने के लिए समझ में आता है?

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

हालांकि, अगर आपको ऐसी स्थिति मिलती है जहां आपको लगता है कि आप ऐसा नहीं कर सकते जो आपको उच्च स्तर की भाषा (कुछ और दूर के बीच) में करने की ज़रूरत है, तो शायद उस दुनिया में खतरनाक गोताखोरी शुरू करें।

यह जानना महत्वपूर्ण है कि विंडोज एपीआई के साथ क्या उपलब्ध है। मुझे नहीं लगता कि आपको इसके साथ कोड को क्रैंक करने की ज़रूरत है, लेकिन आपको पता होना चाहिए कि यह कैसे काम करता है। .NET Framework में बहुत सारी कार्यक्षमता है, लेकिन यह पूरे विंडोज एपीआई के लिए प्रबंधित कोड समकक्ष प्रदान नहीं करता है। कभी-कभी आपको धातु के करीब थोड़ा सा होना पड़ता है, और यह जानकर कि वहां क्या है और यह कैसे व्यवहार करता है, आपको इसका उपयोग करने के बारे में बेहतर समझ देगा।

सरल जवाब, हाँ।

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

Learning a new programming language or technology is for one of three reasons:
1. Need: you're starting a project for building a web application and you don't know anything about ASP.NET
2. Enthusiasm: you're very excited about ASP.NET MVC. why not try that?
3. Free time: but who has that anyway.

कुछ नया सीखने का सबसे अच्छा कारण है। अगर आपको कुछ ऐसा करने की ज़रूरत है जो .NET ढांचा नहीं कर सकता (उदाहरण के लिए प्रदर्शन की तरह) तो WinAPI आपका समाधान है। तब तक हम खुद को .NET के बारे में सीखने में व्यस्त रहते हैं

डेस्कटॉप पर अधिकांश ज़रूरतों के लिए आपको Win32 को जानने की आवश्यकता नहीं है, हालांकि .NET में Win32 का बहुत कम नहीं है, लेकिन यह आउटलेटिंग सामग्री में है जो आपके आवेदन के 1% से कम होने का अंत हो सकता है।

यूएसबी सपोर्ट, एचआईडी सपोर्ट, विंडोज मीडिया फाउंडेशन सिर्फ मेरे सिर के ऊपर से। Win32 से केवल कई शानदार Vista API उपलब्ध हैं।

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

मैं इसे इस तरह से रखूंगा। मुझे Win32 API में प्रोग्रामिंग पसंद नहीं है। यह प्रबंधित कोड की तुलना में दर्द हो सकता है। लेकिन, मुझे खुशी है कि मुझे यह पता है क्योंकि मैं प्रोग्राम लिख सकता हूं अन्यथा मैं नहीं कर पाऊंगा। मैं उन कार्यक्रमों को लिख सकता हूं जो अन्य लोग नहीं कर सकते हैं। इसके अलावा यह आपको दृश्यों के पीछे अपना प्रबंधित कोड क्या कर रहा है, इस बारे में अधिक जानकारी देता है।

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

लापरवाही आत्म-पदोन्नति के जोखिम पर ....

मैं बस एक ऐसी स्थिति में आया जहां Win32 एपीआई मेरा एकमात्र विकल्प था। मैं एक सूची बॉक्स में प्रत्येक आइटम पर विभिन्न टूलटिप्स रखना चाहता हूं। मैंने लिखा है कि मैंने इसे कैसे किया यह प्रश्न ।

एनालॉजी: यदि आप एक जीवित (प्रोग्रामिंग) के लिए कारें बनाते हैं, तो यह जानना बेहद प्रासंगिक है कि इंजन कैसे काम करता है (Win32)।

यह वास्तव में प्रश्न के समान ही है, क्या मुझे सी (या यहां तक ​​कि असेंबलर) जैसी निम्न स्तर की भाषा सीखनी चाहिए।

इसमें कोडिंग निश्चित रूप से धीमी है (हालांकि निश्चित रूप से परिणाम बहुत तेज है), लेकिन इसका सच्चा लाभ यह है कि आप किसी और के रूपक को समझने के बजाय सिस्टम स्तर के करीब क्या हो रहा है, इसकी अंतर्दृष्टि प्राप्त कर सकते हैं ।

यह तब भी बेहतर हो सकता है जब चीजें अच्छी तरह से काम नहीं करतीं, या पर्याप्त तेज़ी से या ग्रैन्युलरिटी की तरह आपको आवश्यकता होती है। (और कम से कम कुछ subclassing और superclassing करते हैं।)

यह सवाल धार्मिक पर सीमा है :) लेकिन मैं वैसे भी अपने विचार दूंगा।

मैं Win32 एपीआई learing में मूल्य देखते हैं। अधिकांश, यदि नहीं, तो GUI लाइब्रेरीज़ (प्रबंधित या अप्रबंधित) परिणाम Win32 API को कॉल करता है। यहां तक ​​कि सबसे गहन पुस्तकालयों में भी 100% एपीआई शामिल नहीं है, और इसलिए हमेशा अंतराल होते हैं जिन्हें प्रत्यक्ष एपीआई कॉल या पी / इनकोकिंग द्वारा प्लग करने की आवश्यकता होती है। एपीआई कॉल के चारों ओर रैपर के कुछ नाम अंतर्निहित एपीआई कॉल के समान नाम हैं, लेकिन वे नाम बिल्कुल स्वयं-दस्तावेज़ नहीं हैं। तो अंतर्निहित एपीआई को समझना, और उसमें इस्तेमाल की जाने वाली शब्दावली, रैपर एपीआई को समझने में सहायता करेगी और वे वास्तव में क्या करेंगे।

इसके अलावा, यदि आप अंतर्निहित एपीआई की प्रकृति को समझते हैं जो फ्रेमवर्क द्वारा उपयोग किए जाते हैं, तो आप किसी दिए गए परिदृश्य में किस लाइब्रेरी कार्यक्षमता का उपयोग करना चाहिए इसके संबंध में बेहतर विकल्प बनाएंगे।

चीयर्स!

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

मैं Win32 एपीआई सीखने से पहले वर्षों के लिए मानक सी / सी ++ पर रखा, और काफी धब्बेदार होने के लिए, "सीखना Win32 एपीआई" भाग मेरे जीवन का सबसे अच्छा तकनीकी अनुभव नहीं है।

एक तरफ Win32 एपीआई काफी अच्छा है। यह सी मानक एपीआई (जिसे fopen की आवश्यकता होती है, के विस्तार की तरह है, जब आपके पास CreateFile हो सकता है। लेकिन मुझे लगता है कि यूनिक्स / लिनक्स / जो भी होसोज़ में एक ही gizmo फ़ंक्शन हैं। वैसे भी, यूनिक्स / लिनक्स, उनके पास "सबकुछ एक फ़ाइल है"। विंडोज़ में, उनके पास "सबकुछ एक है ... विंडो" (कोई मजाक नहीं है! CreateWindow !) देखें।

दूसरी ओर, यह एक विरासत एपीआई है। आप कच्चे सी, और कच्चे सी पागलपन से निपटेंगे।

• किसी की संरचना को अपने स्वयं के आकार को कुछ कोड 32 फ़ंक्शन पर शून्य * पॉइंटर से गुज़रने के बारे में बताएं।
• संदेश बहुत भ्रमित हो सकता है, भी: Win32 विंडोज़ के साथ सी ++ ऑब्जेक्ट्स को मिलाकर चिकन के बहुत ही रोचक उदाहरण होते हैं या अंडे समस्या (मजाकिया क्षण जब आप एक प्रकार का इसे हटाएं; कक्षा विधि में) लिखते हैं।
• जब आप ऑब्जेक्ट विरासत से अधिक परिचित होते हैं तो WinProc को उपclass करना हेड-स्प्लिटिंग और इष्टतम से कम है।
• और निश्चित रूप से, " इस भयानक दुनिया में क्यों उन्होंने इस तरह से काम किया है ?? " क्षण जब आप अपने सिर के साथ अपने कीबोर्ड के साथ कई बार एक बार फिर से घर वापस आते हैं चाबियाँ आपके माथे में उत्कीर्ण होती हैं, सिर्फ इसलिए कि किसी ने "विंडो" के रंग को बदलने में सक्षम होने के लिए एपीआई लिखने के लिए और अधिक तार्किक माना है, न कि इसकी एक संपत्ति को बदलकर, बल्कि इसे अपनी मूल विंडो से पूछकर।
• आदि।

आखिरी हाथ में ( तीन हाथ ??? ), मान लीजिए कि विरासत एपीआई के साथ काम करने वाले कुछ लोग स्वयं विरासत कोड स्टाइल का उपयोग कर रहे हैं। जिस क्षण आप सुनते हैं " const डमी के लिए है " या " मैं नामस्थान का उपयोग नहीं करता क्योंकि वे रनटाइम गति को कम करते हैं ", या यहां तक ​​कि बेहतर " अरे, जिसने सी ++ की आवश्यकता है? मैं ऑब्जेक्ट उन्मुख सी के अपने ब्रांड में कोड !!! " (कोई मजाक नहीं ... एक पेशेवर वातावरण में, और परिणाम काफी दृष्टि थी .. ।), आप इस तरह के डर को महसूस करेंगे कि केवल guillotine ।

तो ... सब कुछ, यह एक दिलचस्प अनुभव है।

संपादित करें

इस पोस्ट को फिर से पढ़ने के बाद, मुझे लगता है कि इसे अत्यधिक नकारात्मक के रूप में देखा जा सकता है। यह नहीं।

यह कभी-कभी दिलचस्प है (साथ ही निराशाजनक) यह जानने के लिए कि चीजें हुड के नीचे कैसे काम करती हैं। आप समझेंगे कि, भारी (असंभव?) बाधाओं के बावजूद, Win32 API टीम ने आपके "अंतिम Win64 ओवर-द-टॉप एप्लिकेशन" में "पुराना Win16 प्रोग्राम" से सब कुछ सुनिश्चित करने के लिए अद्भुत काम किया है, एक साथ काम कर सकता है, अतीत में, अब, और भविष्य में।

सवाल यह है: क्या आप वास्तव में करना चाहते हैं?

क्योंकि कुछ और उच्च स्तर और / या ऑब्जेक्ट उन्मुख एपीआई में किए जा सकने वाले काम करने के लिए हफ्तों का खर्च करना काफी कठिन हो सकता है (वास्तविक जीवन अनुभव: विन एपीआई के लिए 3 सप्ताह, तीन में 4 घंटे के खिलाफ अन्य भाषाओं और / या पुस्तकालय)।

वैसे भी, आपको रेमंड चेन का ब्लॉग बहुत ही रोचक लगेगा क्योंकि विन एपीआई और उसके विकास दोनों वर्षों में उनके अंदरूनी विचारों के बारे में:

https://blogs.msdn.microsoft.com/oldnewthing/

सीखना सी या निचली स्तर की भाषा निश्चित रूप से उपयोगी हो सकती है। हालांकि, मुझे अप्रबंधित WinAPI का उपयोग करने में कोई स्पष्ट लाभ नहीं दिख रहा है।

इस धारणा पर कि आप विंडोज़ पर लक्षित ऐप्स बना रहे हैं:

• यह निश्चित रूप से सिस्टम के निचले स्तर को समझने के लिए जानकारीपूर्ण हो सकता है - वे कैसे काम करते हैं, आपका कोड उनके साथ कैसे इंटरैक्ट करता है (भले ही केवल अप्रत्यक्ष रूप से), और जहां आपके पास अतिरिक्त विकल्प हैं जो उच्च-स्तरीय अबास्ट्रक्शन में उपलब्ध नहीं हैं
• ऐसे समय होते हैं जब आपका कोड उतना कुशल, उच्च-प्रदर्शन या आपकी आवश्यकताओं के लिए पर्याप्त सटीक नहीं हो सकता
• हालांकि, अधिक से अधिक मामलों में, हमारे जैसे लोग (जिन्होंने कभी "अप्रबंधित कोडिंग" सीखा नहीं है) प्रोग्रामिंग को खींचने में सक्षम होंगे जो हम Win32 "सीखने" के बिना करने की कोशिश कर रहे हैं।
• इसके अलावा, ऐसी कई साइटें हैं जो काम करने वाले नमूने, कोड टुकड़े और यहां तक ​​कि पूरी तरह से कार्यात्मक स्रोत कोड प्रदान करती हैं जिन्हें आप "लीवरेज" (उधार लेना, चोरी करना) कर सकते हैं - लेकिन जांचें कि आप किसी भी पुन: उपयोग लाइसेंस या कॉपीराइट का पालन कर रहे हैं! ) किसी भी अंतराल को भरने के लिए जो .NET फ्रेमवर्क क्लास लाइब्रेरीज़ (या पुस्तकालय जिन्हें आप डाउनलोड या लाइसेंस कर सकते हैं) द्वारा प्रबंधित नहीं किया जाता है।
• यदि आप Win32 में चारों ओर गड़बड़ किए बिना उन चीजों को दूर कर सकते हैं जिन्हें आप Win32 में चारों ओर गड़बड़ कर रहे हैं, और आप अच्छी तरह से गठित, पठनीय प्रबंधित कोड विकसित करने का अच्छा काम कर रहे हैं, तो मैं मास्टरिंग कहूंगा। नेट की तुलना में बेहतर विकल्प होगा अपने आप को दो बहुत ही अलग वातावरण पर पतला फैलाएं।
• यदि आपको अक्सर उन विंडोज़ की उन सुविधाओं का लाभ उठाने की आवश्यकता होती है जिन्हें अच्छी फ्रेमवर्क क्लास लाइब्रेरी कवरेज नहीं मिला है, तो हर तरह से, आपको आवश्यक कौशल सीखें।
• मैंने कोडिंग के "अन्य क्षेत्रों" के बारे में चिंता करने में बहुत अधिक समय बिताया है कि मैं "अच्छे कार्यक्रम" बनाने के लिए समझने के लिए अनुमानित हूं, लेकिन वहाँ बहुत सारे मासोचिस्ट हैं जो वहां हैं सोचें कि हर किसी की जरूरतें और इच्छाएं स्वयं की तरह हैं। दुख साथी चाहिये। :)

On the assumption that you're building apps for the "Web 2.0" world, or that would be just as useful/beneficial to *NIX & MacOS users:

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