Linux support

[Sharparam]

This issue is a bit less of an issue/request and more to document what I found.

From the limited testing I've done this seems to work in Linux already (I can open my save file and the analysis seems to show the correct stuff from what I can tell).

In the code I see there are a couple of native methods from user32 though, which I imagine would not work under Linux, they never seem to actually get called under Linux though.

They seem to be used to prevent multiple instances from running at once, and this check fails under Linux. I'm able to have multiple instances of the app running.

Ideally this check would use something that is cross-platform, or failing that, checking at runtime to use different solutions based on the platform. It's a very minor issue though.

What I did to make a package I can run on my Linux (Arch) environment:

dotnet publish --use-current-runtime --no-self-contained -p:PublishSingleFile=true

This should produce the following files under RemnantOverseer/bin/Release/net8.0/linux-x64/publish:

libHarfBuzzSharp.so
libSkiaSharp.so
RemnantOverseer

(Assuming you run it on a 64-bit Linux system.)

[Angelore]

They seem to be used to prevent multiple instances from running at once, and this check fails under Linux. I'm able to have multiple instances of the app running.

That is correct. These are calls to PostMessage, RegisterWindowMessage, and mutex.
This is not a critical feature, more like a nice to have. I could even package a Linux build myself, but since I'm not running Linux, I would not be able to test it.

[Sharparam]

Easiest would probably be to have a condition that just doesn't call those methods. Although I'm a bit confused why it's not crashing under Linux since it should be trying to at least call RegisterWindowMessage. (Unless JIT magic sees that nothing in NativeMethods is getting called and the static field doesn't initialize?)

[GeorgeV220]

I made some changes to run the project on Linux, but I haven't tested them on Windows yet. You can check out the changes here.

Changes:

• Removed the NativeMethods class.
• Replaced the instance check with TCP-based communication.

I’m also considering using .sock files for the instance check, but I’m not sure if they work well with Windows. If anyone has experience with .sock files on Windows or can offer advice on implementing them, I’d appreciate the help!
I can open a PR if you want to merge those changes or you can cherry-pick them manually.

[AndrewSav]

I'm not sure what .sock files are but by the sound of it is very unlikely to work on windows as in it is almost certainly won't work. My personal preference would be not to use TCP for the app that does not rely on networking for the main functionality.

[GeorgeV220]

I'm not sure what .sock files are but by the sound of it is very unlikely to work on windows as in it is almost certainly won't work. My personal preference would be not to use TCP for the app that does not rely on networking for the main functionality.

Yeah, .sock files (Unix domain sockets) are great on Linux, but you're right... they're not really practical on Windows. That's actually why I went with TCP on the loopback interface (127.0.0.1). It works reliably across platforms and doesn’t depend on the actual network being up it just stays local to the machine.
I'm only using it to check if another instance is running, so it's lightweight and doesn’t add network complexity. Plus, it avoids the issue of leftover .lock files if the app crashes.
That said, other options like named pipes or even memory-mapped files could work too, but they tend to be more platform-specific or a bit more complicated to set up cleanly across different OSes. TCP over loopback felt like the simplest and most portable solution for my case.

[Angelore]

I am not sure why using network interface to check for instances is necessary. NativeMethods Are there to provide a way for the main window to pop up when another instance is attempting to start. The check itself is being done via Mutex, and from my understanding it should work just fine in Linux.

[GeorgeV220]

I am not sure why using network interface to check for instances is necessary. NativeMethods Are there to provide a way for the main window to pop up when another instance is attempting to start. The check itself is being done via Mutex, and from my understanding it should work just fine in Linux.

Yeah, you're totally right that on Windows, the Mutex plus PostMessage setup works fine, it blocks extra instances and brings the window up, no problem.
But on Linux, that same mutex doesn’t actually work like you'd expect. Even though it's "named," .NET doesn’t create a system-wide mutex on Linux, so multiple instances just launch like nothing happened. I ran into that firsthand during testing, it just didn’t stop anything (I might did something wrong idk).
At the time, I used TCP because it was the method I was most familiar with and I needed something that actually worked cross-platform. I totally get that using TCP on localhost for a local app feels a bit dirty, and yeah, there’s really no good reason for a desktop app to open up a TCP listener just to talk to itself.
My plan is to swap it out for named pipes, which are a much better fit for this kind of local IPC. Just needed something functional to get it working.

[Angelore]

But on Linux, that same mutex doesn’t actually work like you'd expect. Even though it's "named," .NET doesn’t create a system-wide mutex on Linux, so multiple instances just launch like nothing happened.

Huh, that is very interesting. Will need to read up on it.

[AndrewSav]

The mutex seems to work fine on linux in .net 9.0 if you use the "Global\" prefix.

Code:

using var mutex = new Mutex(false, @"Global\TestMutex");
if (mutex.WaitOne(0, false)) {
    Console.WriteLine("Mutex aquired");
} else {
    Console.WriteLine("Mutex not aquired");
}
Console.WriteLine("Press any key to continue");
Console.ReadKey();

This is contrary to what the SO question says, but I'm assuming this is down to .net version

[GeorgeV220]

The mutex seems to work fine on linux in .net 9.0 if you use the "Global" prefix.

Oh my God, you're right. It even works in .NET 8. I had been searching online and kept seeing that named mutexes don't work, so I didn't test it with the 'Global' prefix. Thank you for the info. Microsoft DOCS are a little confusing if you have a link so I can read more please send it over!!

[AndrewSav]

@benaryorg what's missing in your opinion for a proper Linux support, with the experience you gained with the project recently?

[benaryorg]

what's missing in your opinion for a proper Linux support, with the experience you gained with the project recently?

TL;DR: nothing really, it works for me, and I feel like it's more than just usable on Linux already.

I'm going to nitpick a little here, just to get all of the tiny things I have in mind out, even though some of them are so minor or edge-casey that if I was maintaining the project, I don't think I'd bother.

This Thread

To be completely honest, I'm not a fan of single-instance applications myself¹, so I didn't really bother to check how it behaves there.
So I just don't really have anything to add to that specific part.

CPU Usage

The CPU usage seems a bit high, almost as if the file watcher had to fall back to a spinloop or something.
I'm not saying that's the cause (or that it's happening at all), just to give you some idea of how it feels.
It could also be something in the UI that keeps re-rendering for some reason, or it may just be my specific setup, and I'm not even sure it's Linux-related.
Eating about a half a core (a single core, so for a 4c/8t CPU it'd be about a 16th of the total CPU) just seems a bit odd, and on weaker systems may lead to slight performance degradation in Remnant while playing.

UI Refreshes

Whenever the savegame is updated the entire view refreshes resetting any scroll position for example.
This is a bit annoying when you're still lacking a lot of items and have scrolled down to the one that interests you, and suddenly it jumps back up because you touched a world stone.
Also probably not Linux specific.
I meant to look into that myself but I'm out of spoons at the moment (and have more pressing matters for when I do *sigh*), because my idea was that maybe the UI could always have all the elements in it, but only have them visible when the filter applies, that way it would just be a property change of sorts rather than a full UI re-render (if that makes sense, also I'm not sure it'd work).
Basically the equivalent of having a bunch of <div>s in HTML and only setting their style=display:none to hide them, instead of recreating the entire DOM.
It could also just be something about my system specifically causing it, I'm not sure.

Thaen Tree Popup

The first one is very likely general for all platforms: I would love to be able to close the Thaen tree hint using Escape, that's all.

The second is how the popup is handled in general, and that may not be specific to Linux but specific to how my window manager (awesomewm) is configured, and it may be some obscure flag that needs to be set, I dunno.
The gist is that I'm using workspaces (which I hear Windows has too nowadays?), and R2O sits on one of them.
When I open the Thaen tree hint, the popup is set to be "always on top", which I guess is fine, but if there is such a thing I'd prefer if it was only on top of the main window and not on top of everything.
Furthermore, the popup somehow manages to set itself to be visible on all workspaces, I didn't even know that was possible.
If you look at the docs for the UI and instantly see a single flag that can be set to make it a bit less.… attention seeking? ^^", that'd be great, but if you don't find anything right away, then it's probably not worth looking too deep into it.

Changelog

This is where I get super nit-picky, feel free to skip this.

I really like the changelog you write up in every GitHub release, it's nice to see the changes.
However it'd be cool if it was part of the repo and not just "metadata" of sorts.
One concrete benefit of it would be that if it was reverse-chronologically, you can keep a "next" section on top that PRs or changes that change something worthy of mentioning can just add to it when they're made, and on a version bump you just rename the headline to the version and create a new "next" headline.
So if something big is changed via a PR you can just go "could you add an entry in the changelog for that please?" and you can be sure that you haven't forgotten anything on release.

What's that got to do with Linux?
A lot of distros (Debian, Gentoo,.… actually most of them I think) copy over the changelog into the package.
This is useful for people who just install the app via some package manager (possibly just a UI "Software Centre") and who don't know about the repo at all.
They see "oh, things are different" and go read /usr/share/remnant-two-overseer/NEWS or something and have the changelog.
It's just a minor nit that is nice for packaging, but that most people probably won't ever notice, so the only reason I mention it is because of the workflow benefits detailed above.

Note: NEWS is just the name that GNU usually uses, just calling it changelog.md is fine.

Linux Binary

Just like you're adding a Windows build to every release via the GitHub stuff, a Linux build would be cool too.
The "usual" format for binaries downloaded by users without a package manager is an AppImage which is basically just all dependencies bundled into a single file that somehow (Magic™²) runs itself.
As listed in the (now edited) OP of #24, I'm already building AppImage files in my CI.
Largely so my friends who're also on Linux can just download and use it, since they use Arch btw, so they can't use my personal packaging which is NixOS specific.
There is an upstream guide to bundling an AppImage, and actions are readily available for both building a dotnet app as well as packaging something into an AppImage out of the box.
I'm not too familiar with GitHub actions so I'd probably just force-push to master in a fork until it works anyway.
The whole thing could however also serve as a general CI pipeline that shows up in PRs to show whether or not it still builds.
There are also actions to automatically create a release (unmaintained but links to active ones), so maybe even the release notes could be auto-copied there.
Just throwing in some ideas.

---

That's really all that comes to mind, but as stated at the beginning, I think it's fine as-is.
The Linux Binary one would be cool if you intend to officially support it.

And if anyone has read this far without skipping anything, I'll buy you dinner should we ever meet.

Once again, thanks everybody for working on this amazing tool!

Footnotes

1. I'm from the "my computer ought to do what I tell it to" camp, so if I tell it to make a mistake (opening the same app twice for no reason) I want it to let me make that mistake.
   I understand the idea and I'm not opposed to it though, it's just that I could care less. ↩

2. not really magic (duh), it's a bit complex but also kind of amazing, but definitely off-topic here ↩

[AndrewSav]

I create a PR that is intended to close this issue. Everyone is invited to review and comment on it.