[cjakeman]

Aman Prajapati has been in touch, through the contact page on www.openrails.org, to announce his port of Open Rails. He has given permission to repeat the messages here:

I'm a developer from India and a big fan of Open Rails. I've built a working native macOS port of Open Rails that runs on Apple Silicon (ARM64) - without Wine or a virtual machine. As far as I can tell, this is the first native Mac build of the engine.

It's up and running with real routes and Indian Railways stock (I've tested KonkanIR with a WDG6G locomotive) at a smooth frame rate on an M-series Mac.

I wanted to reach out and share this with the team. You can see a video of it in action here WhatsApp Video 2026-07-09 at 17.44.38.mp4.

Thanks for building such a great project.

He also publishes the source:

Here is the Git repository with all the changes: https://github.com/A...5/OPEN-RAIL-MAC

It's the full Open Rails source with my macOS / Apple Silicon port committed on top (latest commits: "Native Apple Silicon (macOS) port of Open Rails" and a README explaining the build). You can diff this against the upstream openrails/openrails master to see exactly what changed - 113 files plus a few new macOS-compatibility shims.

If you want to contact Aman by email, send me a PM and I will give you his email address.

[gpz]

Of course he upgraded the project to net8 which we should have done years ago. (To get rid of the dotnet "Framework” version, I mean)

https://github.com/A...ivity.csproj#L3

[James Ross]

gpz, on 17 July 2026 - 11:21 AM, said:

Of course he upgraded the project to net8 which we should have done years ago. (To get rid of the dotnet "Framework” version, I mean)

We get complaints no matter what we do, but I agree that we shouldn't have a problem upgrading now that 1.6 is out and Windows 7 is over 6 years out of support.

Part of the problem is that modern .NET versions have weirdly restrictive Visual Studio compatibility, at least according to the official documentation. For example, .NET 8 is only supported on Visual Studio 2022*, which itself is only supported on Windows 10 1909+. That shouldn't be a problem, but we have a very diverse set of developer machines, and not all have been able to run VS 2022 when previously tested.

*I haven't check Visual Studio 2026 yet, but each .NET version from core 2.1 onwards has only had 1 officially supported Visual Studio version.

[James Ross]

Having checked, officially .NET 8/9/10 are only supported on Visual Studio 2026.

Visual Studio 2022 supports 6 and 7 and only a preview version of 8.

It is entirely possible other combinations work, but it seems nearly impossible to find out - the above is what is officially supported, though.

[cesarbl]

I guess using VS code with the C# extension could be an alternative to VS 2022?

I had a quick look at the port, and most of it is changing path delimiters, as well as implementing some features (such as .ini parsing) that are not available without Windows. It seems to target just RunActivity.exe (the Menu requires Windows Forms, that are not supported), but that's the core part of the simulator. I'll test it to check whether it works both on Linux and macOS.

Personally, I think it makes no sense to keep support for an insecure and proprietary OS (Windows 7) just because of privacy concerns. People interested in privacy can run OpenRails under Linux using Wine, with great performance. However, I was unable to run OR with an Apple Silicon device, so native support for macOS is great.

A more valid concern is supporting people with old PCs which are uneligible for W11. For them, if we migrate to newer .NET versions, we should provide an alternative e.g. by officially supporting Linux (maybe by including some installation instructions as in https://github.com/p...wiki/Linux-Wine ).

Another problem with UNIX-like OSes is that filesystems are typically case-sensitive, while MSTS content usually assumes that filesystem queries are case-insensitive. This forces the Content folder to live in an NTFS or EXT4+casefold partition.

[Rj Zondervan]

By chance I am working on a Linux port the same way as Aman did for macOS, and indeed just ran into the case sensitivity issue yesterday. It is not something that is impossible to bridge (in some cases using an AI model helps to find fixes for this), hardcoded backslashes have more impact (but also, not impossible to overcome).
I'll push to my fork shortly (it also contains a plan to get from a PoC status to something production ready, including a strategy on the forms).

When that fork reaches a workable Proof of Concept I'll also report back about installation/distribution strategies for Linux, because there are some flavours that can exist next to eachother, but target different kinds of Linux user.

[gpz]

Probably all the hardcoded backslashes can be simply replaced with forward slashes in the code. I think the C# file interface treats them identically.

Would it be possible that you create a PR from your fork so that the changes can be synced back?

[Rj Zondervan]

That's certainly the goal of what I'm doing. It might take some time, as said, I'm at the moment really in PoC country. Also before getting it up to scratch for general use there are some things to be discussed, so don't expect the PR to land anytime soon.

[trainGuy6550]

Looks promising... how did you make the DirectX shaders work on Mac?

Hopefully someone considers Linux too...

[ggwp]

Thanks everyone for the warm response and the detailed feedback!

@TrainGuy6550 — on the shaders: the DirectX HLSL isn't running directly. I compile the .fx shaders to MonoGame's OpenGL bytecode (.mgfx) with mgfxc using /Profile:OpenGL, so the DesktopGL (OpenGL) backend runs them. mgfxc itself still needs d3dcompiler, so I run just that one compile step through Wine as a build-time step (with a small MACGL define to skip a per-instance transform that came out wrong on DesktopGL). At runtime the engine is fully native — no Wine.

@gpz / @cesarbl / @Rj Zondervan — you're spot on: it's mostly path delimiters (everything routed through Path.DirectorySeparatorChar), a small .ini reader, DXT decompression, and case-sensitivity handled via a FileSystemCompat helper. It currently targets RunActivity — the Menu still uses Windows Forms, so that's the main remaining piece (Eto.Forms looks like a good cross-platform route). The Windows build path is untouched: the net8 target is gated behind a MacBuild flag, everything else stays net6-windows / net472. So this should be very close to a Linux port too — glad to compare notes, Rj.

@gpz — yes, I'd be glad to open a PR (or a few smaller, focused PRs) so the changes can be reviewed and synced back. Just point me at the preferred target branch and I'll follow the contribution guidelines.

Happy to help push Open Rails toward proper cross-platform support.

— Aman Prajapati (India)

[James Ross]

First of all, it's really exciting to see all this interest in cross-platform portability!

ORMT have agreed to migrate to .NET 6 right now (I'll be doing all the PRs), as we already have that in the project files as an opt-in test. We will evaluate newer versions but Visual Studio compatibility remains a concern that will have to be tested.

cesarbl, on 18 July 2026 - 01:05 AM, said:

I guess using VS code with the C# extension could be an alternative to VS 2022?

Yeah, perhaps. We can test Visual Studio 2026 with .NET 6 (not listed as supported) soon.

cesarbl, on 18 July 2026 - 01:05 AM, said:

A more valid concern is supporting people with old PCs which are uneligible for W11. For them, if we migrate to newer .NET versions, we should provide an alternative e.g. by officially supporting Linux (maybe by including some installation instructions as in https://github.com/p...wiki/Linux-Wine ).

Rj Zondervan, on 18 July 2026 - 02:51 AM, said:

When that fork reaches a workable Proof of Concept I'll also report back about installation/distribution strategies for Linux, because there are some flavours that can exist next to eachother, but target different kinds of Linux user.

Officially supporting Linux or macOS is not very likely in the near term, however, we are happy to accept fixes to the code which make it work more portably. This includes more significant changes, as long as they apply cross-platform without negative effect on Windows.

cesarbl, on 18 July 2026 - 01:05 AM, said:

Another problem with UNIX-like OSes is that filesystems are typically case-sensitive, while MSTS content usually assumes that filesystem queries are case-insensitive. This forces the Content folder to live in an NTFS or EXT4+casefold partition.

Rj Zondervan, on 18 July 2026 - 02:51 AM, said:

By chance I am working on a Linux port the same way as Aman did for macOS, and indeed just ran into the case sensitivity issue yesterday. It is not something that is impossible to bridge (in some cases using an AI model helps to find fixes for this), hardcoded backslashes have more impact (but also, not impossible to overcome).

Filename case sensitivity is definitely an area of concern for portability. We are happy to accept fixes that preserve filename case inside Open Rails but would need to also maintain case-insensitivity for many internal systems e.g. loading deduplication of textures/models.

However, if content itself refers to a file with a different case to the actual file, we will have to carefully evaluate any solutions to this, as we don't want to worsen performance on Windows.

Rj Zondervan, on 18 July 2026 - 02:51 AM, said:

I'll push to my fork shortly (it also contains a plan to get from a PoC status to something production ready, including a strategy on the forms).

We should start a new thread for discussing any cross-platform work on the menu, before anyone starts any significant work.

That said, Eto.Forms, as mentioned by Aman already, has been my preferred option if we were to keep the Windows.Forms style of menu.

ggwp, on 18 July 2026 - 11:12 AM, said:

@TrainGuy6550 — on the shaders: the DirectX HLSL isn't running directly. I compile the .fx shaders to MonoGame's OpenGL bytecode (.mgfx) with mgfxc using /Profile:OpenGL, so the DesktopGL (OpenGL) backend runs them. mgfxc itself still needs d3dcompiler, so I run just that one compile step through Wine as a build-time step (with a small MACGL define to skip a per-instance transform that came out wrong on DesktopGL). At runtime the engine is fully native — no Wine.

Curious what is going on with that transform, but I expect we would be happy to switch everything to the DesktopGL runtime, provided Windows performance doesn't suffer.

We should also be able to avoid #if for platform-specific code in .NET 6+, as any platform-specific code can use the OperatingSystem class instead, although we would want to minimise that too. The less platform-specific code the better.

ggwp, on 18 July 2026 - 11:12 AM, said:

@gpz — yes, I'd be glad to open a PR (or a few smaller, focused PRs) so the changes can be reviewed and synced back. Just point me at the preferred target branch and I'll follow the contribution guidelines.

Smaller, focused PRs are preferable. Please target the default branch "master".

We have full contributing guidelines; specifically this is a "feature" but don't worry too much about the list of requirements for those: we've got them all covered already (this thread + Cross-platform portability/support for Linux/macOS Trello card). Just put a link to this thread and that Trello card into the description of each PR and we're good on the process.

[pschlik]

James Ross, on 19 July 2026 - 07:57 AM, said:

Filename case sensitivity is definitely an area of concern for portability. We are happy to accept fixes that preserve filename case inside Open Rails but would need to also maintain case-insensitivity for many internal systems e.g. loading deduplication of textures/models.

However, if content itself refers to a file with a different case to the actual file, we will have to carefully evaluate any solutions to this, as we don't want to worsen performance on Windows.

One of the most common inconsistencies with capitalization I've seen is the MSTS content folders. I know traditionally it's "TRAINS" and "GLOBAL" and so on, but I've definitely seen packages where you get folder names that aren't all uppercase. Getting that wrong means you can't even load a route, much more troublesome than just a missing texture. And should some workaround be made to handle folders with different case, a lot of parts of the program have the case of these folders defined as literal local variables instead of some global session variable and they rely on the assumption the case doesn't actually matter. Lots of potential for trouble.

[cesarbl]

I don't think we should bother with case-sensitivity at the moment. The user should either ensure that case is consistent in their content, or use a filesystem with case-folding support (e.g. EXT4 or NTFS). We just need to ensure that OR code is consistent (e.g. file names in the Content/ folder have the same case in the code). Adding case-folding support to OR would require that, whenever a file open fails, we have to recursively check all files to find a match, which is very inefficient (but in principle it could be disabled on Windows). Nevertheless, it's better to leave that to the filesystem. At some point, Wine was implementing that and OR performance was terrible, and I had to enable filesystem case-folding.

Instead of ensuring case consistency, TSRE always looks for lowercase filenames (and thus forces you to convert all your files to lowercase), which is incompatible with the consistent-case approach. Thus, restricting the filesystems seems the most convenient way.

[dajones]

There are lots of cases where the file name case in content doesn't match the actual filename and it isn't really possible for the user to fix them all. For example there are shape file names in the global tsection.dat that don't match the actual file. And there shape files that refer to image files that don't match.

And the problem isn't limited to file names. The six MSTS routes use mixed case directory names, like Shapes, but most add-on routes use upper case, like SHAPES. Some equipment models have Sound directories, others have SOUND, and some don't have either.

There are also a lot of relative paths instead of file names. These can contain forward-slash or back-slash. And relative paths often contain .. which appears to work differently on Windows vs Linux. On Windows "Sound/.." appears to always work, but on Linux this only works if Sound exists.

My preferred way to handle all of these issues is to try opening the file with the provided name, and try fixing the file name only if the open fails. This way there is no performance impact unless there is a mismatch. I usually try to fix the route directory names once, but less common directory name issues I fix with a recursive call.

Doug

[eric from trainsim]

cesarbl, on 19 July 2026 - 10:15 AM, said:

Instead of ensuring case consistency, TSRE always looks for lowercase filenames (and thus forces you to convert all your files to lowercase), which is incompatible with the consistent-case approach. Thus, restricting the filesystems seems the most convenient way.

Not so sure you're correct about forcing.

TSRE usually does an internal/in-memory conversion of user inputs, variables in settings files, etc. into lower case because it's more consistent for doing evaluations and slightly safer for file read/write operations.

But last I checked, it doesn't force you to convert a single thing. Or at least... v8.x onward doesn't. I won't pretend to speak for Goku's versions or other forks.

Given a preference, I'd push for case neutrality and put hooks into the code to apply it. I know it might create problems for non-Windows users, but let's be realistic -- the vast majority of users aren't using a case-sensitive file structure or OS.