Re: TIB: Lets Beat a horse


[Prev][Next][Index][Thread]

Re: TIB: Lets Beat a horse




I for one appreciate the beating!--D

Rosyna wrote:

> Sorry to beat a dead horse but...
>
> --- begin forwarded text
>
> Here's an article I picked up recently regarding DOS in Windows 95:
>
> Windows 95 is DOS 7 + Windows 4. Thats it. Nothing more to it. I don't
> see why people would need to debate that. Its not like it's a bad thing.
>
> As an example: When Windows 95 boots press F8 to get the screen where you
> can boot it in DOS-prompt only mode. Do that, and then go into your
> Windows 3.11 directory. Type WIN and, hey presto! your running Windows
> 3.11. Exit Windows 3.11 and go to the root. type Win, and your starting
> Windows 95. Then do select Shutdown and select "Restart the computer in
> MS-DOS mode". Does the computer restart? Nope, it exits Windows. No
> restart whatsoever.
>
> Not really. The difference really boils down to Win95 handles more things
> with VxD's than Win3 did. The architecture is about the same. It has to
> be...otherwise you would not be able to load DOS drivers and TSR's before
> Windows and have them appear in all DOS sessions. OS/2 can run DOS
> drivers and TSR's, but they only appear in the session in which they are
> loaded because there is no "underlying" DOS.
>
> Windows 3+ has always run DOS in V86 mode, and could always run multiple
> DOS sessions. The multitasking wasn't very good, but it could run
> multiple DOS sessions if you had patience.
>
> You're right, DOS is not used for all that much under Win95... but it
> wasn't under Windows for Workgroups either if you had 32-bit file access
> enabled.
>
> MS is following a strategy of gradual evolution. With each release of
> Windows, DOS becomes less important. But Win95 is not "all new". It
> relies quite heavily on 16-bit Windows 3 code, even for 32-bit programs.
> Many functions in USER32 and GDI32 are "thunked" down to the USER16 and
> GDI16. That's the origin of the "Win16MutEx" sema- phore that protects
> such code from being reentered. All programs, even 32-bit ones, get a DOS
> PSP structure. Which makes sense, as the old 16-bit Windows code relies
> on having that.
>
> Frankly, with all the thunking, the long interrupt handler chains, the
> mode transitions, etc, I am amazed that it performs as well as it does.
> But maybe it's not all that great...
>
> One article in Windows/DOS Journal this month is a study comparing the
> context-switch performance of '95 and NT. One would think that '95 would
> be faster, as it is Intel-specific and assembler-optimized, while NT is
> portable and written in C and C++.
>
> One would be wrong. According to the article, NT context-switches about
> twice as fast. The author speculates that it is all the thunking and such
> that kills performance. He points out that '95 has to go all the way down
> to DOS to context-switch, because it has to switch DOS PSP's. Going "down
> to DOS" involves quite a large number of traps and mode transitions, a
> lot of overhead.
>
> Conclusion is that if you are targeting Win95, you should think carefully
> before using threads. Using too many might make your application much
> slower than it would be otherwise.
>
> So, if DOS isn't used, why is all this thunking going on? Why are they
> giving each program a PSP, and switching PSP's on a context switch?
> Answer--DOS _is_ still being used for crucial functions. Whether this is
> good or bad is a different argument.
>
> To unsubscribe, send a message to: listmaster@marlowe.net and include the
> following in the body of the message:
> leave macmarines your_email_address
>
> (substitute the email address you used when joining for "youremailaddress")
>
> --- end forwarded text
>
> ---
> I pledge allegiance to the Mac of Apple Computer Incorporated, and to the
> developers for which it stands, one platform, under Guy, indestructible,
> with creativity and multimedia for all.



--

Douglas S. Oliver
Department of Anthropology
University of California
Riverside, CA 92521
e-mail: douglaso@citrus.ucr.edu
    or: dsoliver@earthlink.net



Follow-Ups: References: