Eric, >> ... 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...?
No one is suggesting an API only for MEM! Also, my ideas about new XMS commands are only for 64-GB memory, NOT for current XMS commands that would continue to run fine for applications expecting and using only the first 4-GB of memory, as we both agree they should! >> ... 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. NO, sir! "Protected mode" moves are done by JEMM386/JEMMEX, since on systems that use either driver, only THEY can "trap" and execute an "Int 15h AH=80h" move-memory request! A "real mode" system can have drivers like UIDE which do their OWN "real mode" moves, as the "MvData" routine does in UIDE, and so it is "real mode" which needs to be told the 64-GB "page" number for an XMS memory block. Also, if a driver were to request 64-GB memory BEFORE loading JEMM386, it will have to include the 64-GB page number in move-memory requests, as JEMM386 then will NOT be the driver allocating the XMS and could not know the page number! Better to have one consistent "Allocate SUPER-extended memory" request, which provides the 64-GB "page" for either "real mode" or "protected mode" systems. Both need it. > For something like a RAMDISK, only the XMS driver has to know any > details about the true location of the memory ... As I noted above, JEMM386/JEMMEX also need to know the 64-GB "page" numbers, since it is they (not the XMS driver!) which handle an XMS move in "protected mode". > As said, I am trying to suggest using the normal XMS 3 API while > still letting software use the extra memory. Exactly as I am trying to do. > It is in no way part of the XMS interface to coordinate PAE paging > between HIMEM and the software that uses XMS. It is, if JEMM386/JEMMEX are present for "protected mode"! I agree address-extension "paging" is the responsibility of only XMS drivers that handle over 4-GB of memory. But they need to co-ordinate such "page" numbers, and offer them both to applications requesting 64-GB memory AND to JEMM386/JEMMEX when using "protected mode". > 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. UIDE could -- see below. Maybe Alain's "database" could, as well. >> 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. This requires revision of many programs, which are NOT expecting to reserve other than one "block" of XMS memory with one XMS "handle". I have NO intention of adding such code in UIDE/RDISK merely to run Win/3, which I still regard as a "hopeless piece-of-junk"! So do most others, who now use at-least Win/XT for serious Windows work. >> 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 ... > > 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. Betcha it is a lot MORE "trivial" than adding 64-GB XMS support! "Pipeline" and simultaneous I-O schemes concern ONLY application programs that use them, NOT the whole system or its XMS drivers! >> 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. UIDE could still have its cache in 64-GB memory if it were changed to do all I-O through its "local" 128-KB XMS buffer. That buffer would have to stay in 32-bit address space, as SATA/UltraDMA chips were designed in the 1994 "32-bit days". Doing all I-O thru its buffer costs a small amount of time in UIDE. But if a HUGE cache is needed and a fast-enough CPU for its binary searches is present this COULD be made to work, certainly for 4-GB caches, maybe more! > 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 also noted Gates & Co. are making file sizes larger and larger, as they still have NO CLUE about doing any sort of SMALL systems! Everyone "MUST have!" the TOTAL Win/Vista on their hard-disks, NO exceptions, and we who want FreeDOS/MSDOS/etc. to "co-exist" with such Bloated BULLSH*T may need larger UIDE caches, in the future. > I for example have 1 GB in Linux and my swapfile never does > anything useful apart from serving as hibernate image ;-). I agree -- I ran Win/NT with only 256KB memory for over 10 years, until I had to get more for testing UIDE/RDISK. I never had any problem due to available memory -- Win/NT still "crashes" now and then, but not due to low memory. Old Gates & Co. BUGS are NEVER fixed, same as those still in V4.49/V4.95 EMM386 after 15 years!! > 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 ... Agreed -- maybe we should save our time and let Bernd handle his DVD/BluRay copies using a "custom" DOS program, not a "new" XMS! >>> 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 ... I would rather NOT be "unsafe" and prefer to "lock" any XMS used by a SYSTEM driver AGAINST being re-mapped, moved-around, or any other Gates & Co. "fun and games"! If XMS "locks" are unusable when running Win/3, maybe it is best not to support Win/3, since it is KNOWN to be at-fault for breaking Gates & Co.'s XMS rules! > 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 ;-). As Captain Kirk once said to Mr. Scott, "You work your miracles, and I'll work mine"! 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
