我經常對 Windows 的控制台主機應用程式感到沮喪，尤其是剪貼簿工作得多麼笨拙、無自動寬度問題等conhost.exe。哪裡可以如果我要編寫自己的接口，我會找到有關必須實現的接口的更多資訊。
我不只是在尋找替代控制台，我已經使用了xtermCygWin。我正在尋找有關如何進行的信息代替Windows 的預設控制台視窗主機。
答案1
以下是一些不錯的控制台替代產品，它們比 cmd 更用戶友好。
如下所述，從 Windows 7 開始，所有這些 shell 都只是 conhost.exe 的接口，甚至是 powershell。有關詳細信息，請閱讀什麼是 conhost.exe 以及為何它會運行。
因此，下面的控制台僅替換了 cmd 所展示的 conhost 的預設視覺化介面，並且僅在直接作為程式呼叫時才有用。它們不能間接調用，就像執行控制台可執行檔（例如 diskpart）時一樣，因為這將調用 conhost，而 conhost 有自己的 I/O 介面和 API。
這是微軟所說的Windows 7 / Windows Server 2008 R2：控制台主機:
ConHost 代表了控制台應用程式 I/O 處理方式的永久變化。沒有登錄項目或群組原則設定可以強制 Windows 恢復到「舊模式」控制台行為。
結論是，如果你希望以比替換cmd介面更深層的方式替換控制台，那麼這是不可能的。微軟已經選擇這種設計作為一種安全措施，並且不會改變。
我能想到的改變 conhost 行為方式的唯一方法是在 conhost API 上設定全域系統掛鉤。我根本不知道這是否可能，而且到目前為止還沒有人做到過（或者如果他們做到了，他們也沒有告訴）。我也不相信微軟會讓你用駭客版本取代像conhost.exe這樣至關重要的系統檔案。
如果需要替換駐留在system32\cmd.exe中的cmd，則需要取得該檔案的所有權，然後重新命名它（cmd1.exe？），將控制台替換exe重命名為cmd.exe並與它工作所需的所有文件。如果替換控制台不支援 cmd 所支援的所有參數，這可能會導致問題。
適用於 .bat 檔案的另一種方法是將新控制台與它們關聯。為此，需要編輯註冊表項HKEY_CLASSES_ROOT\batfile\shell\open\command。看到這個文章了解一些細節。
以下是控制台清單：
答案2
有類似的程序安慰圍繞 cmd.exe 的內容可能可以為您提供所需的內容，但我還沒有看到任何完整的內容可以取代控制台系統。 AFAIK，大多數此類項目只是重定向 stdin/stdout/stderr，然後在 cmd.exe 周圍包裝一個更常見的 GUI，在後台隱藏實際的控制台視窗。
答案3
微軟已經發布了他們的 conhost.exe 原始碼（https://github.com/microsoft/terminal）。
此儲存庫中的控制台主機程式碼是 Windows 本身建置 conhost.exe 的實際原始程式碼。
所以現在你有機會在Windows 10中用你自己的Console Host替換預設的conhost.exe。https://github.com/microsoft/terminal/issues/1817）。
那麼微軟說OpenConsole的原始碼是來自conhost.exe，那我們可以直接用OpenConsole.exe取代conhost.exe嗎？這樣我們就可以獲得更好的預設控制台主機。
我嘗試了一下，效果很好。雖然OpenConsole被打包為UWP應用程序，但OpenConsole.exe實際上是一個普通的Win32視窗程序，可以透過雙擊其exe來運行。如果您完成了 x64 發行版本，您可以從terminal\bin\x64\Release\OpenConsole.exe 找到它。
然後，進入C:\Windows\System32，右鍵conhost.exe，“屬性”，編輯權限列表，賦予目前使用者「完全控制」權限。
然後，將 conhost.exe 重新命名為 conhost-old.exe，並將 OpenConsole.exe 複製到此處並將其重新命名為 conhost.exe。
打開任何控制台應用程式（powershell、wsl...）並享受您的新控制台。
也可以將 OpenConsole 原始碼移植到 Windows 7。
另外，微軟也在Windows 10中引入了Windows Pseudo Console API，讓開發者可以更優雅地開發第三方終端應用程式（是的，它是透過conhost.exe實現的，應該包含在微軟發布的程式碼中） 。
以下是 conhost.exe 實際上負責的事情：
（從https://devblogs.microsoft.com/commandline/windows-command-line-inside-the-windows-console/）
控制台的核心組件由以下部分組成（從下到上）：
ConDrv.sys – 核心模式驅動程式
- 在控制台和任何連接的命令列應用程式之間提供高效能通訊通道
- 在命令列應用程式和它們「附加」到的控制台之間來回傳送 IO 控制 (IOCTL) 訊息
- 控制台 IOCTL 訊息包含
- 表示針對控制台實例執行 API 呼叫的請求的數據
- 從控制台發送到命令列應用程式的文本
ConHost.exe – Win32 GUI 應用程式：
ConHost Core – 控制台的內部結構和管道
- API 伺服器：將從命令列應用程式接收的 IOCTL 訊息轉換為 API 呼叫，並將文字記錄從控制台傳送到命令列應用程式
- API：實作 Win32 控制台 API 以及控制台可以要求執行的所有操作背後的邏輯
- 輸入緩衝區：儲存使用者輸入產生的鍵盤和滑鼠事件記錄
- VT 解析器：如果啟用，則從文字中解析 VT 序列，提取從文字中找到的任何內容，並產生等效的 API 調用
- 輸出緩衝區：儲存控制台顯示幕上顯示的文字。本質上是一個 CHAR_INFO 結構的二維數組，其中包含每個單元格的字元資料和屬性（更多關於下面的緩衝區）
- 其他：上圖中未包含的包括從註冊表和/或捷徑檔案等儲存/檢索值的設定基礎架構。
控制台 UX 應用程式服務 – 控制台 UX 和 UI 層
- 管理螢幕上控制台視窗的佈局、大小、位置等
- 顯示和處理設定 UI 等。
- 泵入 Windows 訊息佇列，處理 Windows 訊息，並將使用者輸入轉換為按鍵和滑鼠事件記錄，並將它們儲存在輸入緩衝區中
答案4
我建議安裝電源外殼，這是 Microsoft 版本的 unix 終端，用於腳本、管道等，或者Microsoft Unix 服務（曾經被稱為SFU），它實際上是Windows 的整個Posix 子系統，直接在核心之上運行（即與WIN32 和Windows API 一起運行，而不是在其之上。再次強調，即它不是模擬的，它基本上是Unix）並且將允許您使用任何（好吧，大多數）*nix 技術和 shell。 Unix 服務沒有獲得更多關注真是遺憾。