Support us on Patreon to keep GamingOnLinux alive. This ensures all of our main content remains free for everyone. Just good, fresh content! Alternatively, you can donate through PayPal. You can also buy games using our partner links for GOG and Humble Store.
We do often include affiliate links to earn us some pennies. See more here.
I posed a question on Twitter recently where I asked developers to jump in with thoughts on essential things to know about when bringing a game to Linux. Let’s look over some answers!

In this article I will go over a few useful answers, giving full credit to the person who sent it in with a link to the tweet they sent to us. I will then give my own thoughts on each point, with any relevant links to help. There's likely hundreds of things we could point up, but these are what I consider to be some of the more common and important issues to keep in mind.

Some of the answers made me laugh, let’s start off with a good old joke about Arch Linux (source):
QuoteIf you are getting completely impossible and weird bugs that is almost impossible to reproduce, check if they are running Arch Linux…

I enjoy a good poke about distributions here and there, but it’s actually very true. Of all the distributions there are, Arch does end up being the most problematic. That's not saying Arch is bad, but being on the edge (it gets newer software faster than most other distributions) obviously increases the amount of issues that are likely to come up, since it's had less time in the oven to work out issues.

Test on Ubuntu and if you can, SteamOS too. If it doesn't work on other distributions, they likely have workarounds as they are likely doing something different. Do not feel the need to test every distribution around, it will be impossible and it's just not needed, don't overthink it. Don't be afraid to limit support to the main bigger distributions either. Some people may not like the idea, but it's too much work for little gain most of the time. Support the big distributions, forget the rest (at least until you're much more familiar with Linux).

One from David Gow (source):
QuoteUse SDL2. Or use something which itself uses SDL. Under no circumstances write X11 code directly.

It doesn't necessarily need to be SDL2, there's also SFML and likely others. The point is, projects like that can make your life a lot easier. You might be wanting to keep everything small, but these projects are bigger for a reason, as they cover tons of edge cases and nuisances you likely haven't even thought of.

There's a reason why Valve, Feral Interactive, Humble Indie Bundle and many others use SDL2 for the Linux ports. Heck, even the Unity game engine moved over to use SDL2 in Unity 5.6.

This next one comes from none other than Timothee Bessett, formerly of id Software (source):
QuotePlayers want you to succeed with your Linux release. Get them involved, for instance have them test stuff up for you.

I think this is an important point for any developer to remember. Linux users want your game to do well, we will often help you test for free, because we want to help. Any time I’ve seen a developer call for Linux testers, they end up getting overwhelmed with the amount of people willing to offer their free time to help out. Opening up a private beta to a few select people is always an option too, there's many ways to get users involved early.

However, this is not a replacement for your own testing! Linux is free to download and use forever, it can be installed by itself or along side Windows & Mac. You can install it inside a virtual machine too if you want to just give it a look over.

This little tidbit comes from Holarse Linux-Gaming, our German friends (source):
QuoteFor your files and savegames there is XDG (like %approot% on windows

This in particular is something I’m keen for developers to know about. Please, for the love of my sanity, don’t put a plain folder of “Game Name” inside my home directory. If you want to know where to store config files and saved games, you can find more info here.

As an example, Unity games tend to be in /home/user/.config/unity3d. Notice the dot before “config”, it’s a hidden directory so it doesn’t pollute a user's home directory and fill it to the brim with random folders.

Another one from Holarse Linux-Gaming (source):
QuoteYes linux filesystems ARE case sensitive

You likely know what this means, but in case you don't: "This" is not the same as "THIS" when it comes to filenames on Linux. A crash in a game that's absolutely bugging you? Check you're looking for the right filename. This single issue has tripped up a lot of developers I've personally spoken to.

Let’s break things up with another amusing one, this time from a Feral Interactive developer (source):
QuoteSomeone WILL play your game on their work render farm, and report the bugs [..] I'd be lying if I said this had only happened once. 128 cores!? 1TB RAM!?

I would be lying if I said this didn’t make me laugh quite a lot. You think some bug reports you got from Windows were weird enough? Prepare yourself.

The same Feral Interactive developer also put forward probably one of the most important points possible (source):
QuoteUse cross compatible tools whenever and where ever, anything can turn into a crutch when you try and port

The amount of times we’ve seen developers announce a Linux port, be it on Steam’s old Greenlight platform, Kickstarter or wherever else, only to announce much later they can’t do it due to something they use being Windows-only is quite staggering. Check early and often that the tools, middleware and whatever else will be able to work somehow on Linux. Don't get stuck in the professionally embarrassing position where you have to u-turn on platform support.

Asking for help is not embarrassing and should not be seen as any kind of weakness, if you put out a call for help finding replacements or getting something to work on Linux, you might be surprised to find people able to help out quite often. I've seen hundreds of developers chatting away on Twitter, Reddit and other sites giving out help and advice about Linux issues.

Another one from a Feral developer (source):
Quoteembrace the shell, the sooner the better. The last thing you want 2 hours before release is to be fumbling around learning bash

The amount of times I've seen developers put up builds where they talk about knowing nothing about Linux: how do you expect to fix bugs in it, if you don't know the first thing about the platform? A little early research and testing will go a long way. The terminal might seem a little scary at first, but from someone who doesn't consider himself even remotely smart: just do it! Learn it and you might find a new friend. Still scared? This site might help you with the basics of the Linux command line.

If you plan to release your game outside of Steam and you want to use a handy installer, take a look at MojoSetup. GOG, the well known game store actually use this for their Linux releases.

An important point I would like to also raise: don't expect Linux sales to make you rich. It's a smaller platform. Bringing a game to Linux isn't just about getting sales from the additional platform, you should also keep in mind all of us likely know people on Windows & Mac we will end up recommending the game to, especially if it has any form of multiplayer. The extra advertising through various Linux websites and the extra word of mouth can be useful.

If you're wondering whether you need to make a 32bit build of your game, in my honest opinion you don't need to bother. 64bit only is fine especially since our own statistics tell us out of 1921 people who answered about their distribution, only 1 person is on a 32bit distribution.

Also, please don't take loud and idiotic users to heart. All communities will have trolls and haters, please do ignore any you find.

If you're trying to port to Linux and you're stuck, don't fret! Take a breath, come have a chat. We have a Forum, our Email inbox is always open, we have an IRC channel, Discord and more.

Finally, if you are considering bringing your game to Linux — thank you, can't wait to try it!

Please do share any other general tips you have in the comments. Article taken from GamingOnLinux.com.
Tags: Editorial
51 Likes
About the author -
author picture
I am the owner of GamingOnLinux. After discovering Linux back in the days of Mandrake in 2003, I constantly checked on the progress of Linux until Ubuntu appeared on the scene and it helped me to really love it. You can reach me easily by emailing GamingOnLinux directly. You can also follow my personal adventures on Bluesky.
See more from me
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
60 comments Subscribe
Page: «2/3»
  Go to:

Maweki 4 Jul 2017
I am German and there are a lot of games that have a problem with comma being the decimal point in my locale. Often enough, even recent Unity games, save floating point data locale independent and parse them locale dependent, leading to crashes, bugs, and corrupted saves.

It's easy enough. Just use Double.Parse with the current locale as separate parameter. It's not magic. I think I've added LC=C_ALL as a environment variable to about half of all Steam games I play.
These days it might also be worth looking into those Snap or Flatpak thingies. Extra fiddling maybe, but near as I understand it could buy you quite a bit of distribution-agnostic-ness.
Snap isn't that good yet. Maybe on Ubuntu it just works but on Debian I only got the CLI apps working. As I understood it, the snap developers have to hardcode NVIDIA driver paths in the framework and I use the binary non-repo driver. So OpenGL doesn't work and at least Krita couldn't run.
Ah. Well, maybe in a couple of years. Too many useful things always seem to be maybe in a couple of years.
natewardawg 4 Jul 2017
My advice would be... Test on a dual screen setup.

If you're using Unity you can check the boxes "Default is Fullscreen" and "Default is Native Resolution" from the "Player Settings" under "Resolution and Presentation". If you don't want to test for resolutions then please at the very least set the "Display Resolution Dialog" to "Enabled".
brandleesee 4 Jul 2017
While it's annoying, I found one relatively simple workaround. Run such games with:

HOME=$HOME/.local/share

Then all that clutter will move to more appropriate location.
Good find! Redefining HOME could be used for many things, it's a cheap "user isolation/virtualization" technology, like chroot but for data. You can add any number of "profiles" in terms of settings/accounts/data to any app, even if it doesn't directly support it.

Hello, could I please ask how to implement that code? Is it in bashrc? Thank you.
Philadelphus 4 Jul 2017
If you're wondering whether you need to make a 32bit build of your game, in my honest opinion you don't need to bother.
Serious question, are there actually that many 64-bit executable games out there and is it actually beneficial?

I ask because the subject comes up regularly on the Paradox forum with people bemoaning the fact that the Clausewitz engine is 32-bit only and predicting massive performance improvements if it were only 64-bit, only for a developer to explain that making the engine 64-bit would change basically nothing about performance (other than allowing the use of more than 4GB of mods together, which is kind of a niche case) and that they have no plans to rewrite the engine.

There may very well be good reasons for making games 64-bit and I've love to hear them, it's just that I tend to see 64-bit thrown around as a bit of a buzz-word.
Shmerl 4 Jul 2017
Serious question, are there actually that many 64-bit executable games out there and is it actually beneficial?

I ask because the subject comes up regularly on the Paradox forum with people bemoaning the fact that the Clausewitz engine is 32-bit only and predicting massive performance improvements if it were only 64-bit, only for a developer to explain that making the engine 64-bit would change basically nothing about performance (other than allowing the use of more than 4GB of mods together, which is kind of a niche case) and that they have no plans to rewrite the engine.

There may very well be good reasons for making games 64-bit and I've love to hear them, it's just that I tend to see 64-bit thrown around as a bit of a buzz-word.

Paradox should unstick their head from the sand, and fix the engine. I suspect their general neglect to make their tools 64-bit compatible, forced Obsidian to release Tyranny in 32-bit only (because it used Paradox account integration libraries). It created the expected mess of lacking LFS and crashes on large XFS partitions. The bottom line - no excuses. 64-bit is a must today. (Luckily Obsidian finally released 64-bit version of Tyranny this June).

Some engines have a lot of work to make them 64-bit, and understandably it can take time. But not doing it at all with excuse that performance is OK as is, is just silly. Beamdog for the reference reworked their current generation of Inifinty engine to 64-bit.


Last edited by Shmerl on 4 Jul 2017 at 9:04 pm UTC
Shmerl 4 Jul 2017
While it's annoying, I found one relatively simple workaround. Run such games with:

HOME=$HOME/.local/share

Then all that clutter will move to more appropriate location.

Hello, could I please ask how to implement that code? Is it in bashrc? Thank you.

No! Don't put this into .bashrc that will royally mess up your session. Put it into some script from which you can launch the game. In the script, add:

export HOME=$HOME/.local/share

Or if you want, add this to the .desktop launcher for it. I.e. let's say the game binary is /path/game_bin

So, the launcher would normally have something like:

Exec=/path/game_bin

And you can change it to (use full correct path, otherwise it won't work):

Exec=env HOME=/home/<your_user>/.local/share /path/game_biun

and etc.


Last edited by Shmerl on 4 Jul 2017 at 9:47 pm UTC
1xok 4 Jul 2017
  • Supporter Plus
Developers, Developers, Developers ...

https://www.youtube.com/watch?v=KMU0tzLwhbE



Dear Developers,

just come to Linux.

;)
ODDity 4 Jul 2017
Great talk from Steam Dev days conference 2014 here..

www.youtube.com/watch?v=Sd8ie5R4CVE

Tools, porting, flow, solutions.
natewardawg 4 Jul 2017
Serious question, are there actually that many 64-bit executable games out there and is it actually beneficial?

I don't believe the argument is really one of how much benefit 64 bit has over 32 bit. Rather, it's an argument of how beneficial is it to ship both 64 bit and 32 bit builds. If you're writing your own engine from scratch, it's quite a waste of time to make sure it's 32 bit compatible on Linux, just make it 64 bit. If you're building a game using a pre-built engine like Unity, Unreal, etc. then you will gain benefits from making 64 bit builds like wider vectors for SIMD instructions and more available memory for your game and won't really gain anything from 32 bit builds.

I would also argue that if there's a rare case where it's easier for a company to make only 32 bit builds why would they waste any time on 64 bit. I can't imagine too many circumstances where this would be the case, but I'm sure it's come up somewhere.

In a nutshell, the point is time and money. 32 bit builds in almost every case are a waste of both time and money. The game we're building right now we've actually cut out 32 bit builds on even Windows due to memory constraints since our game is very heavy on UGC (User Generated Content). I don't feel too bad about cutting out 5% of the market. It really is time to move on from 32 bit :)
denyasis 4 Jul 2017
Make Bug reporting easy. While you can assume most linxers are technically savy and like solving computer related problems, not everyone is at the same level in expertise or ability (or free time). I had one game website that simply said, if you have a bug submit it and the log file here (insert link to their tracker). No indication on what the file's name was, location, etc.

You don't need anything fancy like a log file uploader or anything like that, just some simple, specific directions of what you'd like us to provide. Help us help you!
Duke Takeshi 5 Jul 2017
Nice article liam!

Actually I personally never had any arch-only problems on my system yet. Having switched from ubuntu to antergos, I'm very surprised how smooth the user experience is, also concerning gaming. Until now I never had problems with a single game, and if there was some bug, I found that people running ubuntu have it as well.

The AUR is also a good thing for workarounds since you can install additional packages easily without having to build them yourself.
STiAT 5 Jul 2017
I best liked the "someone will play it in the work render farm" :D.
I was often thinking on trying that one actually XD.
fractilegames 5 Jul 2017
It's actually ABI forward compatible, not backward. See [https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html](https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html)
I always mistake forward/backward compatibility, it depends on the point of view, probably that's why. Yes, this seems impossible to solve once and for all. Either your game doesn't work because the system library is too old or the rest of the system (that's required for the game to run) doesn't work because you shipped a library too old now. The only solution is to constantly update the libs and ship them ASAP with the game binary or just don't use the modern C++ features and stick to stone ages of GCC 4.

Why do devs ship libstdc++ with their games at all? I build my games against "old enough" libstdc++ version, so it should work in any distribution that has the same or later version of that lib. At least I haven't received reports of any issues regarding libstdc++ for a long time.
Klaus 5 Jul 2017
For your files and savegames there is XDG (like %approot% on windows

Some nitpicking first: I assume you mean %APPDATA% and %LOCALAPPDATA%? I mention it because I actually tried to google it and found no Desktop-Windows results for it.

Regardless of the detail, I find %APPDATA% to be an AWFUL location for save-games on Windows. I can't comment on ~/.config, but on Windows %APPDATA% and %LOCALAPPDATA% are directories you typically don't want in your private incremental backups. For backups you have a few choices for these, all of which are bad:
  • Full backup. Will include possibly gigabytes of fast-changing cache files and tens of thousands of not-backup-worthy configuration files, slowing down the backup process and bloating the size of incremental backups. Additionally, much of it is system-installation-dependent and cannot be easily restored after a reinstall without messing anything up.
    On Windows specifically there are also many files that will typically be in use during a weekly incremental backup (e.g. database files of the Chrome, Firefox or Evernote) and will be either locked against read-access or in an inconsistent state.

  • Manually include the savegame folders. Good chance not missing one. Also, a major annoyance as it requires looking up the savegame location for each newly installed game.

  • Manually exclude cache files and other problematic files. Good chance... You get the point.



So no, please don't use the an eqivalent of %APPDATA% for savegames. They are essentially user documents which a user might want to back up or synchronize locally or through the cloud.

On Windows of course this is just as much a problem. Many games now put save games into ~/My Games or ~/Documents/My Games. These two conventions make sense and don't create clutter, but sadly recently some games also put DLCs, mods, cache files or machine-dependent configuration files there, which makes absolutely NO sense.

Of course there are also still programs that try putting their savegames into the game installation directory (DOS convention), which will lead to major frustrations when users uninstall a game and reinstall it later on a new device or after reinstalling the OS, only to find that their savegames have been destroyed in the process.

An important point I would like to also raise: don't expect Linux sales to make you rich. It's a smaller platform. Bringing a game to Linux isn't just about getting sales from the additional platform, you should also keep in mind all of us likely know people on Windows & Mac we will end up recommending the game to, especially if it has any form of multiplayer. The extra advertising through various Linux websites and the extra word of mouth can be useful.

I'm an example here; For sevaral reasons (gaming among them) Windows won out as my everyday work-and-freetime platform, but Linux-gaming articles still make an interesting source for games to give a look :)
gojul 5 Jul 2017
STASIS is suffering from this right now. The engine needs newer libstdc++.so.6 than provided in SteamOS so it doesn't start there. So another advice: check your dependencies on older distros if possible and either ship the libs with the game or link them statically if you can.

I confirm this point : statically linking the game so that it does not have any dependency out of the steam environment is mandatory to me, as even with Debian (which is the basis of both SteamOS and Ubuntu) there are problems from time to time, even though they're frankly rare (maybe one or two games gave me issues).
gojul 5 Jul 2017
I am German and there are a lot of games that have a problem with comma being the decimal point in my locale. Often enough, even recent Unity games, save floating point data locale independent and parse them locale dependent, leading to crashes, bugs, and corrupted saves.

It's easy enough. Just use Double.Parse with the current locale as separate parameter. It's not magic. I think I've added LC=C_ALL as a environment variable to about half of all Steam games I play.

Same here, I'm French and for quite a lot of games (at least 10 / 20% I had to add LANG=C before the command to launch the game. Examples include Anna Extended edition, and so on. Most of the affected titles are indie.
MayeulC 5 Jul 2017
While it's annoying, I found one relatively simple workaround. Run such games with:

HOME=$HOME/.local/share

Then all that clutter will move to more appropriate location.
Good find! Redefining HOME could be used for many things, it's a cheap "user isolation/virtualization" technology, like chroot but for data. You can add any number of "profiles" in terms of settings/accounts/data to any app, even if it doesn't directly support it.

Hello, could I please ask how to implement that code? Is it in bashrc? Thank you.

If you are using steam, right click on your game>Properties>Set launch Options>type HOME=$HOME/.local/share %command%
That's typically where you change the command line for steam games, and this sets the $HOME environment variable for this game, so that the game will consider the new folder as your home directory.

You could also set the same before launching steam: in theory (never tried it), it should make the well-behaved apps save in $XDG_DATA_HOME (if set), and all the others in the right path.
But I must say that I usually prefer reporting this directly to the developers. Some are quite open about it, and it has led to quick updates in a few cases. The issue with this is that applications are not aware that this is a hidden directory, and might try to access $HOME/Music, or $HOME/Pictures/Screenshots, or whatever. There are sometimes a few legitimate uses for accessing the user directory (though the ones I provided were bad examples, they should use $XDG_MUSIC_DIR :)

To continue the rant on home folder cluttering:
Spoiler, click me

This is a real problem: a quick look at my home directory gives me (might not be 100% accurate, some apps might have moved since. I include both games and apps, to insist on the fact that this is a generalized pproblem, I don't think the data here is too sensitive. Game-related directories are marked with stars)
.adobe            ********
.alsoftrc
.android
.AndroidStudio1.3
.AndroidStudio1.4
.AndroidStudio2.2
.Anomaly 2        ********
.Anomaly Korea    ********
.anthy
.appdata
.arduino
.arduino15
.aspell.en.prepl
.aspell.en.pws
.audacity-data
.bash_history
.bashrc
.bitsquid         ********
.blender
.bout             ********
.bzr.log
.cache
.ccache
.codeblocks
.config          (I am OK with this one)
.cpan
.cups
.darwinia         ********
.dbus
.designer
.dillo
.directory
.dmrc
.dosbox
.electricsheep
.emacs.d
.esd_auth
.face
.face.icon
.filebot
.fltk
.fluxbox
.fontconfig
.fonts
.fonts.conf
.FoulPlay         ********
.frictionalgames  ********
.frozenbyte       ********
.ganttproject
.ganttproject.d
.gconf
.gconfd
.gdb_history
.gdbinit
.gftp
.gimp-2.8
.gitconfig
.gksu.lock
.gnome
.gnupg
.gnutls
.gphoto
.gradle
.gstreamer-0.10
.gtk-bookmarks
.gtkrc-2.0
.gtkrc-2.0-kde4
.gvfs
.hfconsolerc
.hfpdrc
.histfile
.hplip
.ICEauthority
.icons
.install4j
.installjammerinfo
.ipython
.java
.jfduke3d         ********
.john
.jssc
.JxBrowser
.kde4
.kde-old
.kde-services
.killingfloor     ********
.klei             ********
.kodi
.lesshst
.lgp
.links
.local            (I am OK with this one)
.loki             ********
.LUFTRAUSERS      ********
.lyx
.m2
.macromedia       ********
.mandelbulber
.mandelbulber_log.txt
.mbwarband
.minecraft        ********
.minetest         ********
.mono
.mozc
.mozilla
.mplayer
.MyWM
.nanorc
.netwatch.1.3.0
.netwatch.1.3.1
.node_repl_history
.npm
.octave_hist
.octave_packages
.openalrc
.openvr           ********
.ophcrackrc
.oracle_jre_usage
.Osmos            ********
.p7zip
.paradoxinteractive ******
.phoronix-test-suite
.pki
.platformio
.processing
.pulse
.pulse-cookie
.python_history
.qt
.QtWebEngineProcess
.quicksynergy
.recently-used
.renpy
.repoconfig
.repopickle_.gitconfig
.revenge_of_the_titans      ********
.revenge_of_the_titans_1.80 ********
.rnd
.Scilab
.screenrc
.secrets-of-raetikon *******
.serverauth.11609
.serverauth.1349
.serverauth.2431
.sidhe
.Skype
.smb
.solar2             ********
.Spyder
.spyder2
.spyder2-py3
.sqlite_history
.ssh
.starruler2         ********
.steam              ******** /!\
.steampath          ******** /!\
.steampid           ******** /!\
.subversion
.SupergiantGames    ********
.swt
.synergy
.teeworlds          ********
.texlive
.thumbnails
.thunderbird
.tilp
.traktor            ********
.ts3client
.uim.d
.ut2004             ********
.vim
.viminfo
.vimrc
.vnc
.vvvvvv             ********
.weblaf
.wget-hsts
.wine
.wireshark
.WorldOfGoo         ********
.wxHexEditor
.Xauthority
.xchat2
.Xilinx
.xine
.xinitrc
.xinitrc-backup
.xinstall
.xmms
.xscreensaver
.xscreensaver-getimage.cache
.xsession
.xsession-backup
.xsession-errors
.xwmconfig
.zcompdump
.zenmap
.zshrc
.zshrc.zni

Uber Entertainment deserves a special mention for getting it, but not quite right, and creating the ".local/Uber Entertainment/" folder on my computer
On the other hand, wine games tend to clutter my home folder with non-hidden directories, which is worse. But to reiterate, I am against cluttering the home directory, even with dotfiles (that goes even for old-timers such as .vimrc, .bashrc, .ssh...).
Granted, I will need to wipe everything and start with a fresh home/system at some point.

Tip: something I sometimes do when I want to debug a title:
ORIGINAL_COMMAND=%command% konsole
(where konsole is your usual terminal emulator). What's nice here is that you will have a terminal with all environment variables (LD_LIBRARY_PATH, LD_PRELOAD, PWD) already set up, and launching the game is just $ORIGINAL_COMMAND away.

In most cases, games launch a script which then performs 36/64 bits detection, and sometimes distribution/DE specific tweaks. Feral's is quite interesting :)

I also have another old computer, that has a slow, 32bit only atom CPU, on which I like to play games every now and then, but these are obviously light ones (even super hexagon can be laggy at times), and I wouldn't mind not getting the latest releases, even the simple 2D games.
Aryvandaar 5 Jul 2017
I enjoy a good poke about distributions here and there, but it’s actually very true. Of all the distributions there are, Arch does end up being the most problematic. That's not saying Arch is bad, but being on the edge (it gets newer software faster than most other distributions) obviously increases the amount of issues that are likely to come up, since it's had less time in the oven to work out issues.

Arch is only problematic if the user don't know what he is doing. I can imagine that people report "bugs" that is actually the user not having set up his system properly.

I'm of the opinion if a Linux system is set up right, it shouldn't matter when you run games. Steam uses it's own libraries anyway which takes care of most of the problems.
Lakorta 5 Jul 2017
On the other hand, wine games tend to clutter my home folder with non-hidden directories, which is worse.
PlayOnLinux has a PrivateUserDirs option (Configure -> Install components, you have to do that for each virtual drive). Should be doable with normal wine, too.


Last edited by Lakorta on 5 Jul 2017 at 12:45 pm UTC
While you're here, please consider supporting GamingOnLinux on:

Reward Tiers: Patreon. Plain Donations: PayPal.

This ensures all of our main content remains totally free for everyone! Patreon supporters can also remove all adverts and sponsors! Supporting us helps bring good, fresh content. Without your continued support, we simply could not continue!

You can find even more ways to support us on this dedicated page any time. If you already are, thank you!
The comments on this article are closed.