First post, by DosFreak
- Rank
- l33t++
http://groups.google.com/group/microsoft.publ … 235c9b36282f0b2
This is an update detailing what I've tried and what worked, 4 Cases in order of worst to best: […]
This is an update detailing what I've tried and what worked, 4 Cases in
order of worst to best:Target Application: PADS Perform DOS v6.0.1
Original OS: DOS
Challenges:
1. Uses Phar Lap 386|DOS-Extender v5.1,
2. Uses -REALBREAK command-line switch so it needs DPMI v1.0 host with
Map Conventional Memory in Memory Block function (INT31h AX=0509h),
3. Supports 21 different video cards at 1024x768 or 1280x1024, BUT NO S3
cards
or VESA selections,
4. Uses a parallel port hardware key.Numbers 2 and 3 are the biggest problems by far.
*** Win XP SP2 Retail, native ***
Main Problem: Lack of DPMI v1.0 host with Map Conventional Memory in
Memory Block function (INT31h AX=0509h)I tried to get PADS Perform to run in Win XP SP2 without a VM, but there is
one incompatibility with the Phar Lap 386|DOS-Extender (later called TNT
DOS-Extender) involving DPMI v0.9 versus DPMI v1.0 support. PADS Perform
used an Extender or DPMI option called the -REALBREAK command-line switch.
This requires a DPMI v1.0 host which provides the Map Conventional Memory in
Memory Block function (INT31h AX=0509h). But MS only provides support for
DPMI v0.9 with EMM386.EXE or later, DOSX.EXE (HIMEM.SYS is the XMS host).
DPMI v0.9 doesn't support INT31h AX=0509h.The purpose of the -REALBREAK switch is to request that some of the code and
data be placed in conventional memory. One of the things this allows is to
mix Real-mode and Protected-mode code.There appears to be 2 reasons to use -REALBREAK to load some of the
application in conventional memory:1. Having some of the application in conventional memory can apparently
improve the performance for some programs.2. Mixing Real-mode and Protected-mode code. Apparently Real-mode code can
be mixed with Protected-mode code if the Real-mode code and data are 64K or
less and they are loaded in conventional memory.If the reason is number 1, then the program will work in the NT series by
using "-REALBREAK 0" which tells the Extender to load 0KB in conventional
memory. I believe Autodesk's 3D Studio Release 4 falls into this category
since people have reported that this makes it work in Win 2000 and XP,
although the performance is cut in half. (If the DOS-Extender is bound with
the application to have only one .EXE, use CFIG386.EXE to change the
-REALBREAK switch, ex. "CFIG386.EXE 3DS.EXE -realbreak 0". If using a
separate loader such as TNT.EXE, use "TNT.EXE -REALBREAK 0 Program.EXE").If the reason is number 2, then you're screwed. Period. The application
will never run in the NT series. It appears PADS Perform falls into this
category.The -REALBREAK switch is the worst way to load mixed code together. There
are two other ways to deal with loading mixed code mentioned by Phar Lap.
The preferred way is to use the realcopy() function shown in DOX-Extender's
MDRAW sample program. "Using realcopy() avoids any potential compatibility
problems with -REALBREAK.". If it were possible to reverse engineer enough
of PADS Perform to add the realcopy() function and eliminate the need for
-REALBREAK, then PADS Perform would probably work in the NT series. However,
that is well beyond my capabilties. As the professors always used to say
"It's left as an exercise for the student".Here's what happens:
If your program uses the -REALBREAK command-line switch, DOS-Extender will
refuse to load it unless the DPMI host provides the Map Conventional Memory in
Memory Block function (INT31h AX=0509h).(See Phar Lap -> Ardence -> Citrix Tech Note 43 and 44 and the TNT
DOS-Extender Reference Manual).When PADS Perform is started, the DOS-Extender starts to load and quickly
displays the following infamous error:Phar Lap err 74: Can't use -REALBREAK under this version of DPMI
Error TNT.20074: Can't use -REALBREAK under this version of DPMIWith -REALBREAK set to 0, the DOS-Extender loads. PADS Perform starts to
load, but quickly displays the following error:Panic!!!!
cannot reach real mode vector
EAX ........ 0000250F
EBX ........ 00000000
ECX ........ 00008DC0
EDX ........ 002D0008
Exiting ...PADS Perform uses the Phar Lap 386|DOS-Extender v5.1 bound into the main
PADS executable so that there is only one .EXE to run, PPERFORM.EXE. I also
tried using the TNT DOS-Extenders v7.0 and V8.02, TNT.EXE, as a loader to
load PADS Perform with "TNT.EXE PPERFORM.EXE" so I would have the features of
the newer version, in case that provided something more compatible to the Win
NT series. In fact, I'd always had to use the TNT.EXE loader method just to
get Perform to run in Win 98SE. PADS didn't provide a PHARLAP.386 VxD, so
Perform didn't originally run in Win 9x. I had access to the DOS-Extender
SDK v7 and v8. I tried v7.0 and v8.02 TNT.EXE loaders paired with their
respective PHARLAP.386 VxD in the SYSTEM.INI file's [386Enh] section and they
both worked. So I've always used v8.02 to run in 98SE. I tried all these
variations in Win XP but nothing worked. I tried all combinations of the
Memory and Compatibility settings in the shortcut used to start the program
and still nothing worked (EMS must always be None).There was never any file from Phar Lap for Win NT that was equivalent to
PHARLAP.386 for Win 9x.I've even tried other DPMI v1.0 hosts such as DPMIONE and HX DOS-Extender.
HIMEM.SYS must be loaded to give an XMS host. But with or without DOSX.EXE
loaded, DPMIONE and HX will refuse to load with the following messages:DPMIONE:
The CPU is in Virtual Mode and there's no VCPI host.
DPMIONE.EXE not installed.HX DOS-Extender:
HDPMI32: CPU is in V86 mode, but no VCPI/DPMI host detected.
These are similar to Phar Lap error 35 that results from loading
DOS-Extender without loading DOSX.EXE:Error TNT.20035: The 386 chip is currently executing in virtual 8086 mode
under
the control of another program. You must turn off this
other
program in order to use TNT DOS-Extender to run in protected
mode.Therefore, I could never get DPMI v1.0 support in Win XP.
Final Results: The program will not run natively in any Win NT series.
This is an update detailing what I've tried and what worked, 4 Cases in
order of worst to best:Target Application: PADS Perform DOS v6.0.1
Original OS: DOS
Challenges:
1. Uses Phar Lap 386|DOS-Extender v5.1,
2. Uses -REALBREAK command-line switch so it needs DPMI v1.0 host with
Map Conventional Memory in Memory Block function (INT31h AX=0509h),
3. Supports 21 different video cards at 1024x768 or 1280x1024, BUT NO S3
cards
or VESA selections,
4. Uses a parallel port hardware key.Numbers 2 and 3 are the biggest problems by far.
*** Virtual PC 2007 ***
Host - Win XP SP2, Retail
Guest - Win 98SE, Retail
Video support - S3 Trio32/64 PCI (732/764) (with VM Additions), VESA
standard up
to 1024x768 and 1280x1024Main Problem: Lack of Video Support
I tried this since I thought I might get lucky and have one of the 21
supported cards be compatible with the S3 Trio32/64 or the VESA standard. I
was of course dreaming. Only 4 selections even drew garbage on the screen at
1024x768: the Tseng Labs ET4000 and ET3000, the ATI VGA Wonder +, and the
Paradise VGA. The IBM 8514A and the ATI Ultra (mach8) were well behaved,
displaying "NO 8514 PRESENT" and exiting. All the others drew nothing and
left the window blank and hung, needing an Alt-Del to get back to the VM
Desktop. Only the IBM VGA setting worked which restricted the resolution to
an unacceptable 640x480.Aside from the video, it was easy to get PADS Perform running. After
installing Windows 98SE and the VM Additions, the network was already
working. So I copied all the PADS Perform application directory as well as
my old System.ini, Config.sys, and Autoexec.bat files from the host which
shows up in Network Neighborhood to the VM C: drive (I had copied the files
from an old computer to the host ahead of time for this experiment). I
copied the line needed by PADS Perform to the System.ini file in the VM
C:\WINDOWS and the whole Config.sys and Autoexec.bat to C:\ of the VM 98SE.
I remmed out lines that were only needed by other applications. Mainly I
needed:SYSTEM.INI [386Enh] - DEVICE=C:\PADS\PHARLAP.386
CONFIG.SYS - DEVICE=C:\WINDOWS\HIMEM.SYS
DEVICE=C:\WINDOWS\EMM386.EXE NOEMS
DOS=HIGH
DOS=UMB
AUTOEXEC.BAT - PATH as appropriate
Loadhigh C:\WINDOWS\COMMAND\DOSKEY.COM /bufsize=1024
SET environment variables as appropriate for PADS
Perform(DOSKEY was only for convenience and not required).
I also set the LPT1 Setting to Physical parallel port: LPT1 (378h-37Fh) in
the Settings for the Virtual Machine.Final Results: Application runs perfectly, but only at an unacceptable
standard
VGA 640x480 resolution. Slower than DOSBox, but the
speed is
acceptable.*** VMware Workstation v6.0.0 ***
Host - Win XP SP2, Retail
Guest - Win 98SE, Retail
Video support - VESA 2.0 standardMain Problem: Lack of Video Support
I didn't try this since I thought it would have the same results as Virtual
PC. It has the same type of video limitations for PADS Perform so I assume
it will run but at an unacceptable standard VGA 640x480 resolution.*** DOSBox v0.7 ***
Host - Win XP SP2, Retail
Guest - None, DOSBox emulates MSDOS 5.0 inherently
Video support - VGA and VESA built-in; Tseng Labs ET4000, S3 Trio32/64, and
Paradise VGA (with Vasyl's SVGA Additions)Main Problem: Slight color problem at 1024x768, corrected with ANSIPLUS
This program is really impressive. The hardest part is collecting the
pieces you need from various sites. Sourceforge handles the official build,
currently DOSBox v0.7. There is a site for "unofficial" CVS builds posted
daily which have fixes and possible additions. This is mainly for beta
testers and comment. Then there are builds produced by people in the DOSBox
community which use the official source and add various features in code
contributed by other people in the DOSBox community. Three often used ones
are:Gulikoza - with Direct3D, OpenGL-HQ, Vasyl's SVGA support, plus others
ykhwong - with Direct3D, OpenGL-HQ, Vasyl's SVGA support, plus others
HAL 9000 - Direct Parallel and Serial Port accessFor PADS Perform DOS, I needed to download the following:
The official DOSBox v0.7 Win32 installer,
The latest build from either YKHWong or Gulikoza,
ANSIPLUS v4.06 from Kristofer Sweger,
PortTalk v2.2 from Beyond LogicI ran the DOSBox installer. Then I unzipped the YKHWong and Gulikoza builds
so I could try each one. I copied the YKHWong files into the DOSBox
directory and replaced DOSBox.exe and DOSBox.conf and any other files that
were older. Then I studied and edited the default .conf configuration file
to make changes as follows:[sdl] - fulldouble=true
fullresolution=1024x768
windowresolution=1024x768
[dosbox] - memsize=64
[vga] - svgachipset=et4000
videoram=1024
[dos] - ems=false
[autoexec] -
mount c c:\
path=C:\;C:\BAT;c:\pads;c:\pads\files;c:\pads\cam; C:\DOS; C:\WINDOWS; C:\WINDOWS\system32; C:\Programs\ANSIPLUS; C:\Programs\PortTalk; C:\ECED; C:\XTGOLD;SET dosx=-swapdir C:\PADS\SwapFile
SET TMP=C:\tempC:\PROGRAMS\ANSIPLUS\ANSIPLUS.exe
C:
cd C:\PADS
C:\PADS\PERFDOS6.COM
del c:\PADS\SwapFile\PP*.SWP
C:\pads\PPERFORM.EXE /SThen create a shortcut from the DOSBox.exe and set Start in: to C:\PADS.
Compatibilty is all default, nothing checked. Copy the edited DOSBox.conf
file to C:\PADS. DOSBox looks for a DOSBox.conf in the Start in: directory.When I first started, I wasn't using ANSIPLUS and there was a problem with
having some colors wrong at 800x600 and 1024x768 in PADS Perform. The colors
were perfect without using ANSIPLUS in XTree Gold v3.0 and an editor called
EC which both run at 640x480. The first thing I thought of to fix the colors
was ANSI.SYS but I couldn't load it in DOSBox even with loaders like Devload
and CTload. So I started going through loadable ANSI.COMs. None worked
until I came across the program ANSIPLUS, which is loadable as a device
driver or a TSR. I loaded it in DOSBox before the application and the colors
were almost perfect. I had to configure ANSIPLUS from the default palette to
the "I" option of IBM-OEM colors and then the colors were perfect. (I'm not
sure why the author didn't set the IBM-OEM colors as the default). Both
Gulikoza and ykhwong builds worked equally well and had the same color
problems. Both were fixed with ANSIPLUS.One thing was odd, I had to run the original bound PPERFORM.EXE without the
TNT.EXE loader. When I tried to start PADS Perform with the TNT.EXE loader,
it and PADS loaded and PADS was at its initial graphic screen ready to go.
But then it would exit back to the DOS Prompt and display a message about not
being able to read the key. This never happened when using just
PPERFORM.EXE. Perhaps it has something to do with not having the matching
PHARLAP.386 driver loaded since Win XP can't use a VxD.One thing that didn't work was the Paradise VGA support. PADS Perform has a
selection for "Paradise VGA" which I selected. I set the DOSBox.conf to:[vga] - svgachipset=pvga1a
videoram=1024PADS would display a line of text as usual before it normally goes to its
graphic screen. But then the cursor would sit at the left under the text
line and never get any further. PADS was running, just not able to display
the correct thing. I could use the keyboard exit sequence "blind" and PADS
would exit and return to the DOS Prompt.Finally I have PADS Perform DOS running in Windows XP SP2. Now the old
hardware and Win 98SE can be retired.Final Results: Application runs perfectly at 1024x768. Faster than Virtual
PC.DOSBox is the program that worked for me, rather than Virtual PC 2007 or
VMware Workstation, because of the ET4000 video support. Both run PADS
Perform DOS. But only DOSBox will let me run at 1024x768, which is a must
have item.A big thanks to the DOSBox Team and especially Vasyl!!!