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
> 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... 
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
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.
> 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 
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...
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
  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
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
  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
  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.
-- 
Bob Comer <Microsoft MVP  Windows - Virtual Machine>
"PlanNine" <Plan...@discussions.microsoft.com> wrote in message 
news:322449DA-7065-450E...@microsoft.com...
>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... 
-- 
Bob Comer <Microsoft MVP  Windows - Virtual Machine>
"Mark Rae" <ma...@markNOSPAMrae.com> wrote in message 
news:ufmctUwY...@TK2MSFTNGP05.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... 
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.
> "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... 
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...
> 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...? 
-- 
Bob Comer <Microsoft MVP  Windows - Virtual Machine>
"Mark Rae" <ma...@markNOSPAMrae.com> wrote in message 
news:eHBMkM0Y...@TK2MSFTNGP06.phx.gbl...
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
  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
  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
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...
(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!!!
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...
(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.