master
windows: Update msvc/getopt to glibc 2.41 (commit 66f3e92)
msvc: Rework msbuild files
windows: Remove VS2013 and VS2015 support
windows: hotplug implementation
windows: Remove ARM32 from MSVC, fix PlatformToolsetVersion
msvc: Add tests/init_context project to MSVC
tests: address review comments on testcore
core: populate libusb_version::describe from git describe, freeze LIBUSB_NANO
tests: Add unit test for libusb_set_option
tests/stress_mt: Add Windows threads support
tests: Add tests/testcore.c, a multi-threaded stress test that hammers libusb_get_device_list / libusb_free_device_list from N threads in parallel. It exists primarily to reproduce the concurrent-enumeration crashes reported in #1793 and the related set_composite_interface race surfaced during PR #1795 review. The stressed code paths include: - usbi_get_device_by_session_id() - usbi_alloc_device() - usbi_connect_device() - libusb_unref_device() / ctx->usb_devs_lock - winusb_device_priv setup races in set_composite_interface and set_hid_interface (Windows, non-hotplug builds) The original C++20 reproducer was posted by smarvonohr and the C version with Win32 threads by mcuee in https://github.com/libusb/libusb/pull/1795#issuecomment-4258288585 This version is adapted from mcuee's C version, with two changes that make it portable and easier to build: - Use the same PLATFORM_POSIX / PLATFORM_WINDOWS thread abstraction that stress_mt.c uses (pthread_create on POSIX, _beginthreadex on Windows, CreateThread on Cygwin), instead of bare pthread. The original would not build with MSVC. - Print the device list once before starting the worker threads, so the operator can confirm at a glance which devices are present. This is useful because the bug only manifests when enumeration touches certain device shapes (e.g. composite devices with HID children that exercise set_composite_interface). Add msvc/testcore.vcxproj following the same template as msvc/stress_mt.vcxproj so the test builds out of the box in Visual Studio against libusb_static. Notes for runners: - The test only triggers the enumeration races in non-HOTPLUG builds. With Windows hotplug enabled, libusb_get_device_list is served from a cache and winusb_get_device_list never runs concurrently, so the bug does not manifest. - The default LOOPS = 100000 is intentionally large for the original bug-hunting use case but takes hours of real work even when the library is correct (each non-hotplug get_device_list does a full Windows USB enumeration, ~10-100 ms). Reduce LOOPS for a quick smoke test. - At least one composite USB device with HID-class child interfaces (USB game controller, headset with controls, Logitech Unifying receiver, etc.) must be present to exercise set_composite_interface. Pure UVC/UAC composite devices like webcams will NOT trigger that path because their child interfaces are not HID class and are not bound to any libusb-supported driver.