>Perhaps, but there's one thing here, that may not get enough attention. How much of a role it plays, I can't say. Perhaps someone a little better versed than I (like Ed Rauh) might know. What I'm talking about is the underlying character based ROM BIOS. These machines were never initially designed to do what they're doing now. If they had been built from day one (like the Mac) to handle the GUI interface, how much different (and probably more reliable) product would we have?
>
In the Win32 environment, we have little or no dependency on the ROM BIOS code beyond POST and bootstrap. Win9x, which still has its underpinnings in DOS, makes use of ROM BIOS code in a few, relatively rare, circumstances; it relies on standard ROM services when forced to run in a compatibility mode (for example, where you have a legacy device with ROM BIOS that doesn't have protected mode support available, like some old, strange disk controllers), when running in MSDOS compatibility mode (essentially, Win9x is not loaded, and only the DOS and ROM BIOS services are accessible) or running in Safe Mode, where no protected mode drivers are loaded and the ROM BIOS is used to handle standard devices to avoid the need for drivers.)
NT has no dependency on ROM BIOS beyond the point where NT's loader starts up; all ROM services are virtualized, and normally replaced entirely with NT kernel code. This virtualization (along with HAL, and OS blocking direct access to some system board functions) is part of the reason that many DOS apps don't run right under NT.
There are lots of problems with the core BIOS for PC compatible systems; one of the biggest is that BIOS code is generally not reentrant, and doesn't understand or allow for multiple processes that may need to access ROM BIOS managed devices at the same time. In addition, the ROM BIOS code runs in real mode, a different memory model than Win32 uses.
There were abortive attempts to make the ROM BIOS more useful to protected mode systems; IBM's EBIOS extensions for the PS2 were designed nfrom the start to make their service usable by the OS/2 kernel, with reentrance and protected mode functionality built in. ABout the only concessions to protected mode environments is code added to the BIOS to accurately reflect the memory installed on the system.
>>I can still bring an NT server to its knees by doing some kind of heavy duty processing on it.
>>
Given the right problem, or the wrong approach to solving one, you can bing almost anything to its knees. I can tell stories about eating a few hours on a big Cray network doing traffic analysis problems.
>>Hopefully when the 64 bit chips arrive they will be able to handle all the processing thrown at them and
>>
More hardware always helps. So does better programming. We often pay a huge price by using the wrong tool to do a job; if I need linked lists, tight control over memory resources, and have a problem where several things should be active at once, to some extent independently of other parts of the problem, or where direct interaction with system resources is needed, VFP is probably the wrong tool to use
for at least part of the task at hand, and trying to use an interpreted, data-oriented language will require much more hardware than a language like C++.
OTOH, it's probably not cost-effective to write a small database app in hand-coded machine language; I'll gladly trade ndisk space for development and maintenance time here.
>>You're absolutely correct to point out the fuzzy nature of today's programs though. I must confess to being *quite* attracted to the n-tier world. Makes lots of good common sense to me.
>>
>N-Tier makes a lot of sense, just as dynamic linking did previously. On reflection, it occurred to me that it falls nicely in line with the top-down design paradigm. I think it was just that we never considered separating the UI before. I believe that it will help us in creating more stable apps by foricing us to pay greater attention to the overall design and purpose. Just a thought, though.
