I'm far from an expert in this, but from my understanding, the NT kernel itself isn't "bad", and does some things better than Linux/other Unix-like kernels (and vice versa). I'd see Microsoft open...
I'm far from an expert in this, but from my understanding, the NT kernel itself isn't "bad", and does some things better than Linux/other Unix-like kernels (and vice versa).
I'd see Microsoft open sourcing the NT kernel (maybe going to a model similar to Apple with XNU and their various OSes) before switching to being fully Linux-based internally. So much of their business is built on backwards compatibility, and the amount of hardware out there, especially in some specialty environments, that only has Windows drivers that can't be covered by Wine or a Wine-esque solution, would preclude a full kernel switch.
Unless they developed a kernel module that could act as a shim to enable Windows drivers (and I imagine the amount of work required to get that working to be significant), they'd be shooting themselves in the foot IMO.
Getting all the Windows drivers to work natively in the Linux kernel would certainly be an inordinate amount of work. Windows supports a large amount of hardware. As for fork, Microsoft seems to...
Getting all the Windows drivers to work natively in the Linux kernel would certainly be an inordinate amount of work. Windows supports a large amount of hardware.
As for fork, Microsoft seems to agree that it’s a hack, and just not worth it. There is posix_spawn that does what you actually want to do 99% of the time with fork/exec, and the last 1% may not be worth it. There’s a lot of historical choices made that were sensible at the time, but later became enshrined as eternal wisdom in order to justify their continued existence even when they seemed more costly than elegant. Windows surely has a lot of these, being ultra-backwards compatible, but Linux certainly does as well, being spiritually compatible with an even older OS.
fork() is quite a terrible primitive; it does a lot of work under the hood that's almost perfectly contrary to the KISS principle. Ideally you'd use posix_spawn or other calls that let you adjust...
fork() is quite a terrible primitive; it does a lot of work under the hood that's almost perfectly contrary to the KISS principle. Ideally you'd use posix_spawn or other calls that let you adjust how memory, resources and everything else is handled. Because 99.99% of the time the defaults that fork uses are bad for performance or security and only in 0.01% of cases (being shell scripts being run by a shell spawning a subshell), you want what fork() does.
"Everything is a file" has also turned out to be not quite that useful. The modern Linux driver stack uses a file to access the GPU, but only really to get the resource handle, then everything moves to special ioctl() calls and memory mapping because files are terrible at being able to do what a GPU does.
Even a simple printer already has different primitives to a file (can't read, can't seek, only write), so IMO Windows isn#t entirely wrong in making these things a separate API that can be more clear and powerful without having to to haggle yourself through the filesystem.
Of course, not to detract, some parts of Windows OS are fairly terrible, yes.
The unix process model is overloaded IMO, it could be much much simpler (only tasks, making them lightweight enough that they can double-duty as threads or process), then you can build more...
The unix process model is overloaded IMO, it could be much much simpler (only tasks, making them lightweight enough that they can double-duty as threads or process), then you can build more complex models on top that suit your needs. In that model, fork() would be a heavy handed function with no purpose other than sugaring much more low level process creation (in Linux, the fork() syscall simply runs the appropriate proper syscalls in the background. There is no native fork() in the Linux process model).
And I hate to be that guy, but plan9 might be functional and have some good ideas, but it's terrible and writing drivers for plan9 is even more terrible because files are simply not a good abstraction for anything but actual files in a filesystem on a disk. Even networked filesystems like NFS start to creak the model of "everything is a file".
Similar LISP might be powerful and one of the most beautiful languages concepted but the reality is simply that most people don't use it, even after they grasp the concept because other languages provide better models out of the box.
The reason the GPU is access with ioctl's and memory mapping is becase the performance of read()+write() is not nearly sufficient to shovel multiple gigabytes per second to the GPU, as is necessary to drive modern GPUs. A GPU is not a printer, it's an entirely self-contained computer that must be entirely controlled by the driver to work properly. It doesn't even remotely work like a normal CPU, hence a simple file operation already doesn't cover what is necessary.
You can do that properly by blocking syscalls like seek() or open() (optionally only blocking non-appending modes) or remove() so that you can only write to the end of the file.
You can do that properly by blocking syscalls like seek() or open() (optionally only blocking non-appending modes) or remove() so that you can only write to the end of the file.
Yeah but a printer is not a file, it's a machine. A teletyper behaves like a file, a printer does not. Modern printers have many more functions than "print text to file".
Yeah but a printer is not a file, it's a machine.
A teletyper behaves like a file, a printer does not.
Modern printers have many more functions than "print text to file".
Yep. They have a read, no seek file, to scan and receive faxes; a write, no read/seek to send faxes; and a read and write file for status and job control.
Yep. They have a read, no seek file, to scan and receive faxes; a write, no read/seek to send faxes; and a read and write file for status and job control.
You can't receive faxes from a read-only file because it requires negotiation of the image format and metadata. Sending faxes is also quite the dance to dial the phone number and push the data...
You can't receive faxes from a read-only file because it requires negotiation of the image format and metadata. Sending faxes is also quite the dance to dial the phone number and push the data through.
Job Control isn't handled by a computer unless you use a print server, which doesn't handle job control on the printer but on the server itself.
Any of those will require developing a protocol for interacting with the file, which kind of makes the entire thing have at least three times as much overhead as necessary if it just had the appropriate API.
You do know most of those happen with a read write socket, right? And hardware handles the faxing the negotiation dance. Otherwise, from the PC side... it's just an input device.
You do know most of those happen with a read write socket, right?
And hardware handles the faxing the negotiation dance. Otherwise, from the PC side... it's just an input device.
It's still there, both in new incarnations and in old. The new version is used for fast snapshotting of processes: they basically suspend a process, fork it, resume the parent, and then capture a...
It's still there, both in new incarnations and in old. The new version is used for fast snapshotting of processes: they basically suspend a process, fork it, resume the parent, and then capture a minidump from the child.
NtCreateProcess has always been able to have fork semantics as well.
I've actually been able to fork a Win32 process with a lot of hacking around (enough to throw up a MessageBox in the child process, at least), but since the Win32 subsystem is all closed source and undocumented, I'd never use it in production code.
Yes, RtlCloneUserProcess() is the new fork-ish system call that is used by the snapshotting stuff. For NtCreateProcess, you just specify the ParentProcess handle. Provided that the handle has the...
Yes, RtlCloneUserProcess() is the new fork-ish system call that is used by the snapshotting stuff.
For NtCreateProcess, you just specify the ParentProcess handle. Provided that the handle has the right access, the created process inherits its address space. When you create the child process's initial thread using NtCreateThread, you can base its stack and context on your own thread's.
As for Win32, there are a few issues:
Most of USER and GDI are implemented in the kernel via the win32k.sys driver. That driver does not expect a fork, so it can't automagically recognize the new process.
This is not as well known, but technically CSRSS.exe is a user-mode component of Win32. A forked process needs to register itself with CSRSS.
** As an aside, this one of the myriad reasons why UWP should be considered to be a layer atop Win32, as opposed to a distinct subsystem; UWP depends on DCOM, MSRPC, and thus CSRSS, which are all Win32 components.
Finally, KERNEL32.DLL, USER32.DLL, and GDI32.DLL are not fork-aware, so they contain per-process and per-thread data that, if reused, will trigger hangs and/or crashes. This is because they were initialized from the parent process. To get a working Win32 fork, you need to write code to clear all of that internal state and essentially reinitialize them from scratch.
This was done for one sector of drivers already: ndis-wrapper. This packages took windows wifi device drivers, wrapped then, and then acted as a kernel shim. If companies did the work themselves,...
Unless they developed a kernel module that could act as a shim to enable Windows drivers (and I imagine the amount of work required to get that working to be significant), they'd be shooting themselves in the foot IMO.
This was done for one sector of drivers already: ndis-wrapper. This packages took windows wifi device drivers, wrapped then, and then acted as a kernel shim.
If companies did the work themselves, porting their drivers over would be rather easy. Of course, they would only do this themselves, mostly, if Windows required it.
I feel like I'm reading a fake alternate-universe article. Windows 11? What!? There's no Windows 11. Microsoft has explicitly stated 10 is the endless version of windows. That's like asking Apple...
I feel like I'm reading a fake alternate-universe article. Windows 11? What!? There's no Windows 11. Microsoft has explicitly stated 10 is the endless version of windows. That's like asking Apple for OSXI... an entire-OS refresh doesn't make sense any more. Regardless of what marketing buzzwords make you think, "rebuilt from the ground-up" is a waste of time in today's industry.
I'll start taking these delusional ravings remotely seriously when authors try to analyze what it would be like to implement the driver stack, the graphics stack, the security model etc. on top of a different kernel, and demonstrate that it would change anything for the best. And not just throw away compatibility with twenty years of accumulated software and hardware.
So far it's only “MS did a Linux-to-Win layer with questionable performance, it means they could totally do the opposite with negligible loss while keeping drivers for millions of device models working! And compatibility with software that hooks at every point in the Windows APIs! See, Wine does a small portion of that just fiiiine after the twenty six years of development.”
Windows has had a POSIX subsystem for quite some time. Can even handle NFS mounting. MS could take a whole, huge step forward by keeping the Explorer DE, and rewriting it under the hood into a...
Windows has had a POSIX subsystem for quite some time. Can even handle NFS mounting.
MS could take a whole, huge step forward by keeping the Explorer DE, and rewriting it under the hood into a POSIX kernel. MacOS even retained compatibility as well for a similar move to a POSIX kernel with the move from System 9 to OSX.
They had a full native GNU stack as well, called it services for unix. It was predictably hamstrung (no BASH/SSH, for example), and so Cygwin eventually outpaced it. It's been discontinued.
They had a full native GNU stack as well, called it services for unix. It was predictably hamstrung (no BASH/SSH, for example), and so Cygwin eventually outpaced it. It's been discontinued.
I can't see it happening. Linux kernel has just as many warts as NT at this point. Even ignoring the software compatibility issues, they'd be throwing out a huge amount of hardware support. I'd...
I can't see it happening. Linux kernel has just as many warts as NT at this point. Even ignoring the software compatibility issues, they'd be throwing out a huge amount of hardware support.
I'd buy the argument that Microsoft have lost enough pride to actually consider the move. I just don't think the move makes business sense for them.
At this point the only thing keeping me on Windows is gaming, and with the progress Valve has made with Proton, that might not even be holding me much longer. I wonder what the implications of a...
At this point the only thing keeping me on Windows is gaming, and with the progress Valve has made with Proton, that might not even be holding me much longer. I wonder what the implications of a switch to the Linux kernel would mean for gaming. Would I be able to run all games on Linux and drop Microsoft with all its telemetry, incessant updates and GUI changes?
I feel exactly the same way. That would be amazing.
At this point the only thing keeping me on Windows is gaming, and with the progress Valve has made with Proton, that might not even be holding me much longer.
I feel exactly the same way.
Would I be able to run all games on Linux and drop Microsoft with all its telemetry, incessant updates and GUI changes?
I'm torn. Gaming was the thing keeping me on Windows, but lately Microsoft has been doing a good job of making me not feel like I need to be in a full blown Linux environment. The Windows 10...
I'm torn. Gaming was the thing keeping me on Windows, but lately Microsoft has been doing a good job of making me not feel like I need to be in a full blown Linux environment. The Windows 10 desktop is adequate. the new Windows Terminal is pretty slick, though I've gotten by fine with cmder for years. Windows Subsystem for Linux is awesome and about to get a whole lot better with WSL2. Hyper-V makes spinning up and managing Linux and Windows VMs pretty trivial. Most of my issues with Windows are just kind of evaporating.
Mediamonkey has to work on wine. The only apps that crap out on wine are either trying to talk to the hardware directly or are buried in the mess that is .net development and tied into that morass...
Mediamonkey has to work on wine. The only apps that crap out on wine are either trying to talk to the hardware directly or are buried in the mess that is .net development and tied into that morass of windows registry hell. Most apps outside of Microsoft's flagship suites and modern games don't do either one of those things.
I'm far from an expert in this, but from my understanding, the NT kernel itself isn't "bad", and does some things better than Linux/other Unix-like kernels (and vice versa).
I'd see Microsoft open sourcing the NT kernel (maybe going to a model similar to Apple with XNU and their various OSes) before switching to being fully Linux-based internally. So much of their business is built on backwards compatibility, and the amount of hardware out there, especially in some specialty environments, that only has Windows drivers that can't be covered by Wine or a Wine-esque solution, would preclude a full kernel switch.
Unless they developed a kernel module that could act as a shim to enable Windows drivers (and I imagine the amount of work required to get that working to be significant), they'd be shooting themselves in the foot IMO.
Getting all the Windows drivers to work natively in the Linux kernel would certainly be an inordinate amount of work. Windows supports a large amount of hardware.
As for fork, Microsoft seems to agree that it’s a hack, and just not worth it. There is
posix_spawnthat does what you actually want to do 99% of the time with fork/exec, and the last 1% may not be worth it. There’s a lot of historical choices made that were sensible at the time, but later became enshrined as eternal wisdom in order to justify their continued existence even when they seemed more costly than elegant. Windows surely has a lot of these, being ultra-backwards compatible, but Linux certainly does as well, being spiritually compatible with an even older OS.fork() is quite a terrible primitive; it does a lot of work under the hood that's almost perfectly contrary to the KISS principle. Ideally you'd use posix_spawn or other calls that let you adjust how memory, resources and everything else is handled. Because 99.99% of the time the defaults that fork uses are bad for performance or security and only in 0.01% of cases (being shell scripts being run by a shell spawning a subshell), you want what fork() does.
"Everything is a file" has also turned out to be not quite that useful. The modern Linux driver stack uses a file to access the GPU, but only really to get the resource handle, then everything moves to special ioctl() calls and memory mapping because files are terrible at being able to do what a GPU does.
Even a simple printer already has different primitives to a file (can't read, can't seek, only write), so IMO Windows isn#t entirely wrong in making these things a separate API that can be more clear and powerful without having to to haggle yourself through the filesystem.
Of course, not to detract, some parts of Windows OS are fairly terrible, yes.
The unix process model is overloaded IMO, it could be much much simpler (only tasks, making them lightweight enough that they can double-duty as threads or process), then you can build more complex models on top that suit your needs. In that model, fork() would be a heavy handed function with no purpose other than sugaring much more low level process creation (in Linux, the fork() syscall simply runs the appropriate proper syscalls in the background. There is no native fork() in the Linux process model).
And I hate to be that guy, but plan9 might be functional and have some good ideas, but it's terrible and writing drivers for plan9 is even more terrible because files are simply not a good abstraction for anything but actual files in a filesystem on a disk. Even networked filesystems like NFS start to creak the model of "everything is a file".
Similar LISP might be powerful and one of the most beautiful languages concepted but the reality is simply that most people don't use it, even after they grasp the concept because other languages provide better models out of the box.
The reason the GPU is access with ioctl's and memory mapping is becase the performance of read()+write() is not nearly sufficient to shovel multiple gigabytes per second to the GPU, as is necessary to drive modern GPUs. A GPU is not a printer, it's an entirely self-contained computer that must be entirely controlled by the driver to work properly. It doesn't even remotely work like a normal CPU, hence a simple file operation already doesn't cover what is necessary.
Sometimes, that's exactly what you want in a file: Write only as append, and no read.
One example might be a sensitive log file. If the log can be edited in full, a hacker could cover up their tracks.
You can do that properly by blocking syscalls like seek() or open() (optionally only blocking non-appending modes) or remove() so that you can only write to the end of the file.
Yeah but a printer is not a file, it's a machine.
A teletyper behaves like a file, a printer does not.
Modern printers have many more functions than "print text to file".
Yep. They have a read, no seek file, to scan and receive faxes; a write, no read/seek to send faxes; and a read and write file for status and job control.
You can't receive faxes from a read-only file because it requires negotiation of the image format and metadata. Sending faxes is also quite the dance to dial the phone number and push the data through.
Job Control isn't handled by a computer unless you use a print server, which doesn't handle job control on the printer but on the server itself.
Any of those will require developing a protocol for interacting with the file, which kind of makes the entire thing have at least three times as much overhead as necessary if it just had the appropriate API.
You do know most of those happen with a read write socket, right?
And hardware handles the faxing the negotiation dance. Otherwise, from the PC side... it's just an input device.
Some food for thought from Microsoft Research about
forkin modern operating systems.The NT kernel can fork a process, the Win32 subsystem cannot.
It's still there, both in new incarnations and in old. The new version is used for fast snapshotting of processes: they basically suspend a process, fork it, resume the parent, and then capture a minidump from the child.
NtCreateProcesshas always been able to have fork semantics as well.I've actually been able to fork a Win32 process with a lot of hacking around (enough to throw up a
MessageBoxin the child process, at least), but since the Win32 subsystem is all closed source and undocumented, I'd never use it in production code.Yes,
RtlCloneUserProcess()is the newfork-ish system call that is used by the snapshotting stuff.For
NtCreateProcess, you just specify theParentProcesshandle. Provided that the handle has the right access, the created process inherits its address space. When you create the child process's initial thread usingNtCreateThread, you can base its stack and context on your own thread's.As for Win32, there are a few issues:
win32k.sysdriver. That driver does not expect afork, so it can't automagically recognize the new process.CSRSS.exeis a user-mode component of Win32. A forked process needs to register itself withCSRSS.** As an aside, this one of the myriad reasons why UWP should be considered to be a layer atop Win32, as opposed to a distinct subsystem; UWP depends on DCOM, MSRPC, and thus CSRSS, which are all Win32 components.
KERNEL32.DLL,USER32.DLL, andGDI32.DLLare not fork-aware, so they contain per-process and per-thread data that, if reused, will trigger hangs and/or crashes. This is because they were initialized from the parent process. To get a working Win32 fork, you need to write code to clear all of that internal state and essentially reinitialize them from scratch.This was done for one sector of drivers already: ndis-wrapper. This packages took windows wifi device drivers, wrapped then, and then acted as a kernel shim.
If companies did the work themselves, porting their drivers over would be rather easy. Of course, they would only do this themselves, mostly, if Windows required it.
I feel like I'm reading a fake alternate-universe article. Windows 11? What!? There's no Windows 11. Microsoft has explicitly stated 10 is the endless version of windows. That's like asking Apple for OSXI... an entire-OS refresh doesn't make sense any more. Regardless of what marketing buzzwords make you think, "rebuilt from the ground-up" is a waste of time in today's industry.
Edit: I saw this in the Hacker News thread on this same article:
Windows has had a POSIX subsystem for quite some time. Can even handle NFS mounting.
MS could take a whole, huge step forward by keeping the Explorer DE, and rewriting it under the hood into a POSIX kernel. MacOS even retained compatibility as well for a similar move to a POSIX kernel with the move from System 9 to OSX.
They had a full native GNU stack as well, called it services for unix. It was predictably hamstrung (no BASH/SSH, for example), and so Cygwin eventually outpaced it. It's been discontinued.
I can't see it happening. Linux kernel has just as many warts as NT at this point. Even ignoring the software compatibility issues, they'd be throwing out a huge amount of hardware support.
I'd buy the argument that Microsoft have lost enough pride to actually consider the move. I just don't think the move makes business sense for them.
At this point the only thing keeping me on Windows is gaming, and with the progress Valve has made with Proton, that might not even be holding me much longer. I wonder what the implications of a switch to the Linux kernel would mean for gaming. Would I be able to run all games on Linux and drop Microsoft with all its telemetry, incessant updates and GUI changes?
I feel exactly the same way.
That would be amazing.
I'm torn. Gaming was the thing keeping me on Windows, but lately Microsoft has been doing a good job of making me not feel like I need to be in a full blown Linux environment. The Windows 10 desktop is adequate. the new Windows Terminal is pretty slick, though I've gotten by fine with cmder for years. Windows Subsystem for Linux is awesome and about to get a whole lot better with WSL2. Hyper-V makes spinning up and managing Linux and Windows VMs pretty trivial. Most of my issues with Windows are just kind of evaporating.
Mediamonkey has to work on wine. The only apps that crap out on wine are either trying to talk to the hardware directly or are buried in the mess that is .net development and tied into that morass of windows registry hell. Most apps outside of Microsoft's flagship suites and modern games don't do either one of those things.
FWIW, Directory Opus looks like the KDE file manager, mostly.
Yeah, it sounds like Dolphin...
https://kde.org/applications/system/org.kde.dolphin
Is Microsoft going to keep the numbered version releases? I remember reading they'd be switching to a subscription model eventually.
Whoops. I don't even use Google. Don't know how that got in there. Can you edit the link, @Deimos?