No, I can imagine it. I worked on an embedded device that I think worked this way (vxWorks), though I didn't get into the device driver side of things very muc

No, I can imagine it. I worked on an embedded device that I think worked this way (vxWorks), though I didn't get into the device driver side of things very much. But it's still a bad approach for general computers, for two reasons. 1. With the current setup, we need an OS that detects the hardware and loads the right code. With Chuck's proposal, that responsibility - and the code to do it - moves to every application. Since there are far more applications than OSes, this is highly inefficient. 2. Let's say I buy an application, and then some time later I buy a new computer. If the new computer has a compatible OS, I can just run the existing program on the new computer. But under Chuck's approach, I need a new version of the program as well - one that knows how to detect the new hardware, and what drivers to load in response. So (virtually) nobody is going to do it that way. It might have made sense when you were fighting for every byte of memory, but that isn't the world we live in any more, and it hasn't been for decades.