Reply 120 of 123, by mkarcher
Yoghoo wrote on Today, 13:21:But mem/c shows Largest free upper memory block 0K (without DOS=UMB). If I start with DOS=UMB it hangs the pc when trying to run any command (config.sys and autoexec.bat load successfully).
It is expected to get 0KB UMB without "DOS=UMB": While the XMS standard includes functions to allocate and free single upper memory blocks, this is not how the MS-DOS kernel will use it. Instead, the MS-DOS kernel uses its integrated memory mechanism for UMBs that it also uses for conventional memory. So, if you add "DOS=UMB" to CONFIG.SYS, MS-DOS will allocate all UMBs from the XMS driver and integrate that memory into the MS-DOS kernel memory management system. MS-DOS will never return UMBs to the XMS driver. "mem /c" only shows DOS memory located in upper memory blocks that are managed by the DOS kernel, so without DOS=UMB, that memory could still be allocated from the XMS driver (as DOS didn't do it), but it is not available in the DOS kernel management system. There could be applications that allocate UMB memory directly from the XMS driver, but I expect them to be extremely rare, as integrating the UMBs into the DOS kernel memory management via DOS=UMB is so common that system on which an application is actually able to allocate memory using the XMS UMB API are really rare.
By the way, this is similar, but not identical to how DOS deals with the HMA (which only exists on 286+ computers, and can only be provided using physical extended memory). The XMS driver can hand out the HMA in one piece to one single user. The XMS driver can not split the HMA into different parts for different users. If you use "DOS=HIGH", DOS will ask the XMS driver to hand the HMA over to DOS. But unlike UMBs, the HMA is not integrated into the normal DOS kernel memory management system, but DOS uses the HMA for special internal purposes only. This is likely due to the fact that unlike UMBs, the HMA is not accessible all the time. For compatibility reasons, there are some situations in which the HMA memory is inaccessible. On the other hand, programs that allocate memory using the normal DOS kernel memory management API expect their memory to be accessible all the time. When you usen DOS=HIGH, DOS controls when the HMA is accessible and when it has to be hidden for compatibility reasons, and DOS is written in a way that it does not require access to the data stored in the HMA while the HMA is hidden. Just like with UMBs, if you have a 286 with HIMEM, you may omit "DOS=HIGH" from CONFIG.SYS, so DOS does not allocate the HMA and places all its data structures into conventional or UMB memory. In that case, applications can ask HIMEM.SYS to hand them the HMA. Again, applications actually doing this are rare, because most systems that support HIMEM.SYS were configured in a way that DOS uses the HMA, so adding HMA support to applications is a complication that only pays off on a very small amount of systems. Unlike UMBs, MS-DOS does not provide an application API to allocate memory in the HMA, so if you use DOS=HIGH, only DOS internal data structures and parts of the DOS kernel code are located in the HMA.
Back to topic. It seems for some reason, you get issues as soon as you try to use UMBs or EMS (both require the use of the page frame) for purposes other than accessing the "virtual" XMS memory. Does your EMS driver have an option to configure a "nesting limit for saved page frames on a handle"? If it does, did you by any chance configure it to zero to conserve memory when loading the EMS driver? If I understood the EXMS source code correctly when I glimpsed over it some days ago, it seems this code requires a saving depth of at least one to work properly, otherwise it would leave the page frame in a messed up state after XMS transfers.
