CompuServe Messages

I don't know if your problem has already been solved yet. I just read your message and haven't seen any replies other than Dave's. Phar Lap Error 35 means that a 386 or better (which Phar Lap 386|DOS-Extender, by definition, requires) is already in "Virtual Mode" under the control of another program. The Extender needs to either control the CPU itself, or be able to communicate with the other program (includes EMS-providing memory managers and/or UMB providers such as EMM386.SYS, EMM386.EXE, QEMM386, etc., task switchers such as DOS Shell, DesqView, etc., and multitaskers such as DesqView, VM-386, Windows, OS/2, etc.). Only one program can act as a Virtual Mode controller at any one time, so if you have a memory manager or task switcher or multitasker that is acting as a Virtual Mode controller, you must either disable it or make sure that the Extender can "talk" to it so that they can negotiate when each program is acting as the Virtual Mode controller. The latter is done via Virtual Control Program Interface (VCPI) and/or DOS Protected Mode Interface (DPMI) specifications. If your memory manager does not support either of the above, it cannot be used with AmiPro or 3DS or any other Phar Lap-extended application. Period. (This is why Windows NT will not run 3DS — it does support DPMI but only DPMI 0.9, a pre-official specification, not the full DPMI 1.0 that OS/2 supports and that ordinary Windows 3.1 can be made to support via PHARLAP.386. No version of Windows or OS/2 supports VCPI at present.). EMM386.EXE as included with MS-DOS 6.0 and Windows 3.1 and later does have VCPI support, but the earlier EMM386.SYS does not. All relatively recent versions of QEMM386 support VCPI (indeed, Quarterdeck helped design the VCPI specification), but does not support DPMI without an additional driver being loaded (which is included with the more recent versions) called "QDPMI.SYS". 386MAX supports both. You can get by with the older EMM386.SYS if you tell it NOT to provide UMBs by not including either the RAM or NOEMS parameters, but this means you will not be able to load any device drivers or TSRs "high" into upper memory. In that mode, EMM386.SYS will not require the CPU's Virtual Mode. In short, your options are: 1. If you see "DEVICE=…\EMM386.SYS…" in your CONFIG.SYS file, replace it with a line pointing to an upgraded EMM386.EXE (in either your DOS or WINDOWS directory — use whichever one has the latest dated EMM386.EXE file in it). If you have none available (only likely if you're using MS-DOS 5 or earlier and do not have Windows), remove any "RAM" or "NOEMS" parameter and consign yourself to loading all device drivers and TSRs into conventional RAM only, or upgrade to MS-DOS 6.x (or PC-DOS 7 if you don't want to help Bill Gates get even richer <g>). 2. Upgrade to QEMM386 or 386MAX. 3. Remove the memory manager entirely (PharLap applications do not require one, though on some machines 3DS can render faster with one), at least on a version of CONFIG.SYS that you plan on using with AniPro. 4. Warp your system with OS/2 2.1 or later. This is by far the best way to run PharLap applications currently available, due to its full multitasking and 32-bit OS combined with full DPMI 1.0 support (which NO version of Windows, including Windows95, has). The main disadvantage is that you will need to remove it or repartition your hard drive later if you intend to move up to 3DS MAX and WindowsNT — Joel Rea @ M&M C. C.