Hello, > 2) Do not support a super allocate, just let XMS clients alloc > memory as long as it is available - but start in the first 4 GB > and/or use memory after that "easy" area only for big allocs... > > 3) You need no outside-visible super extended move as long as > only XMS access to the extra memory is available. HOWEVER this > means that the super XMS driver will have to reject requests to > lock XMS memory to a fixed address inside the first 4 GB (which > simply is the XMS 3 API limit) as soon as it runs out of space > in the first 4 GB. For simplicity, I would not even suggest to > move around XMS handles. Instead, I would support locking and > fixed addresses only for handles which physically were in the > first 4 GB anyway at the moment when they were allocated...
Might work, but it's hackish and IMO it's important that a program can tell Himem that it prefers to get physical memory from beyond the 4 GB limit. > PS: Regarding I/O virtualization, the MS EMM386 API for this > is relatively small, int 2f.4a15 basically. JEMM386 with the > JLM driver support infrastructure could probably implement > support for int 2f.4a15 as a small JLM driver at some time. Yes. > letting software use the extra memory. It is in no way part > of the XMS interface to coordinate PAE paging between HIMEM > and the software that uses XMS. Of course you are right that PAE paging most likely isn't needed, the simpler approach "32-bit paging with 4 MB pages" should do as well. japheth ------------------------------------------------------------------------------ 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
