Hi Jack, >> Ah okay... So there would be a separate API, and separate >> memory areas for XMS 2/3 and the new API then? > > Absolutely! Forgetting XMS V2.0 (only 64-MB), I am suggesting that > all XMS V3.0 requests for 4-GB remain as-is, using the first 4-GB of > memory. XMS "V4.0" commands, if we choose to call them so, will be > modified 3.0 commands to deal with memory ABOVE the first 4-GB.
Hmmm then on one hand only new apps could use XMS 4, but on the other hand, old apps would not have any side- effects from the existence of XMS 4 :-). Note that the new apps will also have to use XMS 3 to get the 3 GB or similar that will be free in the first 4 GB because no sane XMS 3 app will use much of those 4 GB... ;-) > If we do an XMS "V4.0" upgrade for 64-GB memory, the "scheme" used > by "real mode" and "protected mode" should be consistent for both. True. >> actually do contain workarounds for Win compat ... > > Still a BIG problem for drivers like UIDE wanting gigabytes of memory. As said - Windows 3 only has a problem with descriptors for more than 16 MB, so if you have a HIMEM or UIDE implementation of memory-block-copy which creates the descriptors on demand then you can easily copy 1 MB at offset 1 GB of your 2 GB handle and still stay with all offsets relative to the descriptor below 1 MB :-). This is of course not cool for descriptor caching on modern CPU, so a HIMEM could consider only activating this when Windows is active and using "full handle" sized, fixed offset descriptors for access at all other times :-). Note that I am talking about CPU descriptors, not XMS handles. Basically, apps which only use the XMS API to copy data to/from XMS will not even notice whether they run with a HIMEM with such a Windows limit workaround. >> At least in Linux and Windows, a pipeline is something provided by >> the OS kernel ... > > But we are NOT Linux/Windows, are we?? So all "pipeline linked" components of the CD/DVD burn toolkit will have to use some other API to communicate directly with each other instead. >> Yes and no - the metadata of the cache could be kept in the >> easily accessible area while the data itself can be copied >> with normal XMS driver calls without extra performance loss, >> allowing the cache data to stay in non-lockable extra large >> XMS above the 4 GB boundary. Of course I wonder why you do >> want a cache of 4 GB instead of just using a RAMDISK...? > > Agreed -- UIDE's cache tables and binary-search table could remain > in normal 4-GB memory, along with its "local" 128K XMS buffer Okay :-) > A RAMdisk handles a more permanent set of logical FILES, > using a normal DOS directory. RAMDISKs are also sector-based things, not file-based, but indeed they always contain the same sectors, without dynamic decisions about which sectors will be in RAM and which not. > Those who want a SCREAMING-fast DOS system will want BOTH! They could also copy their DOS disk into a RAMDISK at boot, possibly in the background. That would be a combination between a cache and a ramdisk then ;-). I think there are some shareware floppy caches working like this :-) > Be kind -- Bernd contributes much to DOS/FreeDOS/etc. same as we do. Sure. Just a comment on the suggestion that he should or could write a pipeline based burn tool himself... >> No, you just cannot create locks on NEW handles, such which >> got allocated after Windows took over memory maintenance. > > Then I hope UIDE/RDISK or other large-memory drivers DO load first! > >> Enjoy working on your miracles :-) > > Thanks, and you on yours ;-) Thanks :-) 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
