Arx Libertatis Bug Tracker
Please log in to bookmark issues
CLOSED  Bug report #1569  -  App does not Start - Windows XP Compatibility
Posted Jul 23, 2021 - updated Apr 02, 2022   Shortlink:
icon_info.png This issue has been closed with status "Fixed" and resolution "RESOLVED".
Issue details
  • Type of issue
    Bug report
  • Status
  • Assigned to
    Not assigned to anyone
  • Progress
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
  • Posted by
     Guest user
  • Owned by
    Not owned by anyone
  • Estimated time
    Not estimated
  • Category
    Not determined
  • Resolution
  • Priority
  • Reproducability
  • Severity
    Not determined
  • Targetted for
    icon_milestones.png Not determined
  • OS
    icon_customdatatype.png Windows XP
  • Architecture
    icon_customdatatype.png Not determined
  • Fixed in
    icon_customdatatype.png Arx Libertatis 1.2.1
Issue description
Starting the arx.exe on WinXP the OS throws an error msg "cannot find entry poin to create threadpoolwork in kernel32.dll", which is not very surprising, as this function is supported by kernel32.dll from WinNT 6,0 (a.k.a. Vista) and above.

Arx Libertatis 1.1 runs on WinXP, Arx Fatalis runs on WinXP (I am not sure if it even run on Win98 or NT 4) and the readme of Arx Libertatis 1.2 mentions WinXP. Is this particular function vital important for the Arx Libertatis 1.2?
Steps to reproduce this issue
Start the arx.exe again...

Comment posted by
 Daniel Scharrer
Jul 23, 15:19
It did work the last time I checked so something must have broken. We don't use any thread pool functions directly but it does look like the MSVC runtime uses it. You could try removing the vcruntime140.dll, msvcp140.dll and vcruntime140_1.dll files from the Arx Libertatis install and instead installing the latest Visual Studio Redistributable that is available for Windows XP and see if that works.

If it doesn't, then Arx Libertatis will need to be compiled with a different or older compiler for Windows XP support. I'm planning to switch to Clang for Windows builds anyway so maybe that will make it possible to target XP without giving up newer C++ features.
Comment posted by
 Guest user
Jul 27, 16:09
Thanks a lot for the help,

the msvcp140.dll was the problem, as I could trace with dependency walker. Removing the VS-libraries the system falls back to the allready installed 2017 version and the arx.exe runs, slipping right into the next issue:

Arx.exe does not recognize the 5 pak-files. The installer DID recognize the pak files so far. The original arx.exe (noe arx.exe.bak) also recognizes the files.

Renaming (only lower cases, directories without blanks) does not help. Moving the files does not help. Arguments to define the path or data-directory does not help, though the log shows arx.exe obeys to the arguments and searches only the defined directories.

How does the recognition work, by name or by checksum? Is there any registry entry to define the search path? Before I start to tamper with the reg, I better ask...
Comment posted by
 Daniel Scharrer
icon_reply.pngJul 30, 06:21, in reply to comment #6
The .pak files are recognized by name only. They are searched both in the location of the main arx.exe, in the directory specified in HKEY_CURRENT_USER\Software\ArxLibertatis\DataDir or HKEY_LOCAL_MACHINE\Software\ArxLibertatis\DataDir (the installer should have set this) and in the directory passed to the --data-dir option, as well as in the [ user directory.

What is the exact error you get? There should be an arx.log file under My Documents\My Games\Arx Libertatis.

Perhaps you are running the 32-bit arx.exe under 64-bit Windows and the .pak files are in a directory affected by filesystem redirection? I don't think we disable t hat yet since usually the 64-bit arx.exe is used on 64-bit Windows.
Comment posted by
 Guest user
Jul 30, 20:00
Thanks for keeping track...

I am using the good old fashioned (not to say antique) WinXP Win32.

The error in the logfile states, that ark.exe cannot find the five pak-files (all names are mentioned with the * wildcard e.g. speech.pak is "speech*.pak"). The search directories are also listed, that way I could check, if the app is obeying the arguments to narrow down the search. Arx.exe (i.e. Arx Lib) does also recognize the system correctly and puts the logfile into the right (typical WinXP) user-directory.

My first guess was, that the pak-files were somewhat altered (compromized, corrupted, not updated to arx 1.2, whatever) that the app could not recognize them by checksum. As arx-lib does not compare checksums, this theory has to be dropped.

My second guess concerns the Regkey pointing to the search directory. I thought there must be one, because the log only mentions relative paths and there is no entry in the config file. So far I could only find entries for arx fatalis. If the Arx Lib installer just failed to register the keys for Arx Lib the strange behaviour would be explained. Of course I installed under admin privileges.

I will check this out during WE and come with the results on monday. BTW, wasn't the registry editor renamed from "regedit" to "regsvr" between WinNT5 (XP) to WinNT6 (Vista)?
Comment posted by
 Guest user
Aug 02, 16:23
I Checked out the registry and could not find any key concerning Arx Libertatis whatsoever, especially at the two mentioned locations (HKEY_CURRENT_USER\Software\ArxLibertatis\DataDir or HKEY_LOCAL_MACHINE\Software\ArxLibertatis\DataDir). So the installer seems to fail the registration process. I am running on admin rights, so it is definitely no question of privileges. BTW I tried the installer of Arx Libertatis 1.1, which worked fine including the regkeys.

I tried to install those keys manually, which did not work out, though I don't know the exact designation of the argument containing the path. I tried HKEY_CURRENT_USER\Software\ArxLibertatis\ and DataDir as string with the path as value and DataDir as subkey. What is the exact registry entry?

The deinstall app also lacks an information about the install location and installed language.

BTW I found, that Arkane registers the language in words and Arx Fatalis 1.1 registers a numcode in a string.

The logfile states the complete and correct install path (pretty weird isn't it?). I could trace the text snippets back to the arx.exe in INSTALL_DIR\bin\x86, so this app must generate the logfile and this app must know exactly its own location. Obviously that app uses a different source of information, maybe the regkey HKEY_CURRENT_USER\Software\Arkane\?

I allready tried to copy the pak-files to other dirs, which should be coverd by the search, to see, if the game recognizes at least one of them, but it did not work out either. This is odd enough, because the path of the userdata on drive c: is determined from environment-vars not from regkeys, so the app MUST find any pak-file I place in C:\Documents and Settings\{username}\Documents\Mygames\Arx Fatalis\, unless this path should have been stored in a regkey as well. Maybe the missing regkey just hooks the search function (Which datatype has a missing regentry, NIL or empty string?), so it does not search at all.
Comment posted by
 Daniel Scharrer
Mar 27, 16:08
Please try the latest development snapshot and let me know if it works for you again.
Comment posted by
 Daniel Scharrer
Apr 02, 14:27
This should be fixed with the current development snapshots and in the upcoming 1.2.1 release - please let us know if you are still experiencing any issues with AL on Windows XP.

The issue was updated with the following change(s):
  • The custom field Fixed in has been updated, from Unknown to Arx Libertatis 1.2.1.
  • This issue has been closed
  • The status has been updated, from New to Fixed.
  • The resolution has been updated, from Not determined to RESOLVED.
  • This issue's progression has been updated to 100 percent completed.