> On Fri, 14 Aug 2009 15:57:55 -0700, Eric Auer <e.a...@jpberlin.de> wrote:
> Hi Jack,
>> Re: using memory over 4-GB in DOS, the best way to AVOID many new
>> "custom" programs is to raise the capacity of XMS drivers...
>> 1) A change to the XMS request which determines available memory,
>>     with a change to the FreeDOS "MEM" program to display all such
>>     memory.   I believe "MEM" is currently limited at 4-GB.
>> 2) A new "Allocate SUPER-extended memory" request, which requests
>>     memory above 4-GB if available.    This new request would have
>>     to return the "page" number (0 to 15) of the allocated memory,
>>     for programs like UIDE that do their own "real mode" XMS work.
>>     It would still return an XMS "handle" so the "Free XMS memory"
>>     and standard "Move XMS memory" commands could work as-before.
>> 3) A new "Move SUPER-extended memory" request, or a change to the
>>     current "Int 15h AH=87h" move-memory request that denotes what
>>     "page" of memory is being moved, for all "protected mode" move
>>     requests (JEMM386/JEMMEX).    There are no "extra" bits in the
>>     current "Int 15h AH=87h" descriptor block, so some sort of new
>>     "convention" would also be needed for large-scale XMS memory.
> Maybe it can be even more minimal than that...
> 1) Do not tell MEM about the extra memory, just tell it that you
> have 3 GB as long as at least 3 GB are still available ...

This might materially "confuse" users, who expect MEM to report actual
available XMS memory.   Since MEM is only "reporting numbers" to users
I see no reason why MEM cannot remain "honest" about what is does.

> 2) Do not support a super allocate, just let XMS clients alloc
> memory as long as it is available - but start in the first 4 GB
> and/or use memory after that "easy" area only for big allocs ...

NO good!   UIDE and other programs that want to run their OWN "real
mode" XMS moves need to know (A) if XMS above 4-GB is available and
(B) which "page" of 64-GB memory (0 thru 16) was allocated, as they
will need to set the 64-GB "page" registers to do "real mode" work.
The "Allocate super-extended memory" request is necessary.

> Of course this means that the 9 GB RAMDISK that Bernd would want
> for juggling with two big DVD ISOs will need several XMS handles
> but other RAMDISKS already do the same to support big drives via
> pure XMS 2 requests which give you at most 64 MB per handle. This
> also helps Windows 3 compatibility - the XMS handling of Windows
> seems to have a bug if anybody uses descriptors for 16+ MB areas.

Little I can do about Win/3, since UIDE users need a LOT more XMS
than only 16-MB.   Re: Bernd's "9-GB RAMdisk", this is ABSURD and
I have already noted in an earler post that only 100-MB should be
adequate for such copies, if using a "simultaneous I-O" scheme as
in the "DeepBurner" CD/DVD writer program.    "DeepBurner" is for
Windows (runs fine on my ancient Windows/NT), but maybe Bernd can
find a DOS copy of it, or get its source files and make a similar
program to run under DOS.   That would save 8.9-GB!

> 3) You need no outside-visible super extended move as long as
> only XMS access to the extra memory is available. HOWEVER this
> means that the super XMS driver will have to reject requests to
> lock XMS memory to a fixed address inside the first 4 GB (which
> simply is the XMS 3 API limit) as soon as it runs out of space
> in the first 4 GB. For simplicity, I would not even suggest to
> move around XMS handles. Instead, I would support locking and
> fixed addresses only for handles which physically were in the
> first 4 GB anyway at the moment when they were allocated...

Without knowing the address and "page" number of XMS memory above
4-GB, UIDE could not use it in "real mode", and there may be more
programs that would suffer, as well.   Actually, I failed to note
that XMS locks, and their returned 32-bit memory addresses, would
also demand a "Lock SUPER-extended memory" request, to return the
64-GB "page" number as well.

> See the above "only for big allocs" suggestion for this :-).
> Note that for example Windows 3 does similar things - it just
> refuses to let you use XMS call 0c (lock, RBIL table 02762)
> on handles that were allocated after Windows started ;-).   I
> guess it will return error code ad, lock failed at that time.

How often Gates & Co. violate their own "conventions", simply
because they ARE G&C!   If what you say is true, this poses a
BIG problem for drivers using XMS that load after Win/3!   My
own RDISK could be in that category!    I see NO solution for
this, except writing-OFF Win/3 as a hopeless piece-of-TRASH!!

> PS: Regarding I/O virtualization, the MS EMM386 API for this
> is relatively small, int 2f.4a15 basically. JEMM386 with the
> JLM driver support infrastructure could probably implement
> support for int 2f.4a15 as a small JLM driver at some time.

I-O virtualization is "not my department".

> PPS: I have the feeling that keeping ONE ISO in RAM should
> be enough for what Bernd wants, if access is organized well.
> Of course you still need to find 4 GB of DOS soft first ;-)

See my comments above -- Bernd needs to find a DOS equivalent of
"DeepBurner" first!

Jack R. Ellis

Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Freedos-user mailing list

Reply via email to