Path: utzoo!attcan!uunet!samsung!usc!wuarchive!uwm.edu!ux1.cso.uiuc.edu!aries!mcdonald
From: mcdonald@aries.scs.uiuc.edu (Doug McDonald)
Newsgroups: comp.windows.ms
Subject: Re: himem.sys
Message-ID: <1990Jul30.140806.28045@ux1.cso.uiuc.edu>
Date: 30 Jul 90 14:08:06 GMT
References: <1990Jul27.154843.21611@ux1.cso.uiuc.edu> <1990Jul28.212853.8561@ux1.cso.uiuc.edu> <8661@ur-cc.UUCP> <3652@tuminfo1.lan.informatik.tu-muenchen.dbp.de>
Sender: usenet@ux1.cso.uiuc.edu (News)
Reply-To: mcdonald@aries.scs.uiuc.edu (Doug McDonald)
Organization: School of Chemical Sciences, Univ. of Illinois at Urbana-Champaign
Lines: 44

In article <3652@tuminfo1.lan.informatik.tu-muenchen.dbp.de> rommel@lan.informatik.tu-muenchen.dbp.de (Kai-Uwe Rommel) writes:
>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.
>
FLAME ON!

No, that in itself is not a bug, agreed. BUT what is a bug is that himem.sys
supplied with Win 3.0 doesn't work - I have not found a single program -
other than the ones supplied with Windows 3.0 - that will get extended
memory from it. There are STANDARD methods for supporting extended memory.
Himem.sys should support those methods. If itr wants to ADD extra methods,
that is fine. But unless it continues supporting the standard methods - 
THAT IS A BUG!!!

In any case, I have found a fix. Right at the start of himem.sys,
there is code that traps the bios call to get the amount of extended
memory and arbitrarily sets it to zero. So what you have to do is simply
bypass that test by changing the third byte after the one pointed at
by the int 15h interrupt from 88h to 0 - this simply allows himem to
pass through the call to the previous driver, which appears to have
the correct answer. This works for me. I am using the Win 2.11 version
of Smartdrive rather than the Win 3.0 one.  This allows my 386 programs
using the Phar Lap runtime to work.

The way the new himem.sys works is very  very antisocial. 

Doug McDonald