If under Windows XP I go to start>run and type in command to get the command-line (C prompt), commands entered are EXCRUCIATINGLY slow although performance in the rest of Windows is just fine. Strange bug?
Not a bug in Parallels, just you choosing the wrong command - run cmd instead of command to get the right one
No, it's there for DOS compat. However, this *is* a bug in PW, since for some reason its running DOS apps under XP very slowly, and also has trouble installing WIndows 9x (which is really a DOS app also). I think PW need to address this. --Tim
That's not a fix. It's not even a workaround if you need to run DOS applications. I hope it can be fixed properly so I can finally toss my Windows machine.
How about just running a separate VM for DOS? Or running OS X port of DOSbox? DOS app support in NT-kernel OSes including XP was never all that remarkable anyway. I consider CMD as simply an equivalent of Terminal in OS X... not to run DOS apps or anything, but just doing stuff the CLI way.
This is not fixed in RC2, but I noticed a clue in the release notes about Windows 98 in VT-x mode. It turns out that this command.com issue only occurs when VT-x is turned on. So for now I have a workaround, although it's sad to be missing out on the acceleration. Maybe this helps to debug the problem, though.
I have this same problem. The company where I work uses cmd.exe at login to push antivirus updates and an antivirus programme if it is not already installed on your computer. This makes the login process effectively impossible for me on Parallels, since it takes forever to join the network. I didn't make it in half a day yesterday. I'll try the Win 98 solution and see if that helps.
The problem with DOS COMMAND.COM is much more stronger in VT-x mode. If your are going to work with it please switch VT-x off in VM configuration. It will be much faster.
I'll take another try at turning off the VT-X tomorrow. Today's attempt did not go well. After three hours, the antivirus had still not loaded. Task Manager shows the CPU usage as very high, but relatively little is coming through cmd.exe process. At the end of three hours, the Windows XP VM had frozen, and the spinning beachball appeared over Parallels when I tried to get out of Windows XP. It took me a couple of force quits to get out of Parallels. The VM runs fine as long as I don't try to connect to the network. Unfortunately, connecting to the network is the main thing I want Parallels to do!
Any Updates on this bug? I was curious if there are any updates on when this bug may be fixed? I understand the work around for now is to turn of VT-x but I would like to be able to run my legacy DOS apps while utilizing the full speed of Parallels. Please advise. Thanks.
My findings I've been trying VMWare over Windows to run an old DOS application (built on Turbo Vision libraries from Borland if there is any one who remembers those libraries) but it would never work, a simple crash of the app just after starting it. And Parallels was the first one which managed to actually load the application and make it work, but then I faced the same problem as the rest of you, painfully slow. So I tried disabling the Intel VT-x thing, as it was suggested, and then I came back to the old problem, app crashing. I didn't give up and I enabled again the Intel VT but reduced the Acceleration to Normal and surprisingly it work far much better, it didn't crash and it worked almost at a reasonable speed (there are some delays of half a second or a second which are noticeable if you are used to the speed of the app). But there was a small detail I wanted to share with the forum, the application behaves the best when I don't use the keyboard at all, since the application has a windowed interface I can use the mouse to access almost every feature that does not require any input from the user. So I think the problem is related with the buffer for the key strokes. Probably someone from Parallels could comment about this? In the mean time try to set the Acceleration to normal and if it is possible avoid using the keyboard for you application (I know, I know, DOS is 99% keyboard).
