Wow! Check this out... WINE beat XP in 67 out of 147 tests :O!
http://wiki.winehq.org/BenchMark-0.9.5
This belongs in Linux, eh?
Not to mention we already know that WINE pwns XP in every possible way, except where it lost.
So, wine is better at running older games and outdated benchmarks at low resolutions. Cool!
amen.
Quote from: Hitmen on January 21, 2006, 10:41:49 AM
So, wine is better at running older games and outdated benchmarks at low resolutions. Cool!
ROFL
That's still pretty bad that M$ is beat by a third-party program designed to EMULATE it. :P
Quote from: Newby on January 21, 2006, 12:17:44 PM
That's still pretty bad that M$ is beat by a third-party program designed to EMULATE it. :P
Wine is NOT an emulator. It's an alternate implementation :P
Quote from: Newby on January 21, 2006, 12:17:44 PM
That's still pretty bad that M$ is beat by a third-party program designed to EMULATE it. :P
Not really.
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.
Quote from: Joe on January 21, 2006, 03:11:24 PM
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.
Quote from: iago on January 21, 2006, 03:19:29 PM
Quote from: Joe on January 21, 2006, 03:11:24 PM
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.
Quote from: MyndFyrex86] link=topic=4595.msg51706#msg51706 date=1137876162]
Quote from: iago on January 21, 2006, 03:19:29 PM
Quote from: Joe on January 21, 2006, 03:11:24 PM
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.
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.
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.
Good question! I found the link on linux-gamers.net... http://www.linux-gamers.net/modules/news/article.php?storyid=1121&referer=rss
There was something on G4 the other night about how Windows was the revolution because people never had to worry about difficulty playing games anymore, or something a long those lines that Dos was too complicated and hard to use.
Only reason I use Windows is because I love gaming, and wouldn't be able to not play things like WoW, and CS.
Quotesomething a long those lines that Dos was too complicated and hard to use.
Heh, DOS isn't hard to use, it just pisses off the hunt-and-peck typers.. a lot. =p
Quote from: Scr33n0r on January 22, 2006, 06:53:36 AM
There was something on G4 the other night about how Windows was the revolution because people never had to worry about difficulty playing games anymore, or something a long those lines that Dos was too complicated and hard to use.
Only reason I use Windows is because I love gaming, and wouldn't be able to not play things like WoW, and CS.
IIRC WoW runs fine on WINE.
Haha. I don't think Wine cheated, considering they implemented that wmf implimentation verbatim (it was affected by the vulnerability too).
I think it's been stated pretty well in this forum that those comparisons were pathetic.
Somepeople should actually *look* at the benchmark before all the Linux fanboys run up
"YES WE DID SOMETHING TO GAIN SOME SORT OF FALSE BELIEF THAT WE STAND WITH THE BIG BOYS"
Quote from: Newby on January 22, 2006, 10:44:28 AM
Haha. I don't think Wine cheated, considering they implemented that wmf implimentation verbatim (it was affected by the vulnerability too).
The vulnerability is in the specification, not the implementation. The thing is, it's not exploitable without a broken image viewer, which is why it wasn't exploitable until Windows 2000 came along, with the broken image viewers.
Quote from: zorm on January 21, 2006, 07:39:34 PM
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.
I finally got around to reading it, so I can answer the question.
Did you look at the benchmarks? For the most part, they where "draw a line", "allocase xxx bytes of memory", "createa 3d object with 3 light sources", etc. You can't exactly stub that out and hope that the benchmarker doesn't notice. Either it works, or it doesn't.