Path: utzoo!attcan!uunet!know!zaphod.mps.ohio-state.edu!wuarchive!julius.cs.uiuc.edu!ux1.cso.uiuc.edu!aries!mcdonald
From: mcdonald@aries.scs.uiuc.edu (Doug McDonald)
Newsgroups: comp.windows.ms
Subject: Re: HIMEM.SYS Questions
Message-ID: <1990Sep7.185543.16817@ux1.cso.uiuc.edu>
Date: 7 Sep 90 18:55:43 GMT
References: <90246.150126MSR113@psuvm.psu.edu> <269@paldn.UUCP>
Sender: news@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: 28

In article <269@paldn.UUCP> pwilcox@paldn.UUCP (Peter McLeod Wilcox) writes:
>HIMEM.SYS does two things (actually three), first it makes available
>as a requestable resource the first 64k segment after 1meg, i.e. with
>a 80286 or better, the segment address FFFF does not wrap around to
>0 like it does on an 8086.
>
>The second function is to allocate and move blocks of extended memory,
>the user requests a block of extended memory and receives a handle,
>the handle is then used to access the extended memory via himem.sys.
>
>The third function is controling the A20 address line (enable and disable)
>in a hardware independent fashion, which it needs to do to perform the
>other two functions.
>
>Note that none of this is useful unless the program being run knows
>how to access the XMS driver, which very few programs do.
>-- 

However, there is a FOURTH function, that DOES affect programs that
don't know to access himem.sys's particular scheme:

It prevents them from accessing extended memory using the previosly
defined standards - the bios calls and VCPI. In other words,
himem.sys breaks many, many programs.

This was dumb.

Doug McDonald