Operating Systems > Not Quite Mainstream OSes

ReactOS ....

<< < (7/12) > >>

Aloone_Jonez:
One processor emulating another procesor is slow.


Wine dosn't emulate a CPU, it loads the program into memory and the CPU is left to execute it as it normally would.

Think about it, how could this slow things down?

The processor is executing it at it's normal clock rate!

I never mentioned any MS code here!


When the program calls a Windows system routine, Wine just executes it's UNIX equivalent.

How would this slow things down?

The code in the UNIX system call is executing at the normal CPU clock rate!

I never mentioned any MS code here!


If the direct UNIX equivalent dosn't exist Wine calls a DLL written by it's developers that performs the same function.

How would this slow things down?

The code in the DLL is executing at the normal CPU clock rate!

I never mentioned any MS code here!


If you have Windows on your hard disk Wine can use native Windows DLLs.

How would this slow things down?

The code in the DLL is executing at the normal CPU clock rate!

This is all legal since you have licence to use the Windows code on your hard disk.


Wine does not emulate a CPU, it does API emulation, there's a very BIG differance.

Think about it.

You're trying to tell me that DOSEMU is an emulator but Wine isn't!

What does Wine do?
It emulates the Windows API.
You already know how it does it.
I've already said how it works.

What does DOSEMU do?
It emulates DOS API.
How?
To put it simply, by hooking all the DOS interupts and providing DOS driver wrappers for UNIX drivers. DOS programs mostly make system calls via the 21h interupt vector, DOSEMU just hooks this and calls the UNIX equivalents.

I've seen some programs running faster under DOSEMU than they do under native MS-DOS, so it can't be a CPU emulator.

So by your definition DOSEMU isn't an emulator.

They haven't stolen any code, and they don't use the entire FreeDOS code base so by your reasoning it can't be an emulator.

insomnia:
?!?!?!?
Are you joking me??????
Wine isn't slow cause it aien't a damn fucking emulator!

And do stop that crap about it's API structure.
For the last time, Wine has it's own API structure and does not emulate the ones from Windows (I know it can, but that aien't even an official part of the Wine Project.).

Dosemu includes the base code from an other OS, Wine doesn't.

Is this really that hard to understand?

PS: Do you really believe it's name, Wine is Not an Emulator(aka Wine), was just a joke?

[ July 25, 2004: Message edited by: insomnia ]

hm_murdock:
doesn't DOSemu actually run FreeDOS in a VM?

pofnlice:
Brought to you from the great people @



WINE HQ
         
quote:
Myth 1: "Wine is slow because it is an emulator"
Some people mean by that that Wine must emulate each processor instruction of the Windows application. This is plain wrong. As Wine's name says: "Wine Is Not an Emulator": Wine does not emulate the Intel x86 processor. It will thus not be as slow as Wabi which, since it is not running on a x86 Intel processor, also has to emulate the processor. Windows applications that do not make system calls will run just as fast as on Windows (no more no less).
Some people argue that since Wine introduces an extra layer above the system a Windows application will run slowly. It is true that, in theory, Windows applications that run in Wine or are recompiled with Winelib will not be able to achieve the same performance as native Unix applications. But that's theory. In practice you will find that a well written Windows application can beat a badly written Unix application at any time. The efficiency of the algorithms used by the application will have a greater impact on its performance than Wine.

Also, and that's what people are usually interested in, the combination Wine+Unix may be more efficient that Windows. Just as before it's just how good/bad their respective algorithms are. Now to be frank, performance is not yet a Wine priority. Getting more applications to actually work in Wine is much more important right now. For instance most benchmarks do not work yet in Wine and getting them to work at all should obviously have a higher priority than getting them to perform well.

But for those applications that do work and from a purely subjective point of view, performance is good. There is no obvious performance loss, except for some slow graphics due to unoptimized Wine code and X11 driver translation performance loss (which can be a problem sometimes, though).

Myth 2: "Wine is bad for Linux"
One undeniable fact exists: there is a vast software library that works with Microsoft's operating systems. Many of these applications already have Linux equivalents, however for most people there remains a handful of programs keeping them tied to Windows. Some of these programs have almost no chance of getting ported to Linux (e.g. Microsoft Office), others simply can't be ported because they've become abandonware (e.g. TurboTax 1999). Would I want to have Windows just because someday I may need to access an old tax program?
The fact that Wine exists won't prevent companies from porting their software, but having less than a few percentage points of marketshare will. Wine puts more free software into the hands of people who would otherwise not use it. In turn, history has repeatedly shown that larger marketshare leads to more commercial development. More commercial development has always led to more efforts to develop better free software equivalents.

Myth 3: "Emulators like VMWare are better"
Sure they're better.. if you like purchasing a full copy of an operating system just to run it under a virtual machine. Not to mention you need to purchase a copy of VMWare to make it work.
Oh, and don't forget the huge performance hit you take to run an application on a full-blown operating system running on top of an operating system.

However, having said that there are instances where emulators are quite useful. Developers can create sandboxes to run applications in, test other operating systems without rebooting, etc. But having a full-blown emulator just to run a word processor probably isn't the best solution.

Myth 4: "You need Windows anyway"
No. The goal of Wine is a full reimplementation of the Windows API which will make Windows unnecessary.
You can already run a lot of applications without having Windows installed. But you have to realize that because Wine is still far from completion many applications will indeed require Windows for some functionality that Wine does not yet provide itself.

Myth 5: "Wine is bad, Winelib is better"
This seems to be a quite popular myth on Slashdot. Basically some people think that running a regular Windows application with Wine is much less reliable and yields much lower performance than recompiling this same application with Winelib. It seems to be a variant of the 'Wine is slow because it is an emulator' myth.
There is really no reason for this. For starters I certainly did not observe any performance difference between Wine and Winelib for the (relatively few I admit) applications I tested in Winelib. Furthermore you have to realize that bugs are not in the way Wine handles PE, i.e. Win32's executable format, programs. Bugs, and performance issues alike, come from the implementation of the Windows API and this is shared anyway.

Myth 6: "Wine will always be playing catch up to Windows and can't possibly succeed at running new applications"
The architecture of Wine makes adding new APIs (or DLLs) fairly easy. Wine developers rapidly add functions as needed, even applications requiring the latest functionality are usually reported working within a few months of release. Examples of this include Office XP and Max Payne (a DirectX 8.0 game) - both of which were fairly new as of this writing (5/2002.)
In addition, Wine supports using native DLLs when the built-in versions don't function properly. In many cases, it's possible to use native DLL versions to gain access to 100% of the functions an application requires.

Myth 7: "Because Wine only implements a small percentage of the Windows APIs, it's always going to suck"
APIs are like a library - it's always nice to have as many books on the shelves as possible, but in reality a few select books are referenced over and over again. Most applications are written to the lowest common denominator in order to have the widest audience possible. Windows XP support is simply not that important - most applications only require Windows 95 or Windows 98. Currently Wine supports over 90% of the calls found in popular Windows specifications such as ECMA-234 and Open32. Wine is still adding Win32 APIs, but a lot of the work right now involves fixing the existing functions and making architecture changes.
Myth 8: "Wine is only for Windows 3.1 / Wine will never support Win64"
Wine started back in the days when Windows 95 did not exist yet. And although Windows NT (and thus the Win32 API) already existed, it only supported Windows 3.1 applications. Anyway, almost no-one used Windows NT in that time anyway.
But these days are long gone. The Windows 3.1 support may still be more complete than that of the Win32 API but most of the development nowadays happens for the Win32 API. Furthermore I should point out two more things. First, it seems people complaining about Wine supporting only Windows 3.1 usually do not realize that Wine also includes some support for the DOS API. That's because a non negligible percentage of Windows 3.1 and even Windows 9x applications still make calls to the DOS interrupts! Second, Winelib only supports the Win32 API. The Win16 header files (necessary for compiling a Win16 application) have been moved out of the way to simplify development. So in some way the Win32 API is better supported than the Win16 one.

So currently Wine does not support the Win64 API at all. But the Wine team does take Win64 into account when making architectural decisions. In fact we'll probably see history repeating itself: the Win64 API has not been released in a commercial product yet, so no-one is using it anyway. So I can predict that when it becomes widespread we'll see Wine developers starting to work on supporting it.

Myth 9: "Wine is for Linux only"
This is just plain incorrect. Ok, as of now Wine does not run on many platforms: just Linux, FreeBSD and Solaris. Still, this is not 'Linux only'.
It is true too that most developers work on Linux. So you run a higher risk of having a specific release of Wine not compile/work on a non-Linux platform. But this is usually fixed in the next release. Also Wine has been known to be missing some important functionality on non-Linux, e.g. good multi-threading. As far as I know these problems are now solved and Wine works just as well on any of the three platforms mentioned above.

There also is a Win32 compatibility project for OS/2 (Odin), which makes use of Wine code.

Myth 10: "Wine is for Intel x86 only"
Well, it is true that Wine only runs on Intel's x86 processors. Unfortunately it will also require quite a lot of work before it runs on other processor architectures.
But what do we mean by 'running on a non x86 processor'.

First it can mean 'I can compile a Windows application on Sparc, link it with Winelib, and have it run on Solaris'. I know, this is not what you had in mind. This may seem very restrictive and yet would be very useful: it means easy porting of Windows applications to almost any Unix architecture. In any case this is the first step towards allowing Wine to run on other processor architectures. Unfortunately Wine's code is not very portable to other processor architectures, partly because some parts of it have to know a lot about the processor, and partly because most of it makes assumptions like 'sizeof(int)==sizeof(pointer)' and 'byte-sex==little-endian'. This is being worked on though, and progress is being made albeit slowly.

Then we could take it to mean 'Wine on Alpha should be able to run Windows NT Alpha applications'. The prerequisite for this is that Winelib compiles on Alpha (or MIPS, the other defunct Windows NT platform). Now, would it be really useful? I don't think many people have Windows NT applications for the Alpha or MIPS processor. So this is probably not that useful and also rather unlikely to happen since we would need a programmer who has just this combination of hardware and software to work on it.

Then there's what everyone has been waiting for: 'I want to be able to run my x86 Windows applications on any processor architecture I like. That's the most complex one. Again the prerequisite is that Winelib works on this architecture, which will definitely happen someday. Then 'all that is needed' is to integrate an x86 emulator with Wine (and also change Wine's name :). Ulrich Weigand just did that as an experiment some time ago when he had 'some spare time'. He even managed to get some Win16 applications to run. His code was not in a state where it could be integrated into Wine yet and I don't know how much work has been put into pursuing it. His attempt did spark many discussions on Wine's mailing list though. The result is that we would need a sophisticated emulator including a JIT in order to get something really viable (i.e. not too slow). And developing such an emulator is a whole project in itself.
Does it mean it will never happen? Not sure. Maybe we'll get some motivated developers once the Winelib problems are solved. Of course, it would happen much faster if, for instance, Compaq made its Fx32! Intel x86 emulator Open Source and financed the development of Wine for their Alpha machines. As with all Open Source projects, if enough people are interested and pool their resources together, it will happen.

Myth 11: "My game has copy protection that doesn't work with Wine"
TransGaming has done extensive work to get copy protection working. They've added support for popular formats such as SecuRom and SafeDisc. In the case of the latter they've licensed SafeDisc LT from Macrovision and incorporated the necessary changes into the core parts of their Wine tree.
Currently in the LGPL Wine tree you can find support for SafeDisc 1 with SafeDisc 2 on the way. The caveat being that Wine must run in NT mode (configure winver "nt40" in the wine config file).

--- End quote ---


Read the rest-o-teh-myths duder...The introduction page spends a good deal of time talking about how wrong you are A Loone. Oh Yeah...



As a matter of fact...how about you email this guy mailto:julliard_at_winehq.org and explain that to him?



[ July 26, 2004: Message edited by: AmericanBastard ]

hm_murdock:
We win, you lose Aloone. Stop your tantrum and shut up.

Navigation

[0] Message Index

[#] Next page

[*] Previous page