Hey Doug,

>I would imagine so. However, the difference was in how memory was managed. Remember Bill gates saying that there would be no way we'd ever use more than 640K? <g> Well, the 80x86 family of chips thought that was just fine - until reality intervened. <g> hence a few years of screwball memory management schemes plus a few ok to good ones and finally we've managed to get that family of chips where they are linear rather than segmented (paged).

Well, to give Bill some credit, it certainly appeared to be so way back when.

>Remember QEMM? That wa sone of the pretty good managers. Goodness.. Foxplus and the early Foxbase & FoxPro were kick-butt programs primarily because of the Watcom C memory manager. Pharlap? Lots better than MSFT's at that time if I correctly recall.

Ahh, Quarterdeck. Aren't they still (barely) in business?

Not to go off on a rant, but back to the main issue: memory management. Today's developer is so far insulated from the hardware that any decent application is going to be a pig. In around 1990, if not before, things shifted: PC operating systems went from being productive to being user-friendly. It used to be that developers took great joy from squeezing a few more bytes out of an application. One could do a good app in about 40K with a decent interface. Now a marginal Win app takes up a couple of MB. Why? Well, first we coded to the pre-DOC machine (assembler and tweaked 2 and 3GLs in the late 70's and early 80's). This was optimized to the point where we only had to support functions we used or were in ROM/BIOS. Then, with the rule of DOS, we coded to the DOS interrupt and EXE link files (more mem used)....here came some baggage. Now we code towards WinAPIs, whether nakedly or via a higher level code function. More and more baggage.