Xref: utzoo comp.windows.ms:11746 comp.sys.ibm.pc.misc:8846 Path: utzoo!utgpu!news-server.csri.toronto.edu!csri.toronto.edu!wayne Newsgroups: comp.windows.ms,comp.sys.ibm.pc.misc From: wayne@csri.toronto.edu (Wayne Hayes) Subject: Re: OS/2 2.0 is here! READ THIS, you'll be impressed Message-ID: <1991Apr21.175529.2386@jarvis.csri.toronto.edu> Organization: CSRI, University of Toronto References: <1991Apr21.135534.724@jarvis.csri.toronto.edu> <1991Apr21.194928.8267@ux1.cso.uiuc.edu> Date: 21 Apr 91 21:55:29 GMT Lines: 95 In article <1991Apr21.194928.8267@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes: >> And with >>a decent, *efficient* scheduler. (Downloading at 9600bps on my 33MHz 386 >>takes 30% of my processor time under Windows 3.0! It shouldn't take more >>than 5%.) > >How do they do that? Magic?? What do they do with wait loops? Actually you're right. I chose a bad example. A terminal program probably has lots of wait loops that would require near magic to detect and eliminate. My point was, how often do you try running multiple truly CPU intensive DOS applications under Windows? Whenever I do, I get significantly less than 1/n the performance of the machine. This can be (and is) fixed under OS/2 because 1) Disk *writes* can be buffered under HPFS. As far as I know, all the DOS disk cachers under FAT are write-through, so that you can turn your machine off immediately after doing a write without losing data. Since HPFS needs an official shutdown command, it can buffer writes until such time as the disk is available for non-thrashing writes. (All the time-outs and such are configurable if you so wish.) But it still has amazing recovery in the event of a power failure. You won't lose anything except stuff that was written within a few seconds of the power failure. 2) You don't share a single DOS session and there's no requirement to handle all disks requests sequentially. In other words, DOS has a single threaded file system whereas HPFS is multi-threaded. This is also the reason Windows *completely* dies during floppy access. OS/2 does not have this problem. 3) I'm not a DOS expert, but I believe there is significant overhead in task switching between two DOS sessions that are really only using the single DOS session available under Windows. OS/2 runs all DOS sessions completely independently, and thus is far more efficient at switching between them. >>Not enough? How about a new file system (HPFS == High Performance File >>System) > >In other words, a fatal flaw! (Unless, of course, it can be turned off.) First, yes, you can "turn it off" in that you may choose not to install it in the first place, and OS/2 will use plain old FAT. But why in the world would you want to? Well-behaved DOS apps can easily have all disk accesses trapped and translated to the HPFS equivalent OS/2 calls without the DOS app's knowledge. Even some moderately-behaved apps can be handled. Only the truly nasty ones that try direct hardware access will fail, and most developers don't write those any more because they know things like that won't run even under Windows 3.0. (Yes, that *slightly* diminishes the claim of running your DOS 1.1 spreadsheet if it tries hardware access, but this feature is far more probable to be used with say, DOS 3.x, 4.x and maybe 2.x.) This is because OS/2 is running in 386 protected mode and can "see" all memory access and translate from FAT language to HPFS language. But installing HPFS means completely re-formatting your hard drive. So you back up your current partitions, and restore under the DOS box after installing OS/2. Big deal. It's well worth the massive increase in performance you'll get. I used OS/2 1.2 under FAT for a few months and then reformatted to HPFS on the advice from a co-worker. I was *amazed* at the difference. I could *feel* the system running faster. Why is this a fatal flaw? This is the computer industry. You're going to have to give up your old nasty DOS 1.x and 2.x apps eventually and look to the future. >Does it put all those DOS and Windows 3.0 programs in windows?? Including >DOS graphics programs? Like I said, I haven't seen it running yet. It *is* ready to ship, and I've ordered an internal Beta copy (probably get it Monday). The official copies will be going like hotcakes and IBM empolyees are going to have to wait for awhile before getting it. But yes, it runs DOS apps in a window, just like Windows 3.0 in 386 enhanced mode can. And you weren't listening when I said that it will run Windows 2.x and 3.x applications NATIVELY, ie WITHOUT starting up a DOS box, *side by side* with "real" OS/2 applications under Presentation Manager. I'm not sure about graphics programs; I've read so much info internally over the past 2 days. I *do* recall someone talking about a bug being fixed that allowed some graphics programs to be *displayed* under PM. In fact Windows 3.0 in enhanced mode can display DOS graphics programs in a window -- it can't *run* them all because most do direct writes to the video RAM and thus can't run concurrently with Windows. I suspect PM (Presentation Manager, the window manager for OS/2) has similar limitations. You probably wouldn't want to do this anyway. Trapping I/O instructions for writing out blocks of data to disk and translating to OS/2 calls can be done fairly efficiently. But trapping individual machine language instructions that access video memory would be incredibly slow no matter how smart you did it. Windows 3.0 can simulate CGA on my SuperVGA screen, but the graphics run 11 times slower (I just timed it using Fractint). -- NOTICE: Due to the complexity of nearly all topics, the opinions expressed above are in continual process of formation and may be changed without notice. Wayne Hayes INTERNET: wayne@csri.utoronto.ca CompuServe: 72401,3525