2 Dec
2020
2 Dec
'20
7:09 a.m.
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 stage
-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
[1] https://github.com/libuv/libuv/pull/2800
[2] https://github.com/reactos/CMake/commits/cmake-3.17.2-reactos
[3]
https://github.com/ninja-build/ninja/pull/1674#pullrequestreview-425803525
[4] https://github.com/reactos/reactos/pull/3094#pullrequestreview-541258099
[5] https://stackoverflow.com/q/6688895
[6]
https://devblogs.microsoft.com/cppblog/c99-library-support-in-visual-studio…
[7]
https://github.com/reactos/reactos/commit/fdd1d7d60c33b08f4181df8e81c739694…
[8] https://msdn.microsoft.com/en-gb/library/hh567368.aspx