Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raise minimum requirement to VS2017 #2228

Merged
merged 1 commit into from
Jan 7, 2024
Merged

Conversation

XVilka
Copy link
Contributor

@XVilka XVilka commented Jan 1, 2024

Since the auto-sync changes Capstone use C99, no Visual Studio below 2015 could compile it. On the other hand, it's 2024 already, and maintainers have no reason to support this ancient software (the latest Visual Studio is VS2022).

Users of the legacy platforms could either update or use older capstone, or make custom patches/forks. Given the lack of maintainers, supporting those strains limited resources even further.

Instead of VS2015 I used VS2017 just to be safe because in Rizin we check all commits with this version precisely: https://raw.githubusercontent.com/rizinorg/rizin/dev/.appveyor.yml

Closes #2226

@kabeor
Copy link
Member

kabeor commented Jan 3, 2024

According to #2226 (comment), seems it's necessary to make sure VS2015 is fulling supported by Capstone.

@XVilka
Copy link
Contributor Author

XVilka commented Jan 3, 2024

@kabeor I can, but we cannot guarantee it will work since Rizin hasn't tested VS2015 for many years already. In that case, it's better to create the corresponding CI job in the capstone repository but use GitHub Actions instead of AppVeyor.

It's also notable that builds for Windows XP could be created even with VS2022; see OpenSIMH CI for example https://github.com/open-simh/simh/blob/master/.github/workflows/cmake-builds.yml#L112

@Necrolis
Copy link

Necrolis commented Jan 4, 2024

It's also notable that builds for Windows XP could be created even with VS2022; see OpenSIMH CI for example https://github.com/open-simh/simh/blob/master/.github/workflows/cmake-builds.yml#L112

Thats not really VS2022, thats using the VS2017 build toolset for WinXP (v141_xp) with the MSBuild from VS2022 (at least from a brief inspection).

That does mean a minimum toolset of VS2017 won't then remove WinXP support so long as the v141_xp toolset is available/installed (I was under the impression v140_xp that came with VS2015 was the last XP version when I added #2226 (comment) since I've never installed VS2017 on any of my systems).
Microsoft has a bit more info on the (deprecated) WinXP toolsets here. I have updated my comment in the other ticket accordingly.

@kabeor
Copy link
Member

kabeor commented Jan 7, 2024

Ok, changing to vs2017 now seems to make sense. Merged now. Then this link should be added in msvc doc to give necessary guidance to specific users.

Still, vs2015 should be tested and supported in the future.

@kabeor kabeor merged commit 15d9337 into capstone-engine:next Jan 7, 2024
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Has v5.0.x Dropped VS2010 Support?
3 participants