No one wants apps to directly interface with hardware. Imagine loading up a notes app and it directly trys to interface with your hard drive using its own built in FS driver and a bug in that causes your whole drive to be wiped.
Or that you open two programs at once and they try to access the same device at once causing some kind of error and likely data loss or system instability.
I don't even want apps to directly have access to the file level interface of my storage but rather an extra abstraction which lets me pick which files it can access.
> No one wants apps to directly interface with hardware.
I build computer kiosks and I agree wholeheartedly. So many devices/peripherals require some sort of custom implementation. Most have some sort of SDK, but not all. Better hope that SDK comes in your tech stack's language(s) of choice.
Why isn't it just data in / data out?
Even printers and scanners are a pain to deal with. Sure, Windows (and TWAIN) abstracts some of the printer/scanner communication, but it all seems forgotten. Like, why is using new hardware in my software so difficult and how come I can't just implement new hardware the same way every time? To me, it's all just data in/data out from my language runtime to the device. I couldn't care less about the implementation details in between.
I certainly write plenty of code where I write to registers directly to configure hardware modules and don't think I'm using an OS in any way. I assume most of the security design and hardware permissions are handled at a higher level than I usually write code.
