Should software behave differently in a VMWARE VM?

[peter-h]

WinXP VM, win7-64 host.

I am aware of how virtualisation works anduse VMWARE all the time, for pretty complex stuff, but I have a really weird problem: one of the settings in Adobe Distiller (yeah this is old stuff but for a good reason) is not "sticking". It is the one for deleting any existing PDF of same name. I just keep getting the "delete file?" prompt.

The same setup runs fine under native-installed winXP.



I am also aware that under Windows the printer settings need to be done in the application that prints if you want them saved; doing it under Control Panel / Printers is not sufficient.

I could solve it by getting somebody to write a little prog which is continuously checking for the presence of this file and if it sees it, it waits for say 30 secs (the reason is nontrivial) and then deletes it.  It may also be doable with a batch file (which auto starts) which keeps checking for this pdf and if it finds it, it does the wait and then zaps it. But that's ridiculous.

[NE666]

It's been a very long time since I've worked with any version of VMware, however, it used to be the case that virtual disks could be created to be, and/or set as, "Non-persistent". i.e. they would discard changes made during operation, when either the VM was powered-off or reset.

Is it possible that's happened in your case? Hence changes in OS and app config are being lost?

[peter-h]

Great point, but I am not using that option.

I've even tried setting and unsetting that checkbox repeatedly.

Either Distiller works differently in the VM, or it is using some other config (some .ini file?) which is overriding it.

UPDATE: I think I fixed it. It was the common windows problem: a mixup between the C:\Documents and Settings\Peter\Desktop\Appname, and C:\Documents and Settings\All Users\Desktop\Appname. It looks like the app running (and Distiller, being triggered by its print process) did not have privileges to overwrite the file in the other location.

EDIT2: not quite. It mostly works but still breaks occassionally.

[peter-h]

This is an update in case anybody finds this one day...

That checkbox just doesn't work reliably. The reason it used to work out of a VM was because a VM brings some weird performance issues. For example when a program displays a form with various objects on it, when running natively they all come up in milliseconds or less. But in a VM you can get long time delays, which will break things when you have one program waiting for a dialog in another program to appear and then it goes to fill in some data.

VMs just need a fast machine and lots of RAM in the host.

Other obvious things to do in the guest are to disable defragmentation, and even disable the swapfile.
https://www.eevblog.com/forum/projects/winxp-ssd-and-running-winxp-in-a-vm/