Date: Wed, 19 Feb 1997 11:00:23 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jamie@inna.net (Jamie Bowden) Cc: terry@lambert.org, toneil@visigenic.com, jfieber@indiana.edu, hackers@freebsd.org Subject: Windows95: what you don't know, you must reinvent Message-ID: <199702191800.LAA13334@phaeton.artisoft.com> In-Reply-To: <Pine.BSF.3.91.970218210847.274F-100000@dolphin.inna.net> from "Jamie Bowden" at Feb 18, 97 09:10:39 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > It's still just dos/windoze. > > > > It's mostly DOS/Windows. A lot of it isn't, particularly the VM and > > the scheduler code. > > Which you only get if you start the gui. You're still in dos, new and > improved? maybe :-/, but still 16 bit operating environment. Wrong. 16 bit code will not run in Windows95 without extreme measures; these measures are described in detail in the DDK documentation in DDK\DOCS\STDVXD.DOC and VMM.DOC. 16 bit code must be run in a seperate VM, or in the system VM in a part of the legacy scheduler interface used for Windows3.x compatability, which Microsoft calls "Appy Time"; it is similar to bouncing signals to user processes in BSD. The big "wart" on Windows95 is the mapping of some crap required by non-Win32 backward compatability modes into each process address space. OS/2 instances this instead, and manages instance conflicts, which is why it's more reliable, but slower running DOS boxes... sometimes much slower. It was a conscious "memory protection vs. OS/2 winning the market" trade off, given the lack of Win32/Win32s programs vs. the number of legacy apps they would orphan. It is for this reason that I suspect the useful lifetime of Windows95 at no more than 2 more years until these applications must use OS/2-style instances, paying the higher performance penalty for not being Win32 programs, probably in an OS derived from Windows NT Worksatation. For what it's worth, *NOW* is the time for BSD to look at fully supporting the Win32 API. Linux too, for that matter. In general, 32 bit code communicates with 16 bit code using a mechanism called "thunking". To get this back to being topical for the list it is being posted to, it would be useful for BSD to implement a virtual machine manager similar to Windows95's (and NT's) so it, too, could "thunk", even if we did not support "CallAtAppyTime" interfaces because we didn't dip into real mode in the scheduler to make drivers and TSR's in the default real mode VM happy by simulating calls to the "DOS not busy" interrupt. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702191800.LAA13334>