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... 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... 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. 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... 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. Eric 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. 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 ;-) ------------------------------------------------------------------------------ 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 Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
