Status Meeting (November 2020)

[Joachim Henze]

I totally and vehemently agree with Hermes here: We should NOT ditch VS2010.

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? I don't see any.
-"we should not be limited to strict C89" <- No one did request for that. All
we want is to remain compatible to VS2010. A subset.
-"syncing BTRFS is a bit harder" <- So what? Then let others do the job.
Actually BTRFS is not even a mandatory feature of ros. Having it in the tree is just
luxury.
-"libc++" <- I see no urgent need and nothing it would give in return that
would outweight what we would sacrifice.

My arguments again for keeping VS2010:
-VS2010 creates the smallest binaries of all compilers we do support
-VS2010 CAN be installed in ros, when ros is installed as Server during 2nd stage, (yes
this was not the case for a very short moment, unfortunately exactly when we discussed in
https://github.com/reactos/reactos/pull/2658 but now it works again, even in 0.4.14-RC51)
-VS2010 can now even open the VS2010 cmd prompt see
https://jira.reactos.org/secure/attachment/57140/57140_0.4.15-dev-203-g711f…
-no other VS>2010 can even complete its setup in ros, and that will remain like that
for many years to come
-VS2010 is the last version that runs on XPSP3 (which is important for some of our devs
including myself)
-VS2010 is the last version that runs on 2k3SP2 which is our current target
-VS2010 is reliable with industry-proven stability, and itself no moving target (unlike
VS2019 which breaks our builds every few weeks when MS upgrades it)
-VS2010 DOES provide std::unique_ptr. Stating anything else is just a lie. It covers >
95% of CPP2011-standard. It is absolutely possible and not complicated to write
leak-free-code with it.

[Colin Finck]

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