Hi Jack, >> 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 ;-). Eric ------------------------------------------------------------------------------ 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
