On Wed 19-Aug-2009 14:21:04, Eric Auer <e.a...@jpberlin.de> wrote: > I mean if you have some XMS 4 ramdisk then it should also > allow combined usage of XMS 3 and 4, otherwise it would > leave the first 4 GB unused ... Would be somewhat wasteful.
I agree, and that is why "local" data such as UIDE's cache tables would always use normal 4-GB memory. Only LARGE-scale XMS memory such as UIDE's cached DATA would be given the choice of using 4-GB or 64-GB memory. > Depending on whether the used HIMEM is "Windows proof" but > that of course is not the problem of UIDE or RDISK :-) Some > old apps used many small XMS handles to push HIMEM towards > more Windows friendliness but that of course wasted handles. I used V2.06 HIMEM from a server in Hungary as my "model" for what is now the XMGR driver. Even with V2.06 HIMEM in 1989, Gates and Co. knew-enough NOT to issue ALL of an XMS memory-move as one BIOS request (1989 pre-dated even their own EMM386!). Thus, XMGR also executes "real" or "protected" memory moves in small 2K quantities of data, for any "old" BIOS that may do such moves with interrupts OFF! You should assume HIMEM/EMM drivers are "Windows proof" re: this problem -- any that are NOT should be DISCARDED immediately!! >>> So all "pipeline linked" components of the CD/DVD burn toolkit >>> will have to use some other API to communicate directly... >> >> 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... > > Such a program still would have to be written, of course. ABBBsolutely! Nothing comes "free" in our world economy, any more, just like the damned "used to be free" Internet, which is now only a pack of ADVERTISEMENTS everywhere you look! >> I have never seen a RAMdisk that was not file-based > > Maybe we have a misunderstanding here.. The driver itself > is of course a file, but the disk is a DOS block device, > so for DOS it is just a bunch of sectors. The DOS kernel > will then use those sectors as a FAT filesystem which can > contain files, sure, but the ramdisk itself has no idea > what a (FAT) file is. It only needs to provide an initial > state which looks like an empty formatted FAT filesystem. NO misunderstanding, and that is exactly what RDISK and other RAMdisk drivers do. After setting RAM memory to an "initial state", a RAMdisk does memory-moves, not file transfers, with a one-to-one correspondence -- every DOS "read" or "write" to a RAMdisk causes exactly one XMS move request. Thus, one is better-off viewing a RAMdisk as a FILE handler, rather than a "sector" handler. >> RAMdisk is ... GUARANTEED to handle a "temp" ... faster! > > Unless the cache is so big that it never has to discard > data and unless you neglect the overhead that it takes > the cache to "notice" this when reading/writing data ;-) A cache THAT big defeats its pwn purpose, which is to use a SMALL amount of RAM memory to speed-up a much LARGER disk!! UIDE is limited to 2-GB, which some people still believe is a bit high, but in fact hard-disks CAN go up to 2-TERABYTES these days! What you suggest will "never happen". 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
