Joachim, I know about your obsession with Windows XP, which makes it hard to introduce any tool that was created in the last 5 years to improve ReactOS development. In fact, I've already spent multiple days on porting current CMake and Ninja back to Windows XP just to not lock you out [1] [2] [3].

A few of your statements can't be left unchallenged though.

Arguments that were raised by others against VS2010 and my reply:
-"ditching it brings in new developers to ros magically" <- I do ask then, 
where are they?

Hah, nice try! People aren't accepting a 2-year-old decision on dropping VS2010 support yet, even hijack unrelated PRs to mix requested style changes with a call for restoring VS2010 support [4] - and you're already asking for the new developers coming from that "welcoming" attitude towards modern technologies.. Let me be straight: This ain't gonna happen until we import a C++ standard library that actually supports modern C++!

Anyway, it's not like my claims are unfounded. Quoting Dominik2 from Mattermost, one of the potential new developers:

   "if 2020 is the year were ReactOS is ready to leave the 80ths of
   programming (win32 and C), let me know."

He already put his money where his mouth is and started importing Clang's up-to-date and maintained libc++ into ReactOS. Unfortunately, the efforts got halted for now by the equally sorry state of our CRT.

-"we should not be limited to strict C89" <- No one did request for that. All 
we want is to remain compatible to VS2010.

Requesting compatibility with VS2010 is exactly the same as requesting us to stay with C89.
Visual Studio has no C99 support until version 2013 [5] [6].

-"syncing BTRFS is a bit harder" <- So what? Then let others do the job.
-"libc++" <- I see no urgent need and nothing it would give in return that 
would outweight what we would sacrifice.

I get the feeling that you still believe we can code an entire operating system on our own and don't need any third-party components.. We already need VS2010-specific hacks for almost every library we import. As someone who has done that kind of work in the past, let me tell you that it adds at least a day of work for each sync. Work that is unthankful and could otherwise be spent on actual ReactOS development. Multiply that by the number of external dependencies and you get an idea of the wasted time.

Besides, you don't seem to be aware of the sad state of C++ runtime support in ReactOS: We're currently trying to get away with the unmaintained C++98 STLport on MSVC builds and the *ROSBE-PROVIDED* GNU libstdc++ on GCC builds. Each RosBE release requires a new hack in our tree to somehow glue RosBE libstdc++ (compiled against RosBE CRT) and target code (compiled against ReactOS CRT) together [7]. The result is still undebuggable, as it has symbol addresses belonging to the unique libstdc++ build of that RosBE installation.

Calling that situation "no[t] urgent" is grossly negligent.

My arguments again for keeping VS2010:
-VS2010 creates the smallest binaries of all compilers we do support

This is not a metric that is in any way relevant for an alpha-stage operating system that only exists as Debug builds.. Get someone to spend a day or two on optimizing our Release builds and figuring out what blows up the binaries on other compilers, and this argument will no longer hold.

-VS2010 CAN be installed in ros, when ros is installed as Server during 2nd 
-VS2010 can now even open the VS2010 cmd prompt

Yes, that's a really nice achievement, and exactly why nobody here wants to remove support for *running* VS2010 *under* ReactOS :)

This entire discussion is only about *compiling ReactOS* with VS2010. Which, if made a strict requirement for the upcoming years, jeopardizes the future of the project, as I illustrated above.

-no other VS>2010 can even complete its setup in ros, and that will remain like 
that for many years to come

Again, you're not looking into the future here and totally neglect the application support for NT6+ that is being worked on.

-VS2010 [...] covers > 95% of CPP2011-standard.

Not even close: [8]

Best regards,

Colin Finck

[6] [7]

Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Ros-dev mailing list

Reply via email to