Some thoughts

[theuserbl]

Nice to see the Kickstarter project Thorium. But is it the right way?

Differences of situation between WINE and ReactOS:
WINE gives more possibilities.
At first, WINE is for Linux- (and MacOSX) Users. And Linux-User know, what OpenSource is.
ReactOS is more for Windows-User. And they see only: Oh, it is free of charge. But currently you can find Windows XP for lesser then 30 US$ in the internet.

Windows 32bit can run 16bit Windows programs and 32bit Windows programs.
Windows 64bit can run 32bit Windows programs and 64bit Windows programs.
WINE tops it. The 64bit WINE version can run 16bit, 32bit and 64bit Windows programs.
ReactOS on the other hand, seems not to want 16bit Windows programs.

WINE is for Linux an addition. So that Linux programs can run and Windows programs. Because the Windows-programs are on Linux only a "bonus", users don't see it as worth, if not all Windows-programs can run on it.
On ReactOS the only programs, which can run on it, are Windows programs. And ReactOS will every time be compared with the mature low cost Windows.

The mentioned advantage of ReactOS, is the driver-compatiblity. But Windows is incompatible to itself in this point:
Windows XP driver can't be used for Windows 7. And Windows 7 32bit driver can't be used for Windows 7 64bit.



So where do I see the advantages of ReactOS?
The advantage is, that ReactOS is a Windows-clone.

I think, it would be better, if there existing two branches of ReactOS: One XP-like, and one Win7-like.
Currently ReactOS seems to be WinXP like.

A company could create for that enhancements for Windows. So that the full OpenSource ReactOS is on the ReactOS-side, but the company creates enhancements for Windows from it.
In April the Windows XP support by Microsoft ends. This could be the chance, to replace some libraries through ReactOS ones.
And as I have heard, for Win7 with SP1 ends the support on 2020.

For that, the libraries should be compatible to the Microsofts.
I know, that on old WINE-times, it was possible to copy user32.dll in the WINE-directory to use the MS library in WINE.
This is something, which should be possible with ReactOS, too: Using the ReactOS-kernel with all libraries and programs by Microsoft. Or using the Windows-system, with some libraries by ReactOS.

The nice thing is, that the ReactOS-programs are working on Windows. But sadly the original one on Windows are more mature and more feature rich.

Additional it would be wonderful, if you find again the contact to the WINE-people. They still don't want code from ReactOS. But ReactOS have nice programs like charmap.exe and mspaint.exe.They are part of every Windows since Win95/WinNT4, so every Windows-developer can assume, that this programs are on the system and so he could start them from the own program.
But the sad point is, for the code it is only a one way: If anybody contribute code to WINE, then it will be later part of ReactOS, too. But if anybody contribute code to ReactOS, it will not be found its way to WINE.


So I would wish, a better cooperation between ReactOS and WINE, and a better compatiblity of ReactOS to Windows, so that ReactOS-files could be changed with Windows-files and vice versa.
And I think, that branches (WinXP-like and Win7-like) are needed. Stick on WinXP, would not be a good idea. There was a time of ReactOS, where it was discussed, if ReactOS would have a Win95/98-kernel or a WinNT one. And today everyone is happy, that ReactOS have decided for the WinNT kernel. Since Vista, Microsoft have a new kernel for Windows called MinWin. But ReactOS sees to be sticked on the XP one.

Greatings
theuserbl

[PurpleGurl]

ROS gives plenty of options too, and it is just as open source. It uses a lot of WINE code. And anyone can make it more like 7 or 8 if they want. Right now, we go with XP/2003 because we arbitrarily have to start somewhere. But once a good NT implementation is finished, adapting to the other flavors or creating a more thorough compatibility layer than Microsoft would be much more trivial in comparison. We have to have a good foundation first. Those impatient could try to fork it, but they would have to reinvent part of the wheel and duplicate effort. But if there were personal issues or folks feeling held back (and I don't see either here), then forking would be an option.

We are not just free of charge, but give design freedom. The $30 XP for the most part is either not legal, or it is vendor locked. So a XP CD for Dell won't work for Asus or generic unless you have a working serial and activation for it. Look on eBay, and they will not let you sell your XP CDs without including a "piece of hardware the computer won't run without." So they send you the back panel of a laptop, a dead hard drive, a fried motherboard, etc., and make you pay the extra S&H for it.

We are working toward compatibility with Windows libraries.
https://www.reactos.org/node/709

Oh, and we still send patches upstream to WINE. If you read otherwise, it is because of an old misunderstanding. Someone made a false claim against ROS. But once the project was cleared, WINE began to accept relevant patches. There are parts where WINE and ROS differ, since we try to build a NT implementation, where their goal is to provide compatibility through GNU+Linux. Not all WINE changes make it into ROS, either because they would be disruptive, be for another compatibility target, or would be irrelevant (the stuff closer to the kernel).

We have people actively working on the 16-bit support, believe it or not.

[mametoc]

Windows XP driver can't be used for Windows 7. And Windows 7 32bit driver can't be used for Windows 7 64bit.theuserbl

¿? Sorry but Windows XP x86 Realtek AC'97 audio driver works in Windows 7 x86.

No offense but Thorium according whit i readed in this forum, my personal perception it was created more to get funds rather some useful/wanted OS thing, maybe it might get success enough to cover ReactOS Team expectations (funding) or maybe not, but at least is a try as they probably don't found any else more likely/viable thing to do.

[Z98]

The NT kernel is still at the heart of modern Windows. MinWin was an experiment, the lessons of which were used to improve the NT kernel. It is NOT a replacement, and even if it were, MinWin itself is an NT kernel and therefore of the same pedigree as 2k3.

[hbelusca]

As far as I know, MinWin is just classical NT (by that, I mean, the usual ntoskrnl / hal / ntdll + win32k, csrss) with the win32 user mode dlls reorganized (the "api-ms-win-XXXXX.dll"), and the usual dlls (kernel32.dll, advapi32.dll, etc...) thunking on former ones (or the other way around).

[PascalDragon]

Windows 32bit can run 16bit Windows programs and 32bit Windows programs.
Windows 64bit can run 32bit Windows programs and 64bit Windows programs.
WINE tops it. The 64bit WINE version can run 16bit, 32bit and 64bit Windows programs.
ReactOS on the other hand, seems not to want 16bit Windows programs.

It does not seem that you read a blog article from last November or the commit logs or this forum as otherwise you'd know that there is active work on NTVDM which is responsible for running 16-bit DOS and Win3.1 applications on 32-bit Windows.

The mentioned advantage of ReactOS, is the driver-compatiblity. But Windows is incompatible to itself in this point:
Windows XP driver can't be used for Windows 7. And Windows 7 32bit driver can't be used for Windows 7 64bit.

You can't use a 32-bit Linux driver in 64-bit Linux either. Or a driver from kernel 3.12 in kernel 3.13 as the kernel will actively block the loading of such a driver. On Windows on the other hand you have the chance that certain drivers from XP can run on Win7 as well (big exception are graphic drivers for example).

Regards,
Sven

[theuserbl]

Thanks to your answers so far.

I have now ask on the WINE-forum, why they not using ReactOS code:
http://forum.winehq.org/viewtopic.php?f=8&t=20836

The result: ReactOS is the problem, why no cooperation is possible, because of its license.
Please could you change your license to LGPL?

Especially
charmap by Ged Murphy
magnify by Marc Piulachs
calc by Carlo Bramini
fontview by Timo Kreuzer
... etc

are GPL and so are sticked to ReactOS.

Greatings
theuserbl

[EmuandCo]

It's new to me that they are stickied to ROS because they are GPLv2... Did you read the GPLv2?

[mrugiero]

If that's the case, the problem is they are being too strict with the license requirement, not that ReactOS uses GPL in some pieces of their code.
I can understand they require LGPL in the pieces you are to link to, but charmap.exe and mspaint.exe? Who links to them? They are not even libraries.

[Z98]

I'm kind of surprised oiaohm gave you what amounts to a BS response, he's generally smarter than that. Wine and ReactOS have intrinsically different objectives. Wine wants to run Windows applications on Linux. ReactOS wants to run Windows applications on an NT operating system not developed by Microsoft. At a certain level of the software stack, code to achieve both goals can be the same. That is the code that we have imported from Wine and remains under their LGPL license. That is also the code we send patches back upstream whenever we find problems. Sometimes the patches are accepted, other times they're rejected. It's how open source software development works. Then move down the stack a little bit and you start running into places where code cannot be shared. For example, the graphics subsystem on NT is the win32 subsystem. On Linux, it's X. The link tying the upper level libraries with their respective graphics subsystems cannot be shared, period. We're not Linux, we don't have (nor want) X, and so we need code that will never work on Linux.

The current extent of cooperation with Wine is about the limit that cooperation is practical or useful. Increasing "cooperation" won't magically increase the rate at which ReactOS improves, since we've already picked over the things that are useful to us. Putting more effort into code Wine maintains would simply divert attention from code that Wine would never use but code that we absolutely must have. With that consideration, the current level of "cooperation" suits both sides. We report bugs as we find them in the common code for Wine to deal with, leaving us with more time to deal with issues that are specific to ReactOS.