>> 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.
MEM could - but all XMS 2 and XMS 3 apps will be more
confused about a "too honest XMS 4" driver... And to
add a whole new API only for MEM...?
>> 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.
It is only necessary if you have tools that want to use more
than 4 GB for themselves via protected mode themselves. For
something like a RAMDISK, only the XMS driver has to know any
details about the true location of the memory... As said, I
am trying to suggest using the normal XMS 3 API while still
letting software use the extra memory. It is in no way part
of the XMS interface to coordinate PAE paging between HIMEM
and the software that uses XMS. Of course you are right that
protected mode software CAN be interested in protected mode
access to XMS. Again, the only thing that I can imagine to
make use of more than 4 GB RAM is a RAMDISK, no DOS extender.
> Little I can do about Win/3, since UIDE users need a LOT
> more XMS than only 16-MB.
In theory, you can allocate a lot of RAM in pieces of 16 MB.
In addition, HIMEMX can simply use a per-transfer descriptor
strategy instead of a per-handle descriptor strategy. Then
you can stay below 16 MB descriptor size for all transfers
of less than 16 MB block size even if you allocate 4 GB in
a single handle :-) Most transfers (via XMS far call) are
between DOS memory and XMS anyway, so size is inherently
limited to at most 1 MB most of the time. In short: You can
make Windows 3.x happy and still use a lot of XMS... :-).
> 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...
I know... Linux burner tools such as K3B also use growisofs
instead of mkisofs, so they pipeline the filesystem into the
burner while it is generated and avoid the need to have one
big temp file of the size of the whole CD / DVD disk :-). Of
course it is not trivial to do heavy pipeline things in DOS.
> Without knowing the address and "page" number of XMS memory
> above 4-GB, UIDE could not use it in "real mode"...
Well UIDE does not know how to do DMA to 64 bit address space
and I do not even know whether it is possible with normal PCI.
But again, I think UIDE is not among those tools which would
actually gain from using more than 4 GB RAM for one app. You
yourself already said that 6 GB RAM are too much for DOS :-)
I for example have 1 GB in Linux and my swapfile never does
anything useful apart from serving as hibernate image ;-).
> 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...
In my opinion, this thread started with the idea that the
unused (maybe superfluous) memory of Bernd's 6 GB PC can
be used for something SIMPLE such as a RAMDISK so it can
serve any purpose at all in DOS. Having full support with
DMA and 64 bit DOS extenders etc etc would of course be
much more work and would need a much wider API as well.
>> 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 ;-).
> BIG problem for drivers using XMS that load after Win/3!
You can just load them BEFORE Windows - or of course use
the XMS via the normal XMS copy function instead of using
raw protected mode access. As any RAMDISK will in the end
send and receive data via DOS memory, the XMS copy works
perfectly for the purpose and the RAMDISK does not need
to know about the physical location of the XMS... Things
are different for UIDE but again, this will have various
issues with the 4 GB boundary and PAE and locking so it
does not count as SIMPLE for me ;-).
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