BWAPI 4.2.0 always immediately fails when injected on WinXP SP3

[chriscoxe]

Problem

BWAPI 4.1.2 runs fine on WinXP SP3, but BWAPI 4.2.0 always immediately fails when injected on WinXP SP3. Depending on how you run BWAPI, you may see an error pop-up that says:

<program> is not a valid Win32 application.

... then terminates, or it silently immediately crashes.

Proposed solution

I have diagnosed the problems, implemented a fix and I am about to commit it to the develop branch (i.e. just various changes to the vcxproj files). I have tested the resulting Release build outputs on WinXP SP3 and Win7 SP1. See the Instructions section below for how to apply the fix to other projects.

User Story

As a bot writer, I want to upgrade my bot to the latest BWAPI version and still be able to run my bot and others on WinXP SP3 VMs, so that I can efficiently use the hardware I have available, and also because the rules pages for the AIIDE and CIG competitions say entries must be tested on native Windows XP SP3 before submission.

Explanation of the problem

The main reasons why BWAPI 4.2.0 and a lot of .exe (and some newer .dll) bots that I have downloaded that use BWAPI 4.1.2 don't run on WinXP SP3 are because the vcxproj files used to build BWAPI 4.2.0 and the bots uses a version of the Windows SDK that is not compatible with WinXP SP3 or specifies a minimum operating system version and/or a minimum subsystem version that is higher than the version number of Windows XP SP3. Even if you fix this, there are other changes you need to do to the vcxproj files to get it to run successfully.

Tip: See my notes at the end if you are interested how I investigated and diagnosed the problems. The tools I mention there (and the other Sysinternals tools from Microsoft) are very handy for investigating problems like this on Windows when a debugger isn't available or wouldn't help.

Other Projects than just BWAPI are affected!

Unfortunately, in addition to BWAPI, bots' vcxproj files and other libraries that use VS2015 or VS2017 (and probably future versions of VS) would presumably also have to make the same changes to their vcxproj files - not just BWAPI's vcxproj files. By libraries, I potentially mean things like BWEM, BWTA. And also vcxproj files for tournament modules.

Compiler versions/configurations affected

It is only a potential problem for projects if Visual Studio version 2015 or above (e.g. Visual Studio version 2017) is used to build them. Most importantly, if they use <PlatformToolset>v140</PlatformToolset> (i.e. in a Visual Studio version 2015 project) or <PlatformToolset>v141</PlatformToolset> (i.e. in a Visual Studio version 2017 project) in the vcxproj file, the resulting .exe or .dll will probably not run on Windows XP.

Note: the instructions for making these changes are the same regardless of whether BWAPI is being fixed to run on WinXP SP3 or a bot that uses BWAPI 4.2.0 is being fixed that needs to be able to run on WinXP SP3. The problem is not BWAPI per se - the problem is that VS2015 and VS2017 do not properly support running programs (DLLs/EXEs) on WinXP SP3 unless these settings changes have been applied. Bots compiled in VS2015/VS2017 that use earlier versions of BWAPI such as 4.1.2 may be affected too.

Summary of how to fix your builds

• Install the optional "Windows XP support for C++" add-on (at least for Visual Studio version 2017 - I'm not sure about version 2015) on the machine where you are compiling it (by running the Visual Studio setup program - it will ask you if you want to modify your existing installation and allow you to install add-ons).

• Make the following changes to the vcxproj files.

Proposed documentation changes

If the proposed fix is used, presumably the documentation for BWAPI should be updated accordingly to say developers updating BWAPI or writing bots need to install the optional "Windows XP support for C++" add-on for Visual Studio. Otherwise the build will immediately fail with an error saying the add-on needs to be installed.

Instructions for modifying vcxproj files

I am about to commit a fix to the develop branch of BWAPI, but here are the instructions for applying the fix to other vcxproj files (e.g. bots, libraries). For bots, you may find it useful to look at what changes I made to ExampleAIModule.vcxproj or ExampleAIClient.vcxproj. For tournament modules - ExampleTournamentModule.vcxproj. Regardless, ensure you don't have WindowsTargetPlatformVersion set in your vcxproj files. For vcxproj files that build libraries or vcxproj files that haven't defined Subsystem, other changes may be needed (see the other instructions below).

For BWAPI, I only needed to modify the vcxproj files.

• WindowsTargetPlatformVersion: If they exist (they may not exist), remove (i.e. completely remove, don't just change) all lines for WindowsTargetPlatformVersion in all vcxproj files, e.g. remove all lines <WindowsTargetPlatformVersion>8.1</WindowsTargetPlatformVersion>
  In the VS2017 project configuration settings, this setting corresponds to General -> Windows SDK Version. Just to be clear, this is the version of the Windows SDK, not the version of Windows. The Windows SDK version 8.1 only supports development of software down to Windows 7, so theoretically it should run fine on Windows 7 and above, but it needs to be removed (and use v141_xp in the PlatformToolset setting) in order to support running on Windows XP. Note: I suggest removing the line from the vcxproj file rather than editing the setting in VS2017, because I would rather the value be derived automatically by whatever version of Visual Studio is being used (e.g. a future version of Visual Studio), as opposed to setting it myself to an explicit value.

• All the following changes should be done for all vcxproj files, except where it wouldn't make sense (e.g. projects that don't compile any C++ code like Installer.vcxproj don't have any compiler settings). Similarly, all the changes should be done for all project configurations that exist, not just the Release configuration (i.e. Release configuration exists in all projects, Debug exists in most projects except ones like Storm, and only the BWAPI project has Release_Pipeline and Debug_Pipeline, etc). FYI, from my limited testing while I was investigating, the changes seem to be necessary regardless of whether projects are configured/reconfigured to use static (non-DLL) vs dynamic (DLL) runtime libraries, and regardless of whether Debug vs non-Debug runtime libraries are used.

  • PlatformToolset: Change all lines for PlatformToolset to say: <PlatformToolset>v141_xp</PlatformToolset> - assuming using VS2017. I.E. search and replace all occurrences of <PlatformToolset>v141</PlatformToolset> with <PlatformToolset>v141_xp</PlatformToolset> in all vcxproj files. For VS2015 it would be <PlatformToolset>v140_xp</PlatformToolset> not <PlatformToolset>v140</PlatformToolset>. Note: for VS2013 it doesn't seem to be strictly necessary in practice but just for correctness it would be <PlatformToolset>v120_xp</PlatformToolset>. In the VS2017 project configuration settings, this setting corresponds to General -> Platform Toolset (which should now say "Visual Studio 2017 - Windows XP (v141_xp)").

  • /Zc:threadSafeInit-: Add an additional compiler option: <AdditionalOptions>/Zc:threadSafeInit- %(AdditionalOptions)</AdditionalOptions>. In the VS2017 project configuration settings, this setting corresponds to C/C++ -> Command Line -> Additional Options (you can add it via Visual Studio rather than editing if you like). If you don't do this, for Visual Studio version 2015 and above, when running BWAPI version 4.2.0 on WinXP SP3, BWAPI or your bot will (probably or always? not sure which) crash the first time it tries to initialize a static variable that has function level scope 😖.

    • Warnings and technical discussion/details: This change was the last change I attempted after I had made all the other changes, and after I made this single change to all the applicable vcxproj files, it longer crashed when I attempted to run ExampleAIModule.dll for a single player game vs a computer player, so this change seems to be important. After this change, the compiler will no longer initialize static local (function scope) variables in a thread-safe way, but this should not matter much in BWAPI because the documentation for BWAPI already mentions functionality in BWAPI that is not thread-safe. However, if this change is applied in bot vcxproj files, it may be a concern for bots that need to be thread-safe - you may need to implement a thread-safe solution yourself. I don't know for sure whether the other kinds of change than /Zc:threadSafeInit- are strictly necessary, but from my research and from the official documentation they all sound proper and safe assuming that targeting WinXP is a requirement. E.g. no mention of performance hits that could otherwise be avoided while still targeting WinXP etc. I haven't tested to look for downsides running on more recent versions of Windows, e.g. performance hits, but I would be surprised if there is any noticeable difference. I haven't tested to determine which of the other kinds of changes are strictly necessary to avoid crashing on Windows XP SP3 though. All my research says that all the other changes should be done if you want to target XP. Microsoft's documentation for these settings explicitly mentions targeting XP or the support or lack of support for Windows XP in particular, but I haven't been able to find any official documentation that contains a collection of all the instructions for the vcxproj changes you should make to properly target Windows XP (/SP3). There are several web forum topics about it that have bits and pieces of information/advice.

  • PreprocessorDefinitions: Add preprocessor options _WIN32_WINNT=0x0501 and NTDDI_VERSION=0x05010300 e.g. insert the _WIN32_WINNT=0x0501;NTDDI_VERSION=0x05010300; part in something that looks similar to: <PreprocessorDefinitions>NOMINMAX;WIN32;_WIN32_WINNT=0x0501;NTDDI_VERSION=0x05010300;NDEBUG;_CONSOLE;%(PreprocessorDefinitions)</PreprocessorDefinitions>. In the VS2017 project configuration settings, this setting corresponds to C/C++ -> Preprocessor -> Preprocessor Definitions. Note that some vcxproj files that compile source code like BWAPICore.vcxproj don't have a PreprocessorDefinitions section so you need to add it. The purpose is to detect the use of functionality that is incompatible with Windows XP (/SP3), now and in future versions of BWAPI and future versions of compilers. FTR these options are documented at https://msdn.microsoft.com/en-us/library/windows/desktop/aa383745(v=vs.85).aspx. Note that WINVER does not need to be defined because if it does not exist it will be derived automatically from _WIN32_WINNT.

  • MinimumRequiredVersion: In projects that build libraries (for BWAPI this is just the following: BWAPIClient.vcxproj, BWAPICore.vcxproj, BWAPILIB.vcxproj, Util.vcxproj), insert/modify the Lib section after PostBuildEvent section (or add/change the MinimumRequiredVersion settings to the Lib section if the Lib section already exists):
    <Lib>
<MinimumRequiredVersion>5.01</MinimumRequiredVersion>
</Lib>
    In the VS2017 project configuration settings, this setting corresponds to Librarian -> General -> Minimum Required Version. This change is needed because for projects that create libraries, the minimum required version setting isn't automatically derived from the PlatformToolset setting.

  • SubSystem: In projects that don't just build libraries that haven't specified a Subsystem (for BWAPI this is just DocumentationGen.vcxproj), add Link option <SubSystem>Console</SubSystem>. In the VS2017 project configuration settings, this setting corresponds to Linker -> System -> SubSystem. This change is necessary now that PlatformToolset has been changed to v141_xp, because the linker option for "Minimum Required Version" is now derived automatically (as opposed to unspecified), and in order to enforce the minimum required version it needs to know what kind of SubSystem it is. If you make the other changes but not this one, you will see a warning when you try to build, so if you are not sure, you could try to build and see whether there is a warning saying like "Subsystem is not defined".

Other points/queries

I don't know whether any corresponding changes are necessary to the CMake settings(?) because I am not familiar with how CMake is used to build BWAPI.

Testing performed

Building

No new warnings/errors when I run build.bat or compile the solution from scratch in for the Release, Release_Pipeline, Debug, Debug_Pipeline project configurations of the develop branch with these changes applied (I haven't tried the Installer_Target project configuration though because I don't have some required tools installed), nor when I compile my bot (ZZZKBot) linking dynamically with BWAPI with these changes applied to BWAPI's and my bot's vcxproj files. I have also checked that the operating system version and subsystem version both say 5.01 when I run dumpbin /headers <theBinary> on the produced DLL and EXE files (and BWAPI_PluginInjector BWL & QDP files, SNP_DirectIP SNP files).

Unit tests

All unit tests pass when I run build.bat.

Documentation generation

As a quick regression test, I have built it and run the resulting DocumentationGen.exe to check that it still produces some output files and exits with return code zero.

Running

On a WinXP SP3 VM

1. I applied the necessary modifications to the Starcraft folder for upgrading my environment from BWAPI 4.1.2 to BWAPI 4.2.0, e.g. updated bwapi.ini settings for BWAPI 4.2.0, use the new DLLs/EXEs/SNP/BWL files and use ExampleTournamentModule.dll as the tournament module, and the bwapi-data\data\Broodwar.map file is different in BWAPI 4.2.0 than 4.1.2.

2. In bwapi.ini, I used "lan_mode = Local Area Network (UDP)" (against a bot on a different VM) and "auto_menu = ON" and "tournament =bwapi-data/ExampleTournamentModule.dll" and "auto_restart = ON" and "game = JOIN_FIRST" and Tau Cross map.

3. I tested all the Release mode DLLs/EXEs, using Chaoslauncher (I copied the whole Chaoslauncher folder). I ran variants for:

   • ExampleAIModule.dll
   • DevAIModule.dll
   • TestAIModule.dll
   • "bwapi-data\AI\AIModuleLoader.exe bwapi-data\AI\ExampleAIModule.dll"
   • "bwapi-data\AI\AIModuleLoader.exe bwapi-data\AI\DevAIModule.dll"
   • "bwapi-data\AI\AIModuleLoader.exe bwapi-data\AI\TestAIModule.dll"
   • "bwapi-data\AI\ExampleAIClient.exe"
   • My updated bot (ZZZKBot.dll), and
   • "bwapi-data\AI\AIModuleLoader.exe bwapi-data\AI\ZZZKBot.dll".
     No apparent performance problems when I type "/speed 0" in the in-game chat. I let each play at least two consecutive games using "auto_restart = ON" to check there are no problems when games end or running consecutive games. DevAIModule and TestAIModule don't order their units to do anything (which is normal when playing on this map) but they write chat messages and write text to the GUI. I also checked once that one of them could play a game without using any tournament module. I didn't see any crashes or errors/warnings nor crash log files etc produced.

I also performed all the same testing for all the Debug variants.

Notes on the DLLs required by the Debug variants

They require the Debug variants of the C++ Runtime library in order to run. The redistributable installer only installs the Release mode variants, not the Debug variants, and there are no Microsoft installers on the web for the Debug variants. Microsoft do not provide them and say Debug variants are not supposed to be redistributable. To get it working, I temporarily copied concrt140d.dll, msvcp140d.dll, vccorlib140d.dll, vcruntime140d.dll from the Win7 SP1 machine where I have VS2017 installed, from folder "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Redist\MSVC\14.10.25008\debug_nonredist\x86\Microsoft.VC150.DebugCRT" to the "C:\WINDOWS" folder on the WinXP SP3 VM (after checking that I was not overwriting any existing DLLs in that folder), and similarly copied "C:\Program Files (x86)\Microsoft SDKs\Windows Kits\10\ExtensionSDKs\Microsoft.UniversalCRT.Debug\10.0.15063.0\Redist\Debug\x86\ucrtbased.dll" to the "C:\WINDOWS" folder. After testing, to tidy up, I removed those DLLs from the "C:\WINDOWS" folder (be careful not to delete other DLLs!). I tidied them up because it is not good practice to put DLLs only used for testing/Debugging in important Windows folders like that because they may interfere with other programs (e.g. slow down performance) - the proper way to deploy them would be to put them in the same folder as your executables. Putting them in "C:\WINDOWS" temporarily was just a convenience because the Debug variants I am testing are scattered across several folders.

On a Win7 SP1 VM

I did all the same testing as for a WinXP SP3 VM. I.E. I ran the Release variants and Debug variants (not just the Release variants). FYI, with regards to the DLLs required by the Debug variants (e.g. msvcp140d.dll), I copied the same DLL files to the Win7 SP1 VM as the ones I copied to WinXP SP3.

Tips/tools/info about investigating this problem and others like it without Visual Studio

VS2017 does not support remote debugging on WinXP. Here is some info about what I did that may help others to investigate these kinds of problems in future. I googled to research potential problems targeting XP using Visual Studio 2015/2017. I diagnosed the problems by doing a few checks from my research on-line, and using a few handy tools that I was already familiar with. I checked the "operating system version" and "subsystem" values printed by doing Start -> Programs -> Visual Studio 2017 -> Visual Studio Tools -> Developer Command Prompt for VS 2017 -> "dumpbin /headers <theBinary>" (when targeting Windows XP they should both say "5.01". Before I made these changes they were both saying "6.00" which is Windows Vista. I ran the profiler menu option in Dependency Walker (i.e. depends.exe; I downloaded it for free and you don't need to register or install it) on Chaoslauncher.exe on WinXP SP3, seeing what address in BWAPI.dll or ExampleAIModule.dll it crashed at (for me, it always crashed due to an "Access Violation"). On my machine where I have VS2017 installed, I did Start -> Programs -> Visual Studio 2017 -> Visual Studio Tools -> Developer Command Prompt for VS 2017 -> "dumpbin /DISASM <theDLL> > <theOutputTextFile>". Then I had a look at the disassembly in the text file and see what function it crashed in and tried to decipher it to get an idea what it might have been trying to do when it crashed, around the address printed by Dependency Walker for the crash. Googling some disassembly snippets led me to the explanation at https://stackoverflow.com/questions/32517234/access-violation-on-static-initialization

There may be better ways of investigating than Dependency Walker - maybe WinDBG.

I also tried to figure out what happened on the WinXP SP3 machine by running ProcMon there (a Sysinternals tool that I downloaded from Microsoft). At first I thought the thread that Chaoslauncher started to load BWAPI couldn't start because it couldn't find some DLLs that don't exist on my WinXP SP3 machine ("C:\WINDOWS\system32\api-ms-win-core-fibers-l1-1-1.dll" and "C:\WINDOWS\system32\api-ms-win-core-localization-l1-2-1.dll", and after it fails it also searches for "C:\WINDOWS\system32\api-ms-win-core-sysinfo-l1-2-1.dll"; they don't exist even though I've installed all the redistributables). It turned out to not be the sole explanation why BWAPI wasn't starting (it was actually starting ok - it was just starting then crashing very soon after starting), but it does help explain why the /Zc:threadSafeInit- change is needed. api-ms-win-core-fibers-l1-1-1.dll is supposed to contain functions like FlsAlloc which deal with initializing thread-local storage.

Normally if a DLL or EXE isn't starting I would open it in Dependency Walker to see if there are missing DLLs that it obviously needs (note: you can ignore errors/warnings for MSJAVA.DLL and MPR.DLL because they are not really a problem, but any other errors/warnings are probably a problem, except that Dependency Walker may not realize that the working directory should be your Starcraft directory so if there are DLLs in the Starcraft directory that it needs you can try copying them to the same folder as the binary then re-run Dependency Walker). It can't check for dynamically loaded DLLs unless you try running the profiler though. Note that having some missing dynamically loaded DLLs are not necessarily cause a problem for programs - it depends whether the program has been written to be able to recover and continue without them.

General comments about BWAPI continuing to support WinXP SP3

Of course, WinXP SP3 is no longer officially supported by Microsoft. New versions of compilers and SDKs may provide improvements such as performance improvements, but going forwards, I think it would be a shame if BWAPI drops support for WinXP SP3 without good reason. E.g. if it ends up boiling down to a question of whether we want BWAPI to be able to make use of the improvements.

WinXP SP3 is nice because it has low system requirements such as memory and hard disk usage, and low performance overheads like CPU/memory used by the OS. This makes it ideal for running as many guest VMs as possible for your available hardware in a tournament manager setup for doing test runs or training vs other bots.

If you are doing training using self-play there may be faster ways of doing it in future such as simulation (perhaps in future with OpenBW or BWAPI for OpenBW I am guesssing...). However, if you want to test against existing bots to evaluate its performance (or are running a tournament with 20-50+ bots like AIIDE or CIG or SSCAIT) and only have their binaries not their source code, you have to actually run the other bots so you need machine(s) or VMs to run them on that are compatible with the bots' binaries. the less resources each bot instance needs, the more bot instances you can run on your machine(s) at the same time.

Note: a while ago I experimented with using bwapi.ini's "lan_mode = Local PC" mode with both bots running on the same machine, and "lan_mode = Direct IP" modes, but they seemed a lot slower (in terms of real-world time to run a series of games) than using "lan_mode = Local Area Network (UDP)" with the two bots on different VMs on the same physical machine. Using Windows, the most efficient way I have found to use your hardware seems to be one VM per bot, preferably with all VMs on one (powerful) physical machine (as opposed to physically separate less powerful machines), running as guest OS'es in the same host OS. I haven't tried tscmoo's bwheadless or Wine etc though...

[chriscoxe]

Committed to develop branch. Perhaps someone like @heinermann could review? I'd like to mention it in the bwapi Facebook group but another pair of eyes on it before I post would be good.

[chriscoxe]

Update: I have updated the issue to say that I have now also tested all the Debug variants (i.e. not just the Release variants). I only updated the subsections of the "Testing performed" section - all the rest of the issue is unchanged.

[chriscoxe]

I'm not sure whether anyone has noticed this issue because nobody has commented on it yet, so I'll mention it in the bwapi Facebook group.

Unless there are any complaints/concerns about the issue, I would like to request a new release of BWAPI that could potentially be used for AIIDE 2017 (if the organizers want it). I don't know what is involved with planning or packaging a release though. Please could someone like @heinermann comment?

[davechurchill]

4.2.0 works on our systems, so no fix is necessary for the 2017 AIIDE tournament, but thanks Chris!

[chriscoxe]

If it isn't needed for AIIDE 2017 then there is no urgency for a BWAPI release, so @heinermann please ignore my request for a new BWAPI release.

[chriscoxe]

So AIIDE 2017 will be using Windows 7 or above, not Windows XP SP3? Or have you somehow managed to get official BWAPI 4.2.0 release working on Windows XP SP3? How?

[davechurchill]

It is using Windows 7, we have been since... 2015?

[chriscoxe]

I see. Looking forward to the tournament :)

[jaj22]

This was already an issue for 4.1.2 VS2013 client bots: Krasi0 and tscmoo won't run in XP SP3, for example ("Not a valid win32 executable"). Apparently v120 toolset DLLs work on XP, but v120 executables do not.

Would support persuading everyone to use the XP toolsets, as XP VMs are much less annoying. Probably doomed though.

[davechurchill]

I think requiring people to be compliant for an OS that has lost official support is a bad idea. Windows 7 will be fine for a long time

…

On Tue, Aug 1, 2017 at 10:01 PM, jaj22 ***@***.***> wrote: This was already an issue for 4.1.2 VS2013 client bots: Krasi0 and tscmoo won't run in XP SP3, for example ("Not a valid win32 executable"). Apparently v120 toolset DLLs work on XP, but v120 executables do not. Would support persuading everyone to use the XP toolsets, as XP VMs are much less annoying. Probably doomed though. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#733 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABIkqCRexP2pGLSqDwodmfCRZbho8w-Tks5sT8NogaJpZM4Ont4g> .

-- David Churchill - dave.churchill@gmail.com Assistant Professor Department of Computer Science Memorial University of Newfoundland http://www.cs.mun.ca/~dchurchill Lead AI Programmer, Lunarch Studios http://www.lunarchstudios.com <http://lunarchstudios.com/>

[chriscoxe]

I agree that people should not be forced to be compliant in other projects. Just to be clear, my intention was to propose the changes to BWAPI so BWAPI could run on Windows XP SP3, and let people make their own decision whether they apply the changes to other projects in case they want their projects to be able to run on Windows XP SP3.

However, I don't know enough about linkers (VS or others that might be used) to know whether using the proposed changes in BWAPI would force/restrict people that do not want/need their projects to run on Windows XP SP3 with regards to what they are able to do in their own projects and still be compatible with BWAPI. If anyone knows, please could you comment? The main changes I wonder about are preprocessor options "_WIN32_WINNT=0x0501" and "NTDDI_VERSION=0x05010300", and "/Zc:threadSafeInit-". Especially if people want their projects to link statically with BWAPI. If it would force/restrict people, then I would reject the proposed changes and perhaps make it clear in the documentation that BWAPI no longer supports Windows XP SP3.

[chriscoxe]

Using BWAPI 4.2.0 with the changes applied, I've just successfully run a game of my bot after I compiled my bot linking with that build of BWAPI but in ZZZKBot.vcxproj I've used "<PlatformToolset>v141</PlatformToolset>" (not "<PlatformToolset>v141_xp</PlatformToolset>") and without "_WIN32_WINNT=0x0501" and without "NTDDI_VERSION=0x05010300" and without "/Zc:threadSafeInit-". So it is possible in at least some cases to use the changed BWAPI without also making the corresponding changes in a bot's vcxproj file. My bot is very simple though - it doesn't have any other dependencies or use any functionality for the more recent toolset/SDK versions. And I haven't tried an EXE bot. This doesn't help to know whether it might force/restrict other projects, but it does show that it's at least possible.

[heinermann]

If this doesn't require everyone changing their bot's project files then we can do it.

I don't think forcing all devs to change their runtime for Windows XP is a reasonable ask. BWAPI 5 will mitigate these compiler things.

[chriscoxe]

In response to @heinermann 's comments:

If this doesn't require everyone changing their bot's project files then we can do it.

Just to summarize what I have tested and what I haven't tested in this regard: in my last post I showed that my bot works with the proposed BWAPI fix without needing to change my bot's project files (i.e. so it uses a project file that's equivalent to BWAPI 4.2.0's ExampleAIModule's project file). Like I said though, my bot is simple - I haven't tested it for projects that use any functionality for the more recent toolset/SDK versions or more complicated bots or EXE bots or client DLL bots or tournament modules or libraries like BWTA/BWEM or bots that rely on other 3rd-party libraries or Debug build configurations or Java projects (although I can't see how JNI could be a problem in itself).

I don't think forcing all devs to change their runtime for Windows XP is a reasonable ask.

Agreed.

BWAPI 5 will mitigate these compiler things.

Good to know (I don't know what is planned in BWAPI 5 but it's still good to know).