=> Hal, just for fun, imagine IBM adding a new access method => (XAM) and then burning the 390 OS onto a chip.
They could do that today and IIRC already have but the maintenance logistics are too burdensome. When you have an OS that is fully reentrant and hardware that supports a very high level of memory allocation guarding (unlinke Wintel), you can dump everything on a chip and walk away from it. => => If you recall structured programming constructs implemented => with macros, you know that the macro assembler could have => provided proper building blocks all along, but we didn't see => it that way because we were mesmerized by so-called 4GL => languages that never really coalesced, which is essentially => why we have too many choices today. => I never felt that way because when you are "in bed" with the hardware, as one is with assembler, it is difficult to see any (and I mean any) advantage to changing partners simply because of a pretty face. After all, beauty is only skin deep and under that skin you are still running with the same instruction-set-architecture. So I never fell for that stuff. => I started xBase with dBaseIII because it seemed to me that => of all the PC languages available at the time, it was head => and shoulders above the rest. In fact, surveying what's => available today, I *still* think that's the case. => => I know this isn't going to do any good, but I'll say it => anyway: MS be damned for what they didn't do with the best => of the 4GL language breed! I started because someone had a problem with an app written in FoxBase and asked me to fix it. Fortunately, that person had a dBase manual to lend me :) The reason there are no x86 assembler programmers to speak of is that Intel never pushed it and never really had to once M$ came around. I used Intel's assembler-like product, PLM, and found it quite powerful. How could it not be powerful? It exposed every nook and cranny of the hardware and made it all accessible. And it really is simple at that level. It's the OS and API that gets laid on top that can really drive you batty and M$ gets first place every time worst design. It's hard to imagine a design that is worse. => => As to the macro assembler + XAM + 390 in a chip, a part of => me says it's too late now to go back and do the whole thing => over again, but then the other part says what else are we => going to do - throw some more languages at the problem? => => FWIW, I'm sticking with VFP. I've got a huge investment in => the product and think we're not going to have real problems => for at least a decade. => When the moment of truth does come, we'll have better => choices then we do today. IBM, for example, isn't about to => let this country lose it's most important advantage in the => world economy. Ain't going to happen. Will it mean putting => OS390 onto a chip? I think so. Will it mean an XAM access => method? I have no idea, and I probably even doubt it, but I => do believe it would be a very smart move. Me too. I've been forced to accept the fact that Stanley Works no longer manufactures Yankee® screwdrivers and Skil won't be selling battery chargers for the best 9.6v drill ever made. But I don't have to accept the end of VFP, only VFP as we know it. It is a great product in a great package. => => Bill => B+ HALinNY _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[EMAIL PROTECTED] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
