Slashdot Mirror
Steven Edwards On The Future Of ReactOS And Wine
Alex_Ionescu writes "WineHQ brings us the scoop on the latest developments in ReactOS, as well as on Steven Edward's excellent job on porting Wine to MingGW and linking the two platforms together. This is an interesting insight into the WINE and ReactOS project, and a must-read for anyone interested into the future of Windows-replacement projects like these."
Although I don't see the use now, I know that 10 years from now on, I will say THANKS too all the developers that will have allowed anybody to use their old unsupported softwares...
We've always been at war with Eurasia.
I can see the usefulness of Wine, in running legacy programs as well as serving as a bridge between Windows apps and Linux. But why write an entire new OS for this same purpose? I just don't see the point of re-inventing yet another Windows wheel.
Perhaps starting from scratch (ReactOS) is easier than the writing the middleman layer (Wine), which is still playing catch up after many years?
(Any flames was unintentional. I would love for either project to succeed, I just want to know their merits)
VIVA1023.com | Political Fashion.
Of course it will be relevent, once it has compatibility with windows you have a massive application base on a libre os. it doesn't really matter if it wanders away from compatibility with 'longhorn' etc, the point is porting to windows proggys to it will be trivial and with the amount of applications already available, enough people may actually be using it to make the porting worthwhile. Effectively you solve the 'chicken and egg' problem by skipping the egg, if that makes sense.
This is a joke. I am joking. Joke joke joke.
-----------
WAP software
Would it be possible to use the Wine code to run hardware driver code written specifically for windows, under linux? I guess it would be nice if this could be done without having the complete "wine" emulator in core, only the necessary components. Perhaps someone could write a windows driver -> linux driver converter, which takes the windows driver object code, and links in the necessary components from wine (only those win32 functions called by the driver, plus dependencies).
If Pandora's box is destined to be opened, *I* want to be the one to open it.
> once it has compatibility with windows you have a massive application
> base on a libre os.
Don't see it. Wine has been trying for ten years just to get the Windows APIs recreated. So lets assume these guys get to 1.0 by 2009, five years from now. How much Windows NT 4.0 software do you expect anyone to be itching to run in 2009?
> point is porting to windows proggys to it will be trivial
Winelib is already feature complete enough to port most Windows proggys. Haven't seen em busting down CodeWeaver's doors to get help porting much of anything.
And remember the hardware problem. How much effort in the Linux camp goes to getting hardware working? How much new hardware in 2009 is going to be shipping with NT4 drivers? Or assume they get NT5.1 (XP) drivers running somehow.... without rewriting the internals of ReactOS too much. Longhorn is going to ship by 2008/09 so driver availibility will already be drying up for XP by then. So are they going to be writing their own drivers? And how about drivers in general? NT/XP ships with drivers for most common hardware, so the vendors don't bother shipping one with the actual products. But those are (C) Microsoft and non-redistributable so where does ReactOS get drivers for all of that common hardware? Yea in theory it is possible to be able to load the Nvidia driver for the GeForce 10000 Belchfire 1GB that will be shipping by then and will include a driver disc, but what about USB webcams and firewire hard drives, onboard sound chips, ACPI, etc. Who writes those drivers?
Democrat delenda est
What we really need for those PC104 and other small boards is an OS with the following features:
open-source and configurable
reliable and stable
small resources requirements
working from ROM
Win32 compatible, supporting DCOM and MS-style networking.
There is no need for DirectX, scanner support and such. It looks much like that despite Microsoft declares embedded systems support as one of their primary goals, they just do not know what to do.
WinCE is for PDAs, not for industrial systems.
Wine the point is to create a windows clone. Wine has some of that functionality, but depends on Linux/bsd/unixy stuff to work.
What wine already has would be usefull in the NON-UNIX environment they a building.
Now thier choices are to
a) remove the dependancies on *nix from wine, somthing mingw helps with.
b) recreate everything usefull in wine from scratch (re-invent the wheel)
c) add a unix emulator for an nt workalike that will support wine so that thier running a windows workalike on a unix workalike on windows workalike.
Which do you think is thier best option.
Mycroft
https://signup.leagueoflegends.com/?ref=4c3ed6600b6ea
Actually, it is some US companies that are trying to sell to the government that OSS is "un-American" and "goes against the American way of life", is "used by terrorists". You know what companies they are so I wont bother naming them here.
What the parent poster, and all other posters (me included) that associate OSS with terrorism, being un-American, a hippie, a communist, etc. Is using it as sarcasm, as if they were posting directly to those companies who are saying such things.
ie:
SCO: "Linux is unAmerican and is a terrorist threat to national security"
LZelot: "Ohhh, Well I guess there is going to be a big national full out anti-terrorist investigation, and a $100000000 bounty on all penguins"
SCO: "See, even the zelots agree"
it is only after a long journey that you know the strength of the horse.
The reason Dr. Dos and other failed was in part do to the fact that it depended on income to succed and thus could go belly up financially. Much harder for an open source project do that.
No, the reason DR-DOS failed is because it is *DOS*. By the time it became popular (the DR-DOS 5.0 days) it was already irrelevant.
DHCP only implies UDP, and that's rather easy. In fact, I participated in a project where it took ~6 months to get IP/UDP/ARP/DHCP running in VHDL on a FPGA, and let me tell you, it's way harder than in pure software.
TCP on the other hand is really complex.
OG.
Steven has been a good friend of mine for many years. I can remember him trying to get StarCraft and IE working in WINE years ago. At the time, I thought that it was a wasted effort. I still do in a way, since I prefer native applications to using any form of Windows applications, but I am glad to see that Steven is now able to make a living off of something he loves. The article was quite good, and if you would have seen the improvements in ReactOS in the past year or two, you would be shocked. There wasn't even a GUI (at all) or a file manager even 2 years ago!
Talk about MEGA-COOL projects!
The way it's described in the article, soon, you'll have as high a probability of running Linux on ReactOS alongside your Windows apps as you will to running your windows apps alongside your Linux apps on Linux through Wine.
And all these projects share code and therefore testers.
Once more users and developers flock to these solutions, the level of quality will keep rising.
It really is going to be very interesting.
And probably nerve-wracking for Microsoft...
I really can't see where Microsoft's niche will be.
I don't know the meaning of the word 'don't' - J
Unix was cloned for a number of reasons.
No, Unix was never cloned at all... at least not in the same sense that ReactOS is a clone of WindowsNT. But then again, Unix isn't even a piece of software. UNIX(tm) is, however.
ReactOS aims for binary compatibility with Windows (it barely works, but that is their goal). Linux and BSD not only lack binary compatibility with UNIX, they don't have complete source code compatibility either- and their maintainers don't want to add it, considering some old UNIX ways to have been mistakes.