Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Virtual PC 2004 or 2007 Video Card Support for DOS programs

148 views
Skip to first unread message

PlanNine

unread,
Mar 9, 2007, 4:13:27 AM3/9/07
to

I have 2 old DOS legacy applications that I'd hoped to move from their old
computers to modern hardware running XP SP2 by using Virtual PC. These are
applications which MUST be kept running, there is no money or resources to
change or update. It's either keep separate computers for them or find a way
to run them on a virtual machine. But I have 3 concerns:

1. They use the PharLap 386 DOS Extender

2. One needs to talk to a hardware key on the parallel port

3. The BIGGEST problem is they talk directly to the video card and have 21
supported cards that run at 1024x768 or 1280x1024 (none of which includes any
S3 chips). They need to run at least at 1024x768 and just 16, 256, or 64K
colors (8 or 16-bit).

I can run the applications in MSDOS 6.22 or Windows 98SE in full screen mode
(ie, without rebooting to DOS mode). The current computers are setup as
follows:

Windows 98SE

4 have Hercules Dynamite 128 PCI cards with the ET6000 chip and 4MB MDRAM.
Windows 98SE runs an ET6000 driver, the applications run an ET4000
driver (ET3000 driver is also compatible with the ET6000).

1 has an ATI Graphics Pro Turbo PCI card with the mach64 chip, ATI RAMDAC
(not IBM), and 4MB VRAM.
Windows 98SE runs the mach64 driver, the applications run the VGA
Wonder + driver (as long as the card has the ATI RAMDAC).


So I'm hoping the PharLap Extender won't be a problem. What I'm worried
about is the hardware, especially the video card. I DON'T need 3D, DirectX,
or Overlay support etc. I just need straight forward 2D support. But I need
to have virtualization or some support for one of the cards in the
applications list. S3 was not included in the applications.

Here is the complete list of supported cards and the maximum resolution:

Video Card Resolution

ATI VGA Wonder + 1024x768
(Runs on ATI Graphics Pro Turbo (mach64 with ATI RAMDAC (not IBM)) )
ATI Ultra (mach8) 1024x768

Elsa Alpha 1024x768
Elsa Spectra 1280x1024

Genoa SuperVGA HiRes 1024x768
Genoa SuperVGA 70Hz HiRes 1024x768

IBM 8514A 1024x768

Metheus UGA 1104 1024x768
Metheus UGA 1124 1024x768
Metheus UGA 1224 1280x1024

Orchid ProDesigner VGA 1024x768
Orchid ProDesigner II VGA 1024x768

Paradise VGA Card 1024x768

STB VGA Extra/EM 1024x768

TI TIGA 1024x768
TI TIGA 1280x1024

Trident VGA 1024x768

Toucan VGA 1024x768

Tseng Labs ET3000 1024x768
Tseng Labs ET4000 1024x768
(Both run on ET6000)

Video-7 VRAM VGA 1024x768
Video-7 1024i VGA 1024x768


Is it possible the S3 is compatible with one of the cards in the list, such
as the IBM 8514A, ATI mach series, or TI TIGA?


The MS main page for Virtual PC 2007 and 2004 make it sound like the
perfect answer, except they don't say much about hardware virtualization.
One of the white papers mentions parallel and serial ports and CDROM drives,
but that's it. So I go digging through the discussion threads and all I see
is virtualization for an obscure S3 chip (the Trio). Am I missing something?
Is there a way to virtualize other video cards? Or is this otherwise great
software rendered useless by a lack of video card virtualizations? I know
the application won't be talking to the video card on the new computer, so
the virtual machine must virtualize the video card that the application wants
to talk to. If the only video card virtualization that exists is the S3
Trio, then Virtual PC is virtually worthless for supporting older legacy
applications. It may work if all you want to do is run a Windows 2000
application on XP or Vista. But it doesn't help at all for any DOS or early
Windows 9x applications. And those are the applications that have the most
need to shift to new systems. The ones still running are typically unique,
can't be replaced, but have to be kept running.

Please tell me I'm wrong and that Virtual PC will do what I need and how
to do it. If not, do you know if VMWare, SVista, or any other virtual
machine will work for me? And if Virtual PC won't work, someone needs to
point out right on the main page that the S3 Trio is the only virtualized
video card or at least put it in the Product Specifications page so everyone
doesn't go through having their hopes raised, only to be disappointed by this
huge limitation. Or perhaps someone could consider adding just a few more
mainstream video card emulations such as the 8514A, ATI mach series, and
Tseng Labs ET4000 and 6000 (and maybe the VESA 1024 driver)?

Thanks

PlanNine

unread,
Mar 9, 2007, 4:18:33 AM3/9/07
to

Mark Rae

unread,
Mar 9, 2007, 4:32:54 AM3/9/07
to
"PlanNine" <Plan...@discussions.microsoft.com> wrote in message
news:1E62E0CC-D032-416B...@microsoft.com...

> Is it possible the S3 is compatible with one of the cards in the list,
> such
> as the IBM 8514A, ATI mach series, or TI TIGA?

I doubt it - but have you tried it...?

> but that's it. So I go digging through the discussion threads and all I
> see
> is virtualization for an obscure S3 chip (the Trio). Am I missing
> something?

No.

> Is there a way to virtualize other video cards?

No.

> Or is this otherwise great software rendered useless by a lack of video
> card
> virtualizations?

Matter of opinion... If you had a real machine with an nVidia graphics card
in it, would you complain that it didn't have a magic switch somewhere which
changed the graphics card into something else...?

> If the only video card virtualization that exists is the S3 Trio,

It is.

> then Virtual PC is virtually worthless for supporting older legacy
> applications.

If those legacy apps require specific hardware, then VirtualPC will not help
you at all...

> Please tell me I'm wrong and that Virtual PC will do what I need and how
> to do it.

You're not wrong.

> If not, do you know if VMWare, SVista, or any other virtual machine will
> work for me?

All other software virtualisation software works this way i.e. by
virtualising a specific set of hardware.

> And if Virtual PC won't work, someone needs to point out right on the main
> page that the S3 Trio is the only virtualized video card or at least put
> it in the
> Product Specifications page so everyone doesn't go through having their
> hopes
> raised, only to be disappointed by this huge limitation.

Best place to raise that would be on the Microsoft feedback page...

> Or perhaps someone could consider adding just a few more mainstream video
> card
> emulations such as the 8514A, ATI mach series, and Tseng Labs ET4000 and
> 6000
> (and maybe the VESA 1024 driver)?

Realistically, that's never going to happen... VirtualPC is a free piece of
software which performs a specific function. If it's not to your liking,
then get your credit card out and go and buy a real machine configured to
your precise specification requirements...


PlanNine

unread,
Mar 9, 2007, 7:06:18 AM3/9/07
to

Thanks for the quick reply.

I haven't tried VPC yet. I saw the posts about video limitations and wanted
to get some expert opinions so I wasn't just beating my head against the wall
spending time trying to do something that would never work.

I guess all I can hope for is that the S3 Trio will be close enough to an
8514A that it might work. I seem to recall that a lot of early XGA chips
were basically 8514 clones with non-interlaced 1024x768 modes.

As for the nVIDIA reference, I don't care what's in the actual host machine.
I'm only concerned about what video card the virtual machine can provide to
the guest OS, in my case Windows 98SE (or MSDOS 6.22). If it would help to
run a dual video card system, I'd do it. Although, the main reason for
looking at using VPC is to do away with separate PCs AND especially to get
away from the older hardware which is getting harder to replace. The actual
supported video cards are getting harder to find even on eBay.

I'll try to find the right place on the VPC page to leave a suggestion about
putting the video card limitation right up front, so to speak.

As for your last comment, I thought I was clear that I already have PCs
running the applications. What I want to do is reduce the number of PCs and
phase out the old hard-to-get hardware. Also, from what I've been reading,
some of the newer motherboards won't run Windows 98SE or DOS natively. So I
was looking at VPC to work around that. If I can't run 98 on new
motherboards and VPC can't virtualize a card that will work, then I'll just
have to try to maintain the current PCs. It's just unfortunate about the
video limitation. I'm still going to try VPC and at least use the 8514A in
the application to see what happens and let you know. Do you think it would
be better to use VPC 2007 or 2004?

Thanks

ronald....@gmail.com

unread,
Mar 9, 2007, 7:17:00 AM3/9/07
to
On Mar 9, 7:06 am, PlanNine <PlanN...@discussions.microsoft.com>
wrote:
> > "PlanNine" <PlanN...@discussions.microsoft.com> wrote in message

You could try DosBox http://dosbox.sourceforge.net

The official DosBox only supports S3, but yhkwong's CVS build:
http://vogons.zetafleet.com/viewtopic.php?t=9306= supports Trident
video emulation.

I don't think th official DosBox supports passthru to LPT but there
are patches for it. Try the official DosBox CVS, yhkwong's CVS and
then Hal 9000's website: http://home.arcor.de/h-a-l-9000/

HAL 9000 works on serial/parallel support in DosBox alot and he may
help you if your nice. He posts on the official VOGONS forum @
http://vogons.zetafleet.com

DosBox officially only supports DOS games but it does run DOS
applications very well.

Mark Rae

unread,
Mar 9, 2007, 8:32:25 AM3/9/07
to
"PlanNine" <Plan...@discussions.microsoft.com> wrote in message
news:34F6EBC8-DF42-4BFA...@microsoft.com...

> I guess all I can hope for is that the S3 Trio will be close enough to an
> 8514A that it might work. I seem to recall that a lot of early XGA chips
> were basically 8514 clones with non-interlaced 1024x768 modes.

I hope it works for you - I'm not holding my breath, though...

> Although, the main reason for
> looking at using VPC is to do away with separate PCs AND especially to get
> away from the older hardware which is getting harder to replace. The
> actual
> supported video cards are getting harder to find even on eBay.

I appreciate that, but...

> It's just unfortunate about the video limitation.

Yes.

> I'm still going to try VPC and at least use the 8514A in the application
> to see
> what happens and let you know.

OK.

> Do you think it would be better to use VPC 2007 or 2004?

In terms of video card emulation, there would be no difference whatever...

However, and I hope this won't depress you even further, DOS is no longer a
supported guest OS in VPC 2007...

The following 32-bit operating systems are supported guests in VPC2007:

Vista Ultimate
Vista Enterprise
Vista Business
WinXP Pro
WinXP Home
Win2k Pro
Win98SE
OS/2 Warp 4

The following operating systems were supported in VPC 2004-SP1 are
compatible, but no longer supported...

DOS 6.22
Win95
Win98
WinME
WinNT4W


Robert Comer

unread,
Mar 9, 2007, 10:11:06 AM3/9/07
to
Hi PlanNine (interesting reference. <g>)

The problem is that Virtual PC, and all of the other current virtualization
products that I know of, don't virtualize the hardware except for the CPU,
they emulate it which is quite a different thing. There just no way to
emulate another video card without starting from scratch and programming the
new emulation in. (it might be nice to have plug-in device emulation code,
but that's not the way they are built now.)

It's always worth a shot to try you program to see if it can handle the
video, but I fear that it's not going to be similar enough. There may be
problems with the parallel key too...

As for if you should use VPC2004 or 2007, I'd try VPC2007.

--
Bob Comer <Microsoft MVP Windows - Virtual Machine>


"PlanNine" <Plan...@discussions.microsoft.com> wrote in message

news:34F6EBC8-DF42-4BFA...@microsoft.com...

Wesley

unread,
Mar 9, 2007, 2:16:21 PM3/9/07
to
PlanNine,

What is the name of your application? We have a extended DOS Cadd program
(GCD) running in a VPC Win98se DOS mode window with 1280X1024 graphics.
--
Wesley

PlanNine

unread,
Mar 9, 2007, 5:38:08 PM3/9/07
to
Hi,

Actually there are more than 2, but I'm concentrating on the hardest. One
is proprietary and only supports the Tseng Labs ET4000 and 6000 and the other
is PADS Perform v6 which supports the 21 cards listed. There are others
including OrCAD 386 which has more video card support than PADS and even has
working VESA 1024x768 drivers. OrCAD 386 even works at 1280x1024 on an ATI
Graphics Pro Turbo mach64GX card in Win98SE and has some S3 support (the 9xx
series), so I'm not as worried about it.

Is GCD Generic CADD? Did it have a driver for the S3 Trio or did you find a
way around it? If so, it could be very helpful.

I've also been looking into Ronald Phillips suggestion about DOSBox. It
also officially supports the S3, but one of the supporters has been writing
additional video card emulations and has working ET3000 and ET4000 emulations
as well as a Paradise PVGA1. The ET4000 emulation would solve a lot of
problems. And other contributors have a way to access the parallel port for
hardware keys. So DOSBox is looking interesting.

Let me know if you got a non-S3 driver to work.

Thanks

Wesley

unread,
Mar 9, 2007, 11:00:05 PM3/9/07
to
PlanNine,

GCD is "Personal Designer" produced by 4D, previously distributed by CV.
Along with various dedicated graphic adapters (VMI and Pixelworks), it came
with a VESA driver that is installed by the application making it S3
compatible. The application runs about 4xs faster in a Win98se VPC then the
previously dedicated DOS machine.
The host is a WinXP, 3 GHz P4. While GCD doesn't have the instant screens
that current CADD programs have, the screen refresh is fast enough. I have a
lot of custom file management and drafting programs created for the system
and I am reluctant to switch to a WinXX CADD program for those functions.

Any application that works with a VESA compatible display adapters, should
run the emulated S3.

GCD utilized a security device attached to the parallel port. The VPC can be
setup to see the host's physical ports. It can also see any USB device that
can be shared on the net. If you install your app in DOS along with
"Workgroups for DOS" , you will be able to see and print to any shared device
on the net. Under Win98, you will need to install Win98 drivers for your
printers. I have a WinXP tiff printer driver on the host that can not be
networked with the Win98 VPC, but all of my other printer and plotter drivers
are OK.

With VPC, GCD is hardware and OS independent. The great thing is that on one
workstation, with a 24 inch display, I am able to put up multiple windows
including the GCD app (1280X1024), other CADD programs, specifications and
calculators at one time. The GCD VPC communicates with the host via the net
and I am almost paperless until I plot/print to present or publish. My
digitized is attached to the host serial port and communicates with GCD. When
I click the mouse over any window, including GCD, it becomes the active
application and will take input from the mouse (digitized in the case of GCD)
and keyboard. The other application run in the back ground finishing whatever
may be assigned to them.

My application runs about 1.3xs faster in Win98se "Boot to DOS" VPC window
then in a DOS VPC window and about 2.5xs faster then the Win98se "command
DOS" window. In the first example, the network can not see the guest although
the guest can see the host. In the second and third install, the net is fully
accessible both ways. Some of the installations run best without the Vmadds
and in the case of DOS, with the exclusion of some of the Vmadds.

--
Wesley

PlanNine

unread,
Mar 10, 2007, 2:01:08 AM3/10/07
to

Thanks for the information. I don't recall the GCD cad program you're
using, but you are lucky for it to have a VESA application driver. And since
it works, that means the emulated S3 Trio in Virtual PC must have a VESA
hardware driver included in the emulation. And that is good to know. Of the
3 applications I mentioned, only OrCAD has VESA drivers and the highest
resolution one goes up to 1024x768, which is fine. The problem is that the
other 2 applications don't have VESA drivers.

The VESA drivers tried to do for DOS what the Windows and OS/2 OSes do for
reducing the video driver work for applications developers. The idea was
that the application could write a single VESA driver using calls to the
"standard VESA API". Then the video card manufacturer could write a single
low level VESA driver to be shipped with the card which provided the APIs
which took care of things from the API level down to the hardware. Both
sides only have to write 1 driver and everybody's happy. Except most apps
still had to provide all the other direct-to-video-card video drivers for
various reasons. And then OS/2 and Windows came along and so a lot of
developers never got around to doing the VESA drivers or getting them
debugged.

So, some apps provided the application side VESA driver, some don't. You
were lucky with GCD. I'm lucky with OrCAD, not so lucky with the others. At
one time, I used the OrCAD VESA 1024x768 driver to run OrCAD in OS/2 v3 and 4
on the ATI Graphics Pro Turbo mach64GX card. It's good to know that the VPC
S3 emulation provides VESA support.

It's interesting about the different speeds for the different virtual
machines in terms of DOS versus DOS in Win98. I remember when I moved PADS
from native MSDOS v6.22 to a DOS Full Screen in Win98SE, the printing speed
increased dramatically. That's how all the apps are currently running, in a
DOS full screen in Win98SE (not rebooting to DOS mode) and the speed is fine
on a 500MHz machine.

And thanks for the information on the parallel port. That was another
concern. Now I know I'll be able to get the apps to see the hardware keys.
Was there anything tricky or obscure about the VPC settings needed?

By the way, did GCD use the PharLap 386 DOS extender or a different one
and did you have to do anything special to get it running? I'm assuming I'll
just be able to use the same config.sys and autoexec.bat settings as in the
native setup.

Thanks

PlanNine

unread,
Mar 10, 2007, 4:27:00 AM3/10/07
to
Hi,

I'm suprised it was available, being such a classic. Sorry for mixing the
terminology, but at least you got the idea. I understand you would have to
write each emulation since each video chip had anywhere from some to a lot of
different registers beyond the VGA set. But it would seem to make sense if
the VPC team had added just 1 or 2 cards per year you could've had the 5 or 6
most common video card families by now, which would make VPC more usable to a
LOT more people. Having just 1 video card emulation is so limiting.

The better option, which is the easiest for the VPC team, is to provide a
way for outside contributors to add video card emulations. Of course, they
would be unsupported by MS, but all you would have to do is provide links to
the contributors and say "You're on your own with these". Before you laugh,
that is exactly what is done with DOSBox which is an open source virtual
machine. DOSBox officially supports the S3 only, but one of the supporters

has been writing additional video card emulations and has working ET3000 and
ET4000 emulations as well as a Paradise PVGA1. The ET4000 emulation would

solve a lot of problems for me obviously. And other contributors have
provided a way to access the parallel port for hardware keys. So DOSBox is
looking interesting to me because of the ET4000 addon from an outside source
and the parallel port support also from an outside source. (Thanks to Ronald
Phillips in previous post).

In another post, Wesley pointed out 3 things that worked for him:

1. He has a DOS Extended application running in a VPC Win98SE guest on a
WinXP host and it's 4 times faster than when run natively in DOS
2. The application included a VESA driver and he's using it to run at
1280x1024
3. The application uses a parallel port hardware key and he was able to set
VPC to use the host's physical port.

So, is it looks like:

1. DOS extenders aren't generally a problem
2. The S3 Trio emulator includes emulation of the Trio's VESA driver or
utility, which makes VPC's video compatible with any application that has
either the S3 Trio driver OR the VESA driver. That's a BIG plus. You should
be sure to point this out. It opens up VPC to a lot more applications.
3. Directly accessing the parallel port is possible. Or at least there's
enough access to let a hardware key work.


I'm still going to try VPC 2007 with the 8514A selection in my
applications and let you know what happens since my apps don't have a VESA
driver (except for 1). But if that doesn't work, then it looks like I'll
have to try DOSBox. I'm sure it won't be as easy to set up, but that ET4000
emulation is hard to resist.

Please pass along the suggestion to the VPC team to open up VPC's video
emulation to 3rd party contributors. If DOSBox can do it, it seems there's
no reason for VPC not to.

Thanks


P.S. It looks like SciTech has thrown in the towel and their SNAP Graphics
and audio driver source code is up for sale. Perhaps a way to get lots of
video and audio emulations in VPC for cheap? Just a thought.

Robert Comer

unread,
Mar 10, 2007, 4:44:31 AM3/10/07
to
I agree, it would be nice, and I will pass the suggestions along.

--
Bob Comer <Microsoft MVP Windows - Virtual Machine>

"PlanNine" <Plan...@discussions.microsoft.com> wrote in message

news:322449DA-7065-450E...@microsoft.com...

Mark Rae

unread,
Mar 10, 2007, 6:13:49 AM3/10/07
to
"Robert Comer" <bobcomer-...@mindspring.com> wrote in message
news:Ou1pshvY...@TK2MSFTNGP05.phx.gbl...

>I agree, it would be nice,

Yes it would, but I just can't see the incentive either for Microsoft or for
the hardware manufacturers...

In the case of Microsoft, VPC is free these days, so it's not exactly
earning them anything, at least, not directly... I doubt they would see much
business justification in adding this functionality to it...

In the case of the hardware manufacturers, they are almost without exception
focused entirely on their current range of products, so would be highly
unlikely to be interested in devoting a chunk of their development resource
to this sort of endeavour...


Robert Comer

unread,
Mar 10, 2007, 9:07:42 AM3/10/07
to
I don't know about that, there seems to be more and more requests for
support of specialized hardware and software in a virtualized environment...

--
Bob Comer <Microsoft MVP Windows - Virtual Machine>

"Mark Rae" <ma...@markNOSPAMrae.com> wrote in message
news:ufmctUwY...@TK2MSFTNGP05.phx.gbl...

Mark Rae

unread,
Mar 10, 2007, 9:54:26 AM3/10/07
to
"Robert Comer" <bobcomer-...@mindspring.com> wrote in message
news:%23or5w0x...@TK2MSFTNGP03.phx.gbl...

>I don't know about that, there seems to be more and more requests for
>support of specialized hardware and software in a virtualized
>environment...

I agree that there is an increasing number of posts *in this newsgroup* on
this subject, but I wonder how representative that is of the global VPC user
base...?

So do you think there would be a market for a version of Virtual PC which
allowed hardware vendors to write add-ins for their specific kit...? Once
the add-in has been installed, it gets added to a dropdown so that it can be
selected when a new guest is created...?

Not really knowing how VPC works internally, I couldn't possibly say how
hard or easy this would be for Microsoft to do... Taking a similar
oft-requested feature, it's always amazed me e.g. that other virtualisation
software seems to support USB very well, yet Microsoft either don't seem
interested in supporting it, or have neither the technical nor financial
resources to support it themselves... Neither of those options seems
particularly plausible, so why doesn't VPC support USB...? Seems to me that
when it comes to requests for adding functionality to VPC, USB support would
hugely outweigh obsolete graphics card support...

I wonder how much Microsoft would charge for this "extended" version of
VPC...? How much do you think people would be willing to pay for it...?

That said, I really *can't* see hardware vendors having any interest in this
at all...


Plan9

unread,
Mar 10, 2007, 11:13:00 AM3/10/07
to
Hi Mark,

I think you misinterpreted my earlier request:

"The better option, which is the easiest for the VPC team, is to provide a
way for outside contributors to add video card emulations. Of course, they
would be unsupported by MS, but all you would have to do is provide links to
the contributors and say "You're on your own with these". Before you laugh,
that is exactly what is done with DOSBox which is an open source virtual
machine. DOSBox officially supports the S3 only, but one of the supporters
has been writing additional video card emulations and has working ET3000 and
ET4000 emulations as well as a Paradise PVGA1. The ET4000 emulation would
solve a lot of problems for me obviously. And other contributors have
provided a way to access the parallel port for hardware keys. So DOSBox is
looking interesting to me because of the ET4000 addon from an outside source
and the parallel port support also from an outside source. (Thanks to Ronald
Phillips in previous post).

Please pass along the suggestion to the VPC team to open up VPC's video

emulation to 3rd party contributors. If DOSBox can do it, it seems there's
no reason for VPC not to."

MS would change VPC to provide hooks for adding video emulators and
provide some documentation. Then MS is done. There is no involvement by
hardware companies. The point here is to be able to provide emulation for
hardware long out of production. Users who have some background in writing
video drivers would write the emulators for themselves and others. And don't
laugh, that is exactly what has happened with DOSBox as I pointed out above.
DOSBox officially supports the S3 Trio64 and VESA. But a user has written
emulators for the Tseng ET3000 and ET4000 and the Paradise PVGA1. No
hardware vendor was involved.

The point is: open up VPC enough that the user community can add to it
where it has limitations, such as video support. Look at how many of the
posts keep asking about video support or video limitations. Users are doing
it for DOSBox, why not VPC?

Thanks


P.S. Read Wesley's second post concerning USB and Parallel support:
"It [VPC] can also see any USB device that can be shared on the net".
I would take that to mean printers and flash drives at the least.

Mark Rae

unread,
Mar 10, 2007, 11:45:59 AM3/10/07
to
"Plan9" <Pl...@discussions.microsoft.com> wrote in message
news:E44E8C16-F04F-4F59...@microsoft.com...

> "The better option, which is the easiest for the VPC team, is to provide a
> way for outside contributors to add video card emulations.

What - just like that...? By snapping their fingers or enabling some hidden
"Allow hardware add-ins" option in their code...?

What I am saying is that neither you nor I know how easy or difficult it
would be for Microsoft to do that... It may be a relatively simple thing, or
it may be that the existing emulated hardware is so totally entrenched
within the VPC code that the whole thing would need to be fundamentally
re-written to offer what you are proposing... And it is my belief that there
is absolutely no incentive whatever for Microsoft to do it... There is no
doubt at all that it would be of benefit to *you* personally because it
would mean that you could do away with some extra hardware... Similarly,
support for MacOSX as a guest would be of great benefit to *me*, as it would
mean I could get rid of my Mac Mini whose sole use to me is website
testing...

> Please pass along the suggestion to the VPC team to open up VPC's video
> emulation to 3rd party contributors.

Hmm - I doubt that that would carry a lot of weight with the VPC development
manager...

> If DOSBox can do it, it seems there's no reason for VPC not to."

I realise that you firmly believe that, but I have to say that I think you
are very naive in business terms... I am of the exact opposite opinion to
you i.e. I firmly believe that there is absolutely no business reason for
Microsoft to do this... You might as well ask your car manufacturer to fix
it so that it works on water as well as land, because that would allow you
to sell your boat...

> Look at how many of the posts keep asking about video support or video
> limitations.

How many exactly...? Maybe someone with [MSFT] after their nic could say how
many times VPC has been downloaded from the Microsoft Download Centre...
Divide one by the other, and then try to justify your request from a
business perspective...


Robert Comer

unread,
Mar 10, 2007, 12:08:13 PM3/10/07
to
> So do you think there would be a market for a version of Virtual PC which
> allowed hardware vendors to write add-ins for their specific kit...? Once
> the add-in has been installed, it gets added to a dropdown so that it can
> be selected when a new guest is created...?

Yes, I do think there's a market for that, look at any other healthy
software line and you'll probably find they have plug ins of some kind for
extensions. This just takes that idea to the VM. (and nobody else but
DOSBOX has it yet..)

> That said, I really *can't* see hardware vendors having any interest in
> this at all...

There's nothing in it for hardware vendors, only software people...

--
Bob Comer <Microsoft MVP Windows - Virtual Machine>

"Mark Rae" <ma...@markNOSPAMrae.com> wrote in message

news:%23XBx%23PyYH...@TK2MSFTNGP06.phx.gbl...

Mark Rae

unread,
Mar 10, 2007, 1:37:22 PM3/10/07
to
"Robert Comer" <bobcomer-...@mindspring.com> wrote in message
news:euegoZzY...@TK2MSFTNGP06.phx.gbl...

> Yes, I do think there's a market for that

Fair enough, Bob - I respect your opinion, so why don't you suggest it to
Ben Armstrong et al and see what they say...?


Robert Comer

unread,
Mar 10, 2007, 5:42:32 PM3/10/07
to
I will.

--
Bob Comer <Microsoft MVP Windows - Virtual Machine>

"Mark Rae" <ma...@markNOSPAMrae.com> wrote in message

news:eHBMkM0Y...@TK2MSFTNGP06.phx.gbl...

Wesley

unread,
Mar 11, 2007, 4:32:05 PM3/11/07
to
PlanNine,

Activating the VPC's ports is done via its menu under edit settings where
you simply assign the port to the VPC. If you have a printer attached to it,
I would guess that you can access from the net as as a shared device
connected to the guest. I have never tried that.

GCD is compiled with the PharLap 386 DOS extender. In order to get some of
its screens to run in a Win98 VPC "command window", I had to disable some of
the windows special keys by editing the pif. While this may not be an issue
for you, I encourage you not to assume that the way you did things in a
physical machine will be the same for a VPC. While they are functionally the
same, the additional interfaces occasionally require a unbiased mind to see
the best approach. After I got up and running in a Win98se "boot to dos
mode", it took another 5 months to get around to editing the pifs so that
GCD's command line would function in a Win98se "command window". I still
think however that the best GCD speed / network access combo for GCD will be
via a DOS VPC. Because my system is a production system, I do not have a lot
of free time and it may be a while before I get around to tewaking a DOS VPC.
I do not recall having to change my autoexec and config files to get GCD
running but did so later.

I have seen drivers that claims to make most display adapters VESA compliant
but that doesn't seem to apply to your situation regarding VPCs. Except as a
user, the subject of drivers is a black, not gray area for me. It is my
understanding that MS selected the S3 because it had the greatest degree of
compatibility with video cards in general. I would give it a try.

We use CADD to model buildings and produce working drawings, what do you do
with your systems ?
--
Wesley

Plan9

unread,
Mar 12, 2007, 4:04:02 AM3/12/07
to

Hi Wesley,

Thanks for the good information. Now I know the PharLap 386 DOS Extender
will work, though I understand I may have to make adjustments in its or the
application's settings or in config.sys. I still have documentation on them
so I think I can get that part going.

The parallel port setup you described seems straight forward. I always
keep the key on a separate LPT from the printer and PADS will only print to
the LPT ports. So the VM is going to have to give real access to the hosts
LPT1 and LPT2. I tried a suggestion from HP one time on how to trick some
DOS programs into printing over the network when they only support LPT ports
and write directly to them. When you create the Standard TCP/IP port for the
printer, you give the port the name of an LPT port such as LPT2. I tried
LPT1-4, but PADS would never work except on a real LPT. HP did say it only
works with some programs. But there are ways to make a file and then print
it in the Windows XP host. I'm really only concerned about the application
getting access to the hardware key. If it can, then that hurdle is overcome.
But printing on the real parallel port would be nice.

Yes, I need a driver that makes the DOS application "VESA compliant"
rather than the display adapter. In other words, I need a driver which
intercepts the application's video accesses to the selected/supported video
card (ET4000 for example) and translates them to VESA API calls. It has to
work on the application side. Then the drivers VESA API calls to the OS/VM
would be acceptable to most of the VMs since most of them seem to emulate the
VESA standard. I imagine it would be difficult to write a driver that does
that, but I haven't written video drivers so I'm not sure. But then not all
of a chips video modes would have to be supported. If the application
doesn't use it, you could ignore 32-bit color modes for example. Or you
could choose to only support 1024x768 8-bit 256 color and 16-bit 64K color
and ignore 800x600 and 1280x1024, etc. Even MS's S3 Trio emulation leaves
out the 24-bit 16M color modes because they are slower than 16-bit and 32-bit
color modes.

Someone gave me a tip that the Window 3.1 SVGA driver (SVGA.EXE containing
SVGA256.DRV and SVGA256.3GR) supports several video cards at 1024x768 256
color, including the ET4000. And someone wrote a program to patch the .DRV
file to make the driver VESA compliant. If they mean the back-end that talks
to the video card, then it could be very useful. If they mean the front-end
that talks to the application, I'm left with the same problem and it doesn't
help me.

In trying to evaluate the available virtual machines that support my host
and guest OSes (WinXP and Win98SE (full screen mode) or MSDOS 6.22), I've
made the following table of video emulation support:


VM Program Video Cards Emulated User Contributed Video Emulation

Bochs VESA VBE, Cirrus Logic SVGA
CL-GD5430 ISA with 2MB VRAM
CL-GD5446 PCI with 4MB VRAM

DOSBox S3 Trio64, VESA 2.0 Tseng Labs ET3000, ET4000,
Paradise PVGA1A

Parallels Workstation VESA 3.0

QEMU VESA VBE,
Cirrus Logic CLGD5446 PCI

SVISTA VESA 3.0

VirtualBox VESA
Custom Graphics Driver in
Guest Additions (Windows+Linux)

VirtualPC 2007 S3 Trio32/64, VESA

VMware Workstation VESA 2.0


VBE = VESA BIOS Extension


They all seem to support VESA and some support either the S3 Trio64 or the
Cirrus Logic CL-GD5446. DOSBox is the only one which supports the Tseng Labs
ET4000 (via an addon), which all of my apps have drivers for. But being open
source, the documentation is thin and I'm sure it will be the hardest to
install and get running. And I'm not sure if it will support the PharLap 386
Extender properly. Whereas the 4 main commercial programs (VPC, VMware
Workstation, Parallels Workstation, and VirtualBox) have good documentation
and good installation programs to get running quickly and easily. But only
one of my applications has a VESA driver, so I'm trying to decide which VM to
tackle first. I know VPC will run the PharLap 386 Extended apps. Then I
also have to worry about the parallel port hardware key. I now have feedback
that DOSBox (with an addon and PortTalk driver) and VPC will support it and
most of the others indicate some sort of parallel port support in the
documentation. I've collected information and programs and will soon have
time to try them out.

Most of my applications are involved in electronic design: circuit design,
PCB design, etc., so that a PCB can be made and the circuit assembled.


Thanks again for all the help,
Plan9

Plan9

unread,
Mar 12, 2007, 4:30:05 AM3/12/07
to
The table in the previous post got messed up, so here it is again:

In trying to evaluate the available virtual machines that support my host
and guest OSes (WinXP and Win98SE (full screen mode) or MSDOS 6.22), I've
made the following table of video emulation support:


VM Program -----------> Video Cards Emulated ---------> User Contributed
Video

Emulation

Bochs ----------------> VESA VBE, Cirrus Logic SVGA
+ _ _ _ _ _ _ _ _ _ _ + CL-GD5430 ISA with 2MB VRAM
+ _ _ _ _ _ _ _ _ _ _ + CL-GD5446 PCI with 4MB VRAM

DOSBox ---------------> S3 Trio64, VESA 2.0 ----------> Tseng Labs ET3000,
ET4000,
+ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ + Paradise PVGA1A

Parallels Workstation > VESA 3.0

QEMU -----------------> VESA VBE,
+ _ _ _ _ _ _ _ _ _ _ + Cirrus Logic CLGD5446 PCI

SVISTA ---------------> VESA 3.0

VirtualBox -----------> VESA
+ _ _ _ _ _ _ _ _ _ _ + Custom Graphics Driver in
+ _ _ _ _ _ _ _ _ _ _ + Guest Additions (Windows+Linux)

VirtualPC 2007 -------> S3 Trio32/64, VESA

VMware Workstation 6.0 > VESA 2.0


VBE = VESA BIOS Extension

Plan9

Plan9

unread,
Jul 18, 2007, 8:32:04 AM7/18/07
to

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 DPMI


With -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.

See next post for results from Virtuel Machines...

Plan9

unread,
Jul 18, 2007, 8:58:03 AM7/18/07
to

Continued from previous post:

(The previous post covered the attempt to run in Win XP SP2 natively,
without a Virtual Machine).


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 1280x1024

Main 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 standard

Main 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 access


For 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 Logic

I 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:\temp

C:\PROGRAMS\ANSIPLUS\ANSIPLUS.exe

C:
cd C:\PADS
C:\PADS\PERFDOS6.COM
del c:\PADS\SwapFile\PP*.SWP
C:\pads\PPERFORM.EXE /S

Then 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=1024

PADS 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!!!

Plan9

unread,
Jul 19, 2007, 4:44:03 AM7/19/07
to

This is an update detailing the progression of 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 ***


Here's what happens:

DPMIONE:

HX DOS-Extender:

What to do? Perhaps a Virtual Machine could solve the problem.
See the next post for results from 3 Virtual Machines...

Plan9

unread,
Jul 19, 2007, 5:36:03 AM7/19/07
to

Continued from previous post:

(The previous post covered the attempt to run in Win XP SP2 natively,
without a Virtual Machine).

This is an update detailing the progression of 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 ***

*** DOSBox v0.7 ***

C:\PROGRAMS\ANSIPLUS\ANSIPLUS.exe

[vga] - svgachipset=pvga1a
videoram=1024

Finally, with the ET4000 support, I have PADS Perform DOS running in Windows
XP SP2 at 1024x768. 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. Virtual PC was easier to find and setup than DOSBox. 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!!!

And a big wish that the VPC team can find a way to increase the video
support. I'm not the only one would like to run my old program in VPC, but
can't solely because of the lack of video support. Perhaps as DOSBox does,
the video could be opened up to outside support. Only a few more cards need
to be supported in order to cover the vast majority of legacy programs from
this era. The ET6000 (which also runs any ET3000 and ET4000 program) and the
ATI mach64 GX with ATI Spectra RAMDAC (which also runs any VGA Wonder +
program) were high volume chips that dominated the market in their era and
cover multiple chips due to their family compatibility.

0 new messages