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."

Comments

Thanks...

[NamShubCMX]

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...

Why?

[AmVidia HQ]

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)

Re:Why?

[KJKHyperion]

You look at Windows and you think "past" and "legacy". We (ReactOS) look at Windows and think "future" and "innovation"

This you say is (my personal opinion, not the project's official position), a lot like people deluding themselves in thinking that a Linux kernel for the next Windows would mean instant improvement. If you knew a bit more about Windows you'd knew it doesn't even make sense - the Windows kernel has proved to be a sound design and I'd be happy if we could at least duplicate it. It's the system services that need a serious redesign, dragging the legacy microkernel corpse as they are, and I'm already doing some research in that direction (currently reimplementing the console model to be driver-based instead of server-based, and allowing custom UI implementations. This will give you, the user, custom terminal emulators, a more efficient SSH server and a job-controlling shell - even a port of your beloved GNU screen. Next stop: overhauling the service manager and rationalizing the user-mode startup sequence)

And please realize that a supposed intrinsic and purely technical superiority of Linux exists almost entirely in your mind - old kernels (2.4 and earlier) weren't that hot, and when you say "Linux" you generally mean "GNU" (those who say "Linux" meaning "Beowulf" or "OpenMOSIX" are the minority) - and realize that "commodity" also means "largely irrelevant" and "expendable" - when ReactOS gets good enough, it could replace even Linux for some people

This poor suffering disucssion

[ChiralSoftware]

People on /. love to talk about all things to do with MS vs. Linux and yet this poor suffering discussion only generates a couple dozen comments. I will add in something about the best real-world way to use Wine: Codeweaver's Crossover Office. It really works. Microsoft Office 2000 works perfectly in Crossover Office, and Office XP is completely usable for day-to-day work. It is amazing how well these things work and how well they integrate into the Linux desktop. Wine is the foundation of it, and it works. If it works this well now, how will it be by the end of the year? They also have a cascade effect, in that if they solve a bug in MS Office, that might also solve bugs in many other untested applications. I have noticed that the unsupported apps work better and better. Wine is a relevant and cool project. The thing that might make it irrelevant is that Linux desktop software options are catching up. I think that OpenOffice.org is already better than MS Office in many respects.

-----------
WAP software

Windows drivers to linux conversion

[StripedCow]

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).

Re:Windows drivers to linux conversion

[DA-MAN]

Apparently it can be done. Take a look at this.

http://www.jankratochvil.net/project/captive/

This compatibility was achieved in the Wine way by using the original Microsoft Windows ntfs.sys driver. It emulates the required subsystems of the Microsoft Windows kernel by reusing one of the original ntoskrnl.exe, ReactOS parts, or this project's own reimplementations, on a case by case basis. Project includes the first open source MS-Windows kernel API for Free operating systems. Involvement of the original driver files was chosen to achieve the best and unprecedented filesystem compatibility and safety.

I see where ReactOS could be REALLY useful

[nickol]

It's embedded systems. Today, Microsoft has Embedded NT 4.0 which is too expensive, WinXP that is too heavy for most embedded computers, and WinCE embedded which is a kind of a joke.

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.

Re:Huh? What?

[Mycroft_VIII]

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

Re:As cool as the concept of ReactOS is...

[fireman sam]

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"

Re:Why clone Unix?

[Olivier Galibert]

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.