I have a 17" MacBook Pro, 2 Gb Ram, latest Parallels beta, Windows XP SP2. At my work I need to access a DOS task for cataloguing books in our school library. The DOS tast is so slow it seems as though Windows has hung. Eventually, after selecting a task in the application something happens. This is not an issue under Bootcamp using the same configuration. There are no problems with windows tasks when running. Is there a way of fixing this?? TIA Rod
I ran into a similar problem when I ran a console/command window based application that I use for entering football statistics. The command window would display the application's initial screen but keyboard responsiveness would be very sluggist. Eventually, the application would hang. Soon after, performance in the VM would get so bad that I would have to reset it. This same application running inside a Windows XP VM running inside Parallels Workstation for Windows 2.2 beta works just fine. The application runs normally and is quite responsive to keyboard input. It appears that this issue is isolated to Parallels Desktop for MAC.
This is a known problem. The only workaround (which only works sometimes) is to launch cmd.exe (intstead of command.com) and try from there.
That's not the only workaround. The one which actually works is to disable VT-x. It'd be nice to hear from Parallels whether this is ever going to be fixed. I'd like my VT-x back.
Edit your VM properties. Select the option "VM Flags" and deselect the option "Enable Intel VT-x support"
A little confused... From what I gather a file running from DOS in XP doesn't work like it does on a windows machine. I am asking because I have compiled a program from visual fortran that is an executable within the command prompt. Will I be able to run this executable at native speed? Thanks, Nuc
It seems many (all?) DOS programs run poorly in parallels. Best to just install the beta (assuming you haven't bought) and give it a whirl for your particular app.
I haven't tried this, but here's my wild guess informed by many years of Windows development experience: If you are talking about a Win32 command line app, I'd guess it would work just fine. If you have a 16 bit comand line app, I'd guess you will run into the problem everyone else is compalining about. Here's my reasoning: Sixteen bit apps run under WOW (Windows On Windows) which is a Windows component that simulates a real mode 8086 using hardware support built into processors from (IIRC) 486 onward. I suspect that Parallels doesn't provide access to that hardware functionality, but emulates it. This means that the DOS command processor and the app it runs are both running emulated (as in slow). Running the 32 bit command processor may improve results by reducing the amount of code that has to be emulated. IMHO, the fact that it works at all is a feather in Parallels' cap BTW. If anyone has any actual info to add to or contridict this, I'd like to see it, being the curious person I am.