Klasická rozhraní API konzoly versus sekvence virtuálních terminálů

Naším doporučením je nahradit klasické rozhraní API konzoly Windowssekvencemi virtuálních terminálů. Tento článek popisuje rozdíl mezi těmito dvěma a probírá důvody našeho doporučení.

Definice

Klasická plocha rozhraní API konzoly systému Windows je definována jako řada funkčních kernel32.dll rozhraní jazyka C v názvu s textem Konzola.

Sekvence virtuálních terminálů jsou definovány jako jazyk příkazů, které jsou vložené do standardních vstupních a standardních výstupních datových proudů. Sekvence virtuálních terminálů používají netisknutelné řídicí znaky pro signalizaci příkazů, které se prokládají normálním tisknutelným textem.

Historie

Konzola Windows poskytuje rozsáhlé rozhraní API pro klientské aplikace příkazového řádku, které umožňuje manipulaci s výstupním zobrazovacím bufferem i vstupním bufferem uživatele. Jiné platformy než Windows si ale nikdy nepovolily tento konkrétní přístup založený na rozhraní API pro jejich prostředí příkazového řádku a místo toho se rozhodly používat sekvence virtuálních terminálů vložené do standardních vstupních a standardních výstupních datových proudů. (Microsoft toto chování podporoval také v počátečních edicích systému DOS a Windows prostřednictvím ovladače s názvem ANSI.SYS.)

Naproti tomu sekvence virtuálních terminálů (v různých dialektech) řídí operace prostředí příkazového řádku pro všechny ostatní platformy. Tyto sekvence mají svůj původ v ECMA Standard a v sérii rozšíření od mnoha dodavatelů, které sledují zpětně společnosti Digital Equipment Corporation a Tektronix, až k modernějším a běžnějším softwarovým terminálům, jako je xterm. V doméně sekvence virtuálního terminálu existuje mnoho rozšíření a některé sekvence mají širší podporu než jiné, ale je bezpečné říci, že svět se standardizoval na tento jazyk jako na jazyk příkazového řádku v prostředí příkazového řádku s dobře známou podmnožinou podporovanou prakticky každou terminálovou i klientskou aplikací příkazového řádku.

Podpora pro různé platformy

Sekvence virtuálních terminálů jsou nativně podporovány napříč platformami, což umožňuje snadno přenášet terminálové aplikace a nástroje příkazového řádku mezi verzemi a variantami operačních systémů s výjimkou Windows.

Naproti tomu rozhraní API konzoly systému Windows jsou podporována pouze ve Windows. Při pokusu o port nástrojů příkazového řádku z jedné nebo jiné platformy musí být mezi windows a virtuálním terminálem napsaný rozsáhlý adaptér nebo knihovna překladu.

Vzdálený přístup

Sekvence virtuálních terminálů mají velkou výhodu pro vzdálený přístup. Nevyžadují žádnou další práci pro přenos nebo provádění vzdálených procedurálních volání nad rámec toho, čeho je potřeba k nastavení standardního vzdáleného připojení příkazového řádku. Stačí jednoduše připojit odchozí a příchozí přenosový kanál (nebo jeden obousměrný kanál) přes kanál, soket, soubor, sériový port nebo jakékoli jiné zařízení, aby se všechny informace vyžadované pro aplikaci, která hovoří o těchto sekvencích, plně přenášela na vzdáleného hostitele.

Naopak rozhraní API konzoly systému Windows jsou přístupná pouze na místním počítači a veškeré úsilí o jejich vzdálený přístup by vyžadovalo vytvoření celé vrstvy vzdáleného volání a přenosového rozhraní nad rámec pouhého jednoduchého kanálu.

Oddělení obav

Některá rozhraní API konzoly systému Windows poskytují přístup na nízké úrovni k vstupním a výstupním bufferům nebo funkce pro pohodlné ovládání interaktivních příkazových řádků. To může zahrnovat aliasy a historii příkazů naprogramované v rámci subsystému konzoly a hostitelského prostředí, nikoli v samotné klientské aplikaci příkazového řádku.

Naproti tomu je na ostatních platformách zajištění paměti o aktuálním stavu aplikace a funkcí pro pohodlí odpovědností samotného nástroje příkazového řádku nebo prostředí.

Způsob zpracování této odpovědnosti v konzole v hostiteli konzoly a rozhraní API usnadňuje psaní aplikace příkazového řádku s těmito funkcemi a odebírání zodpovědnosti za zapamatování stavu výkresu nebo zpracování funkcí usnadnění úprav. To ale téměř znemožňuje připojení těchto aktivit vzdáleně napříč platformami, verzemi nebo scénáři kvůli změnám v implementacích a dostupnosti. Díky tomu je také konečné interaktivní prostředí těchto aplikací příkazového řádku Windows zcela závislé na implementaci, prioritách a cyklu vydání konzolového hostitele.

Například pokročilé funkce pro úpravy řádků, jako je zvýraznění syntaxe a složitý výběr, jsou možné jenom v případě, že aplikace příkazového řádku zpracovává problémy související s úpravami. Konzola nikdy nemohla mít dostatečný kontext k úplnému pochopení těchto scénářů širokým způsobem, jako může klientská aplikace.

Naproti tomu ostatní platformy používají sekvence virtuálních terminálů ke zpracování těchto aktivit a komunikace virtuálního terminálu prostřednictvím opakovaně použitelných knihoven na straně klienta, jako jsou readline a ncurses. Konečný terminál je zodpovědný pouze za zobrazení informací a příjem vstupu prostřednictvím tohoto obousměrného komunikačního kanálu.

Wrong-Way slovesa

V konzole Systému Windows lze některé akce provádět v opačném směru než přirozeného směru u vstupních a výstupních datových proudů. To umožňuje aplikacím příkazového řádku Systému Windows vyhnout se obavám ze správy vlastních vyrovnávacích pamětí. Umožňuje také aplikacím příkazového řádku Windows provádět pokročilé operace, jako je simulace nebo vkládání vstupu jménem uživatele nebo čtení historie zapsaných položek.

I když to poskytuje další moc aplikacím Windows, které fungují v konkrétním kontextu uživatele na jednom počítači, poskytuje také vektor k překročení úrovní zabezpečení a oprávnění nebo domén, pokud se používá v určitých scénářích. Mezi takové scénáře patří provoz mezi kontexty na stejném počítači nebo napříč kontexty do jiného počítače nebo prostředí.

Jiné platformy, které používají sekvence virtuálních terminálů, tuto aktivitu neumožňují. Naším doporučením pro přechod z klasické konzoly Windows na sekvence virtuálních terminálů je sblížovat se s touto strategií z důvodů interoperability i zabezpečení.

Přímý přístup k oknem

Rozhraní API konzoly Windows poskytuje přesný popisovač okna pro konkrétní hostitelské okno. To umožňuje nástroji příkazového řádku provádět pokročilé operace okna tím, že využívá široké spektrum rozhraní Win32 API, které jsou povoleny pro použití s popisovačem okna. Tato rozhraní API Win32 můžou manipulovat se stavem okna, rámečkem, ikonou nebo jinými vlastnostmi okna.

Naproti tomu na jiných platformách s sekvencemi virtuálních terminálů existuje úzká sada příkazů, které lze provádět s oknem. Tyto příkazy můžou dělat například změnu velikosti okna nebo zobrazovaného názvu, ale musí být provedeny ve stejném pásmu a pod stejným ovládacím bodem jako zbytek streamu.

S vývojem Windows se zvýšily bezpečnostní prvky a omezení u popisovačů oken. Kromě toho se vyvinula povaha a existence popisovače okna adresovatelného aplikací u každého konkrétního prvku uživatelského rozhraní, zejména se zvýšenou podporou faktorů a platforem zařízení. Díky tomu je přímý přístup k aplikacím příkazového řádku křehký při vývoji platformy a prostředí.

Unicode

UTF-8 je akceptované kódování pro data Unicode napříč téměř všemi moderními platformami, protože představuje správnou rovnováhu mezi přenositelností, velikostí úložiště a časem zpracování. Systém Windows ale jako primární kódování dat Unicode zvolil UTF-16. Podpora UTF-8 se ve Windows zvyšuje a použití těchto formátů Unicode nebrání použití jiných kódování.

Platforma konzoly Systému Windows je podporovaná a bude i nadále podporovat všechny stávající kódové stránky a kódování. Pro zajištění maximální kompatibility ve verzích Windows použijte UTF-16 a v případě potřeby proveďte algoritmický překlad s UTF-8. Pro konzolový systém probíhá zvýšená podpora UTF-8.

Podporu UTF-16 v konzole je možné využít bez další konfigurace prostřednictvím varianty W všech rozhraní API konzoly a je pravděpodobnější volbou pro aplikace, které jsou již dobře obeznámeny v UTF-16 prostřednictvím komunikace s wchar_t variantou A W jiných funkcí a produktů platformy Microsoft a Windows.

Podporu UTF-8 v konzole lze využít prostřednictvím varianty rozhraní API konzoly proti obslužným rutinám konzoly po nastavení znakové stránky na 65001 nebo CP_UTF8 pomocí metod SetConsoleOutputCP a SetConsoleCP podle potřeby. Nastavení znakových stránek předem je nezbytné pouze v případě, že počítač v Ovládacích panelech, v části Oblast, nevybral možnost "Použít Unicode UTF-8 pro celosvětovou podporu jazyků" pro ne-Unicode aplikace.

Poznámka:

Odteď se UTF-8 plně podporuje ve standardním výstupním datovém proudu pomocí metod WriteConsole a WriteFile . Podpora vstupního datového proudu se liší v závislosti na vstupním režimu a v průběhu času se bude i nadále vylepšovat. Zejména výchozí "uvařené" režimy na vstupu zatím plně nepodporují UTF-8. Aktuální stav této práce najdete na webu microsoft/terminal#7777 na GitHubu. Alternativním řešením je použít algoritmusově přeložitelný UTF-16 pro čtení vstupu přes ReadConsoleW nebo ReadConsoleInputW , dokud se nevyřeší problémy.

Doporučení

Pro veškerý nový a průběžný vývoj ve Windows se jako způsob interakce s terminálem doporučují sekvence virtuálních terminálů . To bude konvergovat klientské aplikace příkazového řádku Windows se stylem programování aplikací na všech ostatních platformách.

Výjimky pro používání rozhraní API konzoly systému Windows

K vytvoření počátečního prostředí je stále nutná omezená podmnožina rozhraní API konzoly systému Windows . Platforma Windows se stále liší od ostatních v procesu, signálu, zařízení a zpracování kódování:

• Standardní popisovače procesu budou stále řízeny rutinami GetStdHandle a SetStdHandle.

• Konfigurace režimů konzoly na popisovači pro zapnutí podpory sekvencí virtuálních terminálů bude zpracována pomocí rutin GetConsoleMode a SetConsoleMode.

• Deklarace kódové stránky nebo podpory UTF-8 se provádí pomocí metod SetConsoleOutputCP a SetConsoleCP .

• U funkcí AllocConsole, AttachConsole a FreeConsole může být vyžadována určitá úroveň celkové správy procesů, aby se mohla připojit nebo opustit relaci zařízení konzoly.

• Signály a zpracování signálu se budou dál provádět pomocí SetConsoleCtrlHandler, HandlerRoutine a GenerateConsoleCtrlEvent.

• Komunikaci s obslužnými rutinami konzolových zařízení je možné provádět pomocí WriteConsole a ReadConsole. Tyto moduly mohou být také využity prostřednictvím runtime programovacího jazyka ve formě: – C Runtime (CRT): Operace vstupně-výstupního streamu, jako printf, scanf, putc, getc nebo jiné úrovně vstupně-výstupních funkcí. – Standardní knihovna C++ (STL), iostream jako cout a cin. – .NET Runtime: System.Console jako Console.WriteLine.

• Aplikace, které musí být informovány o změnách velikosti okna, budou stále muset použít ReadConsoleInput, aby je mohly přijímat spolu s klíčovými událostmi, protože samotné ReadConsole tyto zahodí.

• Hledání velikosti okna musí být stále provedeno pomocí GetConsoleScreenBufferInfo pro aplikace, které se pokoušejí nakreslit sloupce, mřížky nebo vyplnit zobrazení. Velikost okna a vyrovnávací paměti se bude shodovat v pseudokonsoleové relaci.

Budoucí plánování a pseudokonzole

Neplánuje se, že budou rozhraní API Windows konzole odebrána z platformy.

Hostitel konzoly Systému Windows naopak poskytl pseudokonsoleovou technologii pro překlad stávajících volání příkazového řádku systému Windows do sekvence virtuálních terminálů a jejich předávání do jiného hostitelského prostředí vzdáleně nebo napříč platformami.

Tento překlad není dokonalý. Vyžaduje, aby okno hostitele konzoly udržovalo simulované prostředí toho, co by se uživateli zobrazilo ve Windows. Pak promítá repliku tohoto simulovaného prostředí na hostitele pseudokonsole. Všechna volání rozhraní API konzoly systému Windows se provozují v simulovaném prostředí, aby sloužily potřebám starší klientské aplikace příkazového řádku. Na konečného hostitele se šíří pouze efekty.

Aplikace příkazového řádku, která využívá plnou kompatibilitu napříč platformami a plnou podporu všech nových funkcí a scénářů ve Windows i jinde, se proto doporučuje přejít na sekvence virtuálních terminálů a upravit architekturu aplikací příkazového řádku tak, aby odpovídala všem platformám.

Další informace o tomto přechodu windows pro aplikace příkazového řádku najdete v našem plánu ekosystému.