Wow, Ed ... kinda like a mini-history lesson, eh? < g > That's all pretty interesting actually. Yes, I've found that I've had to tweak the PIF file a bit for my 2.0 app to work well under Win9x ... come to think about it, tho, I'm not sure if they end up running the Extended Edition or the Standard (I shipped both runtime libraries with my app and it's been awhile since I set up one of these babies, so I don't remember ...)

Anyway, I hope this helps Paul's original question!

Bonnie

>>There are a number of variants of EMS, and 2.0 got confused in some cases when it saw EMS available from EMM386 where it couldn't allocate a fixed 64K swap area in the UMBs to use for EMS paging (in theory, EMS should be able to use 4 non-contiguous 16K frames to provide the EMS swap space, but the early version of the Watcom DOS Extender used by 2.0 wasn't very forgiving in my experience.) I had far fewer problems with 2.0's extended version using QEMM or Helix's memory manager rather than HIMEM/EMM386, both of which could be easily configured to convert freely between XMS and EMS allocation on the fly, and would move things around in the UMBs to make a contigous 64K block if at all possible.
>>
>>So, Ed, are you saying that if you load nothing else but HIMEM/EMM386, then it should be able to allocate a contiguous 64K block of UMB? Or is that still not a given?
>>
>
>It's not that simple to say, but under Win9x, there are far fewer problems allocating a 64K contiguous block of memory addresses to a VDM (Virtual DOS Machine) in the UMB space. The problem extends a bit deeper than that, in that you have to adjust the memory configuration for the DOS session to explicitly allocate EMS, not XMS or VCPI memory, to work with 2.0; the DOS Extender used by 2.0 was incompatible with the XMS/VCPI memory management scheme, and can still cause problems under Win9x DOS sessions unless the .PIF file settings for the VDM are set up correctly. You can adjust the memory tab of the property sheet for a shortcut that launches a 2.0 extended application fairly easily, but the odds are that the necessary settings won't be there for your default DOS
> session's .PIF file, so launching a 2.0 app from a default MS-DOS prompt shortcut, or the Start Menu/Run box, or from another program (like maybe VFP's RUN command) which spawns a new VDM using a .PIF file that doesn't make the necessary memory allocation adjustments may not always be able to run a 2.0 Extended mode app. You could change things around a bit and fix that, but other DOS apps might not be as happy with the defaults that make FPDOS 2.0 Extended a happy camper.
>
>You can still run into things that will fragment the UMB space without a bunch of LOADHIGH and DEVICEHIGH statements eating things. Devices that use Real Mode drivers will generally require conventional memory or UMB memory out of each VDM. In addition, devices that run in MS-DOS compatibility mode, requiring access to BIOS ROMS to do their thing, or memory-mapped devices like some older NICs, grab fixed chunks of memory out of the UMB space, which can make life tough for creating a contiguous block of 64K for EMS swapping without eating some of the convention memory addres space (the area between 0-640K) in each VDM.
>
>The real problem that arises is the incompatibility between the Watcom DOS Extender used by 2.0, which in effect loaded up it's own virtual memory manager that is incompatible with the Win9x VM manager whenever a 64K contiguous EMS block as well as an adequate amount of EMS memory wasn't available, in order to make memory above the 1MB mark accessible to FPDOS 2.0 Extended Edition. Win9x sacrifices the DOS session that tries to usurp the role of the Win9x VM manager, making 2.0 Extended Edition not work in these situations. 2.0 Standard Edition used EMS in a more compliant way (data and cache only could be placed in EMS; the need for a 64K contiguous segment came from trying to run code in EMS-mapped memory), and would function even if no EMS was available.
>
>2.5 and later used a much-improved DOS Extender, that adhered to the VCPI standard; it relied on a VCPI-compliant memory manager to handle the memory management and addressing issues rather than trying to create an incompatible memory manager if EMS wasn't available. Win9x (and in fact, later versions of HIMEM.SYS from the bad old DOS days) provides a VCPI-compliant manager, so there are far fewer problem running 2.5 and 2.6 Extended Edition; the odds that the default memory settings for a given VDM, without having tweaked the memory settings, are much better (in fact, the Win9x default makes XMS and VCPI memory available, but not EMS, if you don't do anything.)
>
>Does this clear things up at all?