> About the first one, that's also another problem, BIOS doesn't have standard protocol, if there would be such, there would be one standardized way to detect t

> About the first one, that's also another problem, BIOS doesn't have standard protocol, if there would be such, there would be one standardized way to detect the memory layout. It's the same for almost all hardware: graphics cards, sound cards, all use their own register map (which, to make the matter worse, is often kept secret). Even USB stuff, which is supposed to be already homogeneized (i.e USB classes) often requires sending vendor-specific "quirk" strings to get the hardware working (e.g the list of 'quirks' in the snd-usbmidi Linux kernel module). The hardware diversity isn't a detail here. It's the root of the "too many abstractions" problem, and I don't think this is something you can avoid. This is why device drivers exist. This is why operating systems try hard to impose APIs on device drivers (ALSA, Direct3D, etc.) so Firefox, MS Word, Half-Life ... can run on future hardware. This is one reason why the abstraction layers exist (I'm not even talking about memory protection / safety here) : because you don't want to re-release your app every time some vendors makes a new sound card, graphics card, MIDI interface, wi-fi chip, etc. And you don't want to code the support for all this hardware yourself.