hello guys, I got an idea that I’d like to hear your insights about… windows NT kernel was a subsystem agnostic one in the past, it supported multiple subsystems (POSIX, OS/2, win32), but later the first 2 were removed and only win32 now exists..
but as far as I know NT kernel still has the logic to be subsystem agnostic, so can we make a custom subsystem for a windows that replaces win32 (some sort of a windows distro)?
I know I’ll need to interact with SMSS a lot and probably reverse engineer ALPC connections of SMSS and CSRSS that I should emulate
what recourses you suggest for me to study?
btw, the project is currently a private repo in github, but if I found interested people we can make a discord server and work on the project together!
hello again, after some search here are my ideas about how I’d actually do so:
according to “WDDM architecture” article in MS learn (I can’t share links unfortunately), the display stack in windows is as:
1- the kernel mode graphics driver, which is 3rd party supplied and differs from a company to another and even from a GPU to another
2- dxgkrnl.sys, this is an abstraction layer for kernel mode graphics driver, it (I assume and wish) has a stable API to interact with instead of the changing kernel mode graphics driver
3- win32k.sys, this is yet a wrapper for dxgkrnl.sys itself, it abstracts away the messy dxgkrnl.sys driver and shapes how the GUI works in windows, it handles windowing, menus, keyboard and mouse input, etc..
4- win32GDI and gdi32.dll, these are the user-mode start, they interact with kernel mode drivers and I suppose they use syscalls to do so.
so, for a custom subsystem that needs TTY and perhaps GUI in the future, I need a way to draw i the screen directly!
here is what I thought of:
I replace win32k.sys driver with my own, which will interact with dxgkrnl.sys driver via its interface such as “DXGKRNL_INTERFACE” structure (search for it in MS learn)
then I’ll make a DLL that interacts with my new driver, but I don’t know how to interact with it?
I’ll not be able to use syscalls, so should I use IOCTL?
No, they use ioctls. Everything uses ioctls. Unlike Unix, Windows is not based on syscall. The DeviceIoControl handler might use one to switch into kernel mode, but that’s about it.
Look, what’s the point of this? If subsystems were even remotely useful, Windows itself would be using them. It is not. WSL 1, which does an outstanding job of providing a Unix environment within Windows, uses a scheme that is similar to the old subsystem concept, but is NOT. More importantly, WSL 1 did not support GUIs at all, which tells you how hard it is to implement.
The subsystem interface is poorly documented, and any practical knowledge of it has long faded into the mists of antiquity. Give up. There are many more interesting projects you could tackle that have a future.
but this project is more like an experiment to learn windows internals, better to fair and understand exactly why this idea is impossible than just leaving it at all!
I’m reading windows internals 7th edition (part 1 & 2), and I’d really like if you provide some sources at least for why this idea will fail!
btw, I found this interesting structure: [gDxgkInterface Windows 10 2004/20H2 · GitHub ]
that I think may be useful, please provide your insights about it and whether it changes your opinion about the possibility of this idea!
Hesitant to answer since it could be considered off topic until Tim Roberts did it. So here is my answer.
Win32 is just a wrapper over NT API that abstracts away the complexity. In Windows NT there is no "C:" drive, there is "\Devices\Harddisk0\Partition0". It's all for "ease of use". C: is a symbolic link to the actual object. If you are going to make your own subsystem, you are going to have to figure out how to abstract (or not) NT API.
You'll be messing with GDI/Windows that calls into NT APIs or RPCs into smss/csrss. That's where its no longer NT (except NtUser* functions which are from win32k.sys). You'll realize all the real stuff happens in user-mode, not kernel mode. Take services as an instance. There is no such things as service in Windows NT. It's an illusion of RPCs into services.exe. That's part of Win32 too.
It won't be worth it. It's the legacy baggage under all the eyecandy you see.
I want to remind you Win32 internals is not Windows internals. This will not gain you knowledge or experience on developing Windows drivers. The book you are reading contains (as far as I remember) sections for session management and csrss. It might be useful to you, but that's it.
Also, you cannot replace Win32k without triggering PatchGuard.
thanks for your comment Mr. Staarblitz!
I know about the object nature of windows, the drive letters are just symbolic links to kernel objects, and services are nothing but processes connected to services.exe using RPC
however, this isn’t the point of the project, as whether a custom subsystem will use NT object paths instead of drive letters or whether it’ll have services-like logic or not isn’t the important part as far as I understand
the hardest part is actually getting that custom subsystem even loaded instead of win32k and csrss successfully and has access to different hardware devices
I think this is the bottleneck, if I could overcome it, everything else can be done manually!
I don’t even understand you goals here. The obsolete posix subsystem could function in parallel with the win32 subsystem. They both shared hardware devices. There wasn’t a partitioning of hardware into ‘posix’ vs ‘win32’. It was also very limited.
my goal is to make the most minimal windows installation by replacing csrss (win32) subsystem with a custom one, a simple TTY environment… why do that? for 2 reasons:
for learning
if I succeeded, it opens A LOT of opportunities for windows OS customization and optimization
Yes, it would be educational, but it’s not going to open up any opportunities, because no one else is going to use it. This can be shown by the fact that no one else has done so.
Now, I WILL point out that you have the option of writing NT Native applications, which go directly to ntdll.dll, and thus do not go through any of the existing subsystems. It’s quite possible you might be happier in that world. Indeed, if you WERE to write a subsystem, that application would be an NT Native application, so perhaps you should start there anyway.
why do you think no one will use it?
it opens the door for making “windows distros”!
everyone can make his own subsystem, and for toolchain support he can just be POSIX-compliant!
a minimal subsystem will be way more performant and customizable than the highly coupled win32!
of course it’ll be a native application, but I may link to other libs other than ntdll (e..g when replacing win32k -if I could- driver)
I’d like to know more about the usefulness of this idea!
Because no one will use it. If folks want to experiment, they’ll use Linux, where they have access to the source code and rights to distribution. They won’t use Windows, where the native API is undocumented and the kernel source code is proprietary. People use Windows because of the Win32 API.
You can’t make a Windows distribution because you can’t legally distribute the kernel. And, again, no one is asking for that.
thanks Mr. Tim
for the legal problems, I thought about the user giving a licensed, legal ISO image and a custom installer performs necessary modifications, what do you think about this approach?
and yeah, if someone want to experiment linux is a better place, but this doesn’t mean the idea as a whole is useless!
I think it still has benefits, at least taking benefit of NT kernel and executive (which are world-class and highly optimized) with a custom favor!
You'll end up giving up or banging your head to the walls.
NT isn't "highly optimized". Companies use Linux or BSDs when high performance is needed. Windows is used in businesses due to Active Directory and legacy baggage only.
That’s just religious nonsense. The NT kernel has had literally millions of man hours of programmer attention over its 36 year lifespan. Whether you happen to like it or not, the critical processes have certainly been “highly optimized”.
If you mean that windows has not been optimized for a specific workload, in the way that you can optimize a specific build of nix, then yes. On various nix builds you can alter the scheduler, reserve CPU cores for specific tasks and such. But at that point it is not a general purpose OS.
If you are talking about network services (daemons), it is hard to argue that it is possible to build a better performing one for a *nix platform. But it is certainly possible to write a poorly performing one for either platform
