[mmastrac]

While your first statement is reasonable, your second is uncharitable and hostile.

If Windows won't allow use of the filesystem as a database or cannot heuristically detect when a folder is being used as a store of data, Windows is wrong, not the developer.

Amusingly Microsoft ships exclusions for their own software, and states "Opting out of automatic exclusions might adversely impact performance, or result in data corruption. Automatic server role exclusions are optimized for Windows Server 2016, Windows Server 2019, Windows Server 2022, and Windows Server 2025."

https://learn.microsoft.com/en-us/defender-endpoint/configur...

[dangus]

> If Windows won't allow use of the filesystem as a database or cannot heuristically detect when a folder is being used as a store of data, Windows is wrong, not the developer.

I guess Nintendo is wrong for not giving you a file system at all on the Game Boy. The analogy may be extreme but that’s part of the point here: who are we to dictate Microsoft’s design goals and choice of compromises?

It’s really not Microsoft’s fault if their product doesn’t meet the specific needs of someone’s specific software use case.

I do agree that my first suggestion is the more sensible one, but my second one was more of a philosophical point. Windows has been the same old Windows for a long time and developers that don’t understand its limitations and requirements for deploying applications are more in the wrong than Microsoft in this scenario.

If Microsoft felt like the best design decision was to remove windows defender and that there was no negative impact to doing so they would have done it by now.

[mmastrac]

I'm sorry, but I believe your argument is extremely weak.

The Nintendo/Game Boy analogy doesn’t hold water. Nintendo doesn’t give you a filesystem on the Game Boy, but it certainly doesn’t stop you from implementing one yourself. Nintendo doesn’t include a filesystem because that’s not part of the Game Boy’s platform model; it’s a console with fundamentally different goals and constraints. If you require a virtual filesystem to load assets for your game, Nintendo _will not_ slow your cartridge ROM down.

Windows, on the other hand, has always shipped with a general-purpose filesystem and encourages developers to use it for data persistence, caching, configuration, and more. In fact, the Win32 API is deeply file-centric. Even the OS has its own hidden virtual filesystem.

Windows is a Unix-inspired CP/M derivative, and both lineages are strongly file-based. In fact, when Windows tried to replace the filesystem with a database in Longhorn, they failed spectacularly, and only a few pieces of that design are left today. What still exists, however, is a filesystem optimized for storing files.

Suggesting that developers are "in the wrong" for relying on the filesystem on an OS that has always promoted it is like blaming drivers for expecting roads to be usable. We’ve been building software on Windows that reads and writes files for decades, with Microsoft’s full blessing.

If Defender or related tooling starts punishing valid, decades-old patterns like using a folder as a key-value store, that’s not a failure of developers to "understand Windows". It’s a regression in the OS, or at least a poor balance of heuristics.

We absolutely should question Microsoft’s design goals if they break longstanding, legitimate use cases without offering workable alternatives. Being dominant doesn’t make them immune to critique, especially when their changes have real-world consequences for maintainable, cross-platform software using well-established techniques.