मुझे दोबारा बताएं कि हमें .NET और Windows दोनों की आवश्यकता क्यों है? विंडोज सीएलआर में क्यों नहीं जा सकता?

Question

उसी तरह डीओएस विंडोज़ में फंस गया?

हम माइक्रोसॉफ्ट से तीन प्लेटफॉर्म के लिए समर्थन और विकास समाप्त कर चुके हैं, और मुझे यकीन नहीं है कि सीमाएं कहां झूठ बोलनी चाहिए।

सीएलआर (जैसे प्रकार की सुरक्षा, स्मृति सुरक्षा इत्यादि) के लाभ विंडोज़ में क्यों नहीं बनाए जा सकते हैं?

या ब्राउज़र में? एक पूरी तरह से अन्य आभासी मशीन क्यों? (वर्चुअल मशीन इंडिकेशन के स्तर अब हम किस तरह से काम कर रहे हैं? हमने अभी सिल्वरलाइट जोड़ा है - और उस फ्लैश से पहले - एक वीएम इंस्टॉल के अंदर चल रहे ब्राउज़र के अंदर चल रहा है ...)

मैं सर्वर के लिए कच्चे विंडोज देख सकता हूं, लेकिन सीधे हार्डवेयर से बात करने वाले वर्कस्टेशन के लिए सीएलआर क्यों नहीं हो सकता था (या कम से कम पूरी विंडोज विरासत गेंद और श्रृंखला नहीं)?

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

फैक्टॉयड - मुझे याद है कि आईबीएम पीसी पर एमएस-डॉस के खिलाफ बेचने वाले प्रतियोगी आर्किटेक्चर में से एक यूसीएसडी-पास्कल रनटाइम था - एक वीएम

Answer 1

और यह न भूलें कि डॉस विंडोज़ में मोर्चे नहीं था, कम से कम विंडोज़ जिन्हें हम जानते हैं और आज प्यार करते हैं। डॉस ऑपरेटिंग सिस्टम था, विंडोज 3.1 एक जीयूआई खोल ऑपरेटिंग सिस्टम के ऊपर आराम कर रहा था।

जब विंडोज 95 बाहर आया, तो यह सच है कि "माइक्रोसॉफ्ट डॉस" लेबल वाला कोई और बॉक्सिंग उत्पाद नहीं था, लेकिन विंडोज 95, आर्किटेक्चरल में, डीओएस 7.0 था जो एक जीयूआई खोल के साथ आराम कर रहा था।

यह Win98 और WinME (उर्फ Win9X) के माध्यम से जारी रहा।

विंडोज़ जिन्हें हम आज जानते हैं (एक्सपी, विस्टा, 2003, 2008) विंडोज एनटी प्रोजेक्ट, एक पूरी तरह से अलग जानवर से इसका मूल है। (हालांकि एनटी को 3.1, और बाद में 9x बाइनरी के साथ संगत होने के लिए डिज़ाइन किया गया था, और निकट-समान लेकिन विस्तारित एपीआई का उपयोग किया गया था।)

डॉस विंडोज़ में और अधिक खराब नहीं है, हम मूल लिनक्स कोर से परिचित हैं केडीई।

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

प्लस ... एक प्रोग्रामर के रूप में, आपको किसी से भी बेहतर पता होना चाहिए: ऐसा कुछ भी करना आसान नहीं है क्योंकि यह बाहर से दिखाई दे सकता है!

Answer 2

क्योंकि यह पिछड़ा संगतता तोड़ देगा? और मुख्यधारा चिप्स वास्तुकला वीएम वास्तुकला के साथ लाइन नहीं है? कुछ समय पहले जावा वीएम के लिए made hardware, लेकिन कोई भी परवाह नहीं करता था।

Answer 3

क्योंकि माइक्रोसॉफ्ट के पास बड़ी विरासत मिली है, वे केवल ड्रॉप नहीं कर सकते हैं। कंपनियों ने विंडोज और Win32 सॉफ़्टवेयर के लिए बहुत सारे पैसे का निवेश किया है, जिन्हें वे बर्खास्त नहीं कर सकते हैं।

Answer 4

ठीक है, एक के लिए सीएलआर एक ऑपरेटिंग सिस्टम नहीं है। यह एक बहुत बड़ा कारण है क्यों नहीं ... मेरा मतलब है कि शोध ओएस, एकता, यहां तक ​​कि सीएलआर नहीं है। मुझे लगता है कि आपको विंडोज कर्नेल और सामान्य ऑपरेटिंग सिस्टम सामान के बारे में कुछ किताबों पर पढ़ना चाहिए।

Answer 5

माइक्रोसॉफ्ट अभी भी कुछ विंडोज रिलीज से दूर हैं।
लेकिन वे कुछ सोचते हैं जैसे Singularity मुझे लगता है।

Answer 6

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

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

Answer 7

सीएलआर या कुछ वीएम शायद इसका उपयोग किया जा सकता है (वीएम का उपयोग किया जा रहा है) इसके ऊपर एक ओएस चलाने के लिए। लेकिन फिर सवाल यह है कि वीएम बनाने के लिए किसी को क्या उपयोग करना चाहिए? शायद सी/सी ++ या कुछ अन्य समान भाषा और (अधिकांश) शायद कुछ मामलों में असेंबली चीजों को तेज करने के लिए।

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

वे मेरे दो सेंट हैं। :)

Answer 8

मुझे लगता है कि सबसे बड़ा मुद्दा यह है कि सीएलआर एक वीएम पर चलता है, और वीएम अमूर्तता की परत के रूप में उपयोगी है। कुछ .NET ऐप्स को लिनक्स पर चलाया जा सकता है (मोनो प्रोजेक्ट देखें, मुझे लगता है कि वे अब .NET 2 संगतता तक हैं), ताकि सब खत्म हो जाए। सी/सी ++ या भाषाएं जो सीधे हार्डवेयर से बात करती हैं, आपको अपने ओएस और हार्डवेयर आर्किटेक्चर के लिए अलग-अलग बाइनरी में अपने कोड को दोबारा जोड़ना होगा। वीएम रखने का मुद्दा यह है कि, आप कोड लिख सकते हैं, इसे बना सकते हैं, और सटीक उसी बाइनरी का कहीं भी उपयोग कर सकते हैं। यदि आप जावा परिप्रेक्ष्य से इसे देखते हैं, तो उन्होंने अपने वीएम का उपयोग "एक बार कहीं भी चलाने के लिए" मॉडल के रूप में करने का एक बेहतर काम किया है। विंडोज़, मैक और लिनक्स पर पुनर्निर्माण के बिना एक ही जावा कक्षाएं चलती हैं (प्रोग्रामर द्वारा वैसे भी, तकनीकी रूप से वीएम वह काम कर रही है)।

मुझे लगता है कि # 1 बिंदु यह है कि .NET/CLR विंडोज विशिष्ट नहीं है, और आईएमओ माइक्रोसॉफ्ट केवल भाषाओं के .NET सूट में मदद करेगा यदि यह क्रॉस-ओएस संगतता की ओर थोड़ा और प्रयास करता है।

Answer 9

सीएलआर स्वयं किस भाषा का उपयोग करेगा? यह कौन सी एपीआई कॉल करेगा? कहें कि इसे फ़ाइल खोलने या स्मृति आवंटित करने या प्रक्रिया बनाने की आवश्यकता है, आपको लगता है कि सीएलआर ऐसा करने जा रहा है? सीएलआर देशी कोड के शीर्ष पर बनाया गया है। एक प्रबंधित ओएस ओवरहेड बना देगा।

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

उन्हें इसे पिछड़ा संगत बनाना होगा ताकि उन्हें किसी प्रकार का मूल एपीआई बनाना पड़े।

यदि आप कह रहे हैं कि चलो शुद्ध 100% प्रबंधित ओएस बनाते हैं और पिछड़े संगतता को भूल जाते हैं या बाद में कुछ विशाल संगतता प्राप्त करते हैं, तो आप वास्तव में कह रहे हैं कि चलो सब कुछ पर एक कचरा कलेक्टर को मजबूर कर दें, है ना? एक कचरा कलेक्टर और पोर्टेबिलिटी गारंटी के अलावा आपको सीएलआई अनुपालन होने के कारण मिलता है, आप क्या प्राप्त कर रहे हैं? एल्गोरिदम और सबकुछ अभी भी मूल कोड में संकलित किए जाने तक संकलित किया जा रहा है, इसलिए स्मृति प्रबंधन केवल एकमात्र महत्वपूर्ण अंतर है।

Answer 10

मैंने वास्तव में रुझानों को देखा कि सीएलआर सॉफ़्टवेयर स्टैक में गहरा लगाएगा। मुझे याद है कि नवीनतम विंडोज सॉफ्टवेयर स्टैक देखा गया है, कुछ सीएलआर संबंधित लाइब्रेरी को निम्न स्तर पर लगाया गया है।

लेकिन सीएलआर खिड़कियों में नहीं जायेगा, हम जानते हैं कि सॉफ़्टवेयर पारिस्थितिकी के लिए पिछड़ा संगतता बहुत महत्वपूर्ण है।