Xref: utzoo comp.os.msdos.apps:2177 comp.windows.ms:13827 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!uunet!microsoft!bobsc From: bobsc@microsoft.UUCP (Bob SCHMIDT) Newsgroups: comp.os.msdos.apps,comp.windows.ms Subject: Re: MS-DOS v5.0 Release Date 11th June (addendum) Message-ID: <72927@microsoft.UUCP> Date: 16 Jun 91 07:20:18 GMT References: <1006@macuni.mqcc.mq.oz> <72798@microsoft.UUCP> <6669@gssc.UUCP> <72917@microsoft.UUCP> Reply-To: bobsc@microsoft.UUCP (Bob SCHMIDT) Organization: Microsoft Corp., Redmond WA Lines: 35 In article <72917@microsoft.UUCP> I wrote: [concerning EMM386 and WIN /2 conflict] %% My educated guess is that we will fix this in the next release of %% Windows (along with obviating WINA20.386). Note that the conflict %% only arises when you use EMM386 for UMB support. You can turn %% off UMB, and the problem will go away. This will at least allow %% you to run in standard mode, although maybe not under the memory %% configuration you would like. I want to clarify this a bit. While the UMB support does cause this conflict, so will EMS. That is, if EMM386 has actually allocated and used EMS on behalf of some application, Windows will not run in standard mode. For example, add the lines device=c:\dos\emm386.exe on device=c:\dos\ramdrive.sys /a to CONFIG.SYS and reboot. This creates a RAM-drive in expanded memory. Now WIN /S (or WIN /2) will generate the familiar "can't run" message. Also, the question was raised "why does QEMM work?". It appears that QEMM works by patching the Windows DOS extender (DOSX.EXE). If true, this is extremely version-bound; I've heard that the QEMM version that works in Windows 3.00 breaks in Windows 3.00A. All this is from unverified sources within MS; you'd have to contact Quarterdeck for the real scoop. -- -- NOTE: The above is mine alone; I do NOT speak for Microsoft. -- -- Bob Schmidt bobsc@microsoft.UUCP -- -- Bellevue WA USA Windows SDK Support -- Sydney NSW AUS Developer Support (after 1 Oct)