On Wed 19-Aug-2009 13:06:42, Eric Auer <e.a...@jpberlin.de> wrote: >>> Ah okay... So there would be a separate API, and separate >>> memory areas for XMS 2/3 and the new API then? >> >> Absolutely! > > 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 :-)
Of course not, or people will NOT use the new "XMS 4" requests! > 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... ;-) I think the user should be allowed to decide this. I would upgrade my drivers to use 64-GB "XMS 4" memory only if over 4-GB is desired. For under 4-GB, they can allow memory above or below the 4-GB limit, since "below 4-GB" memory will surely work faster. > As said - Windows 3 only has a problem with descriptors for more > than 16 MB ... 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. If you are in fact referring to the descriptors used in an "Int 15h AH=87h" move-memory request, then I have no-problems in UIDE/RDISK. RDISK data transfers are limited by DOS to 64K bytes or less, so it cannot "move" more data at any one time. UIDE was written to work with the ACTUAL "Int 15h AH=87h" logic, present in a BIOS, if there are any "protected mode" applications which still use only the BIOS and not an EMM driver. I doubt this, but I had to write UIDE with this capability, just-in-case. There were some BIOS routines that do memory moves with CPU interrupts OFF, UIDE will NOT move over 2K bytes at a time. Thus, my drivers ARE doing what you suggest. >> 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. True ONLY if people want a "toolkit" and a complex "pipeline". If they want to have only ONE stand-alone program that does DVD/BluRay copies for Bernd, that one program can do whatever it wants and can leave the REST of the DOS system alone and at-peace! >>> ... The metadata of the cache could be kept in the easily >>> accessible area ... >> >> Agreed -- UIDE's cache tables and binary-search table could stay >> in normal 4-GB memory, along with its "local" 128K XMS buffer > > Okay :-) Another item on which we both agree -- Hallelujah!! >> 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. I have never seen a RAMdisk that was not file-based, same as I have never seen a cache that was not LBA-address (i.e. sector) based. >> 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 :-) Such a copy is exactly what I suggest in my driver README for users of RDISK. When a system is powered off, all RAMdisk data is lost, and on the next power-up, any "permanent" RAMdisk files MUST be put back in RAMdisk storage. Compiler "temporary" and other "working" files do not need this. However, NOTE that there is a DIFFERENCE between such "temp"/"working" files and a cache. A RAMdisk holds ALL of such files. A first-in first-out cache may have to DISCARD some sectors of the files when OTHER data must be cached. So the RAMdisk is quite-a-bit more GUARANTEED to handle a "temp"/"working" file faster! 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 Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
