Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!opal!tub!gmdtub!bigfoot!tmh From: tmh@bigfoot.FOKUS.GMD.DBP.DE (Thomas Hoberg) Newsgroups: comp.unix.sysv386 Subject: Re: Running DOS Programs while under UNIX Keywords: DOS, UNIX, PC Message-ID: <201@bigfoot.first.gmd.de> Date: 4 Dec 90 02:01:24 GMT References: <4325@sactoh0.SAC.CA.US> <243@n4hgf.Mt-Park.GA.US> <16067@bfmny0.BFM.COM> Sender: news@bigfoot.first.gmd.de Reply-To: tmh@bigfoot.FOKUS.GMD.DBP.DE (Thomas Hoberg) Organization: Gesellschaft fuer Mathematik und Datenverarbeitung (GMD) Lines: 29 In article <16067@bfmny0.BFM.COM>, tneff@bfmny0.BFM.COM (Tom Neff) writes: |> |> Unfortunately, as 286 and 386 machines come to dominate the marketplace, |> more and more application programs are taking the trouble to [yecch] |> CHECK what CPU they're running on, and run different code as a result. |> The problem is that a program running in V86 mode can do certain 386 |> tests *successfuly*, leading it to believe (erroneously) that it's OK to |> run the full gamut of protected mode stuff -- which promptly bombs MERGE |> or VP/ix. A prime example is Windows 3.0. DESPITE the fact that it |> runs just fine on a *real* 8086/88, and DESPITE the explicit /R switch |> they give you to FORCE it to use 8086/88 mode on any CPU, it **STILL** |> thinks it's smarter than you and checks for that 386 chip! Wham, instant |> death. What a hair tearer. If that's the only reason a session with the debugger should do it. However that's not really a solution, as Windows in 'real' mode isn't at it's best (even with EMS). I heard some rumors that Unix vendors are looking into DPMI (Dos Protected Mode Interface). With DPMI functionality integrated into the Unix Kernel and a GDI-to-X interface, running Windows applications under Unix would be a natural rather than a kludge. Maybe it's time to ask your Unix vendor about DPMI..... ---- Thomas M. Hoberg | UUCP: tmh@prosun.first.gmd.de or tmh%gmdtub@tub.UUCP c/o GMD Berlin | ...!unido!tub!gmdtub!tmh (Europe) or D-1000 Berlin 12 | ...!unido!tub!tmh Hardenbergplatz 2 | ...!pyramid!tub!tmh (World) Germany | BITNET: tmh%DB0TUI6.BITNET@DB0TUI11 or +49-30-254 99 160 | tmh@tub.BITNET