winscape 2275

Oh, so we're talking science fiction then.

Ok, so what do I do when the vendor doesn't support the language I want to use? Or do they know better than I what I should be using?

So we're buttuming the compiler can be trusted to not generate bad code. Do I get to look at object dumps and go down to buttembly debugging if I need to trace a bug?

What if the vendor compiler generates lousy, slow code and I happen to know of application specific optimizations that cut huge fractions off my runtime? Is all my investment in OS (and $$$ vendor compilers) now wasted? Why the hell should I use this slow, inflexible system when I can code in native buttembly on a compebreastor's machine?

I buttume there is something making the vendor programs not "wild"? Since when has an OS vendor ever been a paragon of good practice? I'd agree that OS vendor code is often better than 3rd party code- but it often isn't.

What happens when I need to control some fiddly bit of hardware that the OS isn't set up to allow me to mess with? At some point I'll need to get an executable key for my magic driver. Now wild, 3rd party code is in the OS. At that point I might as well sign everything and use my compiler of choice, conformant with the OS ABI. Oops- can't get that because Vendor Knows Best and they don't allow anyone to access their hardware.

It would have been about as much as a success as driver signing has been in Windows. In other words, irrelevant for anything except PR.

And further, how can you sit there and propose that people use an buttembly emulator on an 8088 system (since thats where you propose it would be of some use) and not expect them to lose their shirts in performance? Its one thing to emulate an Atari 800 on a modern workstation with reasonable fidelity- very much another to do what you suggest.

Gregm