glenn@dlcdev.UUCP (03/26/87)
In late Feb at Microsoft's Systems Software Seminar the "New DOS" was discussed. From the description: - Single-user, multi-tasking - 300K to 600K of code? (DOS 3.2 takes about 50K) - 189 function calls (DOS 3.2 has about 70) - Uses protected mode so applications cannot directly access hardware I wonder if New DOS is not just most of XENIX in DOS clothing. It sure looks like it to me. If this is the case then I guess New DOS will really be SLOW DOS. You remember that one of the main reasons 1-2-3 was so successful was that it directly accessed hardware and so ran quite fast. With New DOS this apparently will not be possible? One possible good consequence of this is that New DOS machines will not have to be "100% IBM compatible" since the New DOS will isolate applications from hardware thru device drivers, with actual hardware being "inaccessible" to applications? What say you?
campbell@maynard.UUCP (03/27/87)
In article <285@dlcdev.UUCP> glenn@dlcdev.UUCP (glenn) writes: >In late Feb at Microsoft's Systems Software Seminar the "New DOS" >was discussed. From the description: > >- Single-user, multi-tasking >- 300K to 600K of code? (DOS 3.2 takes about 50K) ... Oink. I just checked, and the VENIX/Rainbow kernel occupies less than 43K of code. VENIX/Rainbow is a real V7 UNIX port -- multi-user, multi-tasking, real pipes, semaphores, shared memory, virtual consoles, the works. Again, as I said, oink. -- Larry Campbell The Boston Software Works, Inc. Internet: campbell@maynard.BSW.COM 120 Fulton Street, Boston MA 02109 uucp: {alliant,think,wjh12}!maynard!campbell +1 617 367 6846
ted@imsvax.UUCP (03/31/87)
glenn@dlcdev.UUCP: Data Language Corp. >In late Feb at Microsoft's Systems Software Seminar the "New DOS" >was discussed. From the description: >- Single-user, multi-tasking >- 300K to 600K of code? (DOS 3.2 takes about 50K) >- 189 function calls (DOS 3.2 has about 70) >- Uses protected mode so applications cannot directly access hardware >I wonder if New DOS is not just most of XENIX in DOS clothing. It sure >looks like it to me. If this is the case then I guess New DOS will >really be SLOW DOS. You remember that one of the main reasons 1-2-3 >was so successful was that it directly accessed hardware and so ran >quite fast. With New DOS this apparently will not be possible? One >possible good consequence of this is that New DOS machines will not >have to be "100% IBM compatible" since the New DOS will isolate >applications from hardware thru device drivers, with actual hardware >being "inaccessible" to applications? What say you? I say you seem to have noticed the same thing which I have: that a great deal of money and energy has been spent in a manner likely to make very few if any people happier than they are now and many less happy. Going to ADOS or any of the new series of protected mode OSs on 286 equipment would involve giving up two things which seem critical to me: 1. All of the TSR software which allows us to modify the OS itself to our likeing. We would then have to HOPE that we would forever be satisfied with ADOS exactly as it came from Microsoft. 2. All of the huge body of really good software which has been written in 80x86 assembler. This includes professional packages like WordPerfect and 123, brilliant one-offs such as LPTX and key-do, and all sorts of things in between, as well as things such as the Cibray math library, the Lahey Fortran compiler etc. You don't get stuff like this being written for most multi-user machines because the market isn't there. Basically, the 286 protected mode is incompatible with the the existing body of DOS software and, while the 386 machines will be able to handle DOS windows, I have the feeling that they will go for some time being just slightly too expensive for most people to justify as single user machines and users will find themselves right back where they were in 1975, the boss simply adding a new terminal to the 386 every time a new employee is hired. Ted Holden
doug@edge.UUCP (04/10/87)
> In late Feb at Microsoft's Systems Software Seminar the "New DOS" > was discussed. From the description: > > - Single-user, multi-tasking > - 300K to 600K of code? (DOS 3.2 takes about 50K) > - 189 function calls (DOS 3.2 has about 70) > - Uses protected mode so applications cannot directly access hardware > > ... I guess New DOS will > really be SLOW DOS. You remember that one of the main reasons 1-2-3 > was so successful was that it directly accessed hardware and so ran > quite fast. With New DOS this apparently will not be possible?... Another consideration: if'n you put the '286 into protected mode, the CPU *itself* slows way down! So you end up with a slow CPU running applications which have to do long, slow operating-system calls in order to accomplish a simple "store byte into video buffer". The '386 is perhaps even worse. I am not surprised at published reports that beta sites for "MS-DOS 5.0" (as it was called at the time) found that a '386 machine running 5.0 was *slower* than a '286 machine running 3.x! It ain't a bug in the DOS, folks. -- Doug Pardee -- Edge Computer Corp. -- Scottsdale, Arizona
connery@bnrmtv.UUCP (04/13/87)
> Another consideration: if'n you put the '286 into protected mode, the > CPU *itself* slows way down! So you end up with a slow CPU running > applications which have to do long, slow operating-system calls in order > to accomplish a simple "store byte into video buffer". > 1) The 286 runs at least 50% FASTER in protected mode than in REAL mode. If you think about it, this is obvious--REAL mode is a simulation. 2) OS/2 will allow direct video updates just like the current DOS. -- Glenn Connery, Bell Northern Research, Mountain View, CA {hplabs,amdahl,3comvax}!bnrmtv!connery
ralf@b.gp.cs.cmu.edu.UUCP (04/14/87)
In article <631@edge.UUCP> doug@edge.UUCP (Doug Pardee) writes: >Another consideration: if'n you put the '286 into protected mode, the >CPU *itself* slows way down! So you end up with a slow CPU running >applications which have to do long, slow operating-system calls in order >to accomplish a simple "store byte into video buffer". > >The '386 is perhaps even worse. I am not surprised at published reports that >beta sites for "MS-DOS 5.0" (as it was called at the time) found that >a '386 machine running 5.0 was *slower* than a '286 machine running 3.x! >It ain't a bug in the DOS, folks. > >-- Doug Pardee -- Edge Computer Corp. -- Scottsdale, Arizona I can understand why the 386 would slow down in protected mode, but why should the 286 slow way down? The 386 potentially requires three memory accesses for each memory access in the program, due to virtual addresses being mapped by pages rather than by segments as in the 286. But why should the 286 require any additional memory accesses except when loading the segment registers? (on loading the segment registers, I imagine the 286 would fetch the segment descriptor from the segment descriptor table; thus, the only additional overhead would be during segment switching) Also, a smart operating system would not require a system call to write to the screen memory--it would simply set up a virtual screen (like TopView, DESQview, etc) that the application can do with as it pleases, and update the real screen memory every so often. BTW: I have PC-Write running in a DESQview window. PC-Write does as it pleases with the virtual screen, and DESQview updates the real screen about six times a second (== once every timeslice). If I am wrong about the overhead of protected mode on the 286, please let me know. (flames welcome by email, this office tends to be chilly) -- +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | ARPA: RALF@B.GP.CS.CMU.EDU "Teaching COBOL ought to be | | AT&T: (412) 268-3053 (school) regarded as a criminal act" | | Snail: Ralf Brown --- Edsger Dijkstra | | Computer Science Department | | Carnegie-Mellon University DISCLAIMER? Who ever said I claimed | | Pittsburgh, PA 15213 anything? | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ -- +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+ | ARPA: RALF@B.GP.CS.CMU.EDU "Teaching COBOL ought to be | | AT&T: (412) 268-3053 (school) regarded as a criminal act" | | Snail: Ralf Brown --- Edsger Dijkstra | | Computer Science Department | | Carnegie-Mellon University DISCLAIMER? Who ever said I claimed | | Pittsburgh, PA 15213 anything? | +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
brad@kontron.UUCP (04/16/87)
Glenn Connery writes: ... > > 1) The 286 runs at least 50% FASTER in protected mode than in REAL mode. > If you think about it, this is obvious--REAL mode is a simulation. ... Even a cursory look at Intel's iAPX 286 Programmer's Reference Manual will show this to be false. The simple facts about protected mode speed are: 1. Data manipulation instructions run at exactly the same speed in both real and protected modes. 2. Any instruction that alters a segment register (far jumps, calls, and returns, INT, IRET, LDS, LES) will be slower, as the new segment descriptors must be fetched and validated. This also applies to response to external interrupts. Brad Yearwood Kontron Electronics {voder, pyramid}!kontron!brad Mountain View, CA
caf@omen.UUCP (04/16/87)
In article <1622@bnrmtv.UUCP> connery@bnrmtv.UUCP (Glenn Connery) writes:
:> Another consideration: if'n you put the '286 into protected mode, the
:> CPU *itself* slows way down! So you end up with a slow CPU running
:> applications which have to do long, slow operating-system calls in order
:> to accomplish a simple "store byte into video buffer".
:>
:
:1) The 286 runs at least 50% FASTER in protected mode than in REAL mode.
: If you think about it, this is obvious--REAL mode is a simulation.
On the "siev" benchmark, using the same computer and the same compiler,
siev runs no faster under Xenix (protected mode) than it does under DOS
(real mode). If anything, real mode is a hair faster. This applies to
small model programs, large model programs take more cycles to change
segments when in protected mode.gemini@homxb.UUCP (Rick Richardson) (04/16/87)
In article <1622@bnrmtv.UUCP>, connery@bnrmtv.UUCP (Glenn Connery) writes: > > Another consideration: if'n you put the '286 into protected mode, the > > CPU *itself* slows way down! > > 1) The 286 runs at least 50% FASTER in protected mode than in REAL mode. The way I heard it, protected mode is faster than real. I remember a conversation I had with one of the Venix (Unix) OS developers, and he said that when they went from real mode to protected mode Venix on the PC/AT, context switches were 30% faster. Rick Richardson, PC Research, Inc: (201) 922-1134 ..!ihnp4!castor!pcrat!rick when at AT&T-CPL: (201) 834-1378 ..!ihnp4!castor!polux!rer
john@xanth.UUCP (04/17/87)
In article <225@homxb.UUCP>, gemini@homxb.UUCP (Rick Richardson) writes: > The way I heard it, protected mode is faster than real. I remember a > conversation I had with one of the Venix (Unix) OS developers, and > he said that when they went from real mode to protected mode Venix on > the PC/AT, context switches were 30% faster. Yes, context switching will be much faster in protected mode, since a protected mode context switch will only involve changing a few words in descriptor tables and the like, while a real mode context switch would involve a decent amount of copying, especially with a straight UNIX kernel port, which assumes that "u" (for user) area associated with each process is at a fixed location. With real mode, you copy the process' u areas into and out of the fixed u area; with protected mode, you just change the segment descriptor.... Typically, though, other operations will be somewhat slower. -- John Owens Old Dominion University - Norfolk, Virginia, USA john@ODU.EDU old arpa: john%odu.edu@RELAY.CS.NET +1 804 440 4529 old uucp: {seismo,harvard,sun,hoptoad}!xanth!john
steve@edm.UUCP (04/19/87)
In article <225@homxb.UUCP>, gemini@homxb.UUCP (Rick Richardson) writes: > In article <1622@bnrmtv.UUCP>, connery@bnrmtv.UUCP (Glenn Connery) writes: > > > .... put the '286 into protected mode, the CPU *itself* slows way down! > > 1) The 286 runs at least 50% FASTER in protected mode than in REAL mode. > > he said that when they went from real mode to protected mode Venix on > the PC/AT, context switches were 30% faster. Although context switches may be faster, I understand that actual WORK is alot more expensive. Namely: changing any of the index registers can take a LONG time to execute because of having to load new MMU info. This effectively means that the more memory you use, THE SLOWWWEERRRR the application runs (as a general rule). Also: I understand that Digital had some serious performance problems getting concurrent PC-DOS running in protected mode. Can anyone comment on this? -- ------------- Stephen Samuel {ihnp4,ubc-vision,seismo!mnetor,vax135}!alberta!edm!steve
alexande@drivax.UUCP (04/23/87)
In article <141@edm.UUCP> steve@edm.UUCP (Stephen Samuel) writes: > Also: I understand that Digital had some serious performance problems >getting concurrent PC-DOS running in protected mode. Can anyone >comment on this? 286 Protected mode isn't so much of a problem if you're running a program that was written specifically for protected mode (i.e. uses nice selectors, not physical segments). The performance problem comes in when you try to run real-mode programs (e.g. all existing DOS applications) in protected mode. Every time the DOS program loads a segment register, a protection exception occurs, because the value being loaded is a physical segment number, not a selector. So the OS has to jump through some very nasty (and slow) hoops to fool the DOS application into thinking it's running in real mode. DOS programs that were written for small model (few segment register loads), and which don't try to write directly to physical devices (like screen memory) can run pretty nicely in protected mode. The Lattice C compiler is a good example of a "nice" program. This performance problem is probably one reason why Microsoft chose to allow older DOS applications to run on their ADOS by switching back and forth between protected mode and real mode. DRI Concurrent DOS-286 stays in protected mode all the time. The 386, with its virtual 8086 mode, should fix a lot of these problems. -- Mark Alexander ...{hplabs,seismo,sun,ihnp4}amdahl!drivax!alexande "Omit needless words! Omit needless words! Omit needless words!" - W. Strunk