API Konsol Klasik versus Urutan Terminal Virtual
Rekomendasi kami adalah mengganti API Konsol Windows klasik dengan urutan terminal virtual. Artikel ini akan menguraikan perbedaan antara keduanya dan membahas alasan rekomendasi kami.
Permukaan WINDOWS Console API klasik didefinisikan sebagai seri antarmuka fungsional bahasa C dengan kernel32.dll
"Konsol" dalam nama.
Urutan terminal virtual didefinisikan sebagai bahasa perintah yang disematkan dalam aliran input standar dan output standar. Urutan terminal virtual menggunakan karakter escape yang tidak dapat dicetak untuk perintah sinyal yang terjalin dengan teks yang dapat dicetak normal.
Konsol Windows menyediakan permukaan API yang luas untuk aplikasi baris perintah klien untuk memanipulasi buffer tampilan output dan buffer input pengguna. Namun, platform non-Windows lainnya belum pernah membeli pendekatan khusus berbasis API ini ke lingkungan baris perintah mereka, memilih untuk menggunakan urutan terminal virtual yang disematkan dalam input standar dan aliran output standar. (Untuk sementara waktu, Microsoft juga mendukung perilaku ini di edisi awal DOS dan Windows melalui driver yang disebut ANSI.SYS.)
Sebaliknya, urutan terminal virtual (dalam berbagai dialek) mendorong operasi lingkungan baris perintah untuk semua platform lainnya. Urutan ini berakar pada Standar ECMA dan serangkaian ekstensi oleh banyak vendor yang menelusuri kembali ke Digital Equipment Corporation dan terminal Tektronix, hingga terminal perangkat lunak yang lebih modern dan umum, seperti xterm. Banyak ekstensi ada dalam domain urutan terminal virtual dan beberapa urutan lebih banyak didukung daripada yang lain, tetapi aman untuk mengatakan bahwa dunia telah menstandarkan ini sebagai bahasa perintah untuk pengalaman baris perintah dengan subset terkenal yang didukung oleh hampir setiap terminal dan aplikasi klien baris perintah.
Urutan terminal virtual didukung secara asli di seluruh platform, membuat aplikasi terminal dan utilitas baris perintah mudah portabel antara versi dan variasi sistem operasi, dengan pengecualian Windows.
Sebaliknya, API Konsol Windows hanya didukung di Windows. Adaptor ekstensif atau pustaka terjemahan harus ditulis antara Windows dan terminal virtual, atau sebaliknya, ketika mencoba port utilitas baris perintah dari satu platform atau platform lainnya.
Urutan terminal virtual memiliki keuntungan besar untuk akses jarak jauh. Mereka tidak memerlukan pekerjaan tambahan untuk diangkut, atau melakukan panggilan prosedur jarak jauh, atas apa yang diperlukan untuk menyiapkan koneksi baris perintah jarak jauh standar. Cukup menyambungkan saluran transportasi keluar dan masuk (atau saluran dua arah) melalui pipa, soket, file, port serial, atau perangkat lain cukup untuk sepenuhnya membawa semua informasi yang diperlukan untuk aplikasi yang berbicara urutan ini ke host jarak jauh.
Sebaliknya, API Konsol Windows hanya dapat diakses pada komputer lokal dan semua upaya untuk jarak jauh akan mengharuskan membangun seluruh lapisan antarmuka panggilan jarak jauh dan transportasi di luar hanya saluran sederhana.
Beberapa API Konsol Windows menyediakan akses tingkat rendah ke buffer input dan output atau fungsi kenyamanan untuk baris perintah interaktif. Ini mungkin termasuk alias dan riwayat perintah yang diprogram dalam subsistem konsol dan lingkungan host, alih-alih dalam aplikasi klien baris perintah itu sendiri.
Sebaliknya, platform lain membuat memori tentang status aplikasi saat ini dan fungsionalitas kenyamanan menjadi tanggung jawab utilitas baris perintah atau shell itu sendiri.
Cara Konsol Windows untuk menangani tanggung jawab ini di host konsol dan API membuatnya lebih cepat dan lebih mudah untuk menulis aplikasi baris perintah dengan fitur-fitur ini, menghapus tanggung jawab mengingat status menggambar atau menangani fitur kenyamanan pengeditan. Namun, ini membuatnya hampir tidak mungkin untuk menghubungkan aktivitas tersebut dari jarak jauh di seluruh platform, versi, atau skenario karena variasi dalam implementasi dan ketersediaan. Cara menangani tanggung jawab ini juga membuat pengalaman interaktif akhir aplikasi baris perintah Windows ini sepenuhnya tergantung pada implementasi, prioritas, dan siklus rilis host konsol.
Misalnya, fitur pengeditan baris tingkat lanjut, seperti penyorotan sintaksis dan pilihan kompleks, hanya dimungkinkan ketika aplikasi baris perintah menangani masalah pengeditan itu sendiri. Konsol tidak pernah bisa memiliki konteks yang cukup untuk sepenuhnya memahami skenario ini secara luas seperti yang dapat dilakukan aplikasi klien.
Sebaliknya, platform lain menggunakan urutan terminal virtual untuk menangani aktivitas ini dan komunikasi terminal virtual itu sendiri melalui pustaka sisi klien yang dapat digunakan kembali, seperti readline dan ncurses. Terminal akhir hanya bertanggung jawab untuk menampilkan informasi dan menerima input melalui saluran komunikasi dua arah tersebut.
Dengan Konsol Windows, beberapa tindakan dapat dilakukan ke arah yang berlawanan dengan alami pada aliran input dan output. Ini memungkinkan aplikasi baris perintah Windows untuk menghindari kekhawatiran mengelola buffer mereka sendiri. Ini juga memungkinkan aplikasi baris perintah Windows untuk melakukan operasi lanjutan, seperti mensimulasikan/menyuntikkan input atas nama pengguna, atau membaca kembali beberapa riwayat apa yang ditulis.
Meskipun ini memberikan daya tambahan untuk aplikasi Windows yang beroperasi dalam konteks pengguna tertentu pada satu komputer, ini juga menyediakan vektor untuk lintas keamanan dan tingkat hak istimewa atau domain ketika digunakan dalam skenario tertentu. Skenario tersebut termasuk pengoperasian antara konteks pada komputer yang sama, atau di seluruh konteks ke komputer atau lingkungan lain.
Platform lain, yang menggunakan urutan terminal virtual, tidak mengizinkan aktivitas ini. Tujuan rekomendasi kami untuk transisi dari Konsol Windows klasik ke urutan terminal virtual adalah untuk bertemu dengan strategi ini karena alasan interoperabilitas dan keamanan.
Permukaan WINDOWS Console API menyediakan handel jendela yang tepat ke jendela hosting. Ini memungkinkan utilitas baris perintah untuk melakukan operasi jendela tingkat lanjut dengan mencapai gamut lebar API Win32 yang diizinkan terhadap handel jendela. API Win32 ini dapat memanipulasi status jendela, bingkai, ikon, atau properti lain tentang jendela.
Sebaliknya, pada platform lain dengan urutan terminal virtual, ada serangkaian perintah sempit yang dapat dilakukan terhadap jendela. Perintah ini dapat melakukan hal-hal seperti mengubah ukuran jendela atau judul yang ditampilkan, tetapi harus dilakukan dalam pita yang sama dan di bawah kontrol yang sama dengan sisa aliran.
Seiring berkembangnya Windows, kontrol keamanan dan pembatasan pada handel jendela telah meningkat. Selain itu, sifat dan keberadaan handel jendela yang dapat diatasi aplikasi pada elemen antarmuka pengguna tertentu telah berevolusi, terutama dengan peningkatan dukungan faktor dan platform bentuk perangkat. Ini membuat akses jendela langsung ke aplikasi baris perintah rapuh saat platform dan pengalaman berkembang.
UTF-8 adalah pengodean yang diterima untuk data Unicode di hampir semua platform modern, karena mencapai keseimbangan yang tepat antara portabilitas, ukuran penyimpanan, dan waktu pemrosesan. Namun, Windows secara historis memilih UTF-16 sebagai pengodean utamanya untuk data Unicode. Dukungan untuk UTF-8 meningkat di Windows dan penggunaan format Unicode ini tidak menghalangi penggunaan pengodean lain.
Platform Konsol Windows telah mendukung dan akan terus mendukung semua halaman kode dan pengodean yang ada. Gunakan UTF-16 untuk kompatibilitas maksimum di seluruh versi Windows dan lakukan terjemahan algoritma dengan UTF-8 jika perlu. Peningkatan dukungan UTF-8 sedang berlangsung untuk sistem konsol.
Dukungan UTF-16 di konsol dapat digunakan tanpa konfigurasi tambahan melalui varian W dari semua API konsol dan merupakan pilihan yang lebih mungkin untuk aplikasi yang sudah berpengalaman di UTF-16 dengan baik melalui komunikasi dengan wchar_t
varian W dan fungsi dan produk platform Microsoft dan Windows lainnya.
Dukungan UTF-8 di konsol dapat digunakan melalui varian A API Konsol terhadap handel konsol setelah mengatur halaman kode ke 65001
atau CP_UTF8
dengan metode SetConsoleOutputCP dan SetConsoleCP, sebagaimana mewajibkan. Mengatur halaman kode terlebih dahulu hanya diperlukan jika komputer belum memilih "Gunakan Unicode UTF-8 untuk dukungan bahasa di seluruh dunia" di pengaturan untuk aplikasi Non-Unicode di bagian Wilayah Panel Kontrol.
Catatan
Mulai sekarang, UTF-8 didukung sepenuhnya pada aliran output standar dengan metode WriteConsole dan WriteFile. Dukungan pada aliran input bervariasi tergantung pada mode input dan akan terus meningkat dari waktu ke waktu. Terutama mode "dimasak" default pada input belum sepenuhnya mendukung UTF-8. Status pekerjaan ini saat ini dapat ditemukan di microsoft/terminal#7777 di GitHub. Solusinya adalah menggunakan UTF-16 yang dapat diterjemahkan secara algoritma untuk membaca input melalui ReadConsoleW atau ReadConsoleInputW hingga masalah yang beredar diselesaikan.
Untuk semua pengembangan baru dan yang sedang berlangsung di Windows, urutan terminal virtual direkomendasikan sebagai cara berinteraksi dengan terminal. Ini akan menggabungkan aplikasi klien baris perintah Windows dengan gaya pemrograman aplikasi di semua platform lain.
Subset terbatas API Konsol Windows masih diperlukan untuk membangun lingkungan awal. Platform Windows masih berbeda dari yang lain dalam penanganan proses, sinyal, perangkat, dan pengodean:
Handel standar ke proses masih akan dikontrol dengan GetStdHandle dan SetStdHandle.
Konfigurasi mode konsol pada handel untuk memilih dukungan Urutan Terminal Virtual akan ditangani dengan GetConsoleMode dan SetConsoleMode.
Deklarasi halaman kode atau dukungan UTF-8 dilakukan dengan metode SetConsoleOutputCP dan SetConsoleCP.
Beberapa tingkat manajemen proses keseluruhan mungkin diperlukan dengan AllocConsole, AttachConsole, dan FreeConsole untuk bergabung atau meninggalkan sesi perangkat konsol.
Sinyal dan penanganan sinyal akan terus dilakukan dengan SetConsoleCtrlHandler, HandlerRoutine, dan GenerateConsoleCtrlEvent.
Komunikasi dengan handel perangkat konsol dapat dilakukan dengan WriteConsole dan ReadConsole. Ini juga dapat dimanfaatkan melalui runtime bahasa pemrograman dalam bentuk: - C Runtime (CRT): Stream I/O seperti printf, scanf, putc, getc, atau tingkat fungsi I/O lainnya. - C++ Standard Library (STL): iostream seperti cout dan cin. - .NET Runtime: System.Console seperti Console.WriteLine.
Aplikasi yang harus mengetahui perubahan ukuran jendela masih perlu menggunakan ReadConsoleInput untuk menerimanya diselingi dengan peristiwa utama karena ReadConsole saja akan membuangnya.
Menemukan ukuran jendela masih harus dilakukan dengan GetConsoleScreenBufferInfo untuk aplikasi yang mencoba menggambar kolom, kisi, atau mengisi tampilan. Ukuran jendela dan buffer akan cocok dalam sesi pseudoconsole .
Tidak ada rencana untuk menghapus API konsol Windows dari platform.
Sebaliknya, host Konsol Windows telah menyediakan teknologi pseudoconsole untuk menerjemahkan panggilan aplikasi baris perintah Windows yang ada ke dalam urutan terminal virtual dan meneruskannya ke lingkungan hosting lain dari jarak jauh atau di seluruh platform.
Terjemahan ini tidak sempurna. Ini mengharuskan jendela host konsol untuk mempertahankan lingkungan simulasi dari apa yang akan ditampilkan Windows kepada pengguna. Kemudian memproyeksikan replika lingkungan yang disimulasikan ini ke host pseudoconsole . Semua panggilan WINDOWS Console API dioperasikan dalam lingkungan yang disimulasikan untuk melayani kebutuhan aplikasi klien baris perintah warisan. Hanya efek yang disebarkan ke host akhir.
Aplikasi baris perintah yang ingin kompatibilitas penuh di seluruh platform dan dukungan penuh dari semua fitur dan skenario baru baik di Windows maupun di tempat lain oleh karena itu disarankan untuk pindah ke urutan terminal virtual dan menyesuaikan arsitektur aplikasi baris perintah agar selaras dengan semua platform.
Informasi selengkapnya tentang transisi Windows ini untuk aplikasi baris perintah dapat ditemukan di peta jalan ekosistem kami.