Crossfire Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
Here-in lies documentation for efforts to compile the server in VS2022 (latest available as of 2025).

----

I have done all this from within a docker-based VM so I could start with a clean slate and not clobber any existing setup.

To begin with, you must acquire VS2019 to convert the VC6 .dsw workspace into a modern .sln. 2022 dropped support, so this is necessary. Once converted, 2022 can be used to convert the 2019 .sln to 2022. It should be noted that I think it would actually be better to create a fresh SLN file, as there is a lot of cruft left over both from upconverting and the original projects solutions output locations.

Once you have that, you need to update all the source and header files to point to the appropriate new files (as well as add any new files over time) -- I'd also recommend changing the various source/header file filters ("directories") to English from German. Once again, I think just starting fresh would be simpler overall.

Some other steps:

  * Set C++ version to 20. This is only needed for crossfire32 solution, but should probably be done with the plugins.
  * Remove pthreadvsc2 from linking steps (for crossfire32 only, I think)
  * Reduce project warnings for sanity.
  * Add LIBDIR="./" and PLUGIN_SUFFIX=".dll" to the preprocessor definitions for crossfire32.
  * The way VS does compilation leads to .obj files with the same name overwriting one another (e.g., socket/image.cpp and common/server/image.cpp will both generate image.obj in the same place). The solution is to go to `C/C++ -> Output Files -> Object File Name` and set it to `$(IntDir)/%(RelativeDir)` -- this will ensure that no clobbering can occur.

Intermediary stuff done to get to a baseline state:

  * Remove libcurl for now
  * mkdir <source>/share/plugins
  * comment out FOR_MAP_PREPARE and FOR_MAP_FINISH in cfanim.cpp (cf animation plugin). This isn't the right thing to do, but these are functions defined in map.cpp, which would cause the entire universe to be pulled into to be able to compile... I'm not sure what can be done to fix this... maybe there isn't an exposed extern function?

====== Switch to x64 ======

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.

====== Python ======

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 %28x86%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.

====== Reset all uses of FullDebug in path outputs ======

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/`.

====== Fix .rc cruft ======
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.

====== dirent.h missing ======

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.

====== Add include paths ======

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.

====== CLOCK_MONOTONIC ======

The call to `clock_gettime(CLOCK_MONOTONIC, ...)` is unavailable to Windows. What _should_ be done to the codebase is to replace it with [[https://en.cppreference.com/w/cpp/chrono/steady_clock|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);

====== svn_version.h ======

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).

====== Using non-const c strings to create arrays ======

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 ======

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

  #define R_OK 4

:)

====== ffs usage ======

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
  
====== strncasecmp, strcasecmp, strtok_r ======
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

====== common/loader.l, random_map/reader.l (flex) ======
Unfortunately, we'll need to acquire and setup flex to build the needed loader and parser .cpp files. I'm using [[https://github.com/lexxmark/winflexbison?tab=readme-ov-file|winflexbison]], as it has direct integration with visual studio.

Install it, then follow [[https://github.com/lexxmark/winflexbison/blob/master/custom_build_rules/README.md|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`. Additionally, change the `reader.l` 's "Prefix" Flex Option to `readeryy`... This prevents flex symbols colliding with loader's output during final linking.

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).

====== CRLF tragedies ======
Although git can force LF line encoding, might as well update CF to allow both \r\n and \n. This involves modifying `bufferreader.cpp`'s `bufferreader_next_line` and `bufferreader_get_line` functions.

bufferreader_next_line:

  . . .
  int index = 0;
  char *newline = strchr(br->current_line, '\r');
  if (newline == NULL) {
    newline = strchr(br->current_line, '\n');
    index = 1;
  } else {
    index = 2;
  }
  . . .
  if (newline) {
    br->current_line = newline + index;
  . . .

bufferreader_get_line:

  . . .
  int index = 0;
  char *newline = strchr(br->current_line, '\r');
  if (newline == NULL) {
    newline = strchr(br->current_line, '\n');
    index = 1;
  } else {
    index = 2;
  }
  . . .
  if (newline) {
    br->current_line = newline + index;
    strncpy(buffer, curr, cp);
    if (index == 2) {
      buffer[cp - 1] = '\n';
    }
    buffer[cp] = '\0';
  } else {
  . . .

Additionally, load_map_header in map.cpp needs an update on 997 (all lines numbers are approximate, as I have a bunch of printf debug crap all over the place):

  p = strchr(buf, '\r');
  if (p == NULL) {
    p = strchr(buf, '\n');
  }
  if (p == NULL) {
  . . .

and around 1040

  . . .
        if (!strcmp(buf, "endmsg\r\n") || !strcmp(buf, "endmsg\n"))
  . . .
  
and around 1070

  . . .
        if (!strcmp(buf, "endmaplore\r\n") || !strcmp(buf, "endmaplore\n"))
  . . .

AND FINALLY, loader.l needs to be updated to search for "\r\n" or "\n". AFAIK, flex treats "$" as "/\n", so we can just replace "$" with "/\r?\n". The only exception are lines 877 and 878, as they throw out the empty lines (these are <*>(^{WS}$)|\n and #.*\n).

====== "Object" loader issues ======
Maybe because of using winflex, but the "^object{S}" on line 430 doesn't ever match. Changing it to be "^Object{S}" fixes it... it feels that it should have been capitalized in the first place, since that is how archetypes declare it. In the end I changed it to:

  ^[o|O]bject{S}

and it built archetypes ok.

====== arch_types_valid.cpp ======
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).

====== PRINTF_ARGS / __attribute__ ======
I'm too much of a bonehead when it comes to GCC attributes and how to convert that over, so we just define the following in global.h, before the definition of PRINTF_ARGS:

  #ifndef __GNUC__
  #define __attribute__(a)
  #endif

I think this is some sort of terrible catch-all, but it seems to work.

====== BEGONE SERVICES ======
Well, not really. The win32 code expects crossfire to be run as a service and uses a `bRunning` variable to determine if the server is running. What this means is that in server.cpp, we need to disable the WIN32 ifdef on 1603 that looks for bRunning, and just use the while(TRUE) loop:

  #ifdef WIN32_DISABLED
    while(bRunning) {
  #else
    while(TRUE) {
  #endif

====== ALTERNATIVE LEXER NO CRLF WORLD ======
Attempting to do some LF-only work, since I'm not sure if winflex or CRLF patches are breaking things. At any rate, issuing the same flex commands to generate loader.cpp (and not having any of the CRLF patches about), compiling, then trying to collect arches crashes due to machine.arc. It has an excessively long and verbose comment header that is breaking collection, hard. So remove the excess and building works. Why isn't this in a .LICENSE file with the image...?

====== Plugins ======
Plugins have to be in the appropriate directory (lib/plugins), so make sure builds copy to there (can be configured as a post build step).

`SvnRevPlugin` needs extern "C" applied to it, otherwise the exported name gets mangled. Aka it appears as

  ?SvnRevPlugin@@3PADA = ?SvnRevPlugin@@3PADA (char * SvnRevPlugin)
  
When it should be

  SvnRevPlugin = SvnRevPlugin (or similar on this second part

Fix by just prepending extern "C"

  extern "C" CF_PLUGIN char SvnRevPlugin[] = SVN_REV;

Apply the above to both the animator and python plugins.

The python plugin also needed to have CF_PLUGIN added to it's cfpython_proto.h file, so adjust in the following fashion:

  extern "C" int initPlugin(...)

to

  extern "C" CF_PLUGIN int initPlugin(...)

====== Other stuff ======

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

====== New Beginnings ======
With the above crap behind us, we're starting with the following installation:
  * Latest VS2022 with only baseline C++ support
  * GNU flex 2.5.4a-1
  * Python 3.13.2

Oops, my submission broke, so here is the cliff notes version.

1. _Everything_ read by the CF server must be LF. No CRLF business.

2. If using a different Python version or non-global (i.e, C:\Program Files) install, adjust crossfire32 pre-build step to use the right python.exe to generate a .cpp file. Adjust the plugin python to match include, lib, and Libs linking. Copy I think just the main Python version DLL to the crossfire-server root (and maybe the minor version, not certain).

3. Run flex.exe (using the actual path to the one you installed, obviously) from the given common or random_maps directories, with the following appropriate command:


  flex.exe -i -B -Cf -o loader.cpp ../common/loader.l
  
  flex.exe -i -B -Cf -o reader.cpp ../random_maps/reader.l
  
Not checking now, but I think you might need to do

  "-oloader.cpp"

verbitim, aka:

  flex.exe -i -B -Cf "-oloader.cpp" ../common/loader.l
  
Also same for reader... seems goofy.

4. Copy all the files to the appropriate share, etc, and var directories. I will add these as Visual Studio project build steps later.
 
5. Build and you should have the .exe in root project dir and .dlls in their appropriate directory.

6. Oh, also collect the assets (delete .arc, .face, .trs, .tar, .artifaces if they exist).

6.1. Also make sure you have arch in the lib/ dir. I can't recall if it complains if maps isn't in there, but that should end up in share, I think.

  cd lib
  ../crossfire32.exe -data ./ -conf ./config -pack-assets archs crossfire.arc -pack-assets faces crossfire.face -pack-assets treasures crossfire.trs -pack-assets images crossfire.tar -pack-assets artifacts crossfire.artifacts
Crossfire Wiki

User Tools

Site Tools

Page Tools
