Microsoft has some real problems with third-party drivers. They’re a huge source of instability and security vulnerabilities but they’re also responsible for preventing improvements in the overall NT code base. For example, NT drivers typically poke at userspace memory directly and use SEH to catch faults. In contrast, most other operating systems have a copy-in / copy-out model. The copy helpers can do things like disable SMAP for the duration of the call or use special read-from-userspace instructions. NT can’t enable SMAP as long as drivers are loaded that may not use this kind of helper.
Copy helpers also provide a clean point to support multiple APIs. A few years ago, I supervised Konrad Witaszczyk’s masters project, where he implemented a proof of concept for type-aware copy helpers. These let you parse a header file with two different targets (the kernel one and the userspace one) and generated a copy helper for each annotated structure, so 32-bit compatibility layers were basically free: pointers, size_t, and so on get zero extended. 64-bit compatibility on CHERI platforms were similarly free: pointers become capabilities derived from the target process’s default data capability. Structure padding was never copied and so you didn’t worry about kernel information leaks from copying uninitialised structures.
It’s easy to move to this kind of model and get all of the benefits if you control all of the in-kernel code. Linux happily breaks out-of-tree drivers in minor releases. FreeBSD breaks them between major releases. macOS no longer allows any third-party code in the kernel at all, so it’s only NT that has this problem.
This is made worse by the fact that a bunch of the features that are worst for security are actively used by antivirus vendors and so you can’t improve security without breaking antivirus software (which risks antitrust things being reactivated).
I had hoped that XPS (introduced with Vista, iirc?) would be the Microsoft version of Postscript and become the universal printer language but that seems to have gone by the wayside.
Good, I’m happy Microsoft has joined the rest of the world in using the decades-old standard for print output instead of forcing a brand-new reimplementation of another wheel :)
I am not able to ascertain via web searching whether or not Mopria (the new universal print driver framework) supports PostScript passthrough or if all our printed text will have the trademark blurry HP PECL look, as if you printed a jpeg just shy of being at a sharp enough enough resolution. With inkjets it doesn’t make a difference but with lasers it is a night and day difference.
Microsoft has some real problems with third-party drivers. They’re a huge source of instability and security vulnerabilities but they’re also responsible for preventing improvements in the overall NT code base. For example, NT drivers typically poke at userspace memory directly and use SEH to catch faults. In contrast, most other operating systems have a copy-in / copy-out model. The copy helpers can do things like disable SMAP for the duration of the call or use special read-from-userspace instructions. NT can’t enable SMAP as long as drivers are loaded that may not use this kind of helper.
Copy helpers also provide a clean point to support multiple APIs. A few years ago, I supervised Konrad Witaszczyk’s masters project, where he implemented a proof of concept for type-aware copy helpers. These let you parse a header file with two different targets (the kernel one and the userspace one) and generated a copy helper for each annotated structure, so 32-bit compatibility layers were basically free: pointers, size_t, and so on get zero extended. 64-bit compatibility on CHERI platforms were similarly free: pointers become capabilities derived from the target process’s default data capability. Structure padding was never copied and so you didn’t worry about kernel information leaks from copying uninitialised structures.
It’s easy to move to this kind of model and get all of the benefits if you control all of the in-kernel code. Linux happily breaks out-of-tree drivers in minor releases. FreeBSD breaks them between major releases. macOS no longer allows any third-party code in the kernel at all, so it’s only NT that has this problem.
This is made worse by the fact that a bunch of the features that are worst for security are actively used by antivirus vendors and so you can’t improve security without breaking antivirus software (which risks antitrust things being reactivated).
I had hoped that XPS (introduced with Vista, iirc?) would be the Microsoft version of Postscript and become the universal printer language but that seems to have gone by the wayside.
Good, I’m happy Microsoft has joined the rest of the world in using the decades-old standard for print output instead of forcing a brand-new reimplementation of another wheel :)
I am not able to ascertain via web searching whether or not Mopria (the new universal print driver framework) supports PostScript passthrough or if all our printed text will have the trademark blurry HP PECL look, as if you printed a jpeg just shy of being at a sharp enough enough resolution. With inkjets it doesn’t make a difference but with lasers it is a night and day difference.