WPF, WinForms and WinUI now OpenSource

[karlexceed]

In computing, a clone is a hardware or software system that is designed to function in the same way as another system.

https://en.wikipedia.org/wiki/Clone_(computing)

If you narrowly define "clone" as a bit-for-bit exact duplicate, then that's not a clone... That's a copy.

[EmuandCo]

To avoid defamatory saying "ReactOS is Windows clone". Otherwise, at the time they open source Windows, we will wordly become Windows clone and be useless. ReactOS is not Windows, it just happens to implement the Windows 5 API and ABI.
I also mentioned that in the discussion about "am I ReactOS?" API query.

Earth to erkinalp... ReactOS -----> IS <----- a Windows clone, it has to be to provide binary support.

[erkinalp]

FreeDOS also provides binary compatibility.
That does not preclude an API call for an application to determine whether it is running on ReactOS or Windows; nor does it preclude an environment variable check (BEHAVE_LIKE_WINDOWS in my proposal) to quickly set that system-wide for processes started from then on.

[justincase]

Wow, how many topics can we flame each other about in a single (unrelated) thread? (rhetoric, let's please just stop.)

Regarding whether or not ReactOS should use code open sourced by Microsoft:

If we were to fully boycott MS code until they open source the whole codebase as erkinalp suggests, we would (effectively) never be able to use any code from MS, as they're not likely to ever release the whole source of Windows as Open Source Software, and even if they eventually did, it would be way in the future. Too far in the future for it to realistically be of any use to us.

What ReactOS is is effectively an independently developed, fully open sourced, clone, similar to all the (hardware) IBM clones that different companies made back in the early days of personal computers, but (unlike the IBM clones) open source and not for profit. Using a few bits and pieces of code written by Microsoft doesn't make us any more, or less, a clone of Windows than the fact IBM clones mainly all used the same CPU and RAM chips as the original IBM PCs. The fact that some people don't like the word 'clone' (likely due to the legal issues that were brought up by the IBM clones) has prompted some people to recommend that we don't refer to ReactOS as a Windows clone, but as EmuandCo says, ReactOS is a clone, it's just an open source, not for profit clone that's being careful to avoid any legal issues.

Basically what it comes down to is that if anyone (including Microsoft) writes code that will help improve the ReactOS project, gives it an open source license that the ReactOS project can use, and did all of that in a legal way (i.e. not looking at leaked Windows Sources or rewriting code they theoretically may have seen while working at Microsoft), ReactOS developers are free to incorporate it into ReactOS, in the same way that we incorporate wine and fastfat.

Regarding whether of not the recently open sourced WPF, Windows Forms, and Windows UI XAML Library (WinUI) are helpful to the ReactOS project: If you think it might be, then take a closer look at it and post back here with your findings.

[PurpleGurl]

As for using open sourced Windows code, I think we should use it now. If some take issue or there are purists, then they can code their own replacements. That's much like GNU+Linux vs. GNU Hurd.

[erkinalp]

Regarding whether of not the recently open sourced WPF, Windows Forms, and Windows UI XAML Library (WinUI) are helpful to the ReactOS project: If you think it might be, then take a closer look at it and post back here with your findings.

Yes, because it would enable us rewrite the shell in Windows 10 style.

DoorsOS vs ReactOS would have been a good competitive plot.

That's much like GNU+Linux vs. GNU Hurd.

No, it is like FUZIX vs GNU/Linux. FUZIX incorporates open-sourced v7 UNIX source code, and even compiles to PDP-11, original UNIX machine. Literally UNIX revived. GNU/Linux, on the other hand, reimplements UNIX APIs. Trying to propose adding open-sourced UNIX code into Linux would cause you be banned from contribution. This is because everything to be compatible with UNIX has already been implemented in much superior ways. GNU/Hurd kernel is architected completely differently and you will not be able to extract anything useful from UNIX into Hurd.
ReactOS is somewhere between in FUZIX and Linux in terms of reuse of prior implementations (considering components open sourced under suitable licence).

Disclaimer: FUZIX contributor

[PurpleGurl]

Okay, maybe not the best comparison on my part, but maybe you get my point. GNU used Linus Torvald's kernel originally because it was ready at that point, like some Microsoft code is freely available. However, GNU was going to write their own kernel. So if those who don't like us using Microsoft open sourced code can write their own portions.

[justincase]

Regarding whether of not the recently open sourced WPF, Windows Forms, and Windows UI XAML Library (WinUI) are helpful to the ReactOS project: If you think it might be, then take a closer look at it and post back here with your findings.

Yes, because it would enable us rewrite the shell in Windows 10 style.

ReactOS currently targets Windows Server 2003 compatibility, not Windows 10, so that's not currently applicable to the project. If you want to fork ReactOS and integrate a new explorer that uses these components in an attempt to be Windows 10 compatible, you're welcome to do so as long as you make sure you're not violating the licenses of any components you use, but that's not ReactOS.

As for using open sourced Windows code, I think we should use it now. If some take issue or there are purists, then they can code their own replacements. That's much like GNU+Linux vs. GNU Hurd.

No, it is like FUZIX vs GNU/Linux.

Yes & no.

GNU vs Linux is an apt (if imperfect) comparison because both projects were effectively trying to be an open source version of Unix, and the GNU project had a bunch of open source user-land applications available when Linux became a thing, and people started using the the available GNU user-mode parts on top of the Linux kernel, and while some may have been replaced since then, most Linux distributions continue to use many GNU tools and applications to this day.

GNU/Linux vs GNU/Hurd is also a decent (if again, imperfect) analogy, as many people are happy with a GNU user-mode environment on a Linux kernel, despite the fact that the GNU tools and applications were originally developed for use on top of the Hurd kernel, but some people are still continuing to develop Hurd as a separate project from Linux, despite the fact that Linux has been stable for a long time, and Hurd ...um... isn't.

Assuming your description of FUZIX is accurate (I haven't taken the time to dig too deep on the subject of FUZIX yet), then FUZIX vs GNU/Linux also illustrates a part of this situation, as you claim FUZIX is using source code that was originally used in Unix, but is now open source. ... However, your statement that "Trying to propose adding open-sourced UNIX code into Linux would cause you be banned from contribution" is likely incorrect, as there's nothing fundamentally wrong with Linux using Unix code if the licenses are compatible, so if there is something that's actually useful to Linux available through this avenue, they're unlikely to care that it came from Unix as long as the license is compatible. Also, even if the situation is as you've described and you could get banned for suggesting using open sourced Unix code, and the reason is (as you've stated) "because everything to be compatible with UNIX has already been implemented in much superior ways", then that information would apply to the ReactOS situation in a very different way, as we're only suggesting using portions of Windows that have been open sourced for parts that aren't already implemented in a superior way on ReactOS. For instance, if Microsoft suddenly released the source to their NTVDM, it's unlikely ReactOS would have much use for it (except perhaps as a reference to compare to), as we already have an implementation of NTVDM which is superior (if perhaps not 100% complete).