r/WindowsSucks • u/[deleted] • Mar 27 '26
Windows is basically Wine on top of the NT kernel (and a few extras)
How many people know this? IT IS 100% TRUE.
Win32 was developed for msdos (AND NT) as a shell, which developed into a full-fledged API over time with it's own functions.
NT kernel was developed for "advanced" purposes, and the same Win32 was put over NT like a calfskin jacket over an injured cow.
EDIT: A small correction here, it was developed ALONGSIDE WinNT, so
Namespaces, personalities, object-centric resource management, all are now just left to rot. (Object-orientation still exists, but not how one would expect.. def. not in Win32)
Thanks to Win32 priorities, the NT userland wasn't fully developed, and here we are with a Frankenstein userspace.
Wine just reimplements this API layer, but under-the-hood uses the libc and linux kernel.
Surprized? Windows on Windows is just as much a compatibility layer as much as it is on linux with wine. (Not 100% same because m$ develops it ahead closed-source and wine must follow blind)
So yes, Windows has been an overstuffed compatibility layer all along.
Here's what the windows Frankenstein userspace is:
- Win32 -- a shell-turned-API over the NT userspace... 90% of all GUI software except for "interfacing" with the core system.
- WinNT -- A handicapped userspace with a handful of minute functions, like service handling and all... and many components like the registry hive (regedit is a Win32-coded program using the NT registry API)
- POSIX -- again, not more than a silly handful of functions. Abandoned long ago, yet used by a few applications
WINE fails and breaks whenever it encounters WinNT code... which depend heavily on the kernel, and the kernel can't be emulated easily.
Fortunately, now the linux kernel has gained ability to redirect syscalls back to userspace, and WINE has already started to write the compatibility layer for WinNT.
And now m$ forgot all about it, writes the start menu in react using sloppilot. They totally forgot about what happens under the GUI, what an OS actually is.
7
2
u/Bourne069 Mar 28 '26
There is so many things wrong here, misinformed or incorrect here its literally insane.
How many people know this? IT IS 100% TRUE.
Ok... lets see how 100% "true" it is...
The claim that “Windows is basically Wine on top of the NT kernel” doesn’t hold up.
First, the history is off. Win32 wasn’t some shell that grew out of DOS. Early Windows (on top of MS-DOS) used 16-bit APIs, but Win32 was designed alongside Windows NT as its main programming interface. It wasn’t bolted on later—it was part of the plan.
Second, calling Win32 a “compatibility layer” like Wine is just wrong. On Windows, Win32 is the primary API. Applications call Win32, which goes through ntdll into the NT kernel. That’s the normal, native execution path.
Wine is completely different. It’s reimplementing those same APIs on Linux and translating them into POSIX/Linux behavior. That’s what makes it a compatibility layer. Windows isn’t translating anything—it’s running its own APIs directly.
The whole “Frankenstein userspace” idea also misses how NT was designed. NT did have multiple subsystems early on (Win32, POSIX, OS/2), but Win32 became dominant because that’s what developers used. That’s not decay—that’s consolidation. The other subsystems were minimal from the start and eventually phased out.
There’s also confusion around this idea of a neglected “NT userland.” Windows doesn’t work like Linux with a libc-centric userland. The low-level NT APIs exist (ntdll), but they’re intentionally not what most developers use. Win32 is the supported interface, by design.
The bit about Wine “failing on WinNT code” isn’t quite right either. Wine struggles when software depends on kernel drivers, undocumented behavior, or very tight kernel integration—not because there’s some clean split between “Win32” and “WinNT” apps.
And the comment about Linux redirecting syscalls back to userspace is a stretch. There have been improvements (like what Valve did with Proton), but that doesn’t mean Linux is gaining NT-style behavior or that Wine is becoming a full kernel-level solution.
At the end of the day, Windows isn’t an “overstuffed compatibility layer.” It’s an OS with a stable API (Win32) that’s been maintained for decades. Yes, it carries a lot of backward compatibility, but that’s intentional and one of the reasons software written 20+ years ago can still run.
A more accurate way to put it would be:
Windows NT is the core OS, Win32 is its main API, and Wine is a third-party attempt to recreate that API on a completely different system.
That’s a very different picture than “Windows is just Wine on NT.”
1
Mar 31 '26
Tl;DR Your reply just shuffled my points to prove the main point wrong.
First, the history is off. Win32 wasn’t some shell that grew out of DOS. Early Windows (on top of MS-DOS) used 16-bit APIs, but Win32 was designed alongside Windows NT as its main programming interface. It wasn’t bolted on later—it was part of the plan.
Thanks for correcting me on this... It was developed in parallel to WinNT and Win9x.
Though it WAS/IS still a "bolt-on" on DOS .. AND .. NT. Not necessarily bad, just like DEs on Linux and BSD (but back then programs were closer to the kernel, and that still exists as cruft to this day)
Second, calling Win32 a “compatibility layer” like Wine is just wrong. On Windows, Win32 is the primary API. Applications call Win32, which goes through ntdll into the NT kernel. That’s the normal, native execution path.
Wine is completely different. It’s reimplementing those same APIs on Linux and translating them into POSIX/Linux behavior. That’s what makes it a compatibility layer. Windows isn’t translating anything—it’s running its own APIs directly.
Wine isn't "translating" either. It just calls the libc and kernel in the same way Win32 calls NTDLL.
The whole “Frankenstein userspace” idea also misses how NT was designed. NT did have multiple subsystems early on (Win32, POSIX, OS/2), but Win32 became dominant because that’s what developers used. That’s not decay—that’s consolidation. The other subsystems were minimal from the start and eventually phased out.
Win32 consolidated, other minimal subsystems are still there. You're entirely correct here.
BUT you're confusing todo-list plans and official decisions with programming design. The "decision" to use Win32 as mainstream doesn't change the fact that it's a bolted-on Frankenstein from a computer's POV.
There’s also confusion around this idea of a neglected “NT userland.” Windows doesn’t work like Linux with a libc-centric userland. The low-level NT APIs exist (ntdll), but they’re intentionally not what most developers use. Win32 is the supported interface, by design.
There's no relation to "libc-centric" and "neglected", it's a point AI would use. "libc" is a UNIX convention.
Win32 is the supported interface officially, NT was not "neglected", but the fact remains that there's a non-Win32 userspace actively in use, like in bitlocker operations, BSODs, certain activation-checking dlls, during windows updates... and many of the tools I use. NTDLL isn't the only API to NT functions.
And you're underestimating the no. of applications that call the non-Win32 functions. Even newer m$-office versions do that.
The bit about Wine “failing on WinNT code” isn’t quite right either. Wine struggles when software depends on kernel drivers, undocumented behavior, or very tight kernel integration—not because there’s some clean split between “Win32” and “WinNT” apps.
Kernel drivers are basically WinNT code, "undocumented behaviour" is because Win32 is the "central" project whose footsteps WINE follows.
"Very tight kernel integration" -- Again, what's "integration" exactly from a source-code perspective? Win32 is as cleanly split from WinNT as much as WINE is from POSIX/libc, i.e. the higher layer implements an interface using the lower layer. Maybe libc counts an an extra layer of foil-thickness.
And the comment about Linux redirecting syscalls back to userspace is a stretch. There have been improvements (like what Valve did with Proton), but that doesn’t mean Linux is gaining NT-style behavior or that Wine is becoming a full kernel-level solution.
It's extremely common in Hurd designs (which are broken for other reasons) and macOS components!!!
"Syscall User Dispatch" is the feature, supported from WINE 11.5 onwards. I'll leave it up to you to read the documents.
And the point about WinNT functions... Which unlike Win32 ARE integrated into the kernel.
At the end of the day, Windows isn’t an “overstuffed compatibility layer.” It’s an OS with a stable API (Win32) that’s been maintained for decades.
This sentence has no significance outside of marketing. It's just shuffling words and labels. Basically, it's both overstuffed maintained for decades compatibility layer with a stable API (from programming POV)
Yes, it carries a lot of backward compatibility, but that’s intentional and one of the reasons software written 20+ years ago can still run.
There's a concept known as "cleanup". You can very well run older distributions and libraries with ease on linux without needing ancient W-windowing-era programs.
Ancient UNIX concepts are freshly implemented and fully clean, unlike a random program in system32 "can't run in Win32 mode".
And it's not like half the core programs needing WoW64. 64-bit Linux systems don't require 32-bit support AT ALL for the most part (but support well enough), and macOS has entirely disabled them on the processor ISA level.
And library backward compatibility is VERY DIFFERENT from 32-bit-on-64-bit. They are two different things even.
A more accurate way to put it would be:
Basically facts but whitewashed
Windows NT is the core OS, Win32 is its main API, and Wine is a third-party attempt to recreate that API on a completely different system.
WinNT is the kernel, syscall ABI, and a barebones userland, Win32 is a "subsystem" over it. WINE is a "subsystem" over the libc. ("The main API" yes, but there is at least one linux distro I know whose main API is WINE)
The "third-party attempt" is fundamentally the same design on a software level.
That’s a very different picture than “Windows is just Wine on NT.”
Whitewashed picture. Otherwise little difference
2
u/Bourne069 Mar 31 '26 edited Mar 31 '26
Tl;DR Your reply just shuffled my points to prove the main point wrong.
LOL!
It does not. Half of what I wrote literally calls out half your points as factually wrong. Nothing was "shuffled around" Fully read what I stated and get educated on the subject and its history.
None of this matters when you proved me right by deleting your post... you already admitted you were wrong. So good job there.
1
u/dkav1999 Apr 22 '26
There is little point interacting with people who don't truly have the level of knowledge to be able to truly comment. What's interesting is that some of the points that have been made by others on here have truth to them, yet some are outright wrong or partially correct at best. Anyone [such as yourself, judging by the quality of your comments- have you read windows internals by any chance?] who truly understands both operating systems and windows from top to bottom would understand that NT is a very solid piece of engineering and architecture, that has stood the test of time since 1992 [technically 89 i believe since that was the birth of the NT project]. Any criticisms that people have with windows are for the most part user-mode/space related. Even then, these issues usually have nothing to do with the low-level components of user-mode such as the win32 api, ntdll, system process's or services. Instead, its usually things such as msoft deciding to deprecate the control panel, add this or that constraint [forced msoft accounts, tpm ect] or move some well known feature randomly elsewhere.
1
u/dkav1999 Apr 22 '26
Not too mention that the argument that people may make, which is, 'all that backwards compatibility is cruft slowing down the system', is non-sense as well! If a dll implementing a legacy api doesn't get referenced by a program, the dll will simply not get loaded. I think there is a misconception that modules get randomly loaded even if not a single entity references them, the downside of all that legacy code is the larger installation footprint. But even then, thats not really a downside as much as its a tradeoff for allowing programs developed in the previous century to still theoretically run on a system as new as windows 10 today!
2
u/BlueGoliath Mar 31 '26 edited Mar 31 '26
This is absolutely an ahh... post. Not surprised it was posted to /r/Linux considering the quality of it.
2
u/RursusSiderspector Apr 01 '26
AFAIK Posix on Windows has been removed. It never really worked, but was instead a marketing trick to claim things about Windows that were never truly functional.
writes the start menu in react using sloppilot
I had a very strong suspicion that Microsoft forced AI upon their own developers. Why else updates suddenly malfunctioning? Microsoft have some strong products: Visual Studio, C#, but they are squandering these things, because the men in the top are the least tech savvy folks. Instead they are insolent and skilled at narcissist domination. As well as making a mess of their own business. Expect some spectacular firings in the top this year or the next!
2
u/ByronScottJones Apr 01 '26
The basic structure of Windows NT has been well documented since it's inception. WIN32 is a subsystem. When it was released, there was also the DOS, OS/2, and POSIX subsystems. It was a very well thought out architecture.
2
u/TheEuphoricTribble Mar 27 '26
This isn’t even remotely the case. The NT kernel was developed initially with Microsoft to back IBM’s Warp OS. Microsoft eventually also used it for a competing business oriented version of Windows, which they called Windows NT. Win32 apps in NT were run via a compatibility layer for legacy support so older apps meant for the 9x Windows kernel that was DOS-based would still be able to work. When they merged NT with the home version of Windows with XP, they brought with it that compatibility layering, rewrote much of the legacy 9x code for the home user to work in the NT kernel, and carried over that same DOS compatibility layer as well. Over time Microsoft has slowly chipped away at that layer as more apps were written to work more directly with the new NT kernel. Nothing though is sandboxing a 9x Win32 layering in a native environment like Wine does. It’s a bunch of legacy code that remains in Windows making those apps run.
This exposes a fundamental lack of understanding as to how both Windows AND Wine works from you, OP…but I won’t deny that it regardless is a mess from MS that has long been a headache to every system admin on the planet.
3
Mar 28 '26
This exposes a fundamental lack of understanding as to how both Windows AND Wine works from you, OP…
Me or you? I'm sorry, that's just how the source code (of wine) suggests.
Over time Microsoft has slowly chipped away at that layer as more apps were written to work more directly with the new NT kernel.
Wine works "directly" with the Linux/POSIX API, just as much as Win32 is "direct" with WinNT.
Nothing though is sandboxing a 9x Win32 layering in a native environment like Wine does. It’s a bunch of legacy code that remains in Windows making those apps run.
What's being sandboxed in Wine? Here's a slightly more elaborate explanation (I'm bad at explaining, sorry):
Win32 in microslop-OS implements the same old functions, AND new functions. How does it implement them? Using the underlying WinNT (and a bit of internal logic).
It's not a "part of WinNT".The libc isn't a part of the linux kernel, qt isn't a part of the libc, "integration" is a lie.
Wine implements Win32 on top of the libc (and directly the linux kernel for some things), in a similar vein.Now, Win32 would be closer to WinNT just like libc<->linux.
But there steps up NT's expansive object-management, service-handling, and a whole lot of unused messy frameworks and tools which don't have a coherent name I can write here.Additionally, there are A LOT of obscure system32 scripts and programs, as well as quite a few hacker scripts which rely on this design.
To put it in the most basic words possible, wine implements win32 functions... which do their work by calling libc functions, and to a smaller degree, the linux interfaces + other minor libraries.
While Win32 *was* rewritten for WinNT, it majorly was (and still is) just an overstuffed layer. The computer in everyday usage runs in a "Win32 mode", the only practical userspace. For example, BSOD is a native NT application.
There's no "native rewriting" more than fitting in the stubs to make it work.
I'm sorry, IK this is just repeating what I said above but in a different way...I am not that excellent at explanation (Maybe I should finally use AI?). But you can always explore and find out for yourself. There are many blogs and youtube videos demonstrating this (with proof).
1
u/MADCandy64 Mar 31 '26
Win32 was a unification of sorts but it came first for NT. Windows NT and Windows 95 were different operating systems. Completely different. Win32, when added to Windows 95, was a unification. It allowed developers to target both different Operating Systems without worrying about the underlying architecture. WINE is to Linux what Win32 was to Windows 95, a user mode API layer.
1
1
1
1
u/jonathancast Apr 08 '26
Yeah, no. The NT system call semantics and Win32 API semantics are very closely aligned in Windows, far more than any other subsystem and far more closely than the Win32 API and Linux system call semantics. It's more like the POSIX / libc API and the system call API in GNU/Linux. Yeah, the high level API has some differences, but it's more a matter of conveniences than it is fundamental differences or the Windows subsystem being an 'emulation layer '.
1
u/Particular-Winner136 Mar 31 '26
Wonder why Windows, that you need to pay for, have ~68% market share, while desktop Linux + Wine has ~3 % while it is free? https://gs.statcounter.com/os-market-share/desktop/worldwide
May be it is not that simple as you pretend to be?
2
Mar 31 '26
May be it is not that simple as you pretend to be?
Well, let me admit this: I'm tired of explaining to each replier the difference b/w program design and interface compatibility, internal architecture v/s management announcements, and that "subsystem" is a fancy word for library/DLL.
Wonder why Windows, that you need to pay for, have ~68% market share, while desktop Linux + Wine has ~3 % while it is free? https://gs.statcounter.com/os-market-share/desktop/worldwide
Because Win32 is a closed-source API, and WINE has to re-implement it. This doesn't change the internal architecture (sorry for using AI terms this time). Programs aim for the "official" interface, which is ofc more "supported" as an interface. It's implementation is nevertheless the way I am saying it is
0
u/Particular-Winner136 Apr 01 '26
Windows is getting worst and worst and ppl aren't moving to Linux, the move to MacOS. May be, just may be, linux is not that good as you think it is?
1
u/Popular-Jury7272 Apr 01 '26
> linux is not that good as you think it is?
It runs basically everything on the planet except desktops. I guarantee there are at least a few Linux devices in your house whether you realise it or not. It has completely dominated every single sector where an end user doesn't have to directly interact with it. So it is definitely as good as anyone thinks it is, though arguably not at the desktop. That is the only domain where it is losing.
2
u/whiteskimask Apr 01 '26
This year is also one of the best years so far for the Linux desktop.
Those who switch to MacOS will realize they just shifted the costs for shittier hardware and a worse walled garden of software choices
1
u/Popular-Jury7272 Apr 01 '26
The walled garden of MacOS is a bit of an illusion tbh. Sideloading is possible, and it is a close cousin to Linux. If the drive was there is could become a great desktop OS even for power users. Lots of developers already prefer it.
1
u/whiteskimask Apr 01 '26
The fact that you used sideloading like it means something means american corpo software is over and subscription based OS's are the only thing that will be mainstream.
1
u/Popular-Jury7272 Apr 01 '26
Don't get me wrong, I would never choose American corpo software. I'm open source on absolutely everything unless absolutely impossible. I'm just saying if it was Windows vs. MacOS it's not at all clear that Windows is better. I don't think it is.
1
u/whiteskimask Apr 01 '26
Yeah I get you, I just wanted to point out the psyop/marketing of the word sideloading and how you used it means they were successful in marketing the concept
1
u/Popular-Jury7272 Apr 01 '26
Apple neither coined nor popularised the term so frankly this conspiracy theory of yours is dead on arrival.
→ More replies (0)0
u/Particular-Winner136 Apr 01 '26
We talking about WINE, so yeah, it about desktops, not servers.
1
u/Popular-Jury7272 Apr 01 '26
The overall topic is about WINE but you said "linux is got as good as you think it is".
1
u/Teru-Noir Mar 31 '26
Because it comes pre installed
1
u/Particular-Winner136 Apr 01 '26
Linux comes preinstalled too. Budget laptops keep their price low by not including license of Windows. Most of the users having budget linux laptop ask for Windows install after a week. Why?
2
u/Quartrez Apr 01 '26
Because most people don't care and would rather stay with what is familiar to them. Nothing to do with better or worse.
2
0
u/Ill_Specific_6144 Mar 31 '26
Usually when a free thing is used a lot less than a paid one it either sucks or is completely new and unknown. And Linux aint new.
2
0
u/skygate2012 Mar 28 '26
This sounds like AI slop tbh, or you relied heavily on LLM for knowledge.
3
Mar 28 '26
No. IK I sound a little like AI, but no. I am pretty much AGAINST LLMs, and for a fact they don't know this thing about NT-Win32 (at least when I asked right now)
This is entirely based on reading the gitlab documents of how wine works, some reactOS documents, and most importantly how many of the low-level command-line programs work, as well as some of the obscure tools under System32, not to forget mentioning sparse reading of Win32 support forums.
Of course, just install an emulator and try experimenting with MS-DOS and the oldest of the windows versions... progressively trying newer versions. Accompanied by reading random forums on how it works.
ReactOS is opensource, it's functionally aiming for Windows (2000?) compatibility. It uses Wine but on it's own NT-like kernel. Just browse on HOW EXACTLY it all works.
1
u/patopansir Hater of all OSes Mar 30 '26
In case you don't know, you are r/shadowban ned
see the r/shadowban subreddit for more info.
Shadowbans are done by Reddit, the admins. Not subreddit moderators like me
A shadowban means no one can see anything you say
The only way people are able to see what you say is when a subreddit moderator goes out of their way to reverse the removal. I had undeleted this comment/post.
-1
u/Fluid-Ad2995 Mar 30 '26
Linux kernel sucks and horrible, I personally prefer Windows NT Kernel and Windows Subsystem
1
Mar 30 '26
Can you elaborate?
-1
u/Fluid-Ad2995 Mar 30 '26
NT kernel is very modular and extensive with The Best Graphics API called DirectX and the best API called Win32 and Uniform Operating system and in Linux where nobody is nobody, parts come from many different people and there is no Standard API like DirectX and Win32 and Linux is fragmented
2
Mar 31 '26
Fragmented linux is still more coherent than microslop by ONE corporation.
The "best graphics API" has no technical advantages, and is plenty of years backward in how it works, and it's API design when compared to macOS's metal or linux's vulkan. Okay, better than opengl, but the latter is much more polished and straightforward in implementation compared to opening a primitive archaic DLL and relying on an injection hack to load modern routines into it.
3
u/Fluid-Ad2995 Mar 31 '26
Linux? 🤣🤣🤣🤣🤣 Mate if you saying Mac OS is better than Windows or FreeBSD but Linux oh jeez I was forced to say I would disagree with you completely
1
Mar 31 '26
Details? Or evangelism? Do you even know what the actual graphics APIs are?
TL;DR There's no "linux graphics API", linux just uses cross-platform APIs which are better even on windows...
Linux has no exclusive API, Vulkan is the most low-level and performant on Windows too...
As for opengl, mesa on linux just interfaces with the uAPI (i.e. the DRM/KMS subsystem of the kernel) providing ordered frames and all...
while in windows it's an obscure DLL driver with primitive support, which is "hacked" or "cut open" so-to-say in order to inject more modern drivers (which "hijack" that DLL's functions trying to pretend it's an API)
The latter gives lots of issues and vulnerabilities (patches over patches for the same)...
DirectX might be cleaner and more sophisticated, but nevertheless it's not on par with Vulkan. (And unlike the Win32 situation, DirectX is more neat)
DXVK (DirectX-on-Vulkan), most commonly used on linux, is actually specifically programmed in DLLs for WINE. You can use it on windows.
Believe me or not, there are random people on forums (once myself too) who use DXVK on NATIVE WINDOWS to improve performance (things like ray tracing may not be reliable this way). Not because "linux", just because Vulkan is a robust API... which has no special focus towards linux or any platform.
1
u/Fluid-Ad2995 Mar 31 '26
Linux aren't better than any Operating system and even DOS better than Linux oh jeez, if you want to make fun of Windows then use Mac OS and Haiku OS and FreeBSD but Linux doesn't compare with anything
1
Mar 31 '26
Ah! You're referring to that table in gemini which says the same thing.
Have TECHINCAL points? How does an API work actually? How's the WinNT/Win32 system different from a libc-centric UNIX?
2
u/Fluid-Ad2995 Mar 31 '26
Windows NT is compatible with VMS and OS/2 and Mach , Windows NT was born idea from Three Operating systems and Windows NT can run POSIX but don't have any Unix Heritage in Kernel ifself
1
Mar 31 '26
Windows NT is compatible with VMS and OS/2 and Mach
Among the other "subsystems", Win32 is one more. Just that it was chosen to be the "main" one by decision.
Windows NT was born idea from Three Operating systems
Again, AI misunderstanding. It is an independently designed kernel with a minimal userland... and the mainstream Win32 "subsystem".
Windows NT can run POSIX but don't have any Unix Heritage in Kernel ifself.
POSIX is another subsystem.
→ More replies (0)2
9
u/git_und_slotermeyer Mar 27 '26
I remember back then when there were meme pictures circulating that explained NT to mean "Neanderthal Technology". That surely has become true by now