Terminal: تبدو الكتابة داخل محطة WSL الافتراضية مذهلة ، فلماذا هي أفضل من أي تطبيق آخر؟

تم إنشاؤها على ١٤ ديسمبر ٢٠١٨  ·  8تعليقات  ·  مصدر: microsoft/terminal

عذرًا ، هذه ليست مشكلة ، ولكن بدلاً من ذلك ، إنها أكثر من اقتراح / طلب الرجاء عدم كسر كل ما فعلته مع محطة WSL الافتراضية (Ubuntu على وجه التحديد) التي تكون سريعة الاستجابة عندما يتعلق الأمر بعرض الأحرف على الشاشة بعد الضغط مفتاح.

تبدو الكتابة في محطة WSL الافتراضية وكأنك تكتب على الهواء. هناك نعومة غير موجودة في أي تطبيق Windows آخر ، ولا حتى notepad.exe . إذا شعرت أنه يحتوي على 10 مللي ثانية من تأخر الإدخال بدلاً من 75 مللي ثانية + لجميع Windows الأخرى (و 200-250 مللي ثانية + لمعظم التطبيقات المستندة إلى الإلكترون).

ما الذي يجعل محطة WSL تبدو أفضل من notepad.exe وهل سيشق تحسين واجهة المستخدم هذا طريقه إلى جميع تطبيقات Windows في المستقبل؟

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

Issue-Question Product-Conhost

التعليق الأكثر فائدة

أنا حقًا لا أمانع عندما يأتي شخص ما ويقرر أن يخبرنا أننا نقوم بعمل جيد في شيء ما. نسمع الكثير من الشكاوى كل يوم أن منشورًا مثل هذا يعد نسمة من الهواء النقي. شكرا على شكرك!

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

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

إلى حد كبير كل شيء آخر قمت بإدراجه يحتوي على نوع من الطبقة أو إطار العمل ، أو العديد من الطبقات والأطر ، عندما تبدأ في الحديث عن Electron و Javascript. نحن لا نفعل.

لدينا نافذة واحدة مجردة وغير خاصة للغاية مع عدم وجود عناصر تحكم إضافية ملحقة بها. نحصل على مفاتيحنا من أعلى بقليل من النواة نظرًا لأننا نعالجها من رسائل النافذة وليس من نوع من إطار عمل الأحداث الشائع إلى حد كبير في أي إطار عمل أكثر تعقيدًا لواجهة مستخدم غير نظامنا (WPF و WinForms و UWP ، إلكترون). ونقوم بإلقاء النص مباشرة على سطح النافذة باستخدام PolyTextOut من GDI بدون زخرفة.

حتى notepad.exe يحتوي على عناصر تحكم متعددة في نافذته على الأقل وربما (لم أنظر) يستخدم نوعًا من إطار عمل المكتبة في عنصر تحكم التحرير لمعرفة تخطيط النص الخاص به (والذي ربما يستخدم مكتبة أخرى إطار دعم التدويل ...)

بالطبع هذا يعني أيضًا أن لدينا مقايضات. نحن لا ندعم النص الدولي تمامًا مثل كل التطبيقات الأخرى. RTL؟ منطقة ممنوع الذهاب الآن. أزواج بديلة ورموز تعبيرية؟ نحن نصل إلى هناك ولكن ليس هناك بعد. نصوص هندية؟ لا.

لماذا نحب هذا؟ لأحد ، conhost.exe قديم مثل الأوساخ. يجب أن يستخدم الطبقة السفلية المعدنية العارية لكل شيء لأنه تم إنشاؤه قبل إنشاء معظم تلك الأطر الأخرى. وأيضًا يحافظ على أدنى مستوى / أدنى مستوى ممكن لأنه إلى حد كبير أول شيء يحتاج المرء إلى طرحه عند طرح إصدار أو جهاز جديد لنظام التشغيل قبل أن يكون لديك كل الأشياء اللطيفة مثل الأطر أو ما تتطلبه هذه الأطر العمل. كما أنه مكتوب بلغة C / C ++ وهي عبارة عن معدن منخفض وعاري كما يمكننا الحصول عليه.

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

هل سنحاول منعه من التراجع؟ نعم! في الوقت الحالي ، إنها نوع من العمليات اليدوية. نحدد أن شيئًا ما يتباطأ ثم نخرج WPR ونبدأ في أخذ الآثار. نحن نحدق في المسارات الساخنة ونحاول معرفة ما يجري ثم نقوم بتحسينها. على سبيل المثال ، في الدورة الأخيرة أو الدورتين الأخيرتين ، ركزنا على تخصيصات الكومة كمجال رئيسي يمكننا من خلاله تحسين أدائنا من البداية إلى النهاية ، وتغيير الكثير من التعليمات البرمجية لاستخدام واجهات مكدسة شبيهة بالتكرار على الطلب الأساسي المخزن المؤقت بدلاً من ترجمته وتخصيصه في مساحة كومة جديدة لكل مستوى من مستويات المعالجة.

جانبا ، يريد bitcrazed منا أتمتة اختبارات الأداء بطريقة معينة من conhost ، لكنني لم أتوصل إلى بيئة خاضعة للرقابة للقيام بذلك حتى الآن. يقوم نظام Windows Engineering System بإجراء اختبارات الأداء كل ليلة والتي تعطينا طريقة مبسطة لمعرفة ما إذا كنا قد أفسدنا شيئًا ما لنظام التشغيل بأكمله ، وهم يقدمون تقنيًا طريقة جيدة لإدخال اختبارات الأداء الخاصة بنا ... لكنني فقط لم يتم الوصول إلى ذلك بعد. إذا كانت لديك فكرة عن طريقة تمكننا من القيام بذلك بطريقة آلية ، فأنا آذان صاغية.

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

ال 8 كومينتر

أنا حقًا لا أمانع عندما يأتي شخص ما ويقرر أن يخبرنا أننا نقوم بعمل جيد في شيء ما. نسمع الكثير من الشكاوى كل يوم أن منشورًا مثل هذا يعد نسمة من الهواء النقي. شكرا على شكرك!

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

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

إلى حد كبير كل شيء آخر قمت بإدراجه يحتوي على نوع من الطبقة أو إطار العمل ، أو العديد من الطبقات والأطر ، عندما تبدأ في الحديث عن Electron و Javascript. نحن لا نفعل.

لدينا نافذة واحدة مجردة وغير خاصة للغاية مع عدم وجود عناصر تحكم إضافية ملحقة بها. نحصل على مفاتيحنا من أعلى بقليل من النواة نظرًا لأننا نعالجها من رسائل النافذة وليس من نوع من إطار عمل الأحداث الشائع إلى حد كبير في أي إطار عمل أكثر تعقيدًا لواجهة مستخدم غير نظامنا (WPF و WinForms و UWP ، إلكترون). ونقوم بإلقاء النص مباشرة على سطح النافذة باستخدام PolyTextOut من GDI بدون زخرفة.

حتى notepad.exe يحتوي على عناصر تحكم متعددة في نافذته على الأقل وربما (لم أنظر) يستخدم نوعًا من إطار عمل المكتبة في عنصر تحكم التحرير لمعرفة تخطيط النص الخاص به (والذي ربما يستخدم مكتبة أخرى إطار دعم التدويل ...)

بالطبع هذا يعني أيضًا أن لدينا مقايضات. نحن لا ندعم النص الدولي تمامًا مثل كل التطبيقات الأخرى. RTL؟ منطقة ممنوع الذهاب الآن. أزواج بديلة ورموز تعبيرية؟ نحن نصل إلى هناك ولكن ليس هناك بعد. نصوص هندية؟ لا.

لماذا نحب هذا؟ لأحد ، conhost.exe قديم مثل الأوساخ. يجب أن يستخدم الطبقة السفلية المعدنية العارية لكل شيء لأنه تم إنشاؤه قبل إنشاء معظم تلك الأطر الأخرى. وأيضًا يحافظ على أدنى مستوى / أدنى مستوى ممكن لأنه إلى حد كبير أول شيء يحتاج المرء إلى طرحه عند طرح إصدار أو جهاز جديد لنظام التشغيل قبل أن يكون لديك كل الأشياء اللطيفة مثل الأطر أو ما تتطلبه هذه الأطر العمل. كما أنه مكتوب بلغة C / C ++ وهي عبارة عن معدن منخفض وعاري كما يمكننا الحصول عليه.

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

هل سنحاول منعه من التراجع؟ نعم! في الوقت الحالي ، إنها نوع من العمليات اليدوية. نحدد أن شيئًا ما يتباطأ ثم نخرج WPR ونبدأ في أخذ الآثار. نحن نحدق في المسارات الساخنة ونحاول معرفة ما يجري ثم نقوم بتحسينها. على سبيل المثال ، في الدورة الأخيرة أو الدورتين الأخيرتين ، ركزنا على تخصيصات الكومة كمجال رئيسي يمكننا من خلاله تحسين أدائنا من البداية إلى النهاية ، وتغيير الكثير من التعليمات البرمجية لاستخدام واجهات مكدسة شبيهة بالتكرار على الطلب الأساسي المخزن المؤقت بدلاً من ترجمته وتخصيصه في مساحة كومة جديدة لكل مستوى من مستويات المعالجة.

جانبا ، يريد bitcrazed منا أتمتة اختبارات الأداء بطريقة معينة من conhost ، لكنني لم أتوصل إلى بيئة خاضعة للرقابة للقيام بذلك حتى الآن. يقوم نظام Windows Engineering System بإجراء اختبارات الأداء كل ليلة والتي تعطينا طريقة مبسطة لمعرفة ما إذا كنا قد أفسدنا شيئًا ما لنظام التشغيل بأكمله ، وهم يقدمون تقنيًا طريقة جيدة لإدخال اختبارات الأداء الخاصة بنا ... لكنني فقط لم يتم الوصول إلى ذلك بعد. إذا كانت لديك فكرة عن طريقة تمكننا من القيام بذلك بطريقة آلية ، فأنا آذان صاغية.

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

بالحديث عن واجهات برمجة تطبيقات Windows ذات المستوى المنخفض ، وجدت أن كل مكونات وضع المستخدم _ لكل من وحدة التحكم (conhost.exe ، cmd.exe ...) و WSL (wsl.exe ، LxssManager.dll ...) تستخدم C ++ _STL_ بشكل كبير. على سبيل المثال ، في معالجة السلسلة وتخصيص الذاكرة والجداول الافتراضية وما إلى ذلك ، هل سيكون هناك أي تحسين في الأداء إذا تم استخدام لغة C فقط؟

لن أعتبر هؤلاء يستخدمون C ++ STL "بشكل كبير". إنهم بالتأكيد يستخدمون بعض المجموعات وربما القليل من التلاعب بالسلسلة وخوارزمية هنا أو هناك. أشعر أن هناك الكثير في STL من تلك القطع القليلة.

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

الأمان هو في الواقع السبب الرئيسي وراء استخدامنا لقوالب STL بدلاً من محاولة صياغة الهياكل الخاصة بنا كلما أمكن ذلك. إن استخدام قوالب STL للمجموعات والسلاسل يمنحنا عمومًا إمكانية التحقق من الحدود التي كان يجب القيام بها يدويًا بطريقة معرضة للخطأ (أو عدم القيام بذلك على الإطلاق!)

كما أنني لست متأكدًا تمامًا من أن وجود 17 قائمة انتظار مختلفة وتنفيذ قائمة مرتبطة داخل رمز وحدة التحكم عندما كان C مستقيمًا كان أفضل بشكل عام للأداء من استخدام std :: queue و std :: list اليوم. من المحتمل أنها استهلكت مساحة أكبر على القرص لكل تطبيق فردي وهو نوع مختلف من مشكلات الأداء (التخزين وإدخال / إخراج تحميل الصفحة).

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

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

نتطلع حقًا إلى الإصدارات المستقبلية التي تجعل سمات الألوان أكثر توافقًا والخصائص المتعلقة بالتحسينات مثل مفاتيح الاختصار للتكبير +/- على حجم الخط.

miniksa : شكرا على

نحن نستخدم الرتق بالقرب من أقدم وأقل واجهات برمجة التطبيقات التي يجب على Windows إنجاز هذا العمل.

كنت أشعر بالفضول حيال هذا لفترة من الوقت. يبدو أنك تشير إلى Win32 APIs (USER32 / GDI32). لقد أصبحت مؤخرًا غير متأكد مما إذا كانت لا تزال منخفضة المستوى كما يمكن للمرء الحصول عليها في الإصدارات الحديثة من Windows (8.0 والإصدارات الأحدث) ، أو ما إذا كانت واجهات برمجة التطبيقات هذه قد تم تحويلها بصمت لتكون فوق العناصر الأخرى (مثل Direct2D ، DirectWrite وما إلى ذلك). كيف ترتبط واجهات برمجة التطبيقات الأقدم بالواجهات الأحدث؟ سأحب لو استطعت توضيح هذا الشيء!

stakx ، أشير إلى USER32 و GDI32.

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

بالنسبة للجزء الرسومي من خط الأنابيب (GDI32) ، تكون أجزاء وضع المستخدم من GDI منخفضة جدًا. يستدعي التطبيق GDI32 ، ويتم بعض العمل في DLL هذا من جانب وضع المستخدم ، ثم ينتقل استدعاء kernel إلى kernel ويحدث الرسم.

الجزء الذي تفكر فيه بخصوص "تحويله بصمت إلى أعلى العناصر الأخرى" هو على الأرجح أنه بمجرد وصولنا إلى مكالمات kernel ، تميل مجموعة من عناصر GDI للنواة إلى إعادة تشغيلها فوق نفس العناصر مثل DirectX عندما يتم التعامل معه فعليًا بواسطة NVIDIA / AMD / Intel / إلخ. برنامج تشغيل الرسومات ووحدة معالجة الرسومات في الجزء السفلي من المكدس. أعتقد أن هذا حدث مع إعادة هندسة برنامج تشغيل الرسومات التي جاءت كجزء من WDDM لنظام التشغيل Windows Vista. هناك مستند موجود في مكان ما حول المكالمات التي لا تزال سريعة حقًا في GDI والتي تكون أبطأ نتيجة لإعادة النظام الأساسي. آخر مرة عثرت فيها على هذا المستند ودققت فيه ، كنا نستخدم الملفات السريعة.

علاوة على GDI ، أعتقد أن هناك أشياء مثل Common Controls أو comctl32.dll والتي وفرت للأشخاص مجموعات قابلة لإعادة الاستخدام من الأزرار والعناصر لإنشاء واجهات المستخدم الخاصة بهم قبل أن يكون لدينا أطر تعريفية أجمل. نحن لا نستخدم تلك الموجودة في وحدة التحكم حقًا (باستثناء صفحة الخصائص الموجودة في قائمة النقر بزر الماوس الأيمن).

بالنسبة إلى DirectWrite و D2D و D3D و DXGI أنفسهم ، فهي مجموعة منفصلة من الأوامر والمسارات التي تكون بعيدة تمامًا عن الجانب من GDI على الإطلاق في وضع المستخدم والنواة. إنها ليست مرتبطة حقًا بخلاف أن هناك بعض أحكام التشغيل البيني بين الاثنين. تميل معظم أطر عمل واجهة المستخدم الأخرى إلى أن تكون مبنية على قمة مكدس DirectX. XAML مؤكد. أعتقد أن WPF. لست متأكدا من WinForms. وأعتقد أن مكدس التكوين ومدير النوافذ يستخدمان DirectX أيضًا.

بالنسبة إلى جزء الإدخال / التفاعل من خط الأنابيب (USER32) ، أميل إلى العثور على معظم الأشياء الأحدث الأخرى (على الأقل لأجهزة الكمبيوتر المكتبية) مبنية على ما هو موجود بالفعل. المفهوم الرئيسي لـ USER32 هو النوافذ ومقابض النوافذ ويتم إرسال كل شيء إلى مقبض النافذة. طالما أنك تستخدم جهاز سطح مكتب (أو كمبيوتر محمول أو أي شيء آخر ... أعني جهازًا يعمل بنظام Windows على الطراز الكلاسيكي) ، فهناك مقبض نافذة متضمن ورسائل تطفو وهذا يعني أننا نتحدث عن USER32.

قائمة انتظار رسائل النافذة هي مجرد قائمة انتظار مباشرة (أكثر أو أقل) لأي إدخال حدث ذي صلة بتلك النافذة أثناء وجودها في المقدمة + كل ما تم إرساله إلى النافذة بواسطة مكونات أخرى في النظام.

تميل التقنيات الأحدث وأطر العمل مثل XAML و WPF و WinForms إلى تلقي الرسائل من قائمة انتظار رسائل النافذة بطريقة أو بأخرى ومعالجتها وتحويلها إلى عمليات استدعاء حدث لكائنات مختلفة قاموا بتوفيرها في عالمهم.

ومع ذلك ، فإن التقنيات الأحدث التي تعمل أيضًا على منصات أخرى غير سطح المكتب مثل XAML تميل إلى امتلاك القدرة على معالجة الأشياء من مكدس مختلف تمامًا بخلاف USER32. هناك حزمة موازية منفصلة لـ USER32 مع جميع ابتكاراتنا وإدراكنا الجديد حول كيفية حدوث المدخلات والتفاعل الذي لا يتعامل تمامًا مع قوائم انتظار الرسائل الكلاسيكية ومقابض النوافذ بنفس الطريقة. هذه هي مجموعة Core * الكاملة لأشياء مثل CoreWindow و CoreMessaging. لديهم أيضًا مفهوم مختلف لـ "ما هو المستخدم" الذي لا يتمحور حول مؤخرتك في كرسي دوار أمام شاشة مع لوحة مفاتيح وماوس على المكتب.

الآن ، إذا كنت تستخدم XAML أو أحد الأطر الأخرى ... فسيتم التعامل مع كل هذا التعقيد من أجلك. يكتشف XAML كيفية الاعتماد على DirectX نيابة عنك ويتفاوض مع المؤلف ومدير النوافذ للحصول على تأثيرات رائعة نيابة عنك. إنه يكتشف ما إذا كنت ستحصل على أحداث الإدخال الخاصة بك من USER32 أو Core * أو أي شيء بشفافية اعتمادًا على النظام الأساسي الخاص بك ويمكن لمكدسات الإدخال التعامل مع القلم واللمس ولوحة المفاتيح والماوس وما إلى ذلك بطريقة موحدة. يحتوي على أحكام مضمنة بداخله للقيام بجميع أنواع العولمة ، وإمكانية الوصول ، وتفاعل الإدخال ، وما إلى ذلك من الأشياء التي تجعل حياتك سهلة. ولكن يمكنك اختيار الانتقال مباشرة إلى المستوى المنخفض والتعامل معه بنفسك أو تخطي التعامل مع ما لا تهتم به.

الحيلة هي أن GDI32 و USER32 تم تصميمهما لعالم محدود مع مجموعة محدودة من الأوامر. كانت أجهزة الكمبيوتر المكتبية هي الشيء الوحيد الموجود ، مستخدم واحد على لوحة المفاتيح والماوس ، وإخراج رسومات بسيط لشاشة VGA. لذا فإن استخدامها مباشرة على "المستوى المنخفض" كما يفعل conhost أمر سهل للغاية. يمكن استخدام الأنظمة الأساسية الجديدة على "المستوى المنخفض" ولكنها أوامر من حيث الحجم أكثر تعقيدًا لأنها تمثل الآن كل ما حدث مع الحوسبة الشخصية في أكثر من 20 عامًا مثل عوامل الشكل المختلفة والمستخدمين النشطين المتعددين ومحولات الرسومات المتعددة ، و مرارا وتكرارا. لذلك أنت تميل إلى استخدام إطار عمل عند استخدام الأشياء الجديدة حتى لا ينفجر رأسك. إنهم يتعاملون معها من أجلك ، لكنهم يتعاملون معها أكثر من أي وقت مضى ، لذا فهم أبطأ إلى حد ما.

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

على أي حال ، هذا يكفي للتجول في صباح واحد. نأمل أن يكون هذا قد أجاب إلى حد ما على أسئلتك وأعطاك المزيد من البصيرة.

نأمل أن يكون هذا قد أجاب إلى حد ما على أسئلتك وأعطاك المزيد من البصيرة.

miniksa ، لقد فعلت بالفعل! منطقي تمامًا أيضًا. شكرًا جزيلاً لك على الوقت الذي قضيته في كتابة ذلك كله! : +1:

سأغلق هذه القضية الآن. شكرا على الاستفسار ويسرني أنك استمتعت بالمعلومات.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات