Windows developer here. After reading this post, my gut instinct is that this is due to something called 'segment heap'.
A bit of backstory: there are two, totally independent implementations behind the Windows heap allocation APIs (i.e. the implementation code behind RtlHeapAlloc and RtlHeapFree, which are called by malloc/free). The older of the two, developed uring the Dave Cutler era, is known as the "NT heap". The newer implementation, developed in the 2010s, is known as "segment heap". This is all documented online if anyone wants to read more. When development on segment heap was completed, it was known to be superior to the NT heap in many ways. In particular, it was more efficient in terms of memory footprint, due to lower fragmentation-related waste. Segment heap was smarter about reusing small allocations slots that were recently free'd. But, as ever, Windows was very serious about legacy app compat. Joel Spolsky calls this the 'Raymond Chen camp'. So, they didn't want to turn segment heap on universally. It was known that a small portion of legacy software would misbehave and do things like, rely on doing a bit of use-after-free as a treat. Or worse, it took dependencies on casting addresses to internal NT heap data structures. So, the decision at the time was to make segment heap the default for packaged executables. At that time, Windows Phone still existed, and Microsoft was pushing super hard on the Universal platform being the new, recommended way to make apps on Windows. So they thought we'd see a gradual transition from unpackaged executables to packaged, and thus, a gradual transition from NT heap to segment heap. The dream of UWP died, and the Windows framework landscape is more fragmented than ever. Most important software on Windows is still unpackaged, and most of it runs on x64.
Why does this matter? Because segment heap is also enabled by default on arm. Same logic as the packaged vs unpackaged decision. Arm64 binaries on Windows are guaranteed not to be ancient, unmaintained legacy code. Arm64 windows devices have been a big success, and users widely report that they feel more responsive than x64 devices.
A not insignificant part of why Windows feels better on arm is because segment heap is enabled by default on arm.
I'd be interested to see how this test turns out if you force segment heap on x64. You can do it on a per-executable basis via creating a DWORD value named FrontEndHeapDebugOptions under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<myExeName>.exe, and giving it a value of 8.
You can turn it on globally for all processes by creating a DWORD value named "Enabled" under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap, and giving it a value of 3. I do this on my dev machine and have encountered zero problems. The memory footprint savings are pretty crazy. About 15% in my testing.
Building Unreal games. Running windows containers.
Windows server is actually kind of awesome for when you need a Windows machine. Linux is great for servers but Windows server is the real Windows pro. Rock solid and none of the crap.
The worst part of Windows server is knowing that Microsoft can make a good operating system and chooses not to.
An application that is only supported on MS Windows. Yes, those still exist. One project I am working on is supporting such an application that is a mix of desktop and web application talking to industrial monitoring devices.
It's a beast in terms of complexity, in my opinion. But the vendor only supports running it on specific configurations.
As former Windows person who still uses fair amount of Powershell on Linux, I was interested.
However, reading the summary left me confused like you don't understand what's happening at Microsoft.
> Hopefully Microsoft will spend more time in the future on their server product strategy and less on Copilot ;-)
The future product strategy is clear, it's Linux for servers. .Net runs on Linux, generally with much better performance. Microsoft internally on Azure is using Linux a ton and Windows Server is legacy and hell, MSSQL is legacy. Sure, they will continue to sell it because if you want to give them thousands of dollars, they would be idiots to turn it down but it's no longer a focus.
The only people using MSSQL Server are people deep, deep in the Microsoft ecosystem. Think government work, and those unlucky enough to work at a pure Microsoft shop where every problem looks like a Microsoft or Azure solution.
It's not a dominant database anywhere on the outside.
We're a B2B shop migrating to MSSQL, from SQL Anywhere. Managed MSSQL in Azure is fairly easy operationally, especially since we don't have a dedicated DBA and our support staff aren't SQL gurus.
However since we now got the tools for running on both, and experience migrating, we might be moving to PostgreSQL at some point in not too distant future. Managed MSSQL in Azure is not cheap.
I know of a couple of rather fancy, proprietary 2-way radio trunking systems products that use local MS SQL on the back end, to keep track of configs for individual subscriber radios and system configurations for the radio repeaters.
(What's that? Well, if you ever walk into a place like a gigantic oil refinery, you'll see a bunch of people working there. If you look long enough, you'll notice that each of them have an expensive-looking radio ("walkie talkie") on their hip. Some of those radios may be my fault -- and of those that are, there's an MS SQL database that knows exactly how it was programmed. But I didn't pick it; that's just how the system operates.)
It's "legacy" because it's essentially tied to Windows. Yes, technically it works on Linux, and no doubt that was an amazing feat, but no serious company is running MSSQL on Linux when all the documentation, all the best practices are all based on running that on Windows.
Wait until you read about the version they released for ARM, briefly! It had a dynamic recompiler which would produced ARM64 ELF libraries from Windows PE executables, allowing x86_64 MSSQL to run on ARM Linux! They ditched that once Rosetta support on ARM Macs was good enough to run x86_64 VMs, as apparently all they cared about was supporting Docker on Macs...
I think it is essentially "complete drawbridge", too. I haven't played around with it in a while, but from memory, you can coerce it to run arbitrary Windows executables, basically anything without graphics (which are missing from the PAL they ship).
It's quite impressive, though also necessary if you think about it. SQL Server requires the legacy dot net stack, AND it also ships with a full copy of the msvc compiler/linker! Not sure if that's ever used by the Linux port, but it is installed. MSSQL kind of exercises every inch of the Windows API surface.
You can even run e.g. xp_dirtree and see an overlay of the host disk along with Drawbridge's copy of Windows.
For mid sized businesses, where you're mostly just doing some business reporting, a single mssql instance makes for a great and very cheap 'data warehouse'. All the auth magically works for people to connect with Excel, and powerbi+cloud just works out of the box.
I'd be curious what a better/non-legacy solution is! (as I do this stuff haha, and don't see much else other than full cloud options, sf etc)
Even Microsoft considers Microsoft SQL Server legacy! It's had virtually no new features added between 2022 and 2025 other than AI and cloud integration. All the truly capable people have long since left that team and moved into various Azure and Fabric teams.
To give you an idea of how bad things have gotten, there's like one guy working on developer tooling for SQL Server and he's "too busy" to implement SDK-style SQL Server Data Projects for Visual Studio. He's distracted by, you guessed it, support for Fabric's dialect of SQL for which the only tooling is Visual Studio Code (not VS 2026).
There's people screaming at Microsoft that they have VS solutions with hundreds of .NET 10 and SQL projects, and now they can't open it their flagship IDE product because the SQL team office at Redmond has cloth draped over the furnite and the lights are all off except over one cubicle.
Also: There still isn't support for Microsoft Azure v6 or v7 virtual machines in Microsoft SQL Server because they just don't have the staff to keep up with the low-level code changes required to support SSD over NVMe with 8 KB atomicity. Think about how insanely understaffed they must be if they're unable to implement 8 KB cluster support in a database engine that uses 8 KB pages!!!
Typical approach on an HV server is to disable C States, set power management to high, etc preventing x86 from downclocking. Keeping the CPU from seesawing can have big improvements.
But you’re not going to do that in a lab/personal machine, usually.
It all runs better with Linux, Linux isn’t wasting cycles spying on me.
Windows developer here. After reading this post, my gut instinct is that this is due to something called 'segment heap'.
A bit of backstory: there are two, totally independent implementations behind the Windows heap allocation APIs (i.e. the implementation code behind RtlHeapAlloc and RtlHeapFree, which are called by malloc/free). The older of the two, developed uring the Dave Cutler era, is known as the "NT heap". The newer implementation, developed in the 2010s, is known as "segment heap". This is all documented online if anyone wants to read more. When development on segment heap was completed, it was known to be superior to the NT heap in many ways. In particular, it was more efficient in terms of memory footprint, due to lower fragmentation-related waste. Segment heap was smarter about reusing small allocations slots that were recently free'd. But, as ever, Windows was very serious about legacy app compat. Joel Spolsky calls this the 'Raymond Chen camp'. So, they didn't want to turn segment heap on universally. It was known that a small portion of legacy software would misbehave and do things like, rely on doing a bit of use-after-free as a treat. Or worse, it took dependencies on casting addresses to internal NT heap data structures. So, the decision at the time was to make segment heap the default for packaged executables. At that time, Windows Phone still existed, and Microsoft was pushing super hard on the Universal platform being the new, recommended way to make apps on Windows. So they thought we'd see a gradual transition from unpackaged executables to packaged, and thus, a gradual transition from NT heap to segment heap. The dream of UWP died, and the Windows framework landscape is more fragmented than ever. Most important software on Windows is still unpackaged, and most of it runs on x64.
Why does this matter? Because segment heap is also enabled by default on arm. Same logic as the packaged vs unpackaged decision. Arm64 binaries on Windows are guaranteed not to be ancient, unmaintained legacy code. Arm64 windows devices have been a big success, and users widely report that they feel more responsive than x64 devices.
A not insignificant part of why Windows feels better on arm is because segment heap is enabled by default on arm.
I'd be interested to see how this test turns out if you force segment heap on x64. You can do it on a per-executable basis via creating a DWORD value named FrontEndHeapDebugOptions under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<myExeName>.exe, and giving it a value of 8.
You can turn it on globally for all processes by creating a DWORD value named "Enabled" under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Segment Heap, and giving it a value of 3. I do this on my dev machine and have encountered zero problems. The memory footprint savings are pretty crazy. About 15% in my testing.
Cant believe somebody is still using windows server? What’s the use case?
Building Unreal games. Running windows containers.
Windows server is actually kind of awesome for when you need a Windows machine. Linux is great for servers but Windows server is the real Windows pro. Rock solid and none of the crap.
The worst part of Windows server is knowing that Microsoft can make a good operating system and chooses not to.
This has been the case for ever. I recall opting to use Windows Server 2003 over XP back in the day for desktop/workstation use.
Could even enable XP themes IIRC.
Yes I only recently understood why people use Windows Server as a desktop operating system - it looks and feels like old Windows.
Companies that are bigger than startups vibecoding food delivery apps?
Even Apple and Google run AD internally.
Gotta support all those CAD workstations running Windows.
Is Apple hardware still designed on Windows PCs?
Im not really in the space but all the CAD things I see lately are browser based "cloud offerings"
Im not sure is CAD stuff is just served by a basic graphics card at this point or if there is some server side work going on.
OS doesnt mean that much when every industry decided that Chrome was going to be their VM
[delayed]
An application that is only supported on MS Windows. Yes, those still exist. One project I am working on is supporting such an application that is a mix of desktop and web application talking to industrial monitoring devices.
It's a beast in terms of complexity, in my opinion. But the vendor only supports running it on specific configurations.
I hope we migrate our stack to Linux soon, but I think that’ll take few years.
I know big company that run their core on Windows Server 2012, I’ve no idea how they manage the software assurance and compliance
Actually Windows Server 2012 or just Windows Domain functional level? https://learn.microsoft.com/en-us/windows-server/identity/ad...
Companies that aren't technology companies but use technology that has been doing the job for 20 years.
What was the reason 20 years ago?
(I know, I know. That question might be a bit too loaded. I'm really very sorry. No, there's no need that; I'll see myself out.)
Those don't exist. I was told (over and over again) that every company is a technology company.
mild \s
As former Windows person who still uses fair amount of Powershell on Linux, I was interested.
However, reading the summary left me confused like you don't understand what's happening at Microsoft.
> Hopefully Microsoft will spend more time in the future on their server product strategy and less on Copilot ;-)
The future product strategy is clear, it's Linux for servers. .Net runs on Linux, generally with much better performance. Microsoft internally on Azure is using Linux a ton and Windows Server is legacy and hell, MSSQL is legacy. Sure, they will continue to sell it because if you want to give them thousands of dollars, they would be idiots to turn it down but it's no longer a focus.
in no way that I can see is MSSQL or Server "legacy".
The only people using MSSQL Server are people deep, deep in the Microsoft ecosystem. Think government work, and those unlucky enough to work at a pure Microsoft shop where every problem looks like a Microsoft or Azure solution.
It's not a dominant database anywhere on the outside.
We're a B2B shop migrating to MSSQL, from SQL Anywhere. Managed MSSQL in Azure is fairly easy operationally, especially since we don't have a dedicated DBA and our support staff aren't SQL gurus.
However since we now got the tools for running on both, and experience migrating, we might be moving to PostgreSQL at some point in not too distant future. Managed MSSQL in Azure is not cheap.
Heh. State government is the only place I've encounter MSSQL in the past 10 years.
It's common as the backend to a lot of SMB scale ERP and CRM solutions. But almost all of those run on SQL Express.
I know of a couple of rather fancy, proprietary 2-way radio trunking systems products that use local MS SQL on the back end, to keep track of configs for individual subscriber radios and system configurations for the radio repeaters.
(What's that? Well, if you ever walk into a place like a gigantic oil refinery, you'll see a bunch of people working there. If you look long enough, you'll notice that each of them have an expensive-looking radio ("walkie talkie") on their hip. Some of those radios may be my fault -- and of those that are, there's an MS SQL database that knows exactly how it was programmed. But I didn't pick it; that's just how the system operates.)
Which can also run on Linux now.
It's "legacy" because it's essentially tied to Windows. Yes, technically it works on Linux, and no doubt that was an amazing feat, but no serious company is running MSSQL on Linux when all the documentation, all the best practices are all based on running that on Windows.
Why did they port it to Linux?
Knowing nothing about this, I wonder if they're getting ready to retire Windows Server, and wanted to get their server products off it?
Edit: How they did it is also quite fascinating:
https://www.microsoft.com/en-us/sql-server/blog/2016/12/16/s...
https://www.microsoft.com/en-us/research/project/drawbridge/
>a key contribution of Drawbridge is a version of Windows that has been enlightened to run within a single Drawbridge picoprocess.
MSSQL on Linux only seems to use parts of that project (a smaller abstraction layer), but that's still super cool.
Wait until you read about the version they released for ARM, briefly! It had a dynamic recompiler which would produced ARM64 ELF libraries from Windows PE executables, allowing x86_64 MSSQL to run on ARM Linux! They ditched that once Rosetta support on ARM Macs was good enough to run x86_64 VMs, as apparently all they cared about was supporting Docker on Macs...
I think it is essentially "complete drawbridge", too. I haven't played around with it in a while, but from memory, you can coerce it to run arbitrary Windows executables, basically anything without graphics (which are missing from the PAL they ship).
It's quite impressive, though also necessary if you think about it. SQL Server requires the legacy dot net stack, AND it also ships with a full copy of the msvc compiler/linker! Not sure if that's ever used by the Linux port, but it is installed. MSSQL kind of exercises every inch of the Windows API surface.
You can even run e.g. xp_dirtree and see an overlay of the host disk along with Drawbridge's copy of Windows.
The "why" is for Kubernetes and Docker support.
For example, the Aspire.NET orchestrator pulls the Linux docker image of SQL Server in much the same way as it does for MySQL or Postgres.
On the flip side, every single MSSQL instance that I've encountered has been legacy. For at least five years.
For mid sized businesses, where you're mostly just doing some business reporting, a single mssql instance makes for a great and very cheap 'data warehouse'. All the auth magically works for people to connect with Excel, and powerbi+cloud just works out of the box.
I'd be curious what a better/non-legacy solution is! (as I do this stuff haha, and don't see much else other than full cloud options, sf etc)
These days I think airtable and other "no code" systems fit this bill well.
Even Microsoft considers Microsoft SQL Server legacy! It's had virtually no new features added between 2022 and 2025 other than AI and cloud integration. All the truly capable people have long since left that team and moved into various Azure and Fabric teams.
To give you an idea of how bad things have gotten, there's like one guy working on developer tooling for SQL Server and he's "too busy" to implement SDK-style SQL Server Data Projects for Visual Studio. He's distracted by, you guessed it, support for Fabric's dialect of SQL for which the only tooling is Visual Studio Code (not VS 2026).
There's people screaming at Microsoft that they have VS solutions with hundreds of .NET 10 and SQL projects, and now they can't open it their flagship IDE product because the SQL team office at Redmond has cloth draped over the furnite and the lights are all off except over one cubicle.
Also: There still isn't support for Microsoft Azure v6 or v7 virtual machines in Microsoft SQL Server because they just don't have the staff to keep up with the low-level code changes required to support SSD over NVMe with 8 KB atomicity. Think about how insanely understaffed they must be if they're unable to implement 8 KB cluster support in a database engine that uses 8 KB pages!!!
Azure services run on [customized] Hyper-V, thus Windows Server.
Azure networking is Linux.
EDIT: Marvel at the NT4 style Task Manager [0].
[0] https://techcommunity.microsoft.com/blog/windowsosplatform/a...
Microsoft just upstreamed support for running Linux as the Hyper-V equivalent of Dom0, so no Windows required.
https://www.phoronix.com/news/Linux-6.19-Improves-Hyper-V
Typical approach on an HV server is to disable C States, set power management to high, etc preventing x86 from downclocking. Keeping the CPU from seesawing can have big improvements.
But you’re not going to do that in a lab/personal machine, usually.