Reader Feedback on VPC 5.02:
(Most recent reports first - there are probably more in my inbox but with hundreds of mails a day I've not been able to read all emails; one man site with too much work to be able to do that.)
We, too, overlooked (read: misread) the note to actually open and 'Shut
Down', instead of executing a 'Save State' for each disk image prior to
Given that we have literally dozens of configurations (for Web and
application deployment testing; e.g., every flavor and subset version of
Windows 95 edition 1 through current XP) per station, per user, all in Saved
States, this would have been terribly impractical, even if we knew about it
(Note to Connectix: this is a nasty thing to force on your power-user
customers; find another updater method that doesn't "break" existing images
Since all of our images are fully backed up, as well as the original app, we
didn't panic when the newly updated VPC 5.0.2 claimed our images with Saved
States were damaged, and suggested we discard them. We knew we needed
something more practical than opening each, and going through standard 'Shut
Down' before an update on every user box.
What we discovered is that by opening any unsaved image (including a newly
generated one, even one booted from the basic PC Boot Floppy image included
in the extras folder), that then going into Settings and designating other
'C:' drive images as second and third drives, etc., and dismissing the
warning about writing data to them, effectively "un-corrupts" (read:
unlocks) the previously Save State.
The only downside is that sometimes (not always) the now "repaired" images
claim they've not been shutdown properly, and require a ScanDisk session on
next startup. The good news is that I was able to set up a low-level tech
who could "pre-repair" all the images for all the users across the network.
It takes mere moments per disk image using this method. Tedious for dozens
compiling into hundreds, but faster than the alternative, and better than
starting from scratch.
Hopefully this tip will reach a few panicked and frustrated individuals who
would otherwise trust the errant error message and discard the images, and
reinstall everything from OS to applications and user docs from scratch.
[what did you use the open the saved state/images
after the update?]
We used any other image that would open (startup as a Windows or
DOS OS), either one that we repaired, or one that we newly created. By
adding other drive images to that PC state, ones that would normally be C:
drives with bootable OSes on them, they then become "uncorrupted" when added
as D: and E: drives, and can then be booted again as C: drive startup disks
by VPC 5.0.2.
[how can those without any backups of their
drive images select other drive images?]
Sorry, this I should have outlined more clearly.
1) Use the main VPC 'Virtual PC List' window to generate a 'New...' VPC
2) Follow the 'PC Setup Assistant' wizard, create a new (preferably
expandable) drive -- which you will discard later -- with an easily
recognized name like "Kill Me Later" and launch your newly created PC.
3) You will probably get a DOS message about "No OS found on disk....
Install blah blah blah...." Ignore this.
4) Use the 'Capture Floppy Image' command from the floppy icon at the bottom
of the running VPC Window; navigate to your 'Virtual PC 5.0' application
folder: Extras: Installing Other OSes: PC DOS Boot Disk; Select the image.
5) Press 'Enter'; the PC will now boot from the floppy image as drive A: ;
you'll get another DOS message about initializing the C: drive and adding
drivers; say 'No' and continue.
6) Now simply open the 'Drive Settings' for the current PC; add your
original "corrupted" drive image to a 'Drive 2' or 'Drive 3' slot; Save by
hitting 'Restart' as instructed; you may get a warning about writing to the
disk and possible damages; ignore this.
7) To be safe, after restarting the basic DOS again (repeating step 5 if
needed), use the typical DOS commands to verify that you can "mount" the
desired image (e.g., type 'd:' at the 'a:>' prompt; then 'dir/p' at the
'd:>' prompt; if you see your directory with windows on it somewhere, you're
golden). If you can't "mount" the drive, or are afraid of DOS, don't worry
8) Shutdown (not 'Save State'!!!) your newly created DOS PC.
9) Now try again to launch your original VPC config from the 'Virtual PC
List' window, or, if previously discarded, generate yet another new PC, but
select your original disk image as Drive 1 (typically named 'PC DOS 2000' or
similar; may be found in the current user's 'Documents' folder or in the
master VPC application folder), and it should launch normally. You may get a
DOS message about not being shutdown properly; let it run ScanDisk and all
should be well.
As an alternate method, one can try to use the 'Virtual PC Setup Assistant'
to generate a new PC, but rather than create a new drive, use the 'Duplicate
from existing drive image' option. It should do the same thing, but I have
no more corrupted images to test; our method was designed to repair numerous
images (about 150), as many as possible at one time.
"Just a comment on VPC performance. People should be absolutely certain that
the partition containing their VPC application and 'hard drive' is
defragmented. Fragmentation will absolutely destroy VPC performance.
"I was reading through your site and noticed the 5.0.2 update to Virtual
PC. After downloading and installing the update, I decided to try and
connect to the Windows Network at work through Win2000 in Virtual PC.
I connect to a WAP using WEP on my iBook 600 12.1". Before, I could
access the internet using Shared Networking in Win2000, but I could
never connect to my intranet using Shared Networking or Virtual Switch
Networking. After the update, I can connect using Virtual Switch
networking and browse other windows machines.
I was able to do this with a direct wired connection before, but now the
wireless route is a go too.
Just thought everyone else might like to know.
I read your note about VPC 5.0.2 leaving chmod zombies around and
can verify this behavior under 10.1.3 on a QuickSilver G4/733:
sbnoble 9220 7.3 20.4 220012 133924 ?? S 2:53.52 /Applications/Virt
root 9224 0.0 0.1 1728 360 ?? S 0:00.01 VirtualPC_Services
root 9435 0.0 0.1 1344 336 std R+ 0:00.01 ps aux
root 9223 0.0 0.0 0 0 con- Z 0:00.00 (chmod)
sbnoble 9436 0.0 0.0 1112 220 std R+ 0:00.00 fgrep 9
root 9227 0.0 0.0 0 0 con- Z 0:00.00 (chmod)
root 9228 0.0 0.0 0 0 con- Z 0:00.00 (chmod)
root 9229 0.0 0.0 0 0 con- Z 0:00.00 (chmod)
root 9230 0.0 0.0 0 0 con- Z 0:00.00 (chmod)
This is not happening with the 5.0.1 installation under 10.1.3 on a
PowerBook Pismo G3/400, although that version seems to leave
VirtualPC_Services in a zombie state.
It looks like VPC is spawning these chmods but then is not handling
their exit states (done by either calling waitpid() upon a SIGCHLD or
by using sigaction to set SIGCHLD to SA_NOCLDSTOP). Thus the zombies
(which exist only to hold exit state information) wait around until
Looking at the VPC binaries, it appears that it can spawn the BSD
applications /usr/sbin/chown, /bin/chmod, and /bin/sync. I'm not sure
why they feel the need to spawn separate processes for these actions
as they all have equivalent system API's which would be more efficient
My guess is that they are using these chmod's to safely manage root
versus user privelages for resource management. VirtualPC_Services
runs as root, probably to enable network and resource management,
while the main VPC app runs as the user: a VERY good idea for
security. The chmods are probably adjusting the privilages of various
files so that the relatively unprivilaged main app can access them.
I suspect, based on this and Connectix's past statements about
performance under MacOS X, that they programmers are kind of learning
unix as they go. At least they don't run the main VPC app as root:
given that bit of savvy, all else can be forgiven.
- President - Data Expedition, Inc.
I just wanted to add that I had problems with virtual switch even with OSX 10.1.2. As John noted, DHCP was not working for me so I had to place static IP addresses in all my virtual environments. This goes from Win98 to WinXP. But I think this is the way its supposed to work? Since with virtual switch on and running OSX, your Win OS now acts like its connected to a hub and does not share your Macs IP address as it does in shared networking. So unless you have a real DHCP server on your LAN, the PC will not get an IP address with virtual switch enabled.
In OS 9 I do not think Virtual Switch does anything and acts like shared networking? At least that is the way I read their info on it. Here is an excerpt from their FAQ
"Virtual Switch: In Mac OS 9, this option provides the possibility of a fixed IP address for the virtual machine. In Mac OS X, the Virtual Switch allows your virtual machine to become a fully functional network node that can communicate with other virtual machines running on the same Macintosh, the host Macintosh itself, or other computers on the network. Additionally under OS X, Virtual Switch addresses advanced networking needs such as remote login (rlogin) or running a Web or FTP server with predefined port numbers."
And actually I can even use a static IP address if shared networking is used in OS 9. I don't know if its supposed to work that way as using Virtual Switch in OS 9 is supposed to be used for static IP address in OS 9 but its working for me :)
So I suggest John either assign manual IP settings or if he is not trying to fileshare between virtual environments on one Mac, that he should just use Shared Networking.
Thanks, Thomas Koons
Virtual PC Update fixes Windows CE Ver. 3.11 ActiveSync with Compaq IPAQ
Not tried this with anything but my ipaq yet, but here's my specs.
Powerbook G3/400 - Pismo, 384MB RAM
, 20GB HDD
, MACOS X 10.1.3
, Virtual PC 5 with 5.02 updater (released yesterday),
Windows 98SE under VPC
IPAQ USB Charge -N- Sync cable
Compaq IPAQ 3635 16ROM/32RAM
Have never been able to sync my IPAQ before, having hear VPC 502 update
fixed LOTS of stuff, I figured I'd give it a shot. I went to computer
settings and under usb, as I plugged in the IPAQ, boom! my IPAQ showed up.
Shortly after that it detected my ipaq in windows, and then installed Active
Sync again, works perfectly. Installed a CE Cab and an application that
had to install in windows to be installed on CE. I'm thrilled!
Hope everyone else that has a ce device has as much luck with this as I did.
Having seen the article on your site regarding the new VPC 5.0.2 update, I
immediately rushed to the Connectix site, downloaded it, and installed it
(including applying the new 8032 additions).
It works fine in MacOS 9.2.2 on my PowerBook G3 500MHz in both Windows 98
and Windows 2000Pro. It even fixes the conflict that existed in 5.0 and
5.0.1 with Joliet Access.
I then moved on to try it under MacOS 10.1.3 on the same computer.
Unfortunately I seem to have found a huge bug in VPC 5.0.2 under MacOS
Even though I am using exactly the same VPC 5.0.2 application folder,
preference folder and disk images under both MacOS 9.2.2 and 10.1.3
networking does not work under 10.1.3 (and does work under 9.2.2).
I have Virtual Switch enabled for both Windows 98 and Windows 2000Pro and
set to use the default interface. This works perfectly under 9.2.2 but under
10.1.3 the Windows systems (using DHCP) fails to obtain a TCP/IP address and
therefore cannot do any networking. My recollection is that this did work
under VPC 5.0.1. Note: MacOS 10.1.3 itself does not have any networking
problems (i.e. Ping and web-browsing work fine).
Does anyone else see the same problem?
Another reader said he was able to surf/download using IE after the update. I asked if John had read the info in the VPC 5.02 vital info and suggested contacting Connectix tech support and if he tried creating another PC config.
A reader with a "saved state" VPC session updated with 5.02 without shutting down the
saved state first and after the update VPC 5.02 reports it's corrupted. He later wrote:
Yes, I tried the create a new pc option. It walks you through setting up
another virtual pc state BUT it has no OS! So it seems I need to somehow
install Win2000 into my new pc state. Haven't gone that route yet, still
combing the net looking for advice to rescue my old state (I loath having to
reinstall everything). Really there should be a disk-repair type of utility
for fixing corrupt states, I would think.
[his next mail said]
OK I am an idiot!
Here is what happened: I skimmed the read me file and thought that it said
to shut down VPC before installing - well duh, who wouldn't shut down an app
before installing a updater to it?! However, that is not what it said.
Instead, and this is very important, SHUT DOWN YOUR VIRTUAL PC STATES! They
cannot just be saved with VPC shut down, you must shut all states down and
then VPC itself.
To my credit Connectix could have made a bigger deal about this in the read
me file. They could also have mentioned what would happen if you do not shut
So for those as foolish as I who had saved states and ran the updater here
is the solution to getting your states back: uninstall VPC using the
un-install option of the installer on the CDROM (don't worry it won't delete
your states); reinstalled VPC 5, your saved states will work again; shut
down all saved states and then VPC; run the updater. All should be fine.
I think there should be a bold warning as the top line in the installer readme/info panel
and the readme file about shutting down saved states before running the updater.
Another reader commented on "zombie" processes:
Have you noticed all the zombie process that VPC leaves while it's running.
They are all chmod and chown. The longer it runs the more it spawns.
[I asked if he had any network issues after the update]
I don't do any networking from the windows side although Explorer worked
fine and I was able to download stuff from the net.
I could also surf the net, etc. from VPC 5 in OS X after the update. (OS X was using Airport network to share a cable modem.)