search

capstone-engine / capstone

Capstone disassembly/disassembler framework for ARM, ARM64 (ARMv8), Alpha, BPF, Ethereum VM, HPPA, LoongArch, M68K, M680X, Mips, MOS65XX, PPC, RISC-V(rv32G/rv64G), SH, Sparc, SystemZ, TMS320C64X, TriCore, Webassembly, XCore and X86.
http://www.capstone-engine.org
7.61k stars 1.56k forks source link

Raise minimum requirement to VS2017 #2228

Closed XVilka closed 10 months ago

XVilka commented 10 months ago

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 https://github.com/capstone-engine/capstone/issues/2226

kabeor commented 10 months ago

According to https://github.com/capstone-engine/capstone/issues/2226#issuecomment-1873982637, seems it's necessary to make sure VS2015 is fulling supported by Capstone.

XVilka commented 10 months ago

@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 commented 10 months ago

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 https://github.com/capstone-engine/capstone/issues/2226#issuecomment-1873982637 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 commented 10 months ago

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.