No, I don't think you did, how do you propose to prevent these sorts of conflicts outside of an API, remember we did have this, much to the detriment of stability, see Win95 and 98 for details.
Just because you can create the "perfect" app doesn't mean that everyone can.
...
If hardware that is backward compatible uses same I/O ports, IRQs, DMA channels-- there no conflicts to be resolved. When hardware vendors use their on I/O ports arbitrarily, their own IRQ channels, DMA channels then you have conflicts to resolve.
>If you're having to reinvent the wheel and have every application bang the metal to the extent the app requires, you are in effect writing a (partial) driver or framework for your application to sit on...
Ahhm, did you miss the list I gave of advantages; you wouldn't rewrite the driver-- the OS would have the functionality built-in without needing drivers and application would be able to go directly to hardware where driver functionality is not supported or inefficient (like palette example).
>The gains of hardware compatability, yes, lets add 10, 20, 30% extra silicon to every major I/O chip for stuff that's no longer used and long dead... Your entire argument is based on a fairytale world.
Sorry, you keep missing the point. That's your speculation 10-30% extra silicon. Even with some extra silicon, it's worth it given the benefits.
>Not in that post I didn't.
Okay, atleast you admit you did in some other posts.