[dtempleton@virginia.edu]

Hi;

We have a scientific application that can be run under WinXP or from CMD (Dos) that we would like to run as fast as possible on our new MacPro. This thing takes 16-20 hours to run on a pentium, so we would like to have as fast as possible access on the MacPro. We would also like to have it run from the bash terminal, so that we can use bash scripting to optimize data flow.

Can you suggest the best way of running this? We can run under Parallels, of course, but this can't be called from the terminal (I think) We have also considered:

Wine (or DarWine) though this seems to be oriented towards graphic apps.

Q (QEMU) though this is emulated and claims "500 mHz performance".

It seems we might also be able to boot straight into DOS, though then we have... DOS.

any suggestions?

dennis

[ghporter]

Boot Camp, Windows XP, and Command Line (the Windows version of Terminal). In that order...

Seriously, if you want the speed, you NEED to boot native into something that can run the program, rather than Wine which emulates the API (or Parallels, which emulates the whole machine).

Or spend the $1k or so to get a dedicated Windows machine... If you need speed, you need as much of the system as possible to be built for your software.

[Tomchu]

You also have to remember that since this is a DOS application (as you say), then it won't be multithreaded -- so you'll want to run it on the CPU that is fastest at executing a single thread that you have access to.

[Chuckit]

Originally Posted by ghporter 

Seriously, if you want the speed, you NEED to boot native into something that can run the program, rather than Wine which emulates the API

What do you mean? As far as I know, WINE doesn't "emulate" the API in any sense that would slow things down. It reimplements the API.

As for WINE being focused on graphical apps, that is true, but that doesn't mean it doesn't support DOS apps — it just means Windows is a bigger challenge. I'd give that a try, personally.

[ghporter]

Originally Posted by Chuckit 

What do you mean? As far as I know, WINE doesn't "emulate" the API in any sense that would slow things down. It reimplements the API.

As for WINE being focused on graphical apps, that is true, but that doesn't mean it doesn't support DOS apps — it just means Windows is a bigger challenge. I'd give that a try, personally.

Poor choice of words on my part-WINE is indeed a Mac/Unix/Linux interface for the Windows API. But it doesn't implement everything smoothly nor is it without some problems. Maybe it would work fine for a DOS program, maybe not. An extra layer, even a very good one, between the app and the hardware won't be as fast as the Command Line in a native booted Intel machine running Windows. Of course WINE is free (right?), so trying it can't hurt. I just think it won't be as fast as the application might be on a machine running Windows natively.

[Chuckit]

I've actually heard of cases (non-typical, I'm sure) where WINE ran apps faster than Windows just because Windows had a poor implementation of the functions the program depends on.

[hookem2oo7]

are you sure it's an old 16 bit DOS app and not a 32-bit windows command line program?