Closed JuhaSointusalo closed 4 years ago
JuhaSointusalo
commented
6 years ago And my answers:
Move to VS2017 and drop VS2010/2013?
Yes.
Use vcpkg?
Yes.
Drop XP support?
Yes. I think supporting XP is becoming too much work.
Pre-emptively fork vcpkg?
No. Let's see how it goes using upstream directly first.
Integrate vcpkg into BOINC source tree?
Can't decide. I wouldn't mind good ideas.
AenBleidd
commented
6 years ago Hello Juha,
Thank you very much for such great investigation. Here're my answers on your questions:
Move to VS2017 and drop VS2010/2013? Yes Use vcpkg? No Drop XP support? Yes Pre-emptively fork vcpkg? No Integrate vcpkg into BOINC source tree? No
I want to explain a little my answers. I've never work with vcpkg but I see a better alternative creating custom build steps (or even projects) to install or build 3rd party components. This approach can help to have an individual 3rd party component version for each package because it will be hardcoded in the project file or script. Also I see no reason to support XP because it is not supported by Microsoft anymore.
Thanks
Best regards, Vitalii Koshura
2018-02-13 23:29 GMT+02:00 Juha Sointusalo notifications@github.com:
tl;dr: Use VS2017 and vcpkg, drop VS2010, VS2013 and XP. Say yes.
VS2010 and VS2013 are getting old. They don't support newer (or even already dated) language features and their integration to rest of the world either doesn't really exist or is lacking. Below is a link collection that goes into detail of what's new in VS2017 over VS2010/2013. The stuff I'm looking forward to is Git and GitHub integration https://visualstudio.github.com/, C99 and C++11 support, and general IDE and toolchain improvements. The latest update also brought builtin support for Google Test https://blogs.msdn.microsoft.com/vcblog/2017/10/24/unit-testing-test-adapter-for-google-test-goes-in-box/. And I can't wait to try Linux development with VS2017 https://aka.ms/linux-development-with-c-in-visual-studio.
What's New for Visual C++ in Visual Studio 2017 https://docs.microsoft.com/en-us/cpp/what-s-new-for-visual-cpp-in-visual-studio What's New for Visual C++ in Visual Studio 2015 https://msdn.microsoft.com/en-us/library/hh409293(v=vs.140).aspx Visual C++ What's New 2003 through 2015 https://docs.microsoft.com/en-us/cpp/porting/visual-cpp-what-s-new-2003-through-2015 Visual C++ change history 2003 - 2015 https://docs.microsoft.com/en-us/cpp/porting/visual-cpp-change-history-2003-2015
As for language standards, C99 https://en.wikipedia.org/wiki/C99 has been available in GCC and Clang for ages. Would be nice to have Windows build system on par with others. C++11 https://en.wikipedia.org/wiki/C%2B%2B11 on the other hand makes the gap between C++ and more modern languages narrower and makes C++ more pleasurable to work with. (Although, before C++11 can be used in cross-platform code it is necessary to make sure that other platforms use sufficiently recent compiler versions.)
Right now BOINC has solutions for both VS2010 and VS2013 and it seems having two solutions generates just maintenance overhead and confusion. I want to stress that I'm not proposing to add third solution. I'm proposing to replace the current two solutions with one newer.
Build dependencies
Right now dependencies are hosted on BOINC's server on Git repositories. The repos are gigantic and downloading them from Berkeley takes forever. In addition BOINC's server has had reliability problems in the past and with the lack of funding will probably have in the future too. The size of the repos makes it costly to host them on faster and more reliable location.
Updating the dependencies is done infrequently at best and right now the packages are so old that they have several known security holes. Instructions to update the dependencies are vague and incomplete.
I believe vcpkg https://docs.microsoft.com/en-us/cpp/vcpkg would be a better way to manage dependencies. vcpkg is a source based package manager for C++ development on Windows. Instead of downloading prebuilt binaries dependencies are compiled on each developer's machine and instead of fragile manual process vcpkg is automated making sure every developer gets the builds done the same way. Building the packages together from source ensures they are built with compatible settings.
vcpkg also relaxes the burden of keeping dependencies up to date by crowdsourcing the maintenance of build scripts. vcpkg has a central repository of package scripts so it won't be necessary to hunt around the net for scripts.
vcpkg is not the only package manager there is. Some of the others are below and my reasons for not using them:
- Manual process like it is now. Error prone and burden to maintainer.
- DIY scripts. Building software on Windows is not as easy as ./configure && make. Windows comes with very little build tools and utilities and there is no apt-get to install them. Would be a maintenance burden.
- Buckaroo https://buckaroo.pm/. Looks like it expects project to use Buck build system.
- build2 https://build2.org/ + bpkg. Build system in development. Very few packages.
- cget http://cget.readthedocs.io/en/latest/. Can't figure out how it's supposed to be used. Fairly limited number of packages available.
- Chocolatey https://chocolatey.org/. Looks like it's more about application packages and less about software development.
- Clib https://github.com/clibs/clib. Package manager for C. For us, has only zlib packaged.
- CMake https://cmake.org/. CMake has some builtin support for managing dependencies but this would require switching to CMake.
- Conan https://conan.io/. Curated repositories have only a few of the packages we need.
- CPM http://www.cpm.rocks/. Unmaintained, CMake based.
- C++ Archive Network https://cppan.org/. I'm not sure but looks like it expects project to use CMake.
- Hunter https://docs.hunter.sh/en/latest/. CMake based.
- Meson http://mesonbuild.com/ + Wrap http://mesonbuild.com/Wrap-dependency-system-manual.html. Using Wrap would mean switching to Meson which is a different build system.
- Npackd https://npackd.appspot.com/. More about application packages and less about software development.
- NuGet https://www.nuget.org/. Has some C++ packages but it is really targeted for .Net development.
- Pacm https://sourcey.com/pacm/. Can't figure out if it's got a central repository of packages.
- Ryppl https://github.com/ryppl/ryppl. Dead.
- Teapot https://teapot.nz/welcome/index. Yet another build system. Has no central package repository.
The problem with CMake and package managers based on CMake or other build systems is that switching to a different build system is much bigger undertaking than upgrading a current build system is.
vcpkg is by no means perfect:
- While vcpkg is usable it is still under heavy development.
- vcpkg doesn't believe in versioned dependencies between packages. Instead every package used is always the latest. That might result in occasional breakage when APIs change but dependent packages aren't updated yet.
- Since every package in vcpkg is always the latest it is possible that some package is updated to a new version and new API before BOINC is compatible with the new API.
It might be that vcpkg chooses to use a different setting that what we want for some package. That and the possible build breakage means we might at some point have to fork vcpkg in order to get what we want.
XP compatibility
VS0271 itself doesn't run on XP. VS2010 was the last one to run on XP.
VS2017 doesn't create XP compatible binaries by default but project files can be configured to use XP toolchain. At the moment vcpkg doesn't support XP toolchain but there is an open pull request to add the necessary plumbing. However, vcpkg team is not interested in officially supporting XP so to actually use XP toolchain it looks like it would be necessary to add a configuration file to vcpkg even after the pull request is merged. This could be accomplished by either having it as a step in installation instructions or by forking vcpkg and adding the file there.
I did manage to build XP compatible Manager with VS2017+vcpkg by building dependencies normally and building Manager with XP toolchain. Against my expectations this worked. I'm not sure why and I'd rather not rely on it unless someone can explain why it worked and why it would work for other binaries too.
cURL supports different SSL/TLS providers. Right now vcpkg builds it with OpenSSL. There are requests to use Windows' own SSPI/SChannel/WinSSL instead. The problem with XP's SChannel is that it is very old and none of the algorithms it supports are secure today. I built cURL with SChannel and tested it on XP. Of the few BOINC sites I tested it couldn't connect to WCG and BAM. Releasing a BOINC version that can't connect to all projects doesn't make much sense to me. This means that if vcpkg ever changes default to SChannel and we wanted XP compatibility we would need to override that change. This could probably be done with the previously mentioned configuration file but if not the alternative is to fork vcpkg.
The packages in vcpkg use various build systems. Some build system can be configured to use XP toolchain, others not. If BOINC ever depends on a package whose build system doesn't support XP and we still wanted to support XP it would be necessary to either convince the build system maintainers to add XP toolchain support (and probably have us code it) or rewrite the package to use other build system. Both options would require non trivial amount of work.
While it could be possible to initially not support XP and then later enable the support I think it would be better to have it one way or the other right from the beginning so that the project needs to be configured only once and build environment setup instructions will have to be written only once.
I would like to point out the obvious that discontinuing XP support doesn't mean that current client or app versions would magically stop working. People can still continue to use older client versions and projects that want to support XP can use an older version of BOINC source tree to build their apps.
Integrating vcpkg with BOINC
Right now there is little connection between a BOINC version and the dependencies that were used to build it. VS2010 and older dependency repos have branches for client minor release series but that doesn't completely connect the dependencies and client versions. What I would like is that every time a new BOINC version is released the dependency versions that were used were recorded precisely. The client prints out a few version numbers but version numbers don't include build options.
The recommended way to use vcpkg is for user to install it anywhere and run a command that integrates vcpkg with MSBuild. vcpkg then takes care of adding include directories, libraries and all that in builds. This way project files don't need to refer to vcpkg location but it also leaves no trace of used vcpkg package versions in BOINC source tree.
One way to record the exact version dependencies would be to include vcpkg as Git submodule in BOINC source tree and have the submodule always point to a specific commit id in vcpkg repository. vcpkg repository is read only to us so this shouldn't have as much issues as Git submodules in general have. The problem with this approach is that while jumping around between master and pull requests and release branches the binaries inside vcpkg submodule might not actually correspond to the vcpkg version. One way to work around that could be using multiple working directories for master and other branches.
The questions
Before continuing with this some questions need to be answered. I'd appreciate that any 'no' answer is accompanied with an explanation for the 'no'.
Move to VS2017 and drop VS2010/2013? Use vcpkg? Drop XP support? Pre-emptively fork vcpkg? Integrate vcpkg into BOINC source tree?
Related issues: #1832 https://github.com/BOINC/boinc/issues/1832, #2346 https://github.com/BOINC/boinc/issues/2346
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/BOINC/boinc/issues/2348, or mute the thread https://github.com/notifications/unsubscribe-auth/ADFZodqRsT_HBaepJbYhNWV_MA8xMAasks5tUf6_gaJpZM4SEbaE .
JuhaSointusalo
commented
6 years ago @AenBleidd
Thanks for the answers.
Regarding build scripts, I am worried that you badly underestimate how much work they would require. (Or maybe I'm a pessimist.) Pretty much the only thing you have is Powershell and then you'd need to write all the little utilities yourself.
And you'd need download and install all the bigger utilities and build systems. Looking at vcpkg's download cache it has downloaded jom, cmake, nasm and perl. At some point it might be necessary to add, e.g., MSYS2+Autotools, SCons and Python and who knows what else to the list. And you'd need to make sure everything is still compatible with each other. And you'd need to make sure your build scripts are compatible with everyone's setups.
In my opinion DIY scripts are wrong thing to do when there are off the shelf package managers available. But let's see what others have to say.
SETIguy
commented
6 years ago I'd agree to dropping XP in in the BOINC client, but I don't think we should necessarily drop it in the BOINC application libraries. The libraries used in applications should be as generic as possible and it would be nice for them to remain buildable on XP and usable on XP even if we don't supply and support the means to build them. Wise or not, we're still seeing about 5% of windows installations running XP or XP64. Nothing spreads unhappiness among volunteers like saying "Not you." I'm old enough to remember the complaints when we dropped Win98, WinNT and Win2000 support. I still hear it from PPC Mac users. Unlike Apple (and AMD), at least Microsoft hasn't tended to sabotage users of old hardware during upgrades.
On Tue, Feb 13, 2018 at 1:44 PM, Juha Sointusalo notifications@github.com wrote:
And my answers:
Move to VS2017 and drop VS2010/2013?
Yes.
Use vcpkg?
Yes.
Drop XP support?
Yes. I think supporting XP is becoming too much work.
Pre-emptively fork vcpkg?
No. Let's see how it goes using upstream directly first.
Integrate vcpkg into BOINC source tree?
Can't decide. I wouldn't mind good ideas.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/BOINC/boinc/issues/2348#issuecomment-365414798, or mute the thread https://github.com/notifications/unsubscribe-auth/AKXcsuZacMSD42HKVhbR0wlQH_ymwPgjks5tUgJWgaJpZM4SEbaE .
-- Eric Korpela korpela@ssl.berkeley.edu AST:7731^29u18e3
CharlieFenton
commented
6 years ago I currently have VS2010 installed on my Windows 7 box and mainly use it to confirm that changes I make for the Mac don't cause problems on MS Windows, though I have occasionally done development specific to MSW.
If you require using VS2017, please make sure that the free "Community" version is the standard version for building BOINC. The change should not require BOINC developers to purchase the build tools. I realize that InstallShield is not free, but it is only required for building the installer; few BOINC developers need to do that.
davidpanderson
commented
6 years ago Dropping XP support is a minus, and I'm not sure any of the pluses are significant. I'd like to see examples of where new C++ features would make the code faster or simpler.
On Tue, Feb 13, 2018 at 4:38 PM, CharlieFenton notifications@github.com wrote:
I currently have VS2010 installed on my Windows 7 box and mainly use it to confirm that changes I make for the Mac don't cause problems on MS Windows, though I have occasionally done development specific to MSW.
If you require using VS2017, please make sure that the free "Community" version is the standard version for building BOINC. The change should not require BOINC developers to purchase the build tools. I realize that InstallShield is not free, but it is only required for building the installer; few BOINC developers need to do that.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/BOINC/boinc/issues/2348#issuecomment-365455284, or mute the thread https://github.com/notifications/unsubscribe-auth/AA8Kgd0HI_rrtS8qrLre3Tzt2h-ZEa99ks5tUisRgaJpZM4SEbaE .
ras0219-msft
commented
6 years ago Maintainer of Vcpkg here, I'd be happy to answer any questions!
For a large project like BOINC, we consider "freezing" on a particular version (possibly with git submodules) to be the right way to get strong version control. It could be as simple as just writing the "current" commit-id into your README or as intense as checking in a complete copy of vcpkg to the source tree (I wouldn't recommend that, but we are designed to fully function if you chose to do so). At every commit id, we have full hash checking for every dependency to ensure reproducible builds.
If you want to continue(?) distributing prebuilt binaries, we also have the capability to generate those automatically into a variety of containers (7zip, zip, NuGet, and an IFW installer framework) that are completely freestanding from Vcpkg so downstream developers wouldn't even need to install us and would be guaranteed to get the same binaries you've tested against. If you used NuGet packages, they could be hosted on NuGet.org.
CharlieFenton
commented
6 years ago Will the newer language features and APIs provided by VS2017 be fully compatible with the oldest version of MSW OS we wish to support? If not, then we need to be careful not to use them. What method does VS2017 offer to prevent accidentally using APIs or other features that are not fully backward compatible? Do we need to continue building official releases using VS2010 to ensure full backward compatibility with all PCs running BOINC?
(On the Mac, Xcode allows me to specify an older version of OS X as the deployment target, so that I can be warned if I try to use APIs not supported by that version of the OS.)
I keep separate copies of my local repositories, each checked out to a different GIT branch, for reasons that are outside the scope of this discussion. Xcode offers GitHub integration, and I am careful not to use it, because that integration makes it difficult to switch among different branches containing different versions of BOINC. So I consider source control integration to be a drawback.
I agree with @SETIguy that at least the BOINC libraries should remain compatible with XP. It is fairly common for people who buy a newer computer to continue running BOINC on their older machines, dedicating those older computers to BOINC. And if a new client fixes significant bugs, then there is value in building the new client so that it can run on these older systems.
For these reasons, I have expended significant effort to ensure that new builds of BOINC continue to run on Mac OS back to OS 10.6, though the current version is OS 10.13.3. OS 10.6.0 was released in June 2008 and the last update OS 10.6.8 in August 2009. OS 10.7 was released in October, 2010. This effort includes code to determine the OS X version at run time and select different APIs depending on that result, having the BOINC installer select different versions of the screensaver depending on the OS version, and more.
The fact that Microsoft ended extended support for XP in April 2014 is not by itself justification for ending BOINC's support. Also, please look at the general BOINC download page http://boinc.berkeley.edu/download_all.php and note how many different categories of support for different platforms we already have. Every time we add or delete support for an OS version, we must add yet another category. This is another reason I have made the effort to continue supporting Mac OS X back to OS 10.6.
Another consideration is that to be truly open source, people should be able to build the client, manager and screensaver themselves. To that end, I have made sure that BOINC for the Mac can be built with both older and current versions of the Xcode development tools. Likewise, it should be possible for people to build BOINC for personal use with both older and current versions of Visual Studio. Older PCs may not have the hardware needed to run VS2017.
Ageless93
commented
6 years ago I installed VS2017 Community last night, and it has a lot of individual components you can add, that aren't default checked. A comprehensive list of these can be found here: https://docs.microsoft.com/en-us/visualstudio/install/workload-component-id-vs-community
TheAspens
commented
6 years ago The PMC met yesterday and this was one of the items discussed during the call. There is no objection to moving to MS 2017 provided that Windows XP support can be maintained for building the application libraries. @romw believed that there was a way to do that with MS 2017. @romw also said that he was interested in helping with this project and also with getting automated builds of the dependencies working with Vcpkg.
In my personal opinion, (these statements were not discussed at the PMC meeting so the following statement are only my statements as a contributor to BOINC) I am in agreement with @CharlieFenton that BOINC developers should be able to download the build tools for free. This means that things need to be based on the community (free) version of MS 2017. Development should be able to done on any supported version of Windows (https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet). This means that we need to be able to support development on Windows 7 through January 14th, 2020.
I am a HUGE fan of using tools to handle dependency management. It makes it so much easier to get updated versions of dependencies. It would be great of this could all be in place for the 7.12 client release.
TheAspens
commented
6 years ago Let me explain the rationale behind continuing to support Windows XP for building the application libraries.
The usage of Windows XP will only drop over time so eventually we can sunset the operating system. However, at this time we do need to maintain support for at least building the application libraries so that they are compatible with Windows XP.
CharlieFenton
commented
6 years ago Ideally, anyone should be able to check out a tagged repository from GIT and use its contents to build an exact duplicate of the binaries that were originally built and released with that version number. In order to do that, one must also use the same dependencies that were used for the original build. This includes not just the version number of each dependency but also all parameters used in building that dependency.
For the Mac, this is ensured because the build scripts for all dependencies are included in the GIT repository, and the Xcode project (also saved in the GIT repository) specifies the version number for each dependency it links with. There is also a text file _mac_build/HowToBuildBOINCXCode.rtf which lists the required version numbers for its associated version of BOINC. And for more recent versions of BOINC, there is a file _macbuild/dependencyNames.sh used by the Travis CI scripts but also human-readable giving the same information.
With the current system of saving the built dependencies in a separate repository, I don't know if the BOINC client and manager Visual Studio project files enforce the use of the correct dependent library versions. In any case, if a new pre-built dependency library is created, it must not overwrite any earlier ones, to ensure that older BOINC builds can be replicated. And there needs to be some indication in the GIT repository of which version of the pre-built dependencies to use.
If we switch to a method where each person building BOINC also builds her own copy of the dependent libraries (as we do for Macintosh, and which I favor), then the scripts or other files for building the dependencies should be included in the same GIT repository as the other BOINC files in a way that ensures consistent results no matter when a build is done from a particular GIT tag.
JuhaSointusalo
commented
6 years ago @AenBleidd
I wrote:
I am worried that you badly underestimate how much work they would require. (Or maybe I'm a pessimist.)
That should have been something like "Maybe you are optimist and underestimate work required or maybe I'm pessimist and overestimate work required." I hope you didn't interpret that as I would be pessimistic about your skills or anything like that.
@SETIguy
Nothing spreads unhappiness among volunteers like saying "Not you." I'm old enough to remember the complaints when we dropped Win98, WinNT and Win2000 support.
I wasn't active in the forums back then so missed all the riots but that's a good point.
@CharlieFenton
please make sure that the free "Community" version is the standard version for building BOINC
Community Edition works fine, that's what I have been using all along. It is free for 30 days after which you need to register it. I consider registering to be a fairly reasonable price for a complete development environment.
What method does VS2017 offer to prevent accidentally using APIs or other features that are not fully backward compatible?
Technically, it's not Visual Studio but Windows SDK that handles it. SDK headers check for WINVER, _WIN32_WINT and _WIN32_IE and a few more macros. SDK makes declarations visible only when those macros specify a version that's equal or newer than the first version of Windows that supports the declared function or structure. BOINC defines those macros in boinc_win.h, stdwx.h, stdafx.h and Makefile.mingw.
The catch with the above is that SDK v7.0 is the last one Microsoft promises to be XP compatible. Later ones may declare something that is not XP compatible regardless of version macros.
Xcode offers GitHub integration, and I am careful not to use it, because that integration makes it difficult to switch among different branches containing different versions of BOINC.
I just tested something similar. I created another working directory with git worktree add ..\src.release.7.10, checked out master and 7.10 release branches, opened two VS2017 windows and opened solutions from both working directories. Visual Studio's own Git integration (Team Explorer) seems to work right. It shows right branch on both windows and I can change the branch just fine.
GitHub integration on the other hand works correctly only on the full repo. Worktrees aren't supported (they have a bug on it). I imagine it would work better if I had actually copied the repo.
I know nothing of Xcode so I can't offer any ideas of how to make it work better for you, sorry. In any case, you are not required to use Visual Studio's Git or GitHub integration. You can continue to use whatever you use now.
What I would like to use GitHub integration for is to checkout pull requests and examine and comment them while being able to refer to the rest of the code base at the same time. Right now I have to drop to command line for checkout and examining code on the web page is not much fun either. I haven't actually tested the functionality yet because in order to checkout a pull request GitHub requires a clean working directory but that's not possible because I have VS2017 project files there uncommitted. I realise now that I could have created a temporary fork of BOINC to play with. Oh well.
people who buy a newer computer to continue running BOINC on their older machines, dedicating those older computers to BOINC
Good point.
Ideally, anyone should be able to check out a tagged repository from GIT and use its contents to build an exact duplicate of the binaries that were originally built and released with that version number. In order to do that, one must also use the same dependencies that were used for the original build. This includes not just the version number of each dependency but also all parameters used in building that dependency.
Yes. That is exactly my motivation for doing something other than what we do now.
As an example of why recording build options matter: Anyone know if BOINC supports IPv6 on Windows? Well, I can tell it doesn't. cURL doesn't record build options in its header files so I had to write a program that queries libcurl for supported features and link that against BOINC deps. It would have been nice to know if BOINC has never supported IPv6 or was the support accidentally omitted at some point. But finding that out would have required checking out every version of libcurl.dll and testing them. Compared to examining build options history that would have been awful lot of work.
JuhaSointusalo
commented
6 years ago @TheAspens
The PMC met yesterday and this was one of the items discussed during the call.
Guess I got the timing right then :)
There is no objection to moving to MS 2017 provided that Windows XP support can be maintained for building the application libraries.
I think it'll be simpler if either all of BOINC supports running on XP or none at all. Since you want some then all it is.
Eric and Charlie would like that BOINC continues to not only run on XP but to be also buildable on XP. I'm not sure of PMC's opinion.
I was going to suggest that XP users can use MSYS2+Mingw-w64 (the latter can compile 32-bit apps despite its name) but then MSYS2 homepage says "Current MSYS2 can't be installed on Windows XP anymore." D'oh. MSYS2 is based on Cygwin and the last Cygwin version that runs on XP was released on June 2016.
On the other hand, Mingw-w64's provides prebuilt binaries that runs on XP. So XP users could install that and older MSYS2, MSYS or older Cygwin to run configure. MSYS2 includes package manager but since that doesn't work XP users would be on their own when it comes to building and updating dependencies.
Is that ok?
I'd rather not keep VS2010 solution for XP users because that would block taking advantage of language and library improvements (I'll make a separate post about these) and would require keeping it up to date.
CharlieFenton
commented
6 years ago Right now I have to drop to command line for checkout and examining code on the web page is not much fun either.
I strongly recommend you try either TortoiseGit (MSW only, I believe) or SourceTree (Java cross-platform) for interfacing with GitHub. Both are free. I never need to use the command line on either Mac or Windows. You can find information on setting up TortoiseGit here and here. There is also useful information, especially for other platforms, here. Of course, you might find you like Visual Studio's GITHub integration better or more convenient.
TheAspens
commented
6 years ago Eric and Charlie would like that BOINC continues to not only run on XP but to be also buildable on XP. I'm not sure of PMC's opinion.
I think that this is a committer decision rather than a PMC decision. So whatever the committers (which includes you, Eric and Charlie) agree to is good. I'll cast my vote with whatever the participants of this thread agree to.
AenBleidd
commented
6 years ago Hello guys,
I'm just curious, what is actual issues with builds that built by VS 2013 or higher on Windows XP? Maybe, this article ( https://msdn.microsoft.com/en-us/library/jj851139.aspx ) contains an answer and using it we can drop VS 2010 support and move to VS 2017? I see only 1 issue now from my POV is a boinccas.dll but I see no development for this component so it can be used as precompiled.
Thanks Best regards, Vitalii
RichardHaselgrove
commented
6 years ago I have a working Windows XP machine and a working VS2013 BOINC build environment, so I can test - first my existing builds, then that Platform Toolset fix if needed. It would make distribution difficult if we have to use separate build settings. So far, I've upgraded to the stock v7.8.3 version and I'm running SETI, just to make sure we have a working baseline.
JuhaSointusalo
commented
6 years ago @AenBleidd To move to VS2017, no big issues. Update project files to VS2017, switch to XP toolchain, fork and patch vcpkg, fix minor issues, automate stuff, test. Good thing you noticed the boinccas. I was going to use VS0213 files as base but looks like VS2010 will be better choice.
I've been working on the client side issues for 7.10 and I've got two or three more (so that @RichardHaselgrove has to decide if still one more test version is needed :) ). VS2017 could be next week-ish I think.
RichardHaselgrove
commented
6 years ago @JuhaSointusalo - I'm at the stage of being almost ready to call for v7.9.4 builds - the cherrypicks are merged, version numbers updated. I'm just waiting for final confirmation of the url CPDN want to use - they were planning a change this morning, but I haven't heard the final decision yet (database problems intervened). If the issues are small and simple enough to be classed as bugfixes, I could try to hang on - do they have issue numbers I could look at?
RichardHaselgrove
commented
6 years ago Well, I opened it up, and found the 'Platform Toolset' was ready by default:
So, preparing to copy the VS files across. The boinccas.dll was an installer file, wasn't it? I won't be able to test that.
RichardHaselgrove
commented
6 years ago The VS2013 Manager opened fine, but couldn't start the client.
Starting the VS2013 client manually produced this error:
I'll leave it there for tonight.
AenBleidd
commented
6 years ago @RichardHaselgrove, thank you very much! I'll try to dig to find the solution.
RichardHaselgrove
commented
6 years ago For completeness: I copied a complete set of build files (exe, pdb, dll) for boinc, boinccmd, boincmgr from the Windows 7/64 build machine to the XP/32 test machine (yes, it was a 32-bit build). Sources were at v7.9.3: I compiled all three modules on 21 March, and then updated the client only on 28 March (I forget exactly why, but it's probably mentioned in one of the threads here - if I could find my posting history).
JuhaSointusalo
commented
6 years ago If the issues are small and simple enough to be classed as bugfixes, I could try to hang on - do they have issue numbers I could look at?
RichardHaselgrove
commented
6 years ago I was going to draw attention specifically to #2412 in the v7.9.4 release notes - concerns were raised, other people thought the real-world risks were negligible. I've mentioned it in my weekly report-backs, but I think the consensus there was on the 'negligible' side. So we're probably on course for a release with the concerns unaddressed. I'm just going to leave it there - certainly for tonight, possibly for the weekend.
AenBleidd
commented
6 years ago As far as I can see the issue is with the 3rd-party precompiled binaries that are not XP-compatible and contain InitializeCriticalSectionEx() function that is not available for Windows XP and appeared first in Windows Vista.
I searched for InitializeCriticalSectionEx in dependencies and got next list:
I am pretty sure, if we want to support Windows XP but build BOINC on something more modern that VS2010 we need either to rebuild all 3rd-party dependencies with v120_xp toolkit set or use existing prebuilt binaries compatible with WIndows XP.
adamradocz
commented
6 years ago I'm trying to upgrade the project files to Visual Studio 2017 and the libboinc project is building successfully when the Platform Toolset is set to Visual Studio 2017 - Windows XP (v141_xp).
Although when I try to build the boinc project with the Visual Studio 2017 - Windows XP (v141_xp) toolset I get a bunch of LNK2001 errors like
libboinc.lib(base64.obj) : error LNK2001: unresolved external symbol __imp__invalid_parameter
I searched for solutions but nothing helped. Does anyone have any idea what could be wrong?
JuhaSointusalo
commented
6 years ago @adamradocz
The solution needs quite a few changes here and there. Just opening it and letting VS2017 do the upgrade is not enough. I don't remember what changes were needed. It's been a while since I last looked at it. I really need to dust off the stuff I already have and finish it.
adamradocz
commented
5 years ago Another issue that would benefit if we dropped Windows XP support. #2831, #2779
The netmarketshare.com shows that Windows XP has 4.23%, and Windows Vista has 0.31% market share.
I have a theory, that if somebody uses an end-of-life OS, he or she doesn't update the boinc too frequently either. Can somebody confirm or disprove my theory?
adamradocz
commented
5 years ago @JuhaSointusalo can you give some guidance :)
JuhaSointusalo
commented
5 years ago Sneak preview at JuhaSointusalo/boinc-vs2017.
The preview includes new solution and project files, vcpkg as submodule, script to install and update dependencies and a VS project that calls the script. Dependencies are built and made to use automatically.
The idea is that dependencies are updated when anything is built. This could be done as a pre-build step. However, MSBuild builds projects in parallel but vcpkg can't handle that. So the job of the new project is to turn the parallel build partially in to a sequential one. The pre-existing projects that have dependencies (Client, Manager, ...) depend on the new project. vcpkg is updated only from the new project.
This is a preview so there's a few issues. Only 32-bit, FTGL isn't packaged yet so no screensaver or graphics, Manager has some issues with fonts, maybe something in high DPI support. All the dependencies are built as DLLs so Manager especially has "unnecessary" changes to make that work. And it looks like I forgot to save one change and vcpkg is actually updated only once. With that change the new project is always outdated including when starting a debugging session.
I still need to decide what to do with science apps. While for BOINC programs dynamically linked CRT makes most sense science app should probably have statically linked CRT which means all libraries need to be statically linked and that means dependencies need to be compiled differently than for BOINC. I imagine project developer won't appreciate if they need to wait for the build system to build stuff they don't need, like wxWidgets or OpenSSL. So I think I'll add another new project to handle dependencies for science apps, at least temporarily. A better solution requires reading MSBuild manual.
Anyways, forget about the issues and stuff that isn't ready yet. Any comments about this approach on how to handle build dependencies?
JuhaSointusalo
commented
5 years ago Oh right.
You need git, Visual Studio 2017 with Desktop development with C++ workload and Windows XP support for C++ optional component and that's it. Clone the repo, open the solution, start building aaaaand... go take your dog for a walk, this is going to take a while :)
AenBleidd
commented
5 years ago 
Just found this while searching for necessary (not for BOINC) components for my VS2019 installation I'm afraid, someday we have to stop updating and supporting Windows XP
AenBleidd
commented
5 years ago The link to the Microsoft's statement about it: https://go.microsoft.com/fwlink/?linkid=2023588
AenBleidd
commented
5 years ago The problem with vcpkg is next:
As soon as we need to support Windows XP, an appropriate toolset should be installed for Visual Studio. Currently it is deprecated but still can be used. But when building 3rd-party dependencies with vcpkg, this toolset will not be used because specific Target Platfrom should be specified in project files. But these project files are generated with cmake by the script that is placed within vcpkg repository. So in order to build 3rd-party dependencies with vcpkg, corresonded cmake scripts should be patched first that adds an additional complexity to this task.
So, it's not impossible but should be taken into account when working on this task
tl;dr: Use VS2017 and vcpkg, drop VS2010, VS2013 and XP. Say yes.
VS2010 and VS2013 are getting old. They don't support newer (or even already dated) language features and their integration to rest of the world either doesn't really exist or is lacking. Below is a link collection that goes into detail of what's new in VS2017 over VS2010/2013. The stuff I'm looking forward to is Git and GitHub integration, C99 and C++11 support, and general IDE and toolchain improvements. The latest update also brought builtin support for Google Test. And I can't wait to try Linux development with VS2017.
What's New for Visual C++ in Visual Studio 2017 What's New for Visual C++ in Visual Studio 2015 Visual C++ What's New 2003 through 2015 Visual C++ change history 2003 - 2015
As for language standards, C99 has been available in GCC and Clang for ages. Would be nice to have Windows build system on par with others. C++11 on the other hand makes the gap between C++ and more modern languages narrower and makes C++ more pleasurable to work with. (Although, before C++11 can be used in cross-platform code it is necessary to make sure that other platforms use sufficiently recent compiler versions.)
Right now BOINC has solutions for both VS2010 and VS2013 and it seems having two solutions generates just maintenance overhead and confusion. I want to stress that I'm not proposing to add third solution. I'm proposing to replace the current two solutions with one newer.
Build dependencies
Right now dependencies are hosted on BOINC's server on Git repositories. The repos are gigantic and downloading them from Berkeley takes forever. In addition BOINC's server has had reliability problems in the past and with the lack of funding will probably have in the future too. The size of the repos makes it costly to host them on faster and more reliable location.
Updating the dependencies is done infrequently at best and right now the packages are so old that they have several known security holes. Instructions to update the dependencies are vague and incomplete.
I believe vcpkg would be a better way to manage dependencies. vcpkg is a source based package manager for C++ development on Windows. Instead of downloading prebuilt binaries dependencies are compiled on each developer's machine and instead of fragile manual process vcpkg is automated making sure every developer gets the builds done the same way. Building the packages together from source ensures they are built with compatible settings.
vcpkg also relaxes the burden of keeping dependencies up to date by crowdsourcing the maintenance of build scripts. vcpkg has a central repository of package scripts so it won't be necessary to hunt around the net for scripts.
vcpkg is not the only package manager there is. Some of the others are below and my reasons for not using them:
./configure && make. Windows comes with very little build tools and utilities and there is noapt-getto install them. Would be a maintenance burden.The problem with CMake and package managers based on CMake or other build systems is that switching to a different build system is much bigger undertaking than upgrading a current build system is.
vcpkg is by no means perfect:
It might be that vcpkg chooses to use a different setting than what we want for some package. That and the possible build breakage means we might at some point have to fork vcpkg in order to get what we want.
XP compatibility
VS2017 itself doesn't run on XP. VS2010 was the last one to run on XP.
VS2017 doesn't create XP compatible binaries by default but project files can be configured to use XP toolchain. At the moment vcpkg doesn't support XP toolchain but there is an open pull request to add the necessary plumbing. However, vcpkg team is not interested in officially supporting XP so to actually use XP toolchain it looks like it would be necessary to add a configuration file to vcpkg even after the pull request is merged. This could be accomplished by either having it as a step in installation instructions or by forking vcpkg and adding the file there.
I did manage to build XP compatible Manager with VS2017+vcpkg by building dependencies normally and building Manager with XP toolchain. Against my expectations this worked. I'm not sure why and I'd rather not rely on it unless someone can explain why it worked and why it would work for other binaries too.
cURL supports different SSL/TLS providers. Right now vcpkg builds it with OpenSSL. There are requests to use Windows' own SSPI/SChannel/WinSSL instead. The problem with XP's SChannel is that it is very old and none of the algorithms it supports are secure today. I built cURL with SChannel and tested it on XP. Of the few BOINC sites I tested it couldn't connect to WCG and BAM. Releasing a BOINC version that can't connect to all projects doesn't make much sense to me. This means that if vcpkg ever changes default to SChannel and we wanted XP compatibility we would need to override that change. This could probably be done with the previously mentioned configuration file but if not the alternative is to fork vcpkg.
The packages in vcpkg use various build systems. Some build system can be configured to use XP toolchain, others not. If BOINC ever depends on a package whose build system doesn't support XP and we still wanted to support XP it would be necessary to either convince the build system maintainers to add XP toolchain support (and probably have us code it) or rewrite the package to use other build system. Both options would require non trivial amount of work.
While it could be possible to initially not support XP and then later enable the support I think it would be better to have it one way or the other right from the beginning so that the project needs to be configured only once and build environment setup instructions will have to be written only once.
I would like to point out the obvious that discontinuing XP support doesn't mean that current client or app versions would magically stop working. People can still continue to use older client versions and projects that want to support XP can use an older version of BOINC source tree to build their apps.
Integrating vcpkg with BOINC
Right now there is little connection between a BOINC version and the dependencies that were used to build it. VS2010 and older dependency repos have branches for client minor release series but that doesn't completely connect the dependencies and client versions. What I would like is that every time a new BOINC version is released the dependency versions that were used were recorded precisely. The client prints out a few version numbers but version numbers don't include build options.
The recommended way to use vcpkg is for user to install it anywhere and run a command that integrates vcpkg with MSBuild. vcpkg then takes care of adding include directories, libraries and all that in builds. This way project files don't need to refer to vcpkg location but it also leaves no trace of used vcpkg package versions in BOINC source tree.
One way to record the exact version dependencies would be to include vcpkg as Git submodule in BOINC source tree and have the submodule always point to a specific commit id in vcpkg repository. vcpkg repository is read only to us so this shouldn't have as much issues as Git submodules in general have. The problem with this approach is that while jumping around between master and pull requests and release branches the binaries inside vcpkg submodule might not actually correspond to the vcpkg version. One way to work around that could be using multiple working directories for master and other branches.
The questions
Before continuing with this some questions need to be answered. I'd appreciate that any 'no' answer is accompanied with an explanation for the 'no'.
Move to VS2017 and drop VS2010/2013? Use vcpkg? Drop XP support? Pre-emptively fork vcpkg? Integrate vcpkg into BOINC source tree?
Related issues: #1832, #2346