Fix Northstar.dll not loading from non-ascii profile name

[Klemmbaustein]

Fixed an issue where a northstar dll wouldn't be loaded if the profile containing it had non-ascii characters in it's name.

I also removed an unnecessary scope and instead of dereferencing a null pointer when failing to load the LauncherMain function, the program returns 1.

[Klemmbaustein]

Some changes to the pr: it rewrote it to only use ansi strings instead of wide strings.
This makes the code a more consistent since the old code was using both ansi and wide strings in an inconsistent way.

[p0358]

Eh, just changing to -A APIs isn't really gonna fix things (it would on later OSs if Northstar opted into the UTF-8 support thing). I think it should be best kept to -W APIs, and common conversion helper util functions for charset conversions should be defined somewhere.

Also the stuff you put outside of code block was inside of it in order to minimize the unneeded inflation of stack size for the whole program lifetime. It'd be better to put some stuff that was above inside of it too, rather than removing it.

Not to mention the whole conversion could have been avoided in the first place if command line was also parsed with GetCommandLineW() instead :v

[Klemmbaustein]

Eh, just changing to -A APIs isn't really gonna fix things (it would on later OSs if Northstar opted into the UTF-8 support thing). I think it should be best kept to -W APIs, and common conversion helper util functions for charset conversions should be defined somewhere.

Also the stuff you put outside of code block was inside of it in order to minimize the unneeded inflation of stack size for the whole program lifetime. It'd be better to put some stuff that was above inside of it too, rather than removing it.

Not to mention the whole conversion could have been avoided in the first place if command line was also parsed with GetCommandLineW() instead :v

• The scope only contained a single bool, it didn't think that scope was necessary. Maybe we put the entire startup stuff into another function which returns the LauncherMain function pointer, then make the main function only call those two functions? I think this would be more readable.

• From my initial testing unicode characters with the -A functions seemed to work fine. however i just discovered that it doesn't work with japanese characters for example, so you're right.

[Klemmbaustein]

after some more testing: even if the launcher can deal with "more advanced" unicode characters in the game path (i tested japanese characters), at some point it crashes in northstar.dll

[p0358]

Maybe we put the entire startup stuff into another function which returns the LauncherMain function pointer, then make the main function only call those two functions? I think this would be more readable.

Yeah, this is exactly what I ended up doing in TFORevive, as the launcher code is based on its very old version originally (just that originally there were a bit more variables, including some buffers for paths, that are not here anymore). So I approve of that idea.

after some more testing: even if the launcher can deal with "more advanced" unicode characters in the game path (i tested japanese characters), at some point it crashes in northstar.dll

Hm, probably not everyone contributing code over time that dealt with paths considered this problem. I think having the game process opt into using UTF-8 could be worthwhile (this requires creating a .manifest file and passing it to the linker iirc), it'd only work in newer Windows 10's and up (on old ones it'd just work like before), but at least it'd ensure the game and all dependent libraries would work with those paths.

In such case it might be fine to use the -A APIs, provided we know it'd break the game itself either way otherwise...

It's worth to keep in mind though that std::filesystem::path uses wide strings internally on Windows though, so some conversions might sometimes be still unavoidable.

The manifest file would look like this (bonus point is that the process won't be faked into thinking it runs on Windows 8.1 by WinAPI with this):

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
  <application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
      <activeCodePage xmlns="http://schemas.microsoft.com/SMI/2019/WindowsSettings">UTF-8</activeCodePage>
    </windowsSettings>
  </application>
  <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
    <application>
      <!-- Windows 10 and Windows 11 -->
      <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
      <!-- Windows 8.1 -->
      <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
      <!-- Windows 8 -->
      <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
      <!-- Windows 7 -->
      <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
    </application>
  </compatibility>
</assembly>

[Klemmbaustein]

I ended up going with wstrings anyways, because:

1. I already made a functioning version with wstrings for testing
2. Even if it crashes in later either way, if we ever try to fix the issues with unicode characters in the game's path or profile name, having the launcher already support it is better than having it not.

I also put the initialization stuff in InitNorthstar, so the stack size is lower when the game is running without having that scope in the main function.