automatically use the XMS memory pool would require backdoor interactionEMM386 will only allocate VCPI memory from the EMS memory pool. Making itDepends. Some extenders have absolutely no problem allocating from XMS if no VCPI memory available.with HIMEM[64] and generally make things quite a bit more complex.I can see aproblem here (or I can have missunderstood): IMHO what will be used a lot is UMB+VCPI without EMS. The reason for this configuration is whe 1) UMBPCI does not work (new hw), 2) no need for EMS (few programs use it) 3) free as much as possible Low-Memory
Of course, a DOS extender/extended program can still use XMS in addition to VCPI and many of them do.
for comon programs (EMS takes 64k of UMB)(very often needed). Will this configuration work??
For what I learned here, if the machine is not in real mode, which is needed to get UMB, then VCPI is needed. am I wrong?
Unfortunately, DOS/4GW, now crowned That Annoying Extender Which Grossly Misbehaves, doesn't like current EMM386 NOEMS. I'm still trying to sort that out and am not sure whether it's due to no memory in VCPI pool, missing EMS page frame, or something else. NOEMS is pretty badly broken in the EMM386 version out there anyway, but I've fixed it up some for next patch release. Now NOEMS allocates up to 192K for UMB's and VCPI internal table use, which typically leaves at least 32K for a VCPI pool, more if you have fewer UMB's.
What is himem+emm386 footprint in memor(low+umb)?
The DOS/4GW problem does need to be addressed since it's most popular extender out there and a lot of legacy applications use it.
Agreed ;-)
I'm thinking maybe if the residual EMS left-over after UMB allocation is too low, I'll have EMM386 by default grab a hunk of XMS memory at startup to keep for as VCPI pool. Biggest hurdle is that this behavior is not the most friendly use of memory. And if I do that, I'll need to slightly modify HIMEM again to increase default handles, since it's already pretty low without EMM386 grabbing memory.
What would you think about an EMM386 that decided to steal some of your XMS memory at startup, just in case a VCPI-using program wanted it later on? I mean, the memory might never be needed if nothing ran which used VCPI, it would just be gone. Proper settings would need some type of command line parameter control, but we really need is a basic default for the general Joe and Joyce User who simply sticks NOEMS in there and still expects their DOS-extended to run with a DOS extender or related protected mode application than can't fallback to XMS allocation.
I think that we should consider a bit who is Averege-Joe and what machine he may get.
1) if he has no knwledge of dos at all (just a mouse-clicker) and is just testing, he has a powerfull machine and will not care as long as everything runs. For him a good installer is the most important thing.
2) for an old-time DOS user that is really using FreeDOS to run old programs (like Clipper systems) he has at least 4Mb of memory. In this case it FreeDOS should a) run just out-of-the-box and b) could be optimised later if this is really needed
2) for small enbedded systems, anything will be highly optimised and this Joe has the knwledge to do it. So here default are not a problem.
SO: default values should have any value that make the system work smoothly. It just ocurred to me that these values could be dependant on the total amount of memory found in the machine. MS-DOS has this in many places. This way if there is at least 4Mb, a little more in various tables is wellcome.
Alain
PS What program are usint to write you messages? my Thunderbird is behaving strangely in the answer screen and I have to break lines manually.
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Freedos-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-devel
