लेख 2 अगस्त, 2018 को प्रकाशित हुआ

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

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

कमियों में से एक यह है कि विंडोज "उपयोगी" होने की कोशिश कर रहा है, लेकिन यह वैकल्पिक और तीसरे पक्ष के कंसोल, सेवा डेवलपर्स, आदि के डेवलपर्स के साथ हस्तक्षेप करता है। कंसोल या सेवा बनाते समय, डेवलपर्स को संचार चैनलों तक पहुंच की आवश्यकता होती है, जिसके माध्यम से उनके टर्मिनल / सेवा कमांड-लाइन अनुप्रयोगों के साथ डेटा का आदान-प्रदान करते हैं, या उन्हें एक्सेस प्रदान करते हैं। * NIX दुनिया में, यह एक समस्या नहीं है क्योंकि * NIX एक छद्म टर्मिनल (PTY) बुनियादी ढांचा प्रदान करता है जो एक कंसोल या सेवा के लिए संचार चैनल बनाना आसान बनाता है। लेकिन विंडोज पर यह नहीं था ...

... अब तक!

TTY से PTY तक

हमारे विकास के बारे में विस्तार से बताने से पहले, आइए संक्षेप में टर्मिनलों के विकास पर लौटते हैं।

शुरुआत में TTY था

जैसा कि पिछले लेख में चर्चा की गई थी, कंप्यूटिंग के शुरुआती दिनों में, उपयोगकर्ताओं ने कुछ प्रकार के धारावाहिक संचार चैनल (आमतौर पर 20 एमए वर्तमान लूप के माध्यम से) के माध्यम से कंप्यूटर से जुड़े इलेक्ट्रोमैकेनिकल टेलेटिप (टीटीवाई) का उपयोग करके कंप्यूटर को नियंत्रित किया।

केन थॉम्पसन और डेनिस रिची (खड़े) डीईसी पीडीपी -11 टेलेटाइप पर काम करते हैं (इलेक्ट्रॉनिक डिस्प्ले के बिना संदेश)

टर्मिनल वितरण

टेलेटाइप्स को इलेक्ट्रॉनिक डिस्प्ले (आमतौर पर सीआरटी स्क्रीन) के साथ कम्प्यूटरीकृत टर्मिनलों द्वारा प्रतिस्थापित किया गया था। आमतौर पर, टर्मिनल बहुत ही सरल उपकरण होते हैं (इसलिए "डम्ब टर्मिनल" शब्द), जिसमें निम्नलिखित कार्यों के लिए केवल इलेक्ट्रॉनिक्स और प्रसंस्करण शक्ति की आवश्यकता होती है:

कीबोर्ड से टेक्स्ट इनपुट का रिसेप्शन।
एक पंक्ति में दर्ज किए गए पाठ को बफर करना (भेजने से पहले स्थानीय संपादन सहित)।
धारावाहिक चैनल पर पाठ भेजना / प्राप्त करना (आमतौर पर एक बार सर्वव्यापी RS-232 इंटरफ़ेस के माध्यम से)।
टर्मिनल प्रदर्शन पर प्राप्त पाठ का प्रदर्शन।

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

एडमिरल ग्रेस हूपर अपने डेस्क पर DEC VT220 टर्मिनल के साथ अपने कार्यालय में

सॉफ्टवेयर टर्मिनलों का वितरण

1980 के दशक के मध्य से, विशेष टर्मिनलों के बजाय, सामान्य प्रयोजन के कंप्यूटरों का उपयोग धीरे-धीरे किया जाने लगा है, जो कि अधिक किफायती, लोकप्रिय और शक्तिशाली बन गए हैं। कई शुरुआती पीसी और 80 के दशक के अन्य कंप्यूटरों में टर्मिनल अनुप्रयोग थे जिन्होंने पीसी के लिए RS-232 कनेक्शन खोला और कनेक्शन के दूसरे छोर पर किसी के साथ डेटा का आदान-प्रदान किया।

सामान्य प्रयोजन के कंप्यूटर अधिक परिष्कृत हो गए, एक ग्राफिकल यूजर इंटरफेस (जीयूआई) और टर्मिनल अनुप्रयोगों सहित समवर्ती अनुप्रयोगों की एक पूरी नई दुनिया दिखाई दी।

लेकिन एक समस्या थी: एक ही मशीन पर चल रहे दूसरे कमांड-लाइन एप्लिकेशन के साथ एक टर्मिनल एप्लिकेशन कैसे बातचीत कर सकता है? और एक ही कंप्यूटर पर चलने वाले दो अनुप्रयोगों के बीच एक सीरियल केबल को भौतिक रूप से कैसे जोड़ा जाए?

छद्म टर्मिनल सूरत (PTY)

* NIX दुनिया में, एक छद्म टर्मिनल (PTY) शुरू करने से समस्या हल हो गई थी।

PTY मास्टर और स्लेव स्यूडो-डिवाइसेस ("मास्टर" और "स्लेव") को उजागर करके कंप्यूटर में सीरियल टेलीकम्यूनिकेशन इक्विपमेंट्स का अनुकरण करता है: टर्मिनल एप्लिकेशन मास्टर स्यूडो-डिवाइस से कनेक्ट होते हैं, और कमांड-लाइन एप्लिकेशन (उदाहरण के लिए, cmd, पॉवरशेल और बैश जैसे गोले) स्लेव स्यूडो-डिवाइस से कनेक्ट होते हैं। जब कोई टर्मिनल क्लाइंट टेक्स्ट और / या कंट्रोल कमांड (टेक्स्ट के रूप में इनकोडिंग) को मास्टर छद्म डिवाइस में ट्रांसमिट करता है, तो टेक्स्ट का इससे जुड़े दास से अनुवाद किया जाता है। एप्लिकेशन से पाठ को दास छद्म डिवाइस पर भेजा जाता है, फिर मास्टर को वापस और इस प्रकार, टर्मिनल को। डेटा हमेशा एसिंक्रोनस रूप से भेजा / प्राप्त किया जाता है।

छद्म टर्मिनल अनुप्रयोग / शेल

यह ध्यान रखना महत्वपूर्ण है कि "दास" छद्म डिवाइस भौतिक टर्मिनल के व्यवहार का अनुकरण करता है और कमांड पात्रों को पोसिक्स संकेतों में परिवर्तित करता है। उदाहरण के लिए, यदि उपयोगकर्ता टर्मिनल में CTRL + C दर्ज करता है, तो मास्टर के माध्यम से CTRL + C (0x03) के लिए ASCII मूल्य भेजा जाता है। जब एक दास छद्म डिवाइस पर प्राप्त होता है, तो मान 0x03 इनपुट स्ट्रीम से हटा दिया जाता है और एक SIGINT सिग्नल उत्पन्न होता है।

इस तरह के PTY बुनियादी ढांचे का उपयोग व्यापक रूप से * NIX टर्मिनल अनुप्रयोगों, पाठ पैनल प्रबंधकों (जैसे स्क्रीन, tmux), आदि द्वारा किया जाता है। ये एप्लिकेशन openpty() , जो पीटीवाई मास्टर और दास के लिए फ़ाइल डिस्क्रिप्टर (एफडी) की एक जोड़ी लौटाता है। फिर आवेदन एक बच्चे को कमांड-लाइन एप्लिकेशन (उदाहरण के लिए, बैश) को कांटा / निष्पादित कर सकता है, जो जुड़े टर्मिनल पर पाठ को सुनने और वापस करने के लिए अपने fd दासों का उपयोग करता है।

यह तंत्र टर्मिनल अनुप्रयोगों को स्थानीय स्तर पर चलने वाले कमांड लाइन अनुप्रयोगों के साथ सीधे "बात" करने की अनुमति देता है, जैसे कि एक धारावाहिक या नेटवर्क कनेक्शन के माध्यम से एक टर्मिनल दूरस्थ कंप्यूटर से बात करेगा।

क्या, नहीं छद्म कंसोल विंडोज?

जैसा कि हमने पिछले लेख में चर्चा की थी, जबकि विंडोज कंसोल पारंपरिक रूप से पारंपरिक * एनआईएक्स टर्मिनल के समान है, यह कई महत्वपूर्ण तरीकों से भिन्न होता है, विशेष रूप से निम्नतम स्तर पर, जो विंडोज कमांड-लाइन अनुप्रयोगों, तीसरे पक्ष के टर्मिनलों / कंसोल और सर्वर के डेवलपर्स के लिए समस्या पैदा कर सकता है। आवेदन:

विंडोज पर कोई PTY इंफ्रास्ट्रक्चर नहीं है : जब कोई उपयोगकर्ता कमांड-लाइन एप्लिकेशन (उदाहरण के लिए, Cmd, PowerShell, wsl, ipconfig, आदि) लॉन्च करता है, तो विंडोज खुद ही एप्लिकेशन को कंसोल के एक नए या मौजूदा उदाहरण को "कनेक्ट" करता है।
विंडोज तृतीय-पक्ष कंसोल और सर्वर अनुप्रयोगों के साथ हस्तक्षेप करता है: विंडोज (वर्तमान में) टर्मिनलों को संचार चैनल प्रदान करने का एक तरीका नहीं देता है जिसके माध्यम से वे कमांड-लाइन एप्लिकेशन के साथ बातचीत करना चाहते हैं। तृतीय-पक्ष टर्मिनलों को स्क्रीन से कंसोल बनाना है, उपयोगकर्ता-दर्ज डेटा को वहां भेजना है और तीसरे पक्ष के कंसोल के प्रदर्शन पर इसे फिर से डिज़ाइन करके आउटपुट को स्क्रैप करना है!
केवल Windows में कंसोल API है : Windows कमांड-लाइन एप्लिकेशन Win32 Consol API पर भरोसा करते हैं, जो कोड पोर्टेबिलिटी को कम करता है, चूंकि अन्य सभी प्लेटफॉर्म टेक्स्ट / VT का समर्थन करते हैं, एपीआई का नहीं।
गैर-मानक रिमोट एक्सेस : कंसॉल एपीआई पर कमांड-लाइन अनुप्रयोगों की निर्भरता बातचीत और रिमोट एक्सेस स्क्रिप्ट को काफी जटिल बनाती है।

क्या करें?

कई, कई डेवलपर्स ने अक्सर विंडोज के तहत एक पीटीवाई-जैसे तंत्र का अनुरोध किया, विशेष रूप से कॉनमू / सीएमडी, कंसोल 2 / कंसोल, हाइपर, वीएसकोड, विज़ुअल स्टूडियो, डब्ल्यूएसएल, डॉकर और ओपनएसएसएच के साथ काम करने वाले।

यहां तक कि पीटर ब्राइट, अर्स टेक्निका के प्रौद्योगिकी संपादक, ने मुझे कुछ दिनों बाद पीटीवाई तंत्र लागू करने के लिए कहा, जब मैंने कंसोल टीम में काम करना शुरू किया:

और हाल ही में फिर से:

खैर, हमने आखिरकार यह किया: हमने विंडोज के लिए एक छद्म कंसोल बनाया :

विंडोज छद्म कंसोल (अवधारणा) में आपका स्वागत है

लगभग चार साल पहले कंसोल टीम के गठन के बाद से, समूह विंडोज कंसोल और कमांड लाइन के आंतरिक तंत्र के ओवरहाल में लगा हुआ है। इसी समय, हम नियमित रूप से और ध्यान से ऊपर वर्णित मुद्दों और कई अन्य संबंधित मुद्दों और समस्याओं पर विचार करते हैं। लेकिन बुनियादी ढाँचा और कोड छद्म सांत्वना की रिहाई को संभव बनाने के लिए तैयार नहीं थे ... अब तक!

नया विंडोज स्यूडो-कंसोल (CONPTY) इंफ्रास्ट्रक्चर, एपीआई, और कुछ अन्य संबंधित परिवर्तन मौजूदा कमांड लाइन अनुप्रयोगों के साथ पिछड़ी संगतता को तोड़ने के बिना समस्याओं के एक पूरे वर्ग को समाप्त / समाप्त कर देंगे!

नया Win32 CONPTY API (आधिकारिक दस्तावेज जल्द ही प्रकाशित किया जाएगा) अब विंडोज 10 और इसी विंडोज 10 इनसाइडर प्रीव्यू एसडीके के नवीनतम इनसाइडर बिल्ड में उपलब्ध है। वे विंडोज 10 (2018 के पतन / सर्दियों में कहीं और) की अगली प्रमुख रिलीज में दिखाई देंगे।

कंसोल / कॉनहॉस्ट आर्किटेक्चर

अवधारणा को समझने के लिए, आपको विंडोज कंसोल की वास्तुकला का अध्ययन करने की आवश्यकता है, या बल्कि ... कॉनहॉस्ट!

यह समझना महत्वपूर्ण है कि यद्यपि ConHost वह सब कुछ लागू करता है जो आप देखते हैं और Windows कंसोल एप्लिकेशन के रूप में जानते हैं, ConHost में अधिकांश Windows कमांड-लाइन अवसंरचना शामिल है और लागू होती है! अब से, ConHost एक वास्तविक "कंसोल नोड" बन जाता है , जो कमांड लाइन अनुप्रयोगों के साथ बातचीत करने वाले सभी कमांड लाइन अनुप्रयोगों और / या GUI अनुप्रयोगों का समर्थन करता है!

कैसे? क्यों? क्या? आइए एक नज़र डालें।

यहाँ आंतरिक कंसोल वास्तुकला / ConHost का एक उच्च-स्तरीय दृश्य है:

पिछले लेख के आर्किटेक्चर की तुलना में, ConHost में अब VT प्रसंस्करण के लिए कई अतिरिक्त मॉड्यूल और नए CONPTY मॉड्यूल शामिल हैं जो खुले एपीआई को लागू करते हैं:

अवधारणा एपीआई : नए Win32 अवधारणा एपीआई POSIX PTY मॉडल के समान एक तंत्र प्रदान करते हैं, लेकिन विंडोज अपवर्तन में।
VT अन्तरक्रियाशीलता : UTF-8 एन्कोडिंग में इनपुट टेक्स्ट प्राप्त करता है, प्रत्येक प्रदर्शित टेक्स्ट कैरेक्टर को संबंधित INPUT_RECORD रिकॉर्ड में कनवर्ट करता है और इसे इनपुट बफर में सेव करता है। यह 0x03 (CTRL + C) जैसे एस्केप सीक्वेंस को भी प्रोसेस करता है, जिससे उन्हें KEY_EVENT_RECORDS परिवर्तित किया जाता है, जो उचित एक्शन से बचते हैं।
वीटी रेंडरर : कर्सर को स्थानांतरित करने के लिए आवश्यक वीटी अनुक्रम उत्पन्न करता है और पिछले फ्रेम से बदले गए आउटपुट बफर के क्षेत्रों में पाठ और शैली को प्रस्तुत करता है।

ठीक है, लेकिन इसका वास्तव में क्या मतलब है?

विंडोज कमांड लाइन एप्लिकेशन कैसे काम करते हैं?

नए CONPTY बुनियादी ढांचे के प्रभाव को बेहतर ढंग से समझने के लिए, आइए देखें कि विंडोज कंसोल और कमांड-लाइन अनुप्रयोगों ने अब तक कैसे काम किया है।

जब भी कोई उपयोगकर्ता Cmd, PowerShell या ssh जैसे कमांड-लाइन एप्लिकेशन लॉन्च करता है, तो Windows एक नई Win32 प्रक्रिया बनाता है जिसमें यह एप्लिकेशन के निष्पादन योग्य बाइनरी और किसी भी निर्भरता (संसाधन या लाइब्रेरी) को लोड करता है।

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

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

यहां हमें एक आरक्षण करने की आवश्यकता है, क्योंकि कुछ मामलों में कमांड-लाइन एप्लिकेशन कंसोल के एक नए उदाहरण से जुड़े होते हैं, विशेष रूप से सुरक्षा कारणों से, लेकिन उपरोक्त विवरण आमतौर पर सही है।

अंततः, जब कमांड-लाइन / शेल एप्लिकेशन शुरू होता है, तो विंडोज इसे कॉनड्रोड के माध्यम से कंसोल इंस्टेंस (ConHost.exe) से जोड़ता है:

ConHost कैसे काम करता है?

जब भी कोई कमांड लाइन एप्लिकेशन चल रही होती है, तो विंडोज एप्लिकेशन को कॉनहॉस्ट के नए या मौजूदा उदाहरण से जोड़ता है। एप्लिकेशन और इसके कंसोल उदाहरण कर्नेल-मोड कंसोल ड्राइवर (ConDrv) के माध्यम से जुड़े हुए हैं, जो क्रमबद्ध API कॉल अनुरोधों और / या पाठ डेटा वाले IOCTL संदेश भेजता / प्राप्त करता है।

ऐतिहासिक रूप से, जैसा कि पिछले लेख में कहा गया है, कॉनहॉस्ट का काम आज अपेक्षाकृत सरल है:

उपयोगकर्ता कीबोर्ड / माउस / पेन / टचपैड से इनपुट उत्पन्न करता है, जिसे KEY_EVENT_RECORD या MOUSE_EVENT_RECORD परिवर्तित किया जाता है और इनपुट बफर में संग्रहीत किया जाता है।
इनपुट बफर एक समय में एक रिकॉर्ड खाली कर दिया जाता है, अनुरोधित इनपुट क्रियाओं को निष्पादित करता है, जैसे कि स्क्रीन पर पाठ प्रदर्शित करना, कर्सर को हिलाना, कॉपी करना / पाठ चिपकाना, आदि। इन कार्यों में से कई आउटपुट बफर की सामग्री को बदलते हैं। ये परिवर्तित क्षेत्र कॉनहॉस्ट राज्य इंजन द्वारा दर्ज किए गए हैं।
प्रत्येक फ्रेम में, कंसोल आउटपुट बफर के परिवर्तित क्षेत्रों को प्रदर्शित करता है।

जब कमांड-लाइन एप्लिकेशन विंडोज कंसोल एपीआई को कॉल करता है, तो एपीआई कॉल IOCTL संदेशों में क्रमबद्ध होते हैं और कॉनड्रव चालक के माध्यम से भेजे जाते हैं। यह संलग्न कंसोल को IOCTL संदेश भेजता है, जो अनुरोधित एपीआई कॉल को डिकोड और निष्पादित करता है। लौटे / आउटपुट मान IOCTL संदेश में वापस क्रमबद्ध किए जाते हैं और ConDrv के माध्यम से एप्लिकेशन को वापस भेज दिए जाते हैं।

ConHost: भविष्य के लिए अतीत में योगदान

Microsoft जब भी संभव हो मौजूदा अनुप्रयोगों और उपकरणों के साथ पिछड़े संगतता बनाए रखने का प्रयास करता है। खासकर कमांड लाइन के लिए। वास्तव में, विंडोज 10 के 32-बिट संस्करण अभी भी कई / अधिकांश 16-बिट Win16 अनुप्रयोगों और निष्पादन योग्य चला सकते हैं!

जैसा कि ऊपर उल्लेख किया गया है, कॉनहॉस्ट की प्रमुख भूमिकाओं में से एक अपने कमांड लाइन अनुप्रयोगों, विशेष रूप से विरासत अनुप्रयोगों को सेवाएं प्रदान करना है जो विन 32 कंसोल एपीआई पर भरोसा करते हैं और भरोसा करते हैं। अब ConHost नई सेवाएं प्रदान करता है:

आधुनिक कंसोल और टर्मिनलों के साथ संचार के लिए निर्बाध PTY- जैसा बुनियादी ढांचा
विरासत / पारंपरिक कमांड लाइन अनुप्रयोगों को अपग्रेड करना
- इनपुट रिकॉर्ड्स के लिए UTF-8 टेक्स्ट / VT प्राप्त करना और परिवर्तित करना (जैसे कि उपयोगकर्ता द्वारा दर्ज किया गया है)
- कंसोल API होस्ट किए गए एप्लिकेशन को कॉल करता है, अपने आउटपुट बफर को तदनुसार अपडेट करता है
- UTF-8 एन्कोडिंग, पाठ / वीटी में आउटपुट बफर के संशोधित क्षेत्रों को प्रदर्शित करें

निम्नलिखित एक उदाहरण है कि कैसे एक आधुनिक कंसोल एप्लिकेशन एक कमांड लाइन एप्लिकेशन के साथ कॉनपीटी कॉनहॉस्ट के माध्यम से संचार करता है।

इस नए मॉडल में:

कंसोल:
1. खुद का संचार चैनल बनाता है
2. CONPTY बनाने के लिए CONPTY API को कॉल करता है, Windows को चैनलों के दूसरे छोर से जुड़े ConHost का एक उदाहरण चलाने के लिए मजबूर करता है।
3. सामान्य रूप से, ConHost से जुड़े एक कमांड-लाइन एप्लिकेशन (जैसे पॉवरशेल) का एक उदाहरण बनाता है
ConHost:
1. इनपुट पर UTF-8 टेक्स्ट / VT पढ़ता है और इसे INPUT_RECORD रिकॉर्ड में INPUT_RECORD करता है, जो कमांड लाइन आवेदन के लिए भेजे जाते हैं
2. कमांड लाइन एप्लिकेशन से एपीआई कॉल करें जो आउटपुट बफर की सामग्री को संशोधित कर सकता है
3. UTF-8 एन्कोडिंग (पाठ / VT) में आउटपुट बफर में परिवर्तन दिखाता है और प्राप्त पाठ को इसके कंसोल पर भेजता है
कमांड लाइन आवेदन:
1. यह हमेशा की तरह काम करता है, इनपुट को पढ़ता है और कॉन्सोल एपीआई को कॉल करता है, इस बात का कोई अंदाजा नहीं है कि इसका कॉन्टेक्ट कॉन्स्टोस्ट इनपुट और आउटपुट को / से यूटीएफ -8 में ट्रांसलेट करता है!

अंतिम क्षण महत्वपूर्ण है! जब पुरानी कमांड-लाइन एप्लिकेशन कॉनसोल कंसोल एपीआई जैसे कि WriteConsoleOutput(...) लिए कॉल का उपयोग करती है, तो निर्दिष्ट पाठ संबंधित कॉनहॉस्ट आउटपुट बफर को लिखा जाता है। समय-समय पर, ConHost आउटपुट बफर के परिवर्तित क्षेत्रों को टेक्स्ट / वीटी के रूप में प्रदर्शित करता है, जो कंसोल पर वापस स्टडआउट के माध्यम से भेजा जाता है।

अंत में, बाहर से भी पारंपरिक कमांड-लाइन एप्लिकेशन बिना किसी बदलाव के टेक्स्ट / वीटी को "बोलते" हैं !

नए CONPTY बुनियादी ढांचे का उपयोग करते हुए, तृतीय-पक्ष कंसोल अब सीधे आधुनिक और पारंपरिक कमांड-लाइन अनुप्रयोगों के साथ बातचीत कर सकते हैं और उन सभी को टेक्स्ट / वीटी में एक्सचेंज कर सकते हैं।

दूरस्थ रूप से विंडोज कमांड लाइन अनुप्रयोगों के साथ बातचीत

ऊपर वर्णित तंत्र एक कंप्यूटर पर ठीक काम करता है, लेकिन इंटरेस्टिंग करते समय भी मदद करता है, उदाहरण के लिए, रिमोट विंडोज कंप्यूटर पर या कंटेनर में पॉवरशेल उदाहरण के साथ।

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

इस प्रकार, विंडोज मशीन को दूरस्थ रूप से नियंत्रित करने के लिए, हमें कुछ प्रकार के संचार ब्रोकर की आवश्यकता होती है जो नेटवर्क पर डेटा को क्रमिक रूप से अनुक्रमित कर सकते हैं, एप्लिकेशन इंस्टेंस के जीवनकाल का प्रबंधन कर सकते हैं, आदि।

शायद कुछ ssh की तरह?

सौभाग्य से, ओपनएसएसएच को हाल ही में विंडोज में पोर्ट किया गया था और विंडोज 10 में एक अतिरिक्त विकल्प के रूप में जोड़ा गया था । PowerShell Core भी समर्थित PowerShell Core Remoting remoting प्रोटोकॉल में से एक के रूप में ssh का उपयोग करता है। और विंडोज पॉवरशेल चलाने वालों के लिए, विंडोज पॉवरशेल रेमोटिंग को रीमोट करना अभी भी एक स्वीकार्य विकल्प है।

आइए देखें कि विंडोज के लिए ओपनएसएसएच अब आपको विंडोज के गोले और कमांड लाइन अनुप्रयोगों को दूर से नियंत्रित करने की अनुमति कैसे देता है:

OpenSSH में वर्तमान में कुछ अवांछित जटिलताएँ शामिल हैं:

उपयोगकर्ता:
1. Ssh क्लाइंट शुरू करता है, और विंडोज हमेशा की तरह कंसोल इंस्टेंस को जोड़ता है
2. पाठ को कंसोल में जोड़ता है, जो ssh क्लाइंट को कीस्ट्रोक भेजता है
ssh ग्राहक:
1. पाठ डेटा के बाइट्स के रूप में इनपुट पढ़ता है
2. Sshd सुनने की सेवा के लिए नेटवर्क पर पाठ डेटा भेजता है
Sshd सेवा कई चरणों से गुजरती है:
1. डिफ़ॉल्ट शेल (उदाहरण के लिए, Cmd) लॉन्च करता है, जो विंडोज को कंसोल के एक नए उदाहरण को बनाने और कनेक्ट करने के लिए मजबूर करता है
2. ढूँढता है और Cmd इंस्टेंस के कंसोल से जोड़ता है
3. कंसोल को ऑफ़-स्क्रीन ले जाता है (और / या इसे छुपाता है)
4. इनपुट के रूप में स्क्रीन को सांत्वना देने के लिए ssh क्लाइंट से प्राप्त इनपुट भेजता है
Cmd उदाहरण हमेशा की तरह काम करता है:
1. Sshd सेवा से इनपुट एकत्र करता है
2. काम करता है
3. टेक्स्ट को रेंडर / स्टाइल करने, कर्सर को स्थानांतरित करने आदि के लिए कंसोल एपीआई को कॉल करता है।
संलग्न [ऑफ-स्क्रीन] कंसोल:
1. आउटपुट बफर को अपडेट करके एपीआई कॉल करें।
Sshd सेवा:
1. ऑफ-स्क्रीन कंसोल के आउटपुट बफर को स्क्रैप करता है, अंतर पाता है, उन्हें टेक्स्ट / वीटी में एन्कोड करता है और वापस भेजता है ...
एक ssh क्लाइंट जो टेक्स्ट भेजता है ...
कंसोल जो पाठ प्रदर्शित करता है

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

आधुनिक ConHost और CONPTY का उपयोग कर दूरस्थ कार्य

निश्चित रूप से हम स्थिति में सुधार कर सकते हैं? हां, निश्चित रूप से हम कर सकते हैं - चलो कुछ वास्तु परिवर्तन करते हैं और हमारी नई अवधारणा लागू करते हैं:

आरेख दिखाता है कि सर्किट इस प्रकार बदल गया है:

उपयोगकर्ता:
1. Ssh क्लाइंट शुरू करता है, और विंडोज हमेशा की तरह कंसोल इंस्टेंस को जोड़ता है
2. पाठ को कंसोल में जोड़ता है, जो ssh क्लाइंट को कीस्ट्रोक भेजता है
ssh ग्राहक:
1. पाठ डेटा के बाइट्स के रूप में इनपुट पढ़ता है
2. Sshd सुनने की सेवा के लिए नेटवर्क पर पाठ डेटा भेजता है
Sshd सेवा:
1. स्टडिन / स्टडआउट चैनल बनाता है
2. ConPTY शुरू करने के लिए CONPTY API को कॉल करता है
3. कॉन्टपीटी के दूसरे छोर से जुड़ा एक सीएमडी उदाहरण शुरू करता है। Windows ConHost का एक नया उदाहरण आरंभ और माउंट करता है
Cmd उदाहरण हमेशा की तरह काम करता है:
1. Sshd सेवा से इनपुट एकत्र करता है
2. काम करता है
3. टेक्स्ट को रेंडर / स्टाइल करने, कर्सर को स्थानांतरित करने आदि के लिए कंसोल एपीआई को कॉल करता है।
उदाहरण अवधारणा
1. आउटपुट बफर को अपडेट करके एपीआई कॉल करें।
2. आउटपुट बफर के परिवर्तित क्षेत्रों को UTF-8 एन्कोडेड टेक्स्ट / VT के रूप में प्रदर्शित करता है, जो कंसोल / टर्मिनल ssh के माध्यम से वापस भेजा जाता है

कॉन्टपीटी का उपयोग करने वाला यह दृष्टिकोण स्पष्ट रूप से क्लीनर और sshd सेवा के लिए सरल है। विंडोज कंसोल एपीआई के लिए कॉल पूरी तरह से कमांड लाइन एप्लिकेशन के कॉनहॉस्ट उदाहरण में किए गए हैं, जो पाठ और वीटी के लिए सभी दृश्यमान परिवर्तनों को परिवर्तित करता है। जो कोई भी ConHost से जुड़ता है, उसे यह जानने की आवश्यकता नहीं है कि वहां एप्लिकेशन कॉन्सोल एपीआई को कॉल करता है, और टेक्स्ट / वीटी उत्पन्न नहीं करता है!

सहमत हूँ कि इस नई अवधारणा के दूरस्थ तंत्र एक सुंदर, सुसंगत और सरल वास्तुकला की ओर जाता है। ConHost में निर्मित शक्तिशाली विशेषताओं के साथ संयुक्त, पुराने अनुप्रयोगों के लिए समर्थन और अनुप्रयोगों से परिवर्तन प्रदर्शित करने वाले कंसोल कंसोल को टेक्स्ट / VT के रूप में कहते हैं, नया ConHost और CONPTY बुनियादी ढांचा हमें भविष्य में अतीत को स्थानांतरित करने में मदद करता है।

अवधारणा एपीआई और इसका उपयोग कैसे करें

CONPTY API विंडोज 10 इनसाइडर प्रीव्यू SDK के वर्तमान संस्करण में उपलब्ध है।

अब तक, मुझे यकीन है कि आप कुछ कोड देखने के लिए इंतजार नहीं करेंगे;)

एपीआई घोषणाओं पर एक नज़र डालें:

 // Creates a "Pseudo Console" (ConPTY). HRESULT WINAPI CreatePseudoConsole( _In_ COORD size, // ConPty Dimensions _In_ HANDLE hInput, // ConPty Input _In_ HANDLE hOutput, // ConPty Output _In_ DWORD dwFlags, // ConPty Flags _Out_ HPCON* phPC); // ConPty Reference // Resizes the given ConPTY to the specified size, in characters. HRESULT WINAPI ResizePseudoConsole(_In_ HPCON hPC, _In_ COORD size); // Closes the ConPTY and all associated handles. Client applications attached // to the ConPTY will also terminated. VOID WINAPI ClosePseudoConsole(_In_ HPCON hPC);

उपरोक्त एपीआई अवधारणा अनिवार्य रूप से उपयोग के लिए तीन नए कार्यों को उजागर करती है:

CreatePseudoConsole(size, hInput, hOutput, dwFlags, phPC)
- कॉलर द्वारा बनाए गए चैनलों का उपयोग करके, w कॉलम और h लाइनों में आयाम के साथ pty बनाता है:
  - size : चौड़ाई और ऊंचाई (पात्रों में) शंकु बफर के
  - hInput : UTF-8 एन्कोडिंग में टेक्स्ट / VT अनुक्रमों के रूप में PTY को इनपुट डेटा लिखने के लिए
  - hOutput : UTF-8 एन्कोडिंग में पाठ / वीटी दृश्यों के रूप में PTY से आउटपुट पढ़ने के लिए
  - dwFlags : संभावित मान:
    - PSEUDOCONSOLE_INHERIT_CURSOR : बनाई गई CONPTY पैरेंट टर्मिनल एप्लिकेशन के कर्सर स्थिति को इनहेरिट करने की कोशिश करेगी
  - phPC : phPC द्वारा उत्पन्न कंसोल हैंडल
- रिटर्न : सफलता / विफलता। सफल होने पर, phPC में नई ConPty का हैंडल होता है
ResizePseudoConsole(hPC, size)
- एक विशिष्ट चौड़ाई और ऊंचाई प्रदर्शित करने के लिए आंतरिक अवधारणा बफर का आकार बदलता है
ClosePseudoConsole (hPC)
- ConPTY और सभी संबद्ध विवरणकों को बंद कर देता है। CONPTY से जुड़े क्लाइंट एप्लिकेशन भी समाप्त हो जाते हैं जैसे कि वे एक कंसोल विंडो में चल रहे थे जो बंद हो गया
अवधारणा एपीआई का उपयोग करना

निम्नलिखित एक छद्म एपीआई कॉल कोड का एक छोटा सा उदाहरण है जो एक छद्म कंसोल बनाने और जेनरेट किए गए CONPTY को कमांड-लाइन एप्लिकेशन संलग्न करने के लिए है।

नोट: पूर्ण कार्यान्वयन हमारे GitHub रिपॉजिटरी में प्रकाशित किया जाएगा ।
```
  // Note: Most error checking removed for brevity. // ... // Initializes the specified startup info struct with the required properties and // updates its thread attribute list with the specified ConPTY handle HRESULT InitializeStartupInfoAttachedToConPTY(STARTUPINFOEX* siEx, HPCON hPC) { HRESULT hr = E_UNEXPECTED; size_t size; siEx->StartupInfo.cb = sizeof(STARTUPINFOEX); // Create the appropriately sized thread attribute list InitializeProcThreadAttributeList(NULL, 1, 0, &size); std::unique_ptr<BYTE[]> attrList = std::make_unique<BYTE[]>(size); // Set startup info's attribute list & initialize it siEx->lpAttributeList = reinterpret_cast<PPROC_THREAD_ATTRIBUTE_LIST>( attrList.get()); bool fSuccess = InitializeProcThreadAttributeList( siEx->lpAttributeList, 1, 0, (PSIZE_T)&size); if (fSuccess) { // Set thread attribute list's Pseudo Console to the specified ConPTY fSuccess = UpdateProcThreadAttribute( lpAttributeList, 0, PROC_THREAD_ATTRIBUTE_PSEUDOCONSOLE, hPC, sizeof(HPCON), NULL, NULL); return fSuccess ? S_OK : HRESULT_FROM_WIN32(GetLastError()); } else { hr = HRESULT_FROM_WIN32(GetLastError()); } return hr; } // ... HANDLE hOut, hIn; HANDLE outPipeOurSide, inPipeOurSide; HANDLE outPipePseudoConsoleSide, inPipePseudoConsoleSide; HPCON hPC = 0; // Create the in/out pipes: CreatePipe(&inPipePseudoConsoleSide, &inPipeOurSide, NULL, 0); CreatePipe(&outPipeOurSide, &outPipePseudoConsoleSide, NULL, 0); // Create the Pseudo Console, using the pipes CreatePseudoConsole( {80, 32}, inPipePseudoConsoleSide, outPipePseudoConsoleSide, 0, &hPC); // Prepare the StartupInfoEx structure attached to the ConPTY. STARTUPINFOEX siEx{}; InitializeStartupInfoAttachedToConPTY(&siEx, hPC); // Create the client application, using startup info containing ConPTY info wchar_t* commandline = L"c:\\windows\\system32\\cmd.exe"; PROCESS_INFORMATION piClient{}; fSuccess = CreateProcessW( nullptr, commandline, nullptr, nullptr, TRUE, EXTENDED_STARTUPINFO_PRESENT, nullptr, nullptr, &siEx->StartupInfo, &piClient); // ... 
```
अब cmd.exe बनाई गई CONPTY उदाहरण से जुड़ा है CreatePseudoConsole()। कॉल करने वाला कॉनपीटी विवरण का उपयोग करता है जिसे वह Cmd उदाहरण से लिखने / पढ़ने के लिए बनाता है। छद्म कंसोल का आकार बदलकर उपयोग किया जाता है ResizePseudoConsole(), और समापन - कॉल द्वारा ClosePseudoConsole()।

छद्म सांत्वना के लिए रिकॉर्डिंग

CONPTY के लिए इनपुट लिखना सरल है:
```
 // Input "echo Hello, World!", press enter to have cmd process the command, // input an up arrow (to get the previous command), and enter again to execute. std::string helloWorld = "echo Hello, World!\n\x1b[A\n"; DWORD dwWritten; WriteFile(hIn, helloWorld.c_str(), (DWORD)helloWorld.length(), &dwWritten, nullptr); 
```
, ConPTY:
```
 // Suppose some other async callback triggered us to resize. // This call will update the Terminal with the size we received. HRESULT hr = ResizePseudoConsole(hPC, {120, 30}); 
```
ConPTY:
```
 ClosePseudoConsole(hPC); 
```
: ConPTY ConHost .

!

ConPTY API — , , Windows … !

ConPTY API Microsoft, Microsoft ( Windows Linux (WSL), Windows Containers, VSCode, Visual Studio .), , @ConEmuMaximus5 — ConEmu Windows.

, ConPTY API.

, : ConHost . Console API. , , .

, VT, , — .

, Windows, /VT UTF-8 Console API: « VT» , Console API (, 16M RGB True Color ).

/

/ , ConPTY API: , , , , .

VSCode ( GitHub #45693 ) , Windows.

ConPTY API

ConPTY API Windows 10 / 2018 .

Windows, , , ConPTY. Win32 API, API Runtime Dynamic Linking LoadLibrary() GetProcAddress() .

Windows ConPTY, API ConPTY. , , .

, ?

… ! , , ! : डी

, , , . — , Windows , .

. Windows Console GitHub . , .

मिलो विंडोज छद्म कंसोल (अवधारणा)