كيف نبحث في Windows

في قسم «أبحاث Windows» نتحقق من ادعاءات تقنية محددة. في كل مقال نشرح ما تحققنا منه، وفي أي ظروف، وعلى أي أنظمة تنطبق النتيجة.

وجود معامل، وتأثيره على عمل النظام، والزيادة في الأداء تتطلب أدلة منفصلة.

ما يُعتبر دليلًا

نستخدم عدة أنواع مستقلة من الأدلة:

1. التوثيق الأولي. وثائق Microsoft الرسمية، والمواصفات، وتوثيق الشركة المصنّعة للعتاد أو التطبيق.
2. الملاحظة الساكنة. علامات التنفيذ في إصدار محدد من المكوّن. هذه الملاحظة محدودة بالبنية المدروسة، وهي بحد ذاتها لا تثبت تنفيذ المسار أثناء العمل.
3. الملاحظة الديناميكية. أحداث النظام، وحالة المكوّنات، والتتبعات التي تم الحصول عليها في السيناريو الموصوف.
4. القياس المضبوط. مقارنة مقياس مختار مسبقًا عند تغيير معروف وعودة حالة متحقَّق منها.
5. إعادة الإنتاج. تكرار النتيجة في تشغيل مستقل، أو على نظام أو بنية أخرى.

لا تُنشر الطرق الداخلية لأتمتة الجمع والمعالجة. وهذا لا يغيّر شرط الكشف عن السؤال قيد التحقق، والتكوين، والمقاييس، وعدد التشغيلات، والقيود.

حالات المواد

الحالة	المعنى
موثَّق	السلوك موصوف في مصدر عام أولي.
مُلاحَظ	تم اكتشاف حدث أو حالة في البيئة المحددة.
مُقاس	تم الحصول على فرق رقمي وفق المنهجية الموصوفة.
مُعاد إنتاجه	تم تكرار النتيجة بشكل مستقل.
لم يُعَد إنتاجه	لم يُكتشف التأثير المعلن في الظروف المحددة.
بيانات غير كافية	المنهجية أو العينة لا تسمح بالاستنتاج.

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

كيف يُبنى التجربة

قبل القياس تُثبَّت:

• سؤال واحد قيد التحقق؛
• المتغير المستقل؛
• المقياس الأساسي ووحدته؛
• Windows build، والعتاد الجوهري، والتعريفات، وإصدارات التطبيقات؛
• عتبة ذات دلالة عملية؛
• طريقة إعادة الحالة الأصلية.

نقارن الحالة الأصلية والحالة المعدَّلة، ثم نتحقق من العودة. وعند الإمكان نبادل ترتيب التشغيلات المزدوجة. نضبط الإحماء، والتغذية، ودرجات الحرارة، والحمل الخلفي؛ وإذا تعذّر ذلك، نذكر القيد.

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

منصة click-to-photon الفيزيائية

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

يتكوّن المسار الأساسي كما يلي:

1. السلك ملحوم بخط الزر الأيسر في Logitech G PRO X SUPERLIGHT من الجيل الأول. الجبهة الكهربائية تُشغّل مؤقّت Arduino Uno.
2. تمرّ النقرة نفسها عبر متحكّم الفأرة، وUSB، وWindows، واللعبة، وقائمة العرض، وGPU، والشاشة.
3. مستشعر ضوئي مثبَّت على الشاشة يوقف المؤقّت عندما يتجاوز سطوع منطقة الاختبار عتبة مختارة مسبقًا.
4. نتيجة واحدة تحتوي على الفترة الكاملة click-to-photon بالمللي ثانية.

هذه البداية تتضمن عمدًا معالجة متحكّم الفأرة وclick debounce الخاص به، لكنها لا تتضمن الحركة الميكانيكية للزر حتى إغلاق التلامس. لا نطرح تأخير الفأرة من القيمة النهائية. في المنهجية الحالية للقياسات المستقلة لدى RTINGS يُذكر لـ G PRO X SUPERLIGHT مقدار 2.5 ms عبر الكابل و3.1 ms عبر receiver. إن click latency المقيس المنخفض يجعل هذه الفأرة جزءًا مستقرًا مناسبًا للمنصة، لكنه لا يحوّل النتيجة إلى تأخير صافٍ لـ Windows أو اللعبة.

يمكن لمتحكّم HID دقيق منفصل بصيغة Arduino Nano إرسال النقرات إلى Windows تلقائيًا. يُستخدم هذا المسار عندما يكون مطلوبًا إزالة فروق الضغط اليدوي وتكرار إشارة الإدخال بإيقاع مضبوط. وهو يجيب على سؤال آخر ولا يُخلط مع السلاسل التي تبدأ من خط الزر الفيزيائي للفأرة.

في CS2 تُستخدم خريطة workshop باسم BXLAT، حيث تُحدث النقرة تغيّرًا متوقعًا في منطقة الاختبار. ويُطبَّق سيناريو بصري مماثل في Valorant. يُثبَّت موضع المستشعر الضوئي، والدقة، ومعدل تحديث الشاشة، وحد FPS، ووضع display scaling، وpresentation mode، وعتبة الضوء على مدى السلسلة المقارَنة بأكملها.

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

تُجرى الأبحاث على هذه المنصة منذ عدة سنوات، وقد تغيّر شكل التخزين خلال هذه الفترة. في الجدول العام للقياسات التاريخية توجد سلاسل من 300 نقرة وسلاسل أقدم من 100. ولبعض الاختبارات القديمة حُفظت فقط AVG وSTDDEV وMIN وMAX؛ أما P90 أو الرسوم البيانية المفقودة فلا تُستعاد من المجاميع وتُوسم صراحةً بأنها غير متاحة. وستُنشر السلاسل الجديدة بإحصاءات موسّعة.

ما يُنشر في النتيجة

يحتوي المقال على:

• إجابة قصيرة؛
• الادعاء قيد التحقق؛
• نطاق البحث؛
• المنهجية وعدد التتبعات المستقلة؛
• قيم المقاييس والتشتت؛
• الاستنتاجات المؤكَّدة وغير المؤكَّدة؛
• المقاييس المستبعدة أو الملوَّثة؛
• القيود؛
• توصية عملية دون ضمان نتيجة مماثلة؛
• تأكيد عودة الحالة؛
• المصادر العامة الأولية وتاريخ التحقق.

إذا لم تؤكّد النتيجة توصية شائعة أو وظيفة من BoosterX، فيمكن نشرها مع ذلك. فوجود إعداد في المنتج ليس دليلًا على فعاليته.

كيف تتحقق بنفسك

جزء كبير من الملاحظات الديناميكية في أبحاثنا يمكن تكراره بأدوات عامة: Sysinternals ProcMon للتتبعات النظامية، وWinDbg مع رموز Microsoft العامة. يبدو مسار التحقق الأساسي كما يلي.

1. قراءة المعامل — ProcMon. افتح Options → Configure Symbols وحدّد خادم رموز Microsoft العام، لكي تُظهر المكدسات أسماء الوحدات والدوال. ثم أضف مرشّح Path contains — مثل SystemResponsiveness من HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Multimedia\SystemProfile. من أحداث القراءة يظهر هل تُقرأ القيمة، ومتى، وبأي عملية.
2. من يقرأ — مكدس الاستدعاء. النقر المزدوج على الحدث يفتح خصائصه؛ وفي تبويب Stack تظهر سلسلة الوحدات — وهذا هو «قارئ» المعامل. مثلًا، سلسلة من user32.dll إلى win32kfull.sys تعني أن النظام الفرعي Win32k مسؤول عن القيمة.
3. السلوك في وقت التشغيل — WinDbg. مع رموز Microsoft العامة يمكن وضع نقطة توقف على دالة من المكدس ورؤية كيف تُطبَّق القيمة المقروءة.
4. اختبارات اصطناعية. غيّر القيمة وقِس السلوك الملاحَظ. مثلًا، تُقاس فترات إدخال الفأرة باختبارات عامة لمعدل الاستطلاع.

الحد الصادق. لا يُنشر التحليل الساكن للملفات التنفيذية ولا التتبعات الكاملة في المقالات. المسار أعلاه يكرّر الجزء الديناميكي من ملاحظاتنا، لكنه لا يحل محل التحليل الساكن — فاستنتاجاته تتعلق بالبنية المدروسة.

حدود قياس التأخير

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

وبالمثل، زمن CPU لعملية منفصلة لا يساوي التأثير الكلي على FPS، وframetime، واستهلاك الطاقة، أو استجابة النظام. وتُتحقق هذه الاستنتاجات بمقاييس منفصلة.

حماية البيانات

لا تُنشر افتراضيًا ملفات ETL وPML وسجلات الأحداث وتفريغات الذاكرة وتصديرات Registry الأصلية. فقد تحتوي التتبعات النظامية على أسماء المستخدمين، والمسارات، وسطور الأوامر، والعناوين الشبكية، وبيانات حساسة أخرى. وتحذّر Microsoft من ذلك بشكل منفصل في شروط Sysinternals.

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

تصحيح الاستنتاجات

يتغيّر Windows والتعريفات والتطبيقات. يحصل كل مقال على تاريخ آخر تحقق ونطاق الصلاحية. وإذا تعارض قياس جديد مع استنتاج قديم، يُحدَّث المقال مع شرح السبب. ولا تُنقل النتيجة القديمة إلى بنية جديدة تلقائيًا.

الاستقلالية والعلامات التجارية

تُنشر الأبحاث بواسطة فريق BoosterX وقد تتعلق بوظائف المنتج. ويُراعى هذا التعارض المحتمل في المصالح من خلال فصل المنهجية والقيم المقيسة والقيود والنتائج السلبية عن التوصية المتعلقة بالمنتج.

BoosterX Wiki هو منشور مستقل وغير مرتبط بـ Microsoft Corporation ولا مصرَّح له ولا مدعوم ولا معتمد منها. تُستخدم أسماء Microsoft وWindows فقط للوصف الدقيق لموضوع البحث. لمزيد من التفاصيل: Microsoft Trademark and Brand Guidelines.

تاريخ التغييرات

• 2026-08-24: نُشرت المنهجية.
• 2026-09-20: أُضيف قسم «كيف تتحقق بنفسك»؛ وصُحّح رابط مصدر بيانات الفأرة.

آخر تحقق من المنهجية: 2026-09-20.