> I was always under the impression that Microsoft does not fix or is extremely slow at fixing particular virus-allowing bugs due to their business model of licensing access to system features, you have to access to be able to build an antivirus software.
That's bollocks. Unlike Apple which requires Apple's blessing ("entitlement") to access "sensitive" APIs or to load kernel-mode drivers (and is known to randomly grant or deny them), all you need for distribution of a Windows driver is an EV Code sign certificate (from Vista and above) and additionally from Windows 10 onwards to submit the binary to Microsoft for attestation (which likely means they'll run static analysis to check for malware and that's it).
It should not take an experienced programmer more than a couple of weeks to develop the kernel-mode interface of a basic anti-virus/firewall solution that monitors process, registry, file and network access and passes the data to an user-mode analyzer (the latter are the easiest, all you need there is a simple filter driver)... the stuff where it gets tricky is when AV vendors access internal kernel APIs and data structures to check for malware modifications to hide itself. Malware doesn't care much if Microsoft updates something it needs, but AV software should not break down after a kernel upgrade, which is why the stakes for AV vendors are so much higher.
What Microsoft does sell is access to the source code via the Shared Source program [2] - while there is no official program aimed at AV vendors, you can bet that there is a separate program available for the half-dozen major AV vendors there are.
As for "MS is so slow at fixing bugs": the one thing Microsoft cares and what guarantees it the money it makes is backwards compatibility and operating stability. You can take virtually all major Windows 95-era software and it will run unmodified on a modern Windows 10 machine, well over 25 years after its publication - a promise that the Linux kernel upholds but the userland (distributions) does not give a fuck about, and Apple doesn't care much about software written for obsolete platforms at all (see e.g. dropping Rosetta and 32-bit support after the last hardware based on them went obsolete). And unlike Apple, Microsoft has to check all updates in kernel and user land against a literal shitton of hardware combinations and software to make sure no bugs are introduced.
As a user, you can load a third-party kext on macOS without Apple's blessing, even on the M1, but you have to jump through a lot of hoops to do that. I'm not even sure the thing needs to be signed with a developer ID certificate, but that would probably reduce the number of warnings to click through.
Though Apple is now moving towards more of a microkernel architecture, where entire classes of what used to be kernel extensions are now userspace processes. VPN services, network filters/firewalls, some but not all device drivers, etc.
> As a user, you can load a third-party kext on macOS without Apple's blessing, even on the M1, but you have to jump through a lot of hoops to do that.
Agreed, but that's not a reasonable way to distribute any piece of software to an audience that's not a bunch of hardcore hackers. The easiest way for "old" Intel Macs is to install OpenCore which can inject kexts before the kernel even gets execution, but for M1 I'm completely lost.
That's bollocks. Unlike Apple which requires Apple's blessing ("entitlement") to access "sensitive" APIs or to load kernel-mode drivers (and is known to randomly grant or deny them), all you need for distribution of a Windows driver is an EV Code sign certificate (from Vista and above) and additionally from Windows 10 onwards to submit the binary to Microsoft for attestation (which likely means they'll run static analysis to check for malware and that's it).
It should not take an experienced programmer more than a couple of weeks to develop the kernel-mode interface of a basic anti-virus/firewall solution that monitors process, registry, file and network access and passes the data to an user-mode analyzer (the latter are the easiest, all you need there is a simple filter driver)... the stuff where it gets tricky is when AV vendors access internal kernel APIs and data structures to check for malware modifications to hide itself. Malware doesn't care much if Microsoft updates something it needs, but AV software should not break down after a kernel upgrade, which is why the stakes for AV vendors are so much higher.
What Microsoft does sell is access to the source code via the Shared Source program [2] - while there is no official program aimed at AV vendors, you can bet that there is a separate program available for the half-dozen major AV vendors there are.
As for "MS is so slow at fixing bugs": the one thing Microsoft cares and what guarantees it the money it makes is backwards compatibility and operating stability. You can take virtually all major Windows 95-era software and it will run unmodified on a modern Windows 10 machine, well over 25 years after its publication - a promise that the Linux kernel upholds but the userland (distributions) does not give a fuck about, and Apple doesn't care much about software written for obsolete platforms at all (see e.g. dropping Rosetta and 32-bit support after the last hardware based on them went obsolete). And unlike Apple, Microsoft has to check all updates in kernel and user land against a literal shitton of hardware combinations and software to make sure no bugs are introduced.
[1]: https://docs.microsoft.com/en-us/windows-hardware/drivers/da...
[2]: https://www.microsoft.com/en-us/sharedsource/