Path: utzoo!attcan!uunet!mcsun!unido!ira.uka.de!fauern!tumuc!lan!rommel
From: rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel)
Newsgroups: comp.windows.ms
Subject: Re: himem.sys
Message-ID: <3652@tuminfo1.lan.informatik.tu-muenchen.dbp.de>
Date: 30 Jul 90 12:52:41 GMT
References: <1990Jul27.154843.21611@ux1.cso.uiuc.edu> <1990Jul28.212853.8561@ux1.cso.uiuc.edu> <8661@ur-cc.UUCP>
Sender: news@lan.informatik.tu-muenchen.dbp.de
Reply-To: rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel)
Organization: Inst. fuer Informatik, TU Muenchen, W. Germany
Lines: 33

In article <8661@ur-cc.UUCP> ttak@uhura.cc.rochester.edu (Timothy Takahashi) writes:
>In article <1990Jul28.212853.8561@ux1.cso.uiuc.edu> mcdonald@aries.scs.uiuc.edu (Doug McDonald) writes:

>>I discovered a new piece of info: If I include himem.sys (the win 3.0 one)
>>in my config.sys file but not smartdrive, then I CAN run my 386 programs
>>(with the Phar Lap extender) happily all day - UNTIL I run Windows 3.0
>>itself. After that, the 386 programs won't run until I reboot. Could

>Definately, somethings up here. Before I run Windows 3.0, the Dos 4.0 MEM
>command reports extended memory available. After I run Windows 3.0, squat.

Thats for compatibility reasons. Before any program or other driver
(like smartdrv) accesses extended memory via himem.sys, the himem.sys
driver makes itself transparent allowing older programs to access the
extended memory the old way.

After any program uses himem.sys (like smartdrv or Windows 3.0 or even
ramdrive), ALL extended memory can only be accessed via himem.sys.
This is not a bug.

Before you flame on himem.sys - What would you say, if an application
wants to bypass the EMS driver to access an Above Board?
The problem is, that the XMS specification was created very late and
several programs accessing extended memory directly were already on the
market. 

Kai Uwe Rommel

--
/* Kai Uwe Rommel
 * Munich
 * rommel@lan.informatik.tu-muenchen.dbp.de
 */