WINE can beat XP!

[Ergot]

Wow! Check this out... WINE beat XP in 67 out of 147 tests :O!
http://wiki.winehq.org/BenchMark-0.9.5

[Joe]

This belongs in Linux, eh?

Not to mention we already know that WINE pwns XP in every possible way, except where it lost.

[Hitmen]

So, wine is better at running older games and outdated benchmarks at low resolutions. Cool!

[Warrior]

amen.

[Sidoh]

So, wine is better at running older games and outdated benchmarks at low resolutions. Cool!

ROFL

[Newby]

That's still pretty bad that M$ is beat by a third-party program designed to EMULATE it.

[iago]

That's still pretty bad that M$ is beat by a third-party program designed to EMULATE it.

Wine is NOT an emulator.  It's an alternate implementation

[Sidoh]

That's still pretty bad that M$ is beat by a third-party program designed to EMULATE it.

Not really.

[Joe]

If WINE were an emulator, it would create a virtual machine that emulates an X86 processor, which Windows would then be run on. Then, WINE would call forth the EXE within Windows.

All that WINE does is interpret the EXE, instruction for instruction, and calls the apropriate functions from it's own API implementation. If anything, WINE is an interpreter.

[iago]

If WINE were an emulator, it would create a virtual machine that emulates an X86 processor, which Windows would then be run on. Then, WINE would call forth the EXE within Windows.

All that WINE does is interpret the EXE, instruction for instruction, and calls the apropriate functions from it's own API implementation. If anything, WINE is an interpreter.

Something doesn't sound right about that, but I think it's true for the most part. 

[MyndFyre]

If WINE were an emulator, it would create a virtual machine that emulates an X86 processor, which Windows would then be run on. Then, WINE would call forth the EXE within Windows.

All that WINE does is interpret the EXE, instruction for instruction, and calls the apropriate functions from it's own API implementation. If anything, WINE is an interpreter.

Something doesn't sound right about that, but I think it's true for the most part. 

The part that doesn't sound right is the interpreter part.  As I understand it, WINE loads and executes Windows programs just like Windows does, and provides the dynamic link library framework for Win32 API calls.  The API calls then call back to the kernel in standard Win32 (almost all API calls are thunks for kernelmode code), whereas in WINE, it converts necessary calls to Linux.

[iago]

If WINE were an emulator, it would create a virtual machine that emulates an X86 processor, which Windows would then be run on. Then, WINE would call forth the EXE within Windows.

All that WINE does is interpret the EXE, instruction for instruction, and calls the apropriate functions from it's own API implementation. If anything, WINE is an interpreter.

Something doesn't sound right about that, but I think it's true for the most part. 

The part that doesn't sound right is the interpreter part.  As I understand it, WINE loads and executes Windows programs just like Windows does, and provides the dynamic link library framework for Win32 API calls.  The API calls then call back to the kernel in standard Win32 (almost all API calls are thunks for kernelmode code), whereas in WINE, it converts necessary calls to Linux.

But that DOES sound like an interpreter, in a way.  It runs them natively, and maps the calls to its own libraries.  Which is close to what he said. 

[Warrior]

So it just implements the Windows API and maps the actions to X calls and general Linux kernel api? Well I'd guess it's  faster than emulating each processor instruction and all that stuff.

[zorm]

Interesting but how an you actually benchmark something like this? WINE is unfinished so it goes without saying that calling a stub will be faster than calling a real function. Furthermore WINE may cheat at somethings for the speed vs functionality.

[Ergot]

Good question! I found the link on linux-gamers.net... http://www.linux-gamers.net/modules/news/article.php?storyid=1121&referer=rss