Make a binary that looks statically linked, at the start of your main sniff around the OS to find where the heck they put the dynamic linker, execve the dlinker with yourself as an argument and now you can dynamically link against Vulkan and display a nice triangle (after you fix a bunch of other problems relative to this semi-dynamic linking stategy). The result is a single binary that smooths over a bunch of inconsistencies across different distributions that would otherwise require distro-specific builds of the game.
That said, it’s just a PoC so unless someone considers this a valid usecase, nothing will happen and people will just keep gaming on Windows.
The talk links to a build of the executable so you can try it yourself.
Realistically, I think developers target the Steam Runtime (aka old Ubuntu) - or even “better”, Proton (Valve’s Wine fork) is well developed enough developers officially support that. Win32 is the Linux stable userland ABI, after all.
Doesn’t everyone use dynamic loaders (like glad) to load gl/vulkan anyway, in order to deal with the extensions? I’m not sure what this gains you.
Dynamically linking against libdl is the saner way to dynamically load stuff anyway; and libdl is stable and can be counted on to exist. (Unlike some libraries *cough* glibc.)
Based on my understanding… I believe the main point is that linking dynamically (normally) generates an INTERP in the elf header with a static location for the dynamic loader (ld-linux, ld-musl, etc), which is not portable (it uses a full path), as well as the fact that it of course wouldn’t support both musl and glibc (different path/name).
Based on my recollection from having watched the video a day or two ago.. what this is doing is building an elf file with no INTERP header section, but still having a DYNAMIC section and also being statically linked. On first invocation the program locates the dynamic loader (ld-linux, ld-musl, etc), and execve’s itself via the dynamic loader with the full path and as well as adding LD_PRELOAD env params, so it can then effectively run dynamically and pull in the native environment via the dynamic loader (which then pulls in libc and libdl). Everything after that is “normal”.
Dynamically linking against libdl is the saner way
Should be fine! I know nothing about that problem, but this is about how to dynamically link from a statically linked binary. Longer explanation by trousers.
at the start of your main sniff around the OS to find where the heck they put the dynamic linker
Aside: This hits a little too close to home based on $WORK this week. Is there a better way to do this other than parsing the horror that is /proc/self/maps? I was trying to figure out the image base at runtime using only information from the OS.
It isn’t that the format is hard, it is that it tends to elide information and you have to deal with weird stuff like executables having multiple sections and whatnot.
Yes, what the zig compiler does is look at the ELF file for /usr/bin/env - which is highly portable because it is ubiquitous in shebang lines - and that contains the path to the dynamic linker. Empirically it has been completely reliable. I am not aware of any setups where this does not successfully identify the system linker.
This looks like a really cool idea. Hopefully it is not too socially and technically challenging to get the related projects on board.
One issues is that this would not help with games that have anti-cheat. But hopefully if we get a large enough amount of people gaming on Linux, more anti-cheat software will start to support Linux. Although with some of the permissions that anti-cheat software wants to have, idk if the Linux community will ever support it.
Anti-cheat is only an issue for multiplayer games; specifically, for multiplayer games where you play with strangers.
There’s loads of singleplayer games too; I’m not sure what the distribution of popularity is exactly, but if I look at the “bestselling” list on gog.com right now, then most of them are primarily singleplayer games.
Overall, I don’t think that anti-cheat is critical for a significant adoption rate of “gaming on Linux”. Just general lack of customers/interest seems like a far bigger issue to me.
What sort of OBS problems have you been having on Linux? I use OBS on both and the experience has seemed the same to me. Maybe there’s stuff on Windows that I’m not even aware that I’m missing.
Last time I used it, the builtin browser was missing. Also on macOS the audio stuff is clunkier, you need third party apps to create virtual audio devices and connect them manually to sources. I don’t know what’s the status of audio stuff on linux.
In general I have the impression that OBS is developed “windows-first”.
Can anyone summarize the “main idea” from this for those of us who have trouble squeezing video in?
Make a binary that looks statically linked, at the start of your main sniff around the OS to find where the heck they put the dynamic linker, execve the dlinker with yourself as an argument and now you can dynamically link against Vulkan and display a nice triangle (after you fix a bunch of other problems relative to this semi-dynamic linking stategy). The result is a single binary that smooths over a bunch of inconsistencies across different distributions that would otherwise require distro-specific builds of the game.
That said, it’s just a PoC so unless someone considers this a valid usecase, nothing will happen and people will just keep gaming on Windows.
The talk links to a build of the executable so you can try it yourself.
Realistically, I think developers target the Steam Runtime (aka old Ubuntu) - or even “better”, Proton (Valve’s Wine fork) is well developed enough developers officially support that. Win32 is the Linux stable userland ABI, after all.
Holy grail of cross-distro compatibility = Unlocked
Doesn’t everyone use dynamic loaders (like glad) to load gl/vulkan anyway, in order to deal with the extensions? I’m not sure what this gains you.
Dynamically linking against libdl is the saner way to dynamically load stuff anyway; and libdl is stable and can be counted on to exist. (Unlike some libraries *cough* glibc.)
Based on my understanding… I believe the main point is that linking dynamically (normally) generates an INTERP in the elf header with a static location for the dynamic loader (ld-linux, ld-musl, etc), which is not portable (it uses a full path), as well as the fact that it of course wouldn’t support both musl and glibc (different path/name).
Based on my recollection from having watched the video a day or two ago.. what this is doing is building an elf file with no INTERP header section, but still having a DYNAMIC section and also being statically linked. On first invocation the program locates the dynamic loader (ld-linux, ld-musl, etc), and execve’s itself via the dynamic loader with the full path and as well as adding LD_PRELOAD env params, so it can then effectively run dynamically and pull in the native environment via the dynamic loader (which then pulls in libc and libdl). Everything after that is “normal”.
EDIT: here is the code repo, mentioned in the talk on one of the slides: https://github.com/andrewrk/zig-window
Should be fine! I know nothing about that problem, but this is about how to dynamically link from a statically linked binary. Longer explanation by trousers.
Aside: This hits a little too close to home based on $WORK this week. Is there a better way to do this other than parsing the horror that is
/proc/self/maps? I was trying to figure out the image base at runtime using only information from the OS.It isn’t that the format is hard, it is that it tends to elide information and you have to deal with weird stuff like executables having multiple sections and whatnot.
Yes, what the zig compiler does is look at the ELF file for
/usr/bin/env- which is highly portable because it is ubiquitous in shebang lines - and that contains the path to the dynamic linker. Empirically it has been completely reliable. I am not aware of any setups where this does not successfully identify the system linker.This looks like a really cool idea. Hopefully it is not too socially and technically challenging to get the related projects on board.
One issues is that this would not help with games that have anti-cheat. But hopefully if we get a large enough amount of people gaming on Linux, more anti-cheat software will start to support Linux. Although with some of the permissions that anti-cheat software wants to have, idk if the Linux community will ever support it.
Anti-cheat is only an issue for multiplayer games; specifically, for multiplayer games where you play with strangers.
There’s loads of singleplayer games too; I’m not sure what the distribution of popularity is exactly, but if I look at the “bestselling” list on gog.com right now, then most of them are primarily singleplayer games.
Overall, I don’t think that anti-cheat is critical for a significant adoption rate of “gaming on Linux”. Just general lack of customers/interest seems like a far bigger issue to me.
Based on the title I thought this was gonna be about VFIO. Cool to see dlfcn magic instead.
The only two things that keep me on Windows are games and OBS.
OBS works on Linux and Mac too
What sort of OBS problems have you been having on Linux? I use OBS on both and the experience has seemed the same to me. Maybe there’s stuff on Windows that I’m not even aware that I’m missing.
Last time I used it, the builtin browser was missing. Also on macOS the audio stuff is clunkier, you need third party apps to create virtual audio devices and connect them manually to sources. I don’t know what’s the status of audio stuff on linux.
In general I have the impression that OBS is developed “windows-first”.
I’m not a sophisticated OBS user, but it’s generally worked fine for me on Linux.
I’m also using it on linux. But for example the virtualcam plugin is windows only.
Hell yeah. I haven’t booted into windows for a month!