Stop Microsoft
Operating Systems => Not Quite Mainstream OSes => Topic started by: bjx0 on 22 July 2004, 23:20
-
Hi. I'm new to the forum and I HATE Microsoft but unfortunently most of my stuff only runs on Windows. But then I found ReactOS (See ReactOS.com). It's an exact copy of Windows NT but open source and still runs NT programs. I want another one like it. Is there anything like it?
-
FreeDOS (http://freedos.org/)
-
Wrong Forum
-
ReactOS is far form finished, and I far as I know there is nothing else like it.
Your best bet is to read up on Linux a bit before you install it, and check out the Linux hardware compatibility list (http://www.linuxquestions.org/hcl/index.php) to ensure that the distrobution you choose will run on your computer.
Linux has native equivalents of most Windows programmes and they are normally better, and a lot cheaper too, as they are often free. If you really need to keep your Windows programs you can always run them under Wine (http://www.winehq.com/) a Windows emulator.
-
Oh and FREE DOS is hardly an alternative to Windows as it can't run any Windows software.
-
Stop postcount++
(http://forum.microsuck.com/ubb/edit_ubb6.gif)
-
Free DOS is DOS not... Not what I was looking for. I already know about Linux. I want something like ReactOS
-
George:
I have never heard of anything else like ReactOS. I am sorry, but you're SOL I'm afraid.
Why do you hate MS?
Do you hate Windows too?
I hate MS, but I don't hate Windows!
-
quote:
Originally posted by Aloone:
George:
I have never heard of anything else like ReactOS.
Lindows.
-
quote:
Originally posted by insomnia:
Lindows.
That wasn't exactly his point, either.
-
Lindows is nothing like ReactOS. ReactOS is an OSS implementation of NT.
Dave Cutler even said it was damn good.
-
When did David Cutler say that!
I'm also curious about ReactOS, as you know I've had problems with Linux, although I'm still interested. If/when ReatOS becomes more mature and supports most of the NT drivers, I will consider using it.
I will hope that there will be better desktops available than the Windows one. I don't want a free + better Windows clone, I want something a bit different, that's hopefully easier to use.
A cheeper Windows clone that just so happens to have a Linux kernel isn't my idea of a good OS.
If wanted a free Windows clone with a Linux kernel then I could just pirate Lindows. There again I could take any Linux distro, add Wine (if it isn't included), then slap-on XPde.
Anyway isn't Lindows only semi open source?
How did MS take a good OS, then fuck it up so horribley?
I've heard that VMS was almost as good as UNIX, if not even better in some ways.
Thank goodness they didn't get their sticky fingers on UNIX.
Hang on a second if they did, then Linux would have knocked them out!
But if they'd fucked up UNIX, and bastardised the standards, Linux may have only been as good as ReactOS.
Who knows!
-
quote:
Originally posted by JimmyJames: GenSTEP Founder:
Lindows is nothing like ReactOS. ReactOS is an OSS implementation of NT.
Wrong.
ReactOS is like Wine (remember, Wine Is Not an Emulator).
Lindows also uses a Wine Layer.
(IMO they both suck.)
-
ReactOS is not an NT clone, in the way that Linux is an open source UNIX. ReactOS is an attempt to make an open source NT compatalbe operating system.
The kernel is unique, the plan is for it to use NT drivers and not Linux, thus it can't use Linux kernel.
The ReactOS development team have ported some Wine code, as it would be stupid for them to write it from scratch.
quote:
Wine Is Not an Emulator
Wrong, Wine is indeed an emulator!
I know where you got this idea from but the source is incorrect: http://www.winehq.com/site/myths#slow (http://www.winehq.com/site/myths#slow)
This is wrong, IMO the use of the word emulator is very confusing. Wine does emulate Windows, by imitation and if you don't believe me look up the word emulation: http://dictionary.reference.com/search?q=emulation (http://dictionary.reference.com/search?q=emulation)
This is done in a completely different manor to processor emulation, but even so, it is still emulation.
When a PC uses a software emulator to imitate a RISC PC, the program acts as an interpretor, by converting each RISC instruction in the program to it's PC equivalent, instruction by instruction. Processor emulation is shit slow, the same way that a basic interpretor or a python virtual machine is slower than C.
Wine isn't slow because it isn't an interpretor, it's just an API layer. Wine emulates Windows by the the use of a Windows API layer that then is bolted on to any x86 UNIX, which may be run on a different micro under a PC emulator.
I have seen many Windows programs running faster under Wine then they do under Windows, this is because Wine + Linux > effiecent than Windows.
-
quote:
Wrong.
ReactOS is like Wine (remember, Wine Is Not an Emulator).
Lindows also uses a Wine Layer.
No... you're wrong.
Wine translates Windows API calls to Linux and X11. ReactOS IS AN NT COMPATIBLE OPERATING SYSTEM. It doesn't run Linux and do any kind of translation. They've shared code with Wine, but that's it.
Your facts you must get straight. Speak not when your information is false! Mmmmmhmmmhmmm!
-
quote:
Wine translates Windows API calls to Linux and X11.
I did think that too, but I said "API layer" because I thaught I might have been wrong.
I suppose Wine is both an interpretor and an emulator, how confusing?
-
no... its name is true. it is not an emulator. it's a true Windows API on *nix.
-
http://dictionary.reference.com/search?q=emulator (http://dictionary.reference.com/search?q=emulator)
-
quote:
Originally posted by Aloone:
http://dictionary.reference.com/search?q=emulator (http://dictionary.reference.com/search?q=emulator)
That link was horrible and gave me lots of spam.
Wine is NOT A FUCKING EMULATOR.
W I N E
=> Wine Is Not an Emulator.
Does your small brain fails to understand this?
[ July 24, 2004: Message edited by: insomnia ]
-
Wrong again, Wine is an emulator.
Dictionary definition for the word emulator:
1. To strive to equal or excel, especially through imitation: an older pupil whose accomplishments and style I emulated.
2. To compete with successfully; approach or attain equality with.
3. Computer Science. To imitate the function of (another system), as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system.
insomnia, does your small brain fail to understand this?
[ July 25, 2004: Message edited by: Aloone ]
-
A Windows emulator would use its own kernel inside a virtual machine. Wine does not. It uses the kernel of the host OS. It is equal to the Linux or X11 API. In theory, you could run Wine on Windows. You emulate hardware. You implement APIs.
A Windows emulator would not interact with other Linux apps, and instead would run in its own Window... the way VMware or Virtual PC do.
Wine is a Win32 API layer for *nix. VMware is an emulator.
Stop being a dipshit and listen to what people say. Learn things or die.
[ July 25, 2004: Message edited by: JimmyJames: GenSTEP Founder ]
-
quote:
Wine is a Win32 API layer for *nix. VMware is an emulator.
I already know that, read my last posts, moron.
Wine and VMware are both emulators.
Now lets look at the dictionary definition of the word emulator:
Computer Science. To imitate the function of (another system), as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system.
Now lets apply it to Wine:
quote:
To imitate the function of (another system)
In this case with Wine, Linux is imitating Windows.
quote:
as by modifications to hardware or software
Wine is run on top of Linux and thus is a modification to the software.
quote:
that allow the imitating system to accept the same data, execute the same programs
With Wine, Linux can execute the same programs as Windows, thus alowing it to acept the same data (you can run Corel Draw and open files created for use under Windows).
quote:
and achieve the same results as the imitated system.
A program run under Wine will achieve the same results under Wine as it will under Windows.
Wine is an emulator, it allows one system (Linux) to perform the same operation as a different system (Windows).
The mechanism behind an emulator is insignificant when looking at the definition of an emulator, an emulator is a fucking emulator, and Wine is by it's definition, is a fucking emulator!
It makes no fucking differance whether it's a virtual machine, an API layer, or a chip added to the motherboard of a system, an emulator is still an emulator.
If you don't understand this, read this post over and over again and then one day it might sink in through you thick skull, that WINE IS AN EMULATOR!
[ July 25, 2004: Message edited by: Aloone ]
-
I don't know why I just don't say it... I guess I've tried to be too nice...
SHUT THE FUCK UP.
Nobody gives a damn that you know how to look up a word in the dictionary. Do you want a cookie? You're missing the entire point... and to boot, you're being a complete ass.
So, to date, this is what you've done. You started off by coming and dissing Linux in your first post. You annoyed everybody with your childish "Linsux" and "Winbloze" bullshit. Now you're being an ass and snapping at people because they don't agree with your goddamn dictionary?
Fuck off.
-
I guess that running Linux on a Mac would be "emulation". You've modified a system (you removed Mac OS from the picture) and you're running an OS that was "made for" x86 PCs.
Hey, by your definition, you're "emulating".
To paraphrase you...
It makes no difference whether you're stupid, retarded, or just trying to be an asshole. A dipshit is still a dipshit.
-
I was not the first person in this tread to start insulting people.
I have not said either "Linsux" or "Winbloze" in this thread.
I was wrong to use them in the first place, I admit it they are imature and I have not used them for ages.
You only brought them up to be insulting and they are completely irrelevant to this discussion.
Have I dissed Linux in this thread?
NO!
The fact that I have in previous threads is also totally irrevevant.
Dissing something that dosn't work for you does not make you an arse-hole. I admit it, I should have learned a lot more about Linux before I dissed it. To make mends I have not dissed Linux for a while now and I am learning about it. Just because I made a mistake it doesn't make me an arse-hole.
The only reason why you're last 2 posts have been so irrelevant, insulting, and childish, is because it has suddenly occurred to you that you're wrong.
Try admitting it for a change, know one will hate you for it.
(http://graemlins/thumbsup.gif) Nice one Jimmy, thanks for fucking yet another good thread up!
Now you may use this thead to bitch about me all you want
I don't care!
I won't respond unless you or someone else posts something decent.
Think about it, Jimmey you are so cool because you can have the last word if you want it!
-
So you're actually accusing Wine for stealing MS code!?
Do you have any proof of this or are just trying to annoy people like in every other post you made.
You allways come up with the most absurt lies possible.
(http://slug.gnhlug.org/talks/FEB02/pics/slide_6.jpeg)
Ps. Wine doesn't emulate anything.
[ July 25, 2004: Message edited by: insomnia ]
-
quote:
I guess that running Linux on a Mac would be "emulation". You've modified a system (you removed Mac OS from the picture) and you're running an OS that was "made for" x86 PCs.
No, you would no longer be running an OS made for the PC, because by the very act of recompiling the OS you are remaking it for a Mac, an emulator can run a program that was made for use on another system (be it a different Micro, or under a different OS on the same micro) with out modification to the code or data.
quote:
So you're actually accusing Wine for stealing MS code!?
NO!
When did I say that?
quote:
Do you have any proof of this or are just trying to annoy people like in every other post you made.
Ask the people at:
http://dictionary.reference.com/search?q=emulator (http://dictionary.reference.com/search?q=emulator) to change their definition then:
3. Computer Science. To imitate the function of (another system), as by modifications to hardware or software that allow the imitating system to accept the same data, execute the same programs, and achieve the same results as the imitated system.
I know how Wine works.
An emulator dosn't have to emulate differant hardware it can just emulate a differant operating system.
Thus Wine Is Not a hardware Emulator.
Wine is a compatibility layer or an operating system API emulator.
It allows a Linux or UNIX system to execute a program that was compiled for Windows.
Wine loads the program into memory and the CPU is left to execute it as it normally would. Wine interprets the calls that the program normally makes to Windows and then either executes the equivalent UNIX call or if this dosn't exist, calls a routine in one of it's librarys. Some of these can be DLLs either written by the WINE developers or if you have Windows on your hard disk they can be native to Windows.
Jimmy & insomnia, I don't hate you (http://smile.gif) , if I did I wouldn't reply to any of your posts.
I think that we are just arguing about words and interpretation.
You say Wine is not a hardware emulator, I agree I never said it was a hardware emulator.
I am just arguing that Wine alows Linux to run the same programs as Windows by emulation of the Windows API. The same way that DOSEMU (http://www.dosemu.org/) is a DOS emulator for UNIX/Linux.
-
quote:
I am just arguing that Wine alows Linux to run the same programs as Windows by emulation of the Windows API. The same way that DOSEMU is a DOS emulator for UNIX/Linux.
Oh boy :rolleyes:
No that's not how it works.
That woudn't even be legal since you'd need MS code.
Wine is only compatible with it.
Wine doesn't use any MS code.
Emulators are slow, Wine isn't.
It doesn't emulate anything, it's a complete different system(like reactOS) that aims to be compatible with Windows programs.
Their isn't any form of emulating involved.
It's name (Wine is Not an Amulator) is NOT a joke!
That's just how it works.
What will be your next annoying claim.
Claiming GNU is UNIX?
Ps: Please stop pretending as if you understand API structures, you don't.
Also, find yourself a better dictionary...
[ July 25, 2004: Message edited by: insomnia ]
-
or perhaps that BSD "emulates" UNIX because you can run some SysV binaries.
-
Oh, and Aloone...
(http://www.ecsyle.com/jimmyjames/media/beegees.jpg)
-
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 (http://www.dosemu.org/) 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.
-
?!?!?!?
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 ]
-
doesn't DOSemu actually run FreeDOS in a VM?
-
Brought to you from the great people @
(http://www.winehq.com/images/winehq_top_logo.gif)
WINE HQ (http://www.winehq.com/site/myths)
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).
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...
(http://www.finalplanet.net/OURWORLDNOW/eric_estrada_you're_a_homo.jpg)
As a matter of fact...how about you email this guy mailto:julliard_at_winehq.org and explain that to him?
(http://www.winehq.com/images/bannerads/cw-ad02.gif)
[ July 26, 2004: Message edited by: AmericanBastard ]
-
We win, you lose Aloone. Stop your tantrum and shut up.
-
I have included a link to this in a previouse post and I don't know why I didn't do this before, as it illustrates my point!
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.
I never said that Wine emulates each processor instruction of the Windows application.
quote:
As Wine's name says: "Wine Is Not an Emulator":
Wine is not a CPU emulator, it is purely Windows API emulation!
quote:
Wine does not emulate the Intel x86 processor.
I never said it did!
quote:
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.
I never said Wine is slow!
quote:
Windows applications that do not make system calls will run just as fast as on Windows (no more no less).
Well as Wine doesn
-
Dude, I'm a N00b. I know maybe a handfull of command lines in the konsole. I also know you're an EYEDee107. It IS NOT an Emulator. It is a translator/interpretor if anything. When you have someone change a foriegn language into your native tongue so you can understand it, it's called translation. They are in no way, shape or form emulating the other language.
You are saying the developer has no idea what he's talking about, you sir are a dunce. Read WINES web page and feel st00pid. I am through with you on this. If you wrongly feel you are correct, then argue your point with Alexandre Julliard. I'm sure you could make HIM understand, since he only writes it, and himself is obviously errant in saying it's not an emulator.
I will now add you too my list of people who are clueless and laugh at your every post.
[ July 26, 2004: Message edited by: AmericanBastard ]
-
Just edited my post, sorry if it was too late!
A CPU emulator is a translator, it translates the program instruction by instruction to the hosts processors native instruction set (language). Wine is definatly not a translator.
If I run a PC program on a Mac under PC emulator software, the software is acting as a translator (interpreter).
-
OK...as long as you understand you got
PWNED BY TEH N0083J[/i]
[ July 26, 2004: Message edited by: AmericanBastard ]
-
quote:
I think we are just arguing about words and their interpretation.
We are.
That is, we are interpreting the words correctly. You are not. You seem to be very literal and quite inflexible in your comprehension.
-
quote:
Originally posted by Aloone:
I have included a link to this in a previouse post and I don't know why I didn't do this before, as it illustrates my point!
Wine is not a CPU emulator it is emulation of the Windows API under Linux/UNIX.
No it doesn't.
Wine does not emulate any existing MS Windows API stucture. (If it would, you could run ALL Windows programs on it.)
They made their own compatible structure.
Just resemble their size, the one from Wine is much smaller.
An amulated API structure would also mean that it doesn't actually exist.
THE ONE FROM WINE DOES EXIST.
quote:
Originally posted by Aloone:
BUT:
WINE AND DOSEMU BOTH WORK ON A SIMILAR PRINCIPLE!
IF WINE IS NOT AN EMULATOR THEN; IF YOU'RE DEFINITION IS TO BE CORRECT... DOSEMU IS NOT AN EMULATOR EITHER!
[/b]
They're not alike.
Dosemu uses code from an existing OS, Wine doesn't
Ps: Don't even bother to keep replying. I will simply ignore you.
[ July 26, 2004: Message edited by: insomnia ]
-
quote:
You seem to be very literal and quite inflexible in your comprehension.
Maybe I am... maybe you are... maybe we all are!
The names Wine and DOSEMU must be both bullshit then!
IF: Wine Is Not an Emulator.
THEN: DOSEMU can't also be an emulator.
AND
IF: DOSEMU is an emulator.
THEN: Wine must also be an emulator.
Round and round we go!
Wine and DOSEMU both work on a similar principle.
Neither DOSEMU, nor WINE are CPU emulators.
They are both compatibility layers or dare I say it, examples of API emulation of a different OS.
The phrase "compatibility layer" is also very non-descript, you could also argue that a CPU emulator is an example of a "compatibility layer"
since it is literly a layer of code between the OS or program bieng executed, to serve to make the forign code compatible with the host CPU.
Perhaps we should email the developers of both projects and tell them.
Hay it's fun to play word games! (http://smile.gif)
-
Oh and insomnia,
DOSEMU dose not contain the whole FreeDOS code base, and it will not run all DOS programs.
Not all the Win API is documented some is HIDDEN, thus not all Windows programs run under Wine.
DOSEMU has a totally different structure to FreeDOS just as Wine
-
quote:
Originally posted by Aloone:
Oh and insomnia,
Not all the Win API is documented some is HIDDEN, thus not all Windows programs run under Wine.
DOSEMU has a totally different structure to FreeDOS just as Wine
-
Yet again, read the whole thing...
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).
[ July 26, 2004: Message edited by: AmericanBastard ]
-
Wine is not an emulator, and neither is DOSEMU.
Wine doesn't include any Windows code but it can use Windows code (in DLL form) providing that you have Microsoft Windows installed on your hard disk.
If WineHQ.org could get hold of the Windows source they would use it, and if they did then by your logic, Wine would become an API emulator. that make sense
[ July 26, 2004: Message edited by: Aloone ]
-
On second thaughts:
I DON'T CARE !
The fact of the matter is that Wine Is Not a hardware emulator so it doesn't slow your programs down!
Why sould anyone care wheather it is an API emulator or not?
I DON'T GIVE AFUCK!
DOES ANY ONE ELSE?
I AM NOW GOING TO SHUT THE FUCK UP, AS I NO LONGER CARE!
[ July 26, 2004: Message edited by: Aloone ]
-
quote:
Originally posted by Aloone:
I AM NOW GOING TO SHUT THE FUCK UP, AS I NO LONGER CARE!
Finally.
-
what a dipshit. he fucks up a thread (just like he fucked up my GenSTEP thread) by arguing the nitpicky details of something (what is really an emulator? what's is really bloat?)then he goes away once the damage is done.
shitty. let's get this thread back on track... has anbody gotten the ReactOS apps to run on NT?
-
quote:
Originally posted by JimmyJames: GenSTEP Founder:
xxxx x xxxxxxx. xx xxxxx xx x xxxxxx (xxxx xxxx xx xxxxxx xx xx GenSTEP thread) by arguing the nitpicky details of something (what is really an emulator? what's is really bloat?)
Irrelevant, nobody mentioned GenStep or bloat in this thread, and as I have already stated I don't give a fuck, the emulator debate is long gone. I regret starting it now.
I am truly sorry no sarcasm or any shit. I am genuinely sorry. I didn't mean to upset anyone.
Oh and I still don't hate you Jimmy! (http://smile.gif)
quote:
Originally posted by JimmyJames: GenSTEP
then he goes away once the damage is done.
I'm still here! :D
quote:
Originally posted by JimmyJames: GenSTEP
xxxxxx. let's get this thread back on track... has anbody gotten the ReactOS apps to run on NT?
(http://graemlins/thumbsup.gif) I don't know why someone didn't just say this earlier.
ReactOS isn't mature enough for people to write applications for it. I believe it's original purpose was for it to run existing Windows applications. I have not tried it yet, but I imagine it could run very simple programs, maybe a text editor.
When I get the time I will try it.
[ July 26, 2004: Message edited by: Aloone ]
-
quote:
Originally posted by JimmyJames: GenSTEP Founder:
what a dipshit. he fucks up a thread (just like he fucked up my GenSTEP thread) by arguing the nitpicky details of something (what is really an emulator? what's is really bloat?)then he goes away once the damage is done.
shitty. let's get this thread back on track... has anbody gotten the ReactOS apps to run on NT?
It currently ony runs some small GNU apps.
Also, it's currently only focused on NT 4.0.
They plan to use as much Wine code as possible, but they're not that far yet.
[ July 26, 2004: Message edited by: insomnia ]
-
insomnia, I remember you saying in one of your previous posts that ReactOS sucks.
Why?
I think it'll be alright, when/if it gets finished.
-
quote:
Originally posted by Aloone:
insomnia, I remember you saying in one of your previous posts that ReactOS sucks.
Why?
I think it'll be alright, when/if it gets finished.
It doesn't.
However it's basically the same thing as Wine.
Since I don't use(and like) any NT programs, I don't need it.
As a full OS, it doesn't have enough apps.
Technically their's nothing wrong with it, I just don't see anyone ever using it.
(UNIX+Wine makes more sense)
-
quote:
Originally posted by insomnia:
It doesn't.
However it's basically the same thing as Wine.
Since I don't use(and like) any NT programs, I don't need it.
As a full OS, it doesn't have enough apps.
Technically their's nothing wrong with it, I just don't see anyone ever using it.
(UNIX+Wine makes more sense)
Yes, it makes more sense to use a fully working and functional UNIX based OS and run any Windows software under Wine. Rather than using the half finished and far less functional ReactOS. You also don't get the benefits of running any of the free Linux only applications.
ReactOS isn't shit, it's just impractical, the only reason I can see for anyone using it is, if your unlucky like me and your bloody retarded hardware won't run Linux very well.
Don't you think that the ReactOS developers should work on something more worthwhile such as Wine?
Oh and by the way:
I've heard that VMS was almost as good as UNIX, if not even better in some ways.
How did MS fuck up a perfectly good operating system?
I know that David Cutler and some of the VMS team worked on NT.
What went wrong?
Did they start abusing solvents or something?
Or did they write good code only for it to get fucked up by some retarded MS programers?
-
quote:
Originally posted by Aloone:
What went wrong?
DOS
-
ReactOS only shares code with Wine... it isn't like Wine, though... I think they just use Winelib for Win32 compatibility
-
quote:
Originally posted by insomnia:
DOS
No, I was talking about NT...
Oh, you mean they tried to make NT DOS compatible. I was under the impression that NT runs DOS programs under NTVDM (stupid name, NT virtual DOS machine) a DOS compatibility layer.
But there agian it still had to be compatable with the WINDOS series.
Together Wine and DOSEMU have accomplished this in Linux and they haven't fucked it up.
MS must have just brain washed them or something!
[ July 27, 2004: Message edited by: Aloone ]
-
quote:
Originally posted by George:
Free DOS is DOS not... Not what I was looking for. I already know about Linux. I want something like ReactOS
Crossover office on Linux?, Wine?, WineX?
-
no.
I think he really just wants ReactOS... an NT-compatible OS
-
No, I think kintaro means: (crossover office | Wine | WineX) + Linux > ReactOS