on behalf of the user, by the name of laziness

 people tend to see engineering as a mysterious field only the chosen people can specialize in, today, as a software engineer, I'll spoil the truth we've been hiding from the entire world for centuries and centuries, thank me later :)

the truth is that engineering is just about laziness, all you need to be a good engineer is to be lazy, that's it!

in the very early days of computing, when there was no concept of "operating system", controlling computers and loading programs was the responsibility of a human, and it was a real job!
that human was called "operator"

programmers wrote code on punch cards and gave it to the operator, and then he gives it to the computer to process, when finished, he takes the output punch cards and hands them to the programmer to verify their code, and did so for anyone else using the computer

it was such a lazy and boring task to do, so engineers made an "operating system"... a special kind of program that automatically does the operator job, for people using the operating system, it'd sound like magic that a program can load arbitrary programs and execute them!

but under the hood, there is no such a thing like "dynamic", even now in 2026... at the hardware level there is no "dynamism"
the operating system is a higher-level layer than the human operator, it's an abstraction layer, and as any other abstraction layer, it restricts!

people were happy with that new magical program, but humans love to tinker, not a long time and they normalized this and looked for even easier ways to control transistors, so they made high-level programming language that have a runtime/interpreter/virtual machine that should be present with the program, instead of your program getting compiled to a specific CPU architecture and execution environment (like in C/C++), you need a whole intermediate layer between your program and the operating system!
for example in python, the interpreter abstracts the operating system, so you write python-compliant code once and send it to whoever has the interpreter with often some dependencies and you're sure that your program will run regardless of the operating system, CPU architecture, etc..

a good engineer is an engineer that does the job with the least possible work (LPW), I really want to coin this term just to be etched in history

the roadmap for nexus project

 month ago, I shared a project idea about windows subsystem customization, you can view it here.

here I'll share the roadmap splat to some phases:

1- phase 1: win32 familiarity:
I'll first read windows internals 7e book to get a high-level architectural overview of windows as a whole, and be familiar with win32 API and make some different and diverse application ideas that interact with different parts of windows ecosystem to have a good grasp of what I want to replace

2- phase 2: kernel mode, native applications and driver development

here I'll lower down the environment I work on to kernel mode and native applications, instead of building applications on top of win32 ecosystem and rather extend the ecosystem itself and build applications on top of my extensions, more similar to midipix project

3- phase 3: pivot to reactos and experimental PoC

I'll now work on my original idea for a custom environment subsystem but will make a simple PoC not a full blown environment subsystem, the goal here is to understand the mechanics of the tasks to make it easier to build the project on real windows NT, it's the sweep spot now to build the PoC on reactos since they're working on modern WDDM, DirectX graphics kernel and migrating to NT6.0

4- phase 4: the final task: building the actual project

here I'll start working on the actual project on real NT kernel, I'll build an installer that patches windows ISO image, build the actual environment subsystem, I'll rely a lot on reverse engineering here!

along the way, there will be a lot of theoretical knowledge I'll need, OS development theory, reverse engineering, driver development, etc...
I estimate this project to take about 4 years, and yeah it's a long period of time but this isn't an educational project I want to ship as fast as possible, it's a whole learning journey that will put me at the same tier with elite engineers :)

اللون الأحمر

 ..ليا وقت منشرتش بوستات هنا، ف حابب النهاردة أتكلم عن موضوع لطيف جا ف بالي

تخيل معايا فيه حد أعمى من أول ما اتولد، يعني مشافش أي حاجة ف حياته خالص

وأنا اديته تفاحة لونها أحمر

ف هو لمسها بايده وحس أنها تفاحة

ف قلت له دي تفاحة لونها أحمر

ف سألني يعني ايه لون "أحمر"؟

يعني ايه لون من الأساس؟

بتاع ايه ده؟؟

خليني أضرب مثال تاني يوضح الفكرة أكتر..

تخيل حد أطرش من يوم ما اتولد، وبنتواصل معاه بالإشارة

ف شغلت له أغنية لبيلي آيليش وقلت له بالإشارة أني مشغل أغنية، وأن المغنية صوتها أنثوي

ف سألني بالإشارة برضو، يعني ايه صوت "أنثوي"؟

يعني ايه صوت من الأساس؟

بيتحس ازاي يعني؟؟

أنا عارف أنك مقدرتش تجاوب على السؤالين دول، ولا أنا، ولا محدش ف الكوكب كله لحد دلوقتي قادر يشرح للأعمى الألوان أو للأطرش الأصوات!

الحاجة المشتركة بين المثالين دول، هي أن الإجابة عليهم مش حاجة منطقية أو نظرية، دي حاجة حسية، حاجة بتعتمد على حاسة مفقودة عند صاحب السؤال

وبما أنها مفقودة، مستحيل نقدر نجاوب عليهم!!

المشكلة دي هي مشكلة فلسفية اسمها "المشكلة الصعبة للوعي" أو:
the hard problem of consciousness
مشكلة محدش قدر يحلها لحد دلوقتي، وهي محيرة والتفكير فيها بيجيب صداع :)

the limits of imagination

a week ago, I got a very interesting idea that I'll explain and share here about windows environment subsystems

first, I want to explain 3 different terms that I'll use:

- environment subsystem:
an environment subsystem is responsible of exposing a subset of the native executive functionalities in a clean API called "subsystem DLLs", and it typically consists of a kernel-mode part, which is a driver that managed kernel-mode operations required for the environment subsystem to function, user-mode part, which is in most cases a process that takes notifications for different events (process creation/termination, threads creation/termination, etc..) that relates to this specific subsystem and subsystem DLLs which are the API of the environment subsystem that an application links against to use its functionality.

- application subsystem:
an environment subsystem can include more than application subsystem, for example, Windows (win32) environment subsystem includes GUI application subsystem, which manages GUI apps and CUI application subsystem (the console subsystem) which manages CUI applications.

- kernel/executive subsystem:
this is a part of the kernel or the executive layer that manages a specific layer of NT kernel, for example, the object manager subsystem which manages all the objects in the system, and DirectX graphics subsystem which manages DirectX technology.

historically speaking, NT kernel was designed to support multiple environment subsystems: OS/2, POSIX and win32, now only win32 exists and no support for other subsystems is officially maintained by Microsoft

my goal is to replace win32 environment subsystem (and as a consequence, its application subsystems) with a custom one, giving infinite freedom to customize windows while taking benefit of the extensive HAL (hardware abstraction layer) and hardware acceleration that Microsoft provides!

but this isn't easy nor I'm sure it's even possible, it requires syncing different parts of windows and communication with different applications... I'll call my theoretical environment subsystem "nexus", so let's talk about what should nexus do to get loaded as an environment subsystem instead of win32:

1- it should handshake with SMSS using ALPC IPC mechanism:
SMSS (session manager subsystem) is the first user-mode process created, and it's responsible of making the initial sessions and loading the environment subsystem registered in the registry under this key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystems

specifically, Required and kmode keys, Required field contains the major environment subsystem that should be loaded upon boot, and kmode contains the kernel mode part of it, there is another field called optional that contains the optional environment subsystem that'll be loaded on-demand, and it was used with POSIX environment subsystem

SMSS uses ALPC IPC mechanism (refer to this article and this lecture for more information about ALPC), any environment subsystem should interact with SMSS in a specific, undocumented message structure and order, nexus should replicate the communication between csrss.exe (the win32 environment subsystem user-mode process) and smss.exe

2- it should manage different hardware components:
NT kernel and its executive layer and different drivers are kernel-mode components, an environment subsystem should wrap all these messy components in a unified, clean API, win32 environment subsystem does this using win32k* drivers which manage the communication with DirectX graphics kernel driver (dxgkrnl.sys) and mouse and keyboard input, nexus should also make a similar driver, and the biggest hurdle in this layer isn't implementation details as much as its the design itself, because this layer is which defines the characteristics and features of the whole environment subsytem!

3- it should provide environment subsystem DLLs and application subsystems

the first one is easy, it'll be "yet another libc implementation and wrappers" style thingy, but the application subsystems are a major part of an environment subsystems, and designing a solid-yet-flexible application subsystems architecture isn't an easy task!

4- it shouldn't annoy patch guard

update:
I searched a bit about this, it seems like PatchGuard is an ally in this context!
if I understand well, PatchGuard scans the SSDT (and other structures) after loading the environment subsystem and takes its content as a reference, then periodically, and if it found any change, it'll immediately trigger a BSOD... but since the reference scan happens after loading the environment subsystem, I could register syscalls for nexusk driver in the second slot of SSDT, which win32k used to use, and PatchGuard should happily protect it from temper! turning to a world-class protection system for my own environment subsystem!!

disclaimer:

This idea is highly experimental and based on limited research. Many assumptions may be incorrect or incomplete.

However, if all components are handled correctly, it might be possible to:

• Boot the NT kernel
• Load a custom environment subsystem
• Render output via the graphics kernel
• Run a minimal user environment 

Motivation

Why attempt something like this?

1. Curiosity

Understanding Windows internals at a deep level.

2. Performance Potential

In theory, this could produce a system that is:

• Extremely minimal
• Possibly faster than Linux (I wish!)

3. Driver Model Advantage

Windows has a strong driver ecosystem, especially for GPUs.

goals:
these are the goals that I should achieve to say that this idea succeeded:
1- be able to load my environment subsystem components (kernel mode, user mode and environment subsystem DLLs) as the only environment subsystem.

2- be able to communicate with VidPN manager and dxgkrnl.sys and wrap them in a unified interface to manager display in the system

3- provide a C standard library implementation (both statically and dynamically linked libraries) to provide basic functionalities for user mode applications to work

3- make a basic TTY environment and shell with some coreutils to demonstrate the environment subsystem is capable of actually working and performing various operations.

sources:
here are some sources that I'm studying and I'd recommend:
1- windows internals 7th editions (part 1 and 2), these are the most valuable for understanding win32 environment subsystem in order to replace its functionalities
2- OSR forums articles, this is the place where you'll find a nerd explaining the exact problem you're facing and giving you the optimal solution for it anonymously 

3- react OS project source code (especially their implementation for smss and csrss), while they're still working on WDDM and dxgkrnl and still working on NT 5.2 (windows server 2003 version), their codebase is very important to clarify stuff even reverse engineering can't

4- dxg driver for linux (link), which provides a good interface to communicate directly with dxgkrnl.sys driver via IOCTLs, this is a definitive source of microsoft itself, no guesses or hacks and totally works with windows 11 and its graphics stack

5- Midipix project: this is a custom musl libc + POSIX API post built up on NT native API to make porting UNIX-targetted source code easier, it's a very rich source for NT native API reverse engineering

deep vibes <3

I'm obsessed with this kinds of vibes guys!!

microsoft MAY make a good thing, yeah, you read it correctly :)

 مع أني بكره ويندوز والتخلف اللي فيه، ولكني مش هظلمه وزي ما تكلم في بوست  بداية الطريق في نظام البطريق عن الحملة العالمية ضد ويندوز بسبب آخر قرارات أخدوها
بتكلم النهاردة عن مقال نزلوه تقدر تقرأه من هنا

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

المرة دي فيه اختلاف، كتبوا مقال كويس ولو كانت طريقة الكلام كالعادة
corporation slop
 وكلها كلام إنشائي بس لو طبقوها كويس ممكن التجربة في ويندوز تتحسن

أهم حاجة تكلموا عنها هي ال

personalization & customization
performance optimization

بالذات أول نقطة
قالوا أنهم وأخيراً هيضيفوا ميزة أنك تغير مكان التاسك بار وتخليه من فوق تحت يمين شمال أي اتجاه يعجبك
وقالوا أنهم بيغيروا ال
widgets

ويخلوها قابلة للتخصيص أكتر

وقالوا أنهم هيعملوا تحسينات ف الأداء والتخصيص لحاجتين مهمين:
start menu and taskbar
الحاجتين دول مبنيين على حاجة ف ويندوز اسمها:
explorer
وده على عكس ما الناس فاكرة مش مجرد الفايل اكسبلورر اللي بتتصفح منه الملفات
هو عبارة عن
shell
وبرضو على عكس ما الناس فاهمة فكرة الشيل، الشيل نوعين منها اللي بينفذ الأوامر في التيرمنال ومنها الشيل اللي ف ويندوز وهي المسؤولة عن واجهة المستخدم زي شريط المهام وستارت منيو
ومسؤولة عن أجزاء تانية في ويندوز
وبما أنهم هيعدلوها ممكن تبقى قابلة للتخصيص أكتر
هي أصلاً ممكن تبدلها وتستخدم حاجة زي كايرو شيل ابحث عنها على جيتهاب بس عموماً حلو أنهم يحدثوها
وكمان الشيل نفسها مبنية على:
dwm (desktop window manager)
وده الجزء المسؤول عن رسم الشاشة أصلاً
ولكنه للأسف مينفعش تبدله لأنه متداخل مع حاجات كتير ف ويندوز ولو بدلته بأي ويندو مانجير تاني مستحيل ويندوز يشتغل

لو خلوه ممكن يتبدل وعد مني بستخدم ويندوز جنب لينكس ومش بشيله بعد 3 ثانوي!

بيكون أكبر ميزة ف ويندوز وبعدها بيومين بتلاقي 100 مشروع اوبن سورس بيبدله بأداء أحسن وميزات أكتر بمليون مرة
ومش بعيد تلاقي مشروع كايرو شيل نفسه بقى شيل + ويندو مانجير في نفس الوقت

ف أنا فرحان بصراحة بالتصريح ده لأنه أول مرة يستجيبوا لمطالب الناس، وهما برضو مش بقيوا طيبين هما مجرد أن الناس خسرتهم فلوس بس على الأقل أحسن من لا شيء

هما قالوا بينزلوا تحديثات بالميزات الجديدة ل
windows insiders
وهو نسخة من ويندوز للتجربة واختبار الميزات الجديدة فيه مستخدمين بيستخدموها والنظام بيجمع بيانات ويبعتها لمايكروسوفت علشان يقيموا هل الميزات ينفع تتضاف ولا لا
يعني كام شهر مثلاً وبتتضاف لنسخة ويندوز الرسمية اللي احنا بنستخدمها
ننتظر ونشوف

the unified theory of things

for some reason, operating systems developers always try to abstract away everything to one thing and work with that thing!

like UNIX philosophy was "everything is a file".. literally everything, RAM, PC, processes, etc.. all treated as files despite their different nature!

today I discovered something, windows also has similar model.. it treats everything as an "object"

to see this in action we'll need to download WinObjEx tool from sysinternals.. it'll show you most of the objects on your machine

the specific objects I want to show you are those in global key in NT namespace.. this space contains objects such as your hard disk volumes, see this photo for example:

it shows that my PC contains 7 hard disk volumes, but the interesting part is their path.. it's "\Device\HarddiskVolumeX".. what is this?
and where is C: and D: drive letters we are used to?

well, this is a very hard truth but we were in a lifetime illusion, drive letters are just conventions from DOS days that windows pretends they're the hard disk reality, while they're just symbolic links to these paths!

want to see it in action??

this is the field of my D volume, and as you can see it's just a symbolic link for \Device\HarddiskVolume2!

another interesting question, if all hard disk volumes start with that \.. does this mean even NTFS is a tree-like filesystem?
yes!
at the very fundamental level, NTFS is pretty similar to root-based filesystems such as ext4!
the "root" of your hard disk in windows is \\?\, 
my C: volume for example has this path:
\\?\C:\

let's try to use "dir" command to list the D:\ volume, I'll try it both in pwsh core and cmd.exe, in cmd.exe.. it gave me this result:

as you can see dir command successfully identified this weird path and listed D:\ contents.. let's try it in pwsh:

sound weird.. this time it showed nothing, not even an error!

well, I couldn't find why this specifically happen, but I could solve it!

you just need to add -LiteralPath argument to dir command and it'll happily give you the list:
dir -LiteralPath "\\?\D:\"

it gave me similar list to that of cmd.exe!
maybe LiteralPath tells dir to not interpret the path and path it directly to NT native API?
I'm not really sure!

but I just wanted to conclude my post with 2 things:
1- NT kernel is an object-oriented kernel

2- drive letters are just symbolic links, and NTFS is root-based like ext4 filesystem.