Windows 2003, anyone tried it/running it?

Pu-239 · Post by **Pu-239** » 2004-07-15 02:33pm

Praxis, DarWINE would still have to emulate all the libraries and such associated with Windows, so there wouldn't be much of a speed advantage over VPC, furthermore there are compatibility problems with WINE.

Oh, and there are non-apple PPC hardware such as Pegasos which you can run Linux and Mac-on-Linux at a decent speed, and avoid using Apple hardware. Of course, there is no point to doing this- you probably could run MoL on a POWER processor though

. Of course, you would be missing accelerated graphics and altivec among other things though.

Praxis · Post by **Praxis** » 2004-07-15 05:12pm

As I said, it would not be emulating the core files of Windows. They would be PPC-native, recompiled for PPC instead of x86. The emulator ONLY runs the programs.

Durandal · Post by **Durandal** » 2004-07-15 05:44pm

The Windows API would be PowerPC native, but that doesn't mean that it'd be fast by any stretch of the imagination. In fact, I'd imagine that it's poorly optimized and fairly buggy at this point. Furthermore, any third-party libraries and APIs used by any applications would still run under emulation. So drawing all the windows and stuff might be faster, but actually doing things that don't involve Windows API calls would still be emulated.

Praxis · Post by **Praxis** » 2004-07-15 07:16pm

To quote the FAQ:

"Why aren't you just porting QEMU and then running wine through the port of QEMU?"

The primary goal for QEMU was to let Wine (x86) run onto Linux/PPC. QEMU works by translating linux x86 system call to linux ppc system calls. It means that the whole library environment is emulated and requires to be x86. So to have Wine running on top of X11 you would need to do a bunch of translator. The advantage of this approach is that you don't have to deal with function call conversion and the issue you will encounter with endianness and only have to deal with system calls.

The Darwine Team is doing a Mac OS X port of wine, and then the integration of an emulator because we would like to be able to modify Wine to take advantage of Mac OS X . For example we want Darwine to use the Mac OS X Display System, and not X11. It may be faster to have something working using the qemu-user approach, but then, it will be really tricky to improve the Mac OS X's integration.

Regarding speed: We believe it will be faster to have ppc-native dlls. For example consider the User Interface dlls, if they are emulated, as would be the idea of running wine through qemu, the user may notice the slow down, as everything will draw slower on the screen. User Interface slow downs is one of the many reasons an application like Virtual PC is so slow, a lot of the emulated processor cycles are used for drawing the UI, instead of being used for execution. So by having ppc-native dlls which would be linked to the Mac OS X frameworks (Quartz), there will be more emulated proccessor cycles for execution and drawing on screen would be almost instantaneous.
----

The DLL's and WINE and everything will all be PPC native. Compare to Virtual PC in which the system has to emulate EVERYTHING, INCLUDING RAM-hogging Explorer.exe, the entire Windows GUI, the dlls...etc, etc.

Durandal · Post by **Durandal** » 2004-07-15 08:23pm

You're not listening. I KNOW what Virtual PC has to do. But what happens when you run across a DLL that has not been ported by the DarWINE folks? That's right, you have to emulate those calls. Any API which hasn't been reverse-engineered or recompiled by the DarWINE team must be emulated in the traditional fashion or else it simply will not work. And if you'll read what they wrote and what I wrote, you'll see that we say the same thing. Drawing windows and non-custom UI elements may be faster, but that's really it. Compute operations which do not call standard APIs will still have to be emulated.

And guess what? There are plenty of applications which use DLLs not found in a standard Windows install, and thus probably won't be redone by the DarWINE folks.

His Divine Shadow · Post by **His Divine Shadow** » 2004-07-18 04:26pm

Posting this from 2k3, pretty sweet IMHO, gone through the server -> workstation guide I found on the net and it's like XP with the basics now, 2k3 is much more responsive and it boots quick as hell, only OS to be in the same leauge as BeOS that I've seen.

Uraniun235 · Post by **Uraniun235** » 2004-07-19 12:16am

Did you run into any problems?

His Divine Shadow · Post by **His Divine Shadow** » 2004-07-19 03:20am

Uraniun235 wrote:Did you run into any problems?

Only of my own fault, backed up everything I needed except ISDN drivers compatible with 2k3 so when I had it installed I had no drivers, oh well XP supported them out of the box didn't it, or so I thought so I installed XP and tried to get that working, nope I was wrong.

Around this time I dig out an old USB modem hoping XP will recognize it, nope, no generic drivers, but this modem is of some unknown make so I wasn't suprised...

So now I wipe off both 2k3 and XP and install mandrake 8.2 since I had that lying around, I was 100% positive it supported my ISDN card, and it did, thank god, so I downloaded the drivers and wiped Linux and installed 2k3 again and now it's working fine.

2k3 didn't recognize my SB 128PCI at first either but when windowsupdate started downloading it suddenly found and recognized it, I guess the hardware search function looked on MS' online driver database automatically or something.