هذا حسب التصميم.

لدينا خطط لدعم إعداد تطبيق آخر ليكون بمثابة "المحطة الافتراضية" على نظام التشغيل Windows ، ولكن هذه الخطط لا تزال قاسية جدًا وهي في طور العمل.

سيتطلب هذا ميزة نظام التشغيل. أنا أقوم بتحديث العنوان لتمثيل تغيير نظام تشغيل المحطة الطرفية الافتراضي.

أعدت تسمية هذا لإضافة الكلمة الرئيسية [defterm] حتى النهاية حتى نتمكن من العثور عليها بسهولة في عمليات البحث. تظهر الكلمتان "افتراضي" و "محطة" بشكل مثير للقلق في كثير من الأحيان في هذا المستودع. :ابتسامة:

لدي فضول حول كيفية قيام ConEmu بهذا. بمجرد التثبيت ، تفتح كل نافذة cmd / ps / bash جديدة في ConEmu كعلامة تبويب جديدة

لدي فضول حول كيفية قيام ConEmu بهذا. بمجرد التثبيت ، تفتح كل نافذة cmd / ps / bash جديدة في ConEmu كعلامة تبويب جديدة

نفس الشيء هنا ، لست متأكدًا من الكيفية ولكن نأمل أن يتم تحديث Windows لدعم المحطة بالكامل.

لدي فضول حول كيفية قيام ConEmu بهذا. بمجرد التثبيت ، تفتح كل نافذة cmd / ps / bash جديدة في ConEmu كعلامة تبويب جديدة

قد يكون ConEmu (ab) باستخدام القدرة على تعيين مصحح أخطاء مخصص لعملية. أعتقد أن برنامج Process Explorer يقوم بنفس الشيء ليقوم "باستبدال" مدير المهام

كما يدعم Process Hacker "استبدال" مدير المهام .

لدي فضول حول كيفية قيام ConEmu بهذا. بمجرد التثبيت ، تفتح كل نافذة cmd / ps / bash جديدة في ConEmu كعلامة تبويب جديدة

قد يكون ConEmu (ab) باستخدام القدرة على تعيين مصحح أخطاء مخصص لعملية. أعتقد أن برنامج Process Explorer يقوم بنفس الشيء ليقوم "باستبدال" مدير المهام

AFAIR ، فقط يغير مفتاح التسجيل.

أيا كان ، ConEmu تمكن من القيام بذلك ، لذلك يجب على MST أيضًا.

يقوم ConEmu بحقن الخطافات (DLL) في عمليات محددة (مثل explorer.exe أو devenv.exe) لاعتراض إنشاء نوافذ وحدة تحكم جديدة ضمن هذه العمليات. يمكنك قراءة المزيد حول هذا الأمر في المستندات الرسمية: https://conemu.github.io/en/DefaultTerminal.html

كما هو مذكور في هذا الرابط ، هذه الطريقة هي مجرد قرصنة. إنه بالتأكيد ليس حلاً قابلاً للتطبيق لـ Windows Terminal.

لكنها تعمل. إن الوصول إلى نظام فرعي كامل يبسط شيئًا.

الفرق هو أن Windows Terminal هو أحد منتجات Microsoft الرسمية ، لذا فإن التوقع هنا هو أن الجهاز الافتراضي لن يتم تغييره باستخدام اختراق قبيح قابل للاستخدام ، ولكن سيتم دعمه أصلاً بواسطة Windows .

لا أعرف ما إذا كان هذا هو المكان المناسب لذكر ذلك ولكني أشعر أنه قد يكون مناسبًا.

لسبب ما في الوقت الحالي ، يبدو أن لكل من cmd وowershell أحجام خطوط ضخمة وأحجام نوافذ ضخمة تعتمد على كيفية إطلاقها ومن أين يتم إطلاقها. من قائمة البداية ، عبر المستكشف ، عبر Win + R ، إلخ.

عندما تصبح المحطة الجديدة هي الوضع الافتراضي ، فإنها:

1. هل لديك حجم خط وحجم متناسقين للنافذة؟
2. يجب أيضًا أن تكون المحطة الافتراضية من القيام بـ "فتح نافذة Poweshell هنا" وما إلى ذلك؟

فيما يلي بعض الأمثلة لتوضيح ما أعنيه.

بالترتيب ، تم إطلاقه من اختصار شريط المهام ، الذي تم إطلاقه من "فتح نافذة Powershell هنا" ، تم إطلاقه من كتابة "بوويرشيل" في إدخال عنوان مستكشف الملفات (لاحظ كيف يبدو الأمر الافتراضي مختلفًا أيضًا).

سيكون من الجيد أن توحد المحطة الطرفية كل هذا. إنه محبط للغاية.

lloydjatkinson شكرا! من المناسب قليلاً هنا ، لكن يكفي أن نقول:

• تحتوي وحدة التحكم على ثلاثة (!) (ونصف) أماكن مختلفة تقرأ الإعدادات منها
• المحطة بها واحد فقط (ونصف)

للإجابة على نقاطك المرقمة المحددة:

1. نعم ، تمامًا ، لأنه لا يوجد سوى مصدر واحد للحقيقة للإعدادات.
2. نعم ، هذا ما تتبعه هذه الميزة. إعادة التوجيه إلى Terminal في أي وقت يتم فيه تشغيل نافذة وحدة التحكم للاستخدام التفاعلي.

يبدو الموجه الافتراضي وكأنه يمثل أنك في دليل مختلف. بدء powershell من شريط العناوين في المستكشف يفعل ذلك في أي دليل تشاهده حاليًا.

عزيزي الفريق ، هل هذا لا يزال متوقفًا عن العمل المتأخر؟ الآن مع إصدار Powershell7 ، فإنه يزيد الطلب على سهولة الوصول إلى محطة حديثة قادرة على التعامل مع Powershell الصحيح.

1421 يفتح فقط PS5.1 في الوقت الحالي ولا يوجد خيار رسمي لتغيير ذلك

لقد تحدثت مع Steve Lee على Twitter وبالطبع سيكون من المفيد الترويج لاستخدام كل من المنتجين Terminal و Powershell في الإصدارات الأخيرة / الإصدارات الداخلية لعملاء Windows 10.

@ Karl-WE ، نخرج الإصدار 1 من الباب قبل أن نبدأ في النظر في التغييرات اللازمة لنظام Windows لدعم التسجيل والتعداد والتنفيذ لمضيفي وحدة التحكم البديلة (أو الأجهزة الطرفية التي ستستخدمهم)

نظرًا لأن هذا قد يتطلب على الأرجح بعض دعم واجهة برمجة التطبيقات ، فمن المحتمل أن يتم ذلك فقط كجزء من إصدار Windows كبير.

شكرا داستن لعملك الممتاز هنا. آمل أن يتم التواصل مع جهود الفريق المشترك مع فريقي Insider و Powershell ، ونتمنى لك التوفيق مع جداول الإصدار 1.0. ربما يمكننا تحقيق هذا في 20H2 مما يترك كل شخص 9 أشهر على الأقل.

آمل أن تتم إضافة هذا عاجلاً وليس آجلاً ، هل هناك أي حلول عمل غير رسمية؟

كن مطمئنًا أن هذه المشكلة كانت ستحتوي على مئات من تعليقات المجتمع التي تشكل جميع أنواع الحلول المجنونة إذا كان هناك أي ؛)

لدي فكرة عن بعض ملفات الخفافيش الأساسية:
قم بتشغيل ملف bat في الخلفية ثم أغلق نافذة cmd الافتراضية

START /B  wt cmd /c yourfile.bat
exit

كن مطمئنًا أن هذه المشكلة كانت ستحتوي على مئات من تعليقات المجتمع التي تشكل جميع أنواع الحلول المجنونة إذا كان هناك أي ؛)

لقد بدأت تشغيل cmd (والآن بوويرشيل ) من Win + R منذ عقود ، لكنني أقوم بإعادة تدريب نفسي بشكل مؤلم لكتابة wt بدلاً من ذلك. أعتقد أنه يمكنك تعليم حيل جديدة لكلب عجوز. ببطء. 😁

يعمل هذا بفضل الاسم المستعار لتنفيذ التطبيق wt.exe في٪ userprofile٪ \ AppDataLocalMicrosoftWindowsApps

مرحبًا يا فريق المستخدمين ، نظرًا لأن wt لديه الآن مجموعة جيدة جدًا من الخيارات وإعدادات json محددة مسبقًا وجزء يمكن تعريفه من قِبل المستخدم والذي يتضمن أيضًا الإعداد ، أي وحدة التحكم هي وحدة التحكم الافتراضية التي سيتم فتحها عند تشغيل wt - اعتقدت أنها ستكون كافية التقط جميع الخطط التقريبية (https://github.com/microsoft/terminal/issues/492#issuecomment-490092382) لالتقاط المحاولة التالية على الأقل:

تكامل Win + X.

كيف _فكر_ يمكنك تحقيق هذا:

• تواصل مع Jennifer Gentlemen وفريق الإعدادات
• أضف عنصر إعدادات جديدًا قادرًا على استبدال أو تحديث الإعداد التالي لبدء تشغيل wt بدلاً من powerhell أو cmd
• قم بتحديث ملف ADMX وفقًا لذلك حتى يمكن تعيينه عبر GPO أيضًا

• تحذير: الوزن يحتاج إلى التثبيت من قبل المستخدم

• يمكن للمستخدم استخدام خيار وحدة التحكم الافتراضية لتحديد ما سيتم فتحه افتراضيًا من هناك

مثل
"profiles": [ "defaultProfile": "{574e775e-4f2a-5b96-ac1e-a2962a402336}" { "guid": "{574e775e-4f2a-5b96-ac1e-a2962a402336}", "hidden": false, "name": "PowerShell 7", "source": "Windows.Terminal.PowershellCore", "useAcrylic": true }, ],

الإعدادات> التخصيص> شريط المهام

"استبدل Win + X cmd بـ بوويرشيل"

ربما تكون وجهة نظر ساذجة للمستخدم ، ومع ذلك لا أستطيع أن أتخيل أنه من الممكن تبديل cmd إلى Powershell في هذه المرحلة لسنوات حتى الآن ، ولكن دون اتخاذ خطوة صغيرة للأمام لاستبدال هذين العنصرين مرة أخرى بالوزن. ونعم ، سيكون من المنطقي بهذه الطريقة امتلاك وزن مع وبدون حقوق المسؤول ، وفقًا للإعداد الافتراضي ، فهو أيضًا لا يتم رفعه مثل أي وحدة تحكم أخرى (مع استثناءات قليلة)

هل يمكنك من فضلك توضيح سبب وجود الكثير من العمل الذي يتعين القيام به؟ ستكون البداية.

امتلاك خيار تطبيق طرفي افتراضي في الإعدادات> التطبيقات والميزات> التطبيق الافتراضي - يمكنني أن أفهم أن هذا يتطلب المزيد من العمل تحت غطاء المحرك. لقد راجعت مع NirSoft ShellExView أن هذا لا يمكن تحقيقه بسهولة في الوقت الحالي.

ومع ذلك ، فإن تغيير إعداد Win + X المذكور أعلاه هو بالفعل شيء موجود.
يرجى الانتباه إلى أن هناك أداة خارجية يمكنها تغيير قائمة Win + X إلى أي شخص يرضيه ، لكن مصدر التنزيل الذي سأفضله في الوقت الحاضر غير موثوق به.

يمكنك العثور على الأداة هنا ولكن يمكنك استخدامها على مسؤوليتك الخاصة
Win + X Menu Editor. محرر قائمة Win + X
من صنع سيرجي "Happy Bulldozer" Tkachenko
http://winaero.com
يستخدم هذا البرنامج شفرة مصدر أداة hashlnk
hashlnk من توقيع Rafael Rivera
http://www.withinwindows.com/

آمل أن يُسمح لي بنشر هذا المرجع وإلا يرجى إزالته. إذا كان بإمكاني تحميل التطبيق كملف مضغوط أو Onedrive ، فيرجى إبلاغي بذلك. لا يوجد أي تلميح إلى أنه لا يُسمح بتقليده في مكان آخر.

لقد حاولت بنفسي إضافة وزن إلى مجموعة جديدة في قائمة Win + X ولكن لسبب غير واضح ، فشل في القيام بذلك. تبدو الأذونات حول الحق. يمكنني إضافة أي ملف كارتباط باستثناء الأشياء من
٪ localappdata٪ MicrosoftWindowsApps (حتى مع المسار الكامل).

لدي فضول ما الذي يمنع هذا عن طريق التصميم. يبدو أن التطبيقات بها ملفات بحجم 0 كيلوبايت ونوع من الارتباط الرمزي؟ في إدارة المهام ، لا يمكنك أيضًا "فتح موقع" عملية الوزن. أظن أن هذه هي طبيعة محاكاة التطبيقات الافتراضية لتطبيقات MS. ينطبق أيضًا على ميزات أخرى مثل Edge Chromium و notepadS وما إلى ذلك.

بالنظر إلى هذه المعلومات والظروف ، قد أفهم الآن سبب صعوبة تحقيق هذا التغيير. لا يمكنك الوصول إليه من المستكشف ، ولكن يمكنك تشغيله من Win + R / search. كم هذا غريب.

لا يمكنك إضافة wt.exe مباشرة ، لأنه ليس "ملفًا حقيقيًا" ، ولكن إذا قمت بإنشاء اختصار لـ wt.exe ، فستتمكن الأداة من إضافته وستعمل بشكل جيد.

يمكنك قراءة المزيد عنها هنا: https://www.hanselman.com/blog/TotallyUnsupportedHacksAddWindowsTerminalToTheWinXShortcutMenu.aspx

إذا فهمت وظيفة WinX بشكل صحيح ، فإن Windows لا يقوم بالارتباطات حسب المسار فقط ، ربما لمنع الانتحال ولكن أيضًا إنشاء تجزئة للملف. نظرًا لأن جميع "التطبيقات" لا تحتوي على ملف ، فقد يكون سبب "لا يمكن فتحه" هو عدم القدرة على إنشاء التجزئة ، ربما ليس بسبب عدم القدرة على الوصول إليها / قراءتها.

شكرًا للإشارة thlacshanselman ، فهذا يجعل من الصعب فهم سبب عدم وجود طريقة رسمية. إن وجود اختصار لـ Ofc لملف ما يعرضك لخطر العبث به ، وهو ما يبدو أنه يتعارض مع فكرة التصميم الأصلية الخاصة بنظام WinX الذي لا يتم العبث به بسهولة.
يكمن الخطر في أن PUA / البرامج الضارة قد تغير الأهداف في هذه القائمة.

@ Karl-WE أردت فقط التأكد من أن الجميع على نفس الصفحة هنا. Windows Terminal هو تطبيق طرفي / وحدة تحكم - وليس قذيفة . Cmd و PowerShell عبارة عن قذائف . (راجع أيضًا: https://www.hanselman.com/blog/WhatsTheDifferenceBetweenAConsoleATerminalAndAShell.aspx )

لذا فإن إعداد Win + X (IMHO) غير ذي صلة بهذه المشكلة (لأنه يحدد الغلاف فقط ، وليس التطبيق الطرفي).

أنا أفهم تعريفك. في النهاية ، نظرًا للطلبات العديدة نفسها ، تساعد WinX في إنشاء Windows Terminal

• أكثر بروزًا ، والذي لا يمكن إلا أن يساعد في نجاحه وانتشاره وتكريم العمل الذي تم إنفاقه في نهاية المطاف.

• تساعد المستخدمين على جعل نظام shell الافتراضي المفضل لديهم أكثر سهولة.
  والتي قد لا تكون cmd أو PoSh 5.1 قابلة للتكوين في الوقت الحالي.

برؤيتها في ضوء ذلك ، ما زلت أتفق مع اختلافك الملحوظ ولكن الهدف في النهاية هو المساعدة في تسهيل الوصول إلى shell مع امتلاك ميزات أفضل للمحطة مقارنة بوحدة التحكم الافتراضية .

@ nu8 ستوافق على الأرجح على أن "استبدال نظام conhost بإصدار conhost الذي تم إنشاؤه من هذا المستودع" و "تشغيل Windows لمثيل Terminal تلقائيًا" هما شيئان مختلفان تمامًا ؛)

يستضيف هذا المستودع كلاً من مضيف وحدة التحكم _و الوحدة الطرفية. أحدهما يبني على الآخر ، لكنهما بالتأكيد ليسا نفس الشيء.

@ nu8 نظرًا للكم الهائل من الأشياء ، يتعين على DHowett مراجعتها وفرزها في بعض الأحيان ، ربما تكون هناك اختلافات. كما نقلت ، من الواضح أن 492 في الجدول الزمني جاءت قبل عام 1817 ويمكن أن تتغير الأشياء.
سيكون الأمر مزعجًا أكثر إذا نشره بطريقة أخرى. لكن مع ذلك:

والخبر السار هو: أنه على الجدول الزمني ، ولم يعد في التراكم

يرى

1 | المحطة الافتراضية | إذا تم إنتاج تطبيق سطر أوامر ، فيجب فتحه في Windows Terminal (إذا كان مثبتًا) أو الجهاز المفضل لديك
العدد: # 492
المواصفات: # 2080

المصدر: https://github.com/microsoft/terminal/blob/master/doc/terminal-v2-roadmap.md

DHowett أشكرك على عملك هنا ، لدي سؤال صغير:
هل تعتقد أننا يمكن أن نتوقع أن يتم طرح هذا في تحديث windows 20h2 أو 21h1؟ هل أنت على علم بأي عمل داخلي (على مستوى نظام التشغيل) يسير في هذا الاتجاه؟
أتفهم أن الخطط قد تتغير ، لكن ما زلت أشعر بالفضول :)

نحن الفريق الذي سيتعين عليه القيام بالعمل على مستوى نظام التشغيل لتمكين هذه الميزة ، لذلك سأكون مندهشًا جدًا إذا لم نكن على دراية بالعمل الذي يتم إنجازه لتمكين هذا.

ما زلنا نتجاوز الإصدار 1.0 من Terminal ، لذلك لم نبدأ بالفعل في هذا بعد. أود أن أقول أنه من غير المحتمل أن تهبط في 20H2 أو 21H1 ، مع الأخذ في الاعتبار أنه من المحتمل أن يكون علينا إنجاز الميزة (أو على الأقل وضع نماذج أولية) حتى الآن لإدخالها في أي من هذه الإصدارات.

أتساءل ما الذي سيأتي أولاً - إعداد defterm أو دعم تسريع وحدة معالجة الرسومات الكامل في WSL2 ، وعند هذه النقطة يمكننا فقط استخدام محطات Linux الأصلية بدلاً من ذلك ، على الأقل للتطوير الذي يمكن أن يكون افتراضيًا

نظرًا لأن هذه المشكلة بها عدد كبير جدًا من المشتركين ، فسوف أقفلها.
إذا كان لديك شيء تساهم به ويؤثر على الاتجاه الهندسي لهذه الميزة ، فيرجى مراسلتي عبر البريد الإلكتروني على العنوان الموجود في ملفي الشخصي على GitHub.