>>It's wrong when it's wasted to cover the M$'s writing slower and slower system software. Remember the old article "why does your hardware vendor smile when you say you want a machine to run Windows?". It's been some ime in '92 or so, but still holds.

>I'll grant you that MS's internal code (for anything) is not the fastest or leanest that it could be, but it works and is cheap. We as Dev and users have to take some of the credit and blame for the "slower and slower system software". We want all the bells and stuff and we want it now! I hated Windows back in the 86 days. Loved Dos- Fast efficient all that stuff, but I don't want to go back, maybe you do. I don't miss having to try and find a print driver for every program I have. I really like WYSIWYG. If you or I or MS took the time to make sure that we always have the leanest fastest code, I would venture to say that we would starve to death, because when it finally got released it would be totally obsolete.

The more progress I make in VFP, the more I hate to have to go back to DOS to do mainainance (and development!) in FPD.
The printer-and-other-stuff-drivers were not the ugliest thing, but you wouldn't know the Ugliest Thing because your codepage is 437. Every app which used any graphics came with its own set of fonts, and, of course, never heard of our diacriticals. That was the firmest Murphy's law.

"Leanest and fastest" - no, I don't expect that. What I wish for, is if they didn't push a technology change every once in a while (and rename *.* +.+ too), and then ship it before it's mature. I think the last word in M$ regarding release approval doesn't come from any of programmer staff - it comes from the marketing. If they took some more time on thoroughly debugging most of the things beta testers found... they wouldn't leave them for next service release.

Ever seen GEM? It was written for 68000, but ported to x86 - I've seen it perform on a 8MHz XT equally fast as Win3.1 performed on a 33MHz 386. And it took only 16K of EMS. And had it all.