I'm not going to bother with 32-bit in this day and age. The python version available with VS2022 doesn't even seem to include support.

So, go to the top-left solutions property → configuration manager, and add a new active solution platform for x64. Let it inherit from x86. Switch all project solutions to use x64.

Just install the latest available Python for VS2022. It'll say outdated, but there doesn't seem to be a newer one, so oh well. I'm sure it's easy to swap out.

Once installed, add the include directory to the plugin_python solution (it'll be C:\Program Files %28×86%29\Microsoft Visual Studio\Shared\Python39_64\include). Also add the python libs directory to linker additional library dependencies field. And, of course, add python39.lib as a linker dependency.

As it says… some of this got clobbered with the upgrading, but mixed with all the other stuff, it's hard to tell. So, let's just reset it to a default which is already nicer. Basically, everywhere in a project solution where FullDebug is an output, just set the field to use project settings/inherit. This will change it to something like `$(OutDir)$(TargetName)$(TargetExt)`. This results in an output directory like `crossfire32/x64/FullDebug` instead of just `FullDebug/`.

There are ancient references to `afxres.h` in the .rc files. Delete this line. I think you might have to replace with `#include “windows.h”`, but not really sure.

Maybe these .rc files can be removed or re-created from scratch? There's a lot of archaic garbage in them.

Well, the easiest is to add a header-only dirent.h implementation. I added https://github.com/tronkko/dirent/blob/master/include/dirent.h to a `make_win32/include/` directory and added that folder as an include path.

As it says… if the solution is looking for .h files but can't find them, double-check it's pointing to the correct locations.

The call to `clock_gettime(CLOCK_MONOTONIC, …)` is unavailable to Windows. What _should_ be done to the codebase is to replace it with std::chrono::steady_clock. However, the following can be used to replace it:

timespec your_var;
static LARGE_INTEGER tps;
LARGE_INTEGER ticks;
if (!tps.QuadPart) {
  QueryPerformanceCounter(&tps);
}
QueryPerformanceCounter(&ticks);
your_var.tv_sec = (long)(ticks.QuadPart / tps.QuadPart);
your_var.tv_nsec = (long(((ticks.QuadPart % tps.QuadPart) * (1000000000ULL)) / tps.QuadPart);

For now just manually create this. What should be done is a pre-build step that runs a .bat that does the same thing that a shell script currently does to generate this file (check for git and attempt to use current tag (or commit??) as a #define).

There are numerous uses of erroneous code where a non compile-time C string is used to create compile-time sized arrays. e.g., malloc should be used not `char [strlen(dynamic_string)] my_bad_string`. For the time being, I've just used `std::string` where these have been used, as I'm lazy – a real fix would be to switch to std::string in such places for all strings so that we're not mixing unnecessarily (or if someone wants, properly use malloc and free).

R_OK isn't defined in MSVC, it seems. This is in map.cpp… I just added

#define R_OK 4

:)

For Forward's Sake – this can be replaced with _BitScanForward. NOTE, however, that there is actually an assembly language replacement in the code that is active if the `CF_MXE_CROSS_COMPILE` flag is set (see object.cpp:42). However, for better portability/readability, I added the following definition for ffs:

#ifdef _MSC_VER
int ffs(unsigned long v) {
  unsigned long index;
  if (_BitScanForward(&index, v)) {
    return (int)index + 1;
  }
  return 0;
}
#endif

Although there is a definition for this in win32.h, we can just use some built-in calls… also, we need strcasecmp.

So, in win32.h

#ifdef _MSC_VER
#define strncasecmp _strnicmp
#define strcasecmp _stricmp
#desfine strtok_r strtok_s
#endif

Unfortunately, we'll need to acquire and setup flex to build the needed loader and parser .cpp files. I'm using winflexbison, as it has direct integration with visual studio.

Install it, then follow these steps.

Now add `loader.l` to crossfire32's Source Files/common filter dir and `reader.l` to Source Files/random_map. Edit their properties and change the Output File Name to be `%(Filename).cpp` instead of `%(Filename).flex.cpp`.

Now ensure the location where win_flex_bison is extracted to is as an Executable Directory in crossfire32's Solution → Properties → VC++ Directories → Executable Directors.

Finally, build the loader.l and reader.l files and then add the resulting .cpp files to common/ and random_maps/ (if a proper VS solution project file is made, this won't be necessary).

This is a file that is generated from Python… Add a Pre-Build Event to crossfire32 project with the command:

"<some sort of path to>\python.exe" ../common/is_valid_types_gen.py ../include/object.h > ../common/arch_types_valid.cpp

It's goofy, but build once to generate this file, then we can add it as an existing item to source files/common (this won't be necessary with a complete VS project once that's a thing).

There are other minor things, like missing includes for the MSVC environment, but those are easy to figure out.