Hi Jack, > 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
Ah okay... So there would be a separate API, and separate memory areas for XMS 2/3 and the new API then? >> 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! True - if you have a HIMEMXXL then it will need a way to communicate with some EMM386 if you want to use both in parallel. On the other hand, if the access to XMS style memory beyond 4 GB is implemented in some JEMMEXXL then it would only have to communicate with itself, as it is both HIMEM and EMM386 inside the same driver already. > if a driver were to request 64-GB memory BEFORE loading JEMM386 Loading drivers BETWEEN HIMEMX and JEMM386 is a somehow unusual case if my opinion. Combined with the unusually big memory size of more than 4 GB, that adds up to too much unusuality to make UIDE compatibility a priority ;-) >> In theory, you can allocate a lot of RAM in pieces of 16 MB. > This requires revision of many programs, which are NOT expecting True true, yet Windows 3 was so widespread that many drivers actually do contain workarounds for Win compat. And if the XMS move is only done by the XMS driver then the workaround (keep descriptor sizes below 16 MB) can even happen inside HIMEMX itself, needing no changes in other software that uses XMS via the XMS API :-). >> 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! At least in Linux and Windows, a pipeline is something provided by the OS kernel - but of course you can have two apps which communicate directly to form pipes, too. >> 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". Interesting. One would assume that SATA/UDMA was more future-proof than that ;-) > 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 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...? > I agree -- I ran Win/NT with only 256KB memory for over 10 years, 256 MB, probably :-) > 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... I remember that life was quite okay with 16, 32, 64, 192 MB on mixed versions of Windows and Linux for many years indeed. >> 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: Bernd cannot program anything but Warcraft and BAT afair :-) > I would rather NOT be "unsafe" and prefer to "lock" any XMS used > by a SYSTEM driver AGAINST being re-mapped, moved-around... I know I know. My cache also locks memory because it feels bad to have the data of a disk cache swapped out to a disk... :-p. That probably also holds for UIDE, now that I think of it... > other Gates & Co. "fun and games"! If XMS "locks" are unusable > when running Win/3, maybe it is best not to support Win/3... No, you just cannot create locks on NEW handles, such which got allocated after Windows took over memory maintenance. Enjoy working on your miracles :-) 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
