Path: utzoo!attcan!uunet!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!rpi!dali.cs.montana.edu!milton!yoda.eecs.wsu.edu!ckinsman
From: ckinsman@eecs.wsu.edu (Chris Kinsman - EE major)
Newsgroups: comp.windows.ms
Subject: Re: How to get extended mem back after a windows session?
Keywords: extendedmemory,  himem.sys
Message-ID: <1990Oct27.180243.10576@eecs.wsu.edu>
Date: 27 Oct 90 18:02:43 GMT
References: <90297.155820MUHRTH@DB0TUI11.BITNET> <1990Oct26.195130.17719@cs.uoregon.edu>
Reply-To: ckinsman@yoda.UUCP (Chris Kinsman - EE major)
Organization: Washington State University, Pullman
Lines: 21

In article <1990Oct26.195130.17719@cs.uoregon.edu> akm@cs.uoregon.edu (Anant Kartik Mithal) writes:
>In article <90297.155820MUHRTH@DB0TUI11.BITNET> MUHRTH@tubvm.cs.tu-berlin.de (Thomas Muhr) writes:
>>Nothing against the sophisticated memory management of himem.sys, but
>>we use older software which needs extended memory and has no chance to
>>communicate their needs via himem. Smalltalk V/286 for example.
>>Is there a utility available which after invocation of windows, I mean,
>>after leaving it, gives extended memory back for undiscplined programs?
>
>I actually don't understand why we need himem.sys at all. After all,
>both 286 and 386 systems can address extended memory without a
>problem (in protected mode), so why do we need to use himem? I
>understood the logic for emm, but not xms.
>
The reason as I understand it is to enable programs other than windows to access
extended memory.  On the 386 at least you can only have 1 protected mode memory
manager.  HIMEM.SYS becomes this manager and will then dole out the extended 
memory to your various programs.  If Windows was the protected mode memory   
manager no other programs would be able to access the memory unless they
communicated with windows.

Chris