Single, precompiled program for both Windows and Linux?
Moderator: Moderators
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Single, precompiled program for both Windows and Linux?
I've been reading about software development and this idea came to my mind. For cross compatibility for PC programs, the only options seem to be either using an interpreted language, or releasing multiple binaries. However, it shouldn't be impossible to detect what OS your program is running under and only execute the corresponding routines that deal with this OS, should it? I don't know if this would just end up being multiple seperate programs inside of one though...
- rainwarrior
- Posts: 8734
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
Re: Single, precompiled program for both Windows and Linux?
They don't use the same executable format, so one OS would not know how to load the other's executable. If they can't load it, they can't run it.
Re: Single, precompiled program for both Windows and Linux?
In interpreted languages, this thing is called a "polyglot".
In compiled languages, it's called a "Fat" binary. OSX made use of them for the PPC-to-x86 and x86-to-amd64 transistions, and there were a small handful of DOS/win32 hybrids, but almost everywhere else it's been forsaken.
Most Linux binaries are so-called "ELF", which requires the first 4 bytes have a specific contents; in contrast, Windows binaries require the first two bytes to instead be "MZ". (I think.)
An ELF and DOS COM "Fat" binary could probably be made - the ELF header would become jg +0x45 / dec sp / inc si and much of the rest of the ELF header can be massaged into useful values.
I think the reason the idea never really caught on is that so much of what a program does is interacting with the system. It's hard to reuse the actual compiled code - assuming both sides are the same ISA - because even if the program is doing the same minimal thing, every single place it called "open" or "read" or whatever would have to be patched, or some other kind of multiplex.
Modern Windows ("WSL") supports natively running many Linux ELF binaries now. Linux can be configured to support natively running any program it knows how to find an interpreter for ("binfmt-misc")
In compiled languages, it's called a "Fat" binary. OSX made use of them for the PPC-to-x86 and x86-to-amd64 transistions, and there were a small handful of DOS/win32 hybrids, but almost everywhere else it's been forsaken.
Most Linux binaries are so-called "ELF", which requires the first 4 bytes have a specific contents; in contrast, Windows binaries require the first two bytes to instead be "MZ". (I think.)
An ELF and DOS COM "Fat" binary could probably be made - the ELF header would become jg +0x45 / dec sp / inc si and much of the rest of the ELF header can be massaged into useful values.
I think the reason the idea never really caught on is that so much of what a program does is interacting with the system. It's hard to reuse the actual compiled code - assuming both sides are the same ISA - because even if the program is doing the same minimal thing, every single place it called "open" or "read" or whatever would have to be patched, or some other kind of multiplex.
Modern Windows ("WSL") supports natively running many Linux ELF binaries now. Linux can be configured to support natively running any program it knows how to find an interpreter for ("binfmt-misc")
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: Single, precompiled program for both Windows and Linux?
Fat binary appears to be exactly what I meant. I was only thinking about everything being x86-64; when you get to supporting multiple ISAs, you might as well release separate binaries.
Edit: I saw that it's straight up just the Linux kernel running in Windows, so I'm going to answer my own question and say yes. This seems like a pretty big deal; I'll probably just target 64 bit Linux.
Wow; it looks like the performance level isn't far behind running programs natively in Linux as well. So unless I'm not understanding this correctly, you can use (some) Linux syscalls and they'll work under Windows 10 as just as long as the file extension is .elf?Modern Windows ("WSL") supports natively running many Linux ELF binaries now
Edit: I saw that it's straight up just the Linux kernel running in Windows, so I'm going to answer my own question and say yes. This seems like a pretty big deal; I'll probably just target 64 bit Linux.
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: Single, precompiled program for both Windows and Linux?
Hmm, I've been looking at x86-64 Linux syscall tables, and I haven't found anything that looks like it could pretain to the GUI; am I missing something?
Re: Single, precompiled program for both Windows and Linux?
GUI stuff in Linux is done through communication with an X server.
Linux can load PE executables for Win32 if you install a PE loader and a reimplementation of required Win32 calls. We call this "Wine".
Linux can load PE executables for Win32 if you install a PE loader and a reimplementation of required Win32 calls. We call this "Wine".
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: Single, precompiled program for both Windows and Linux?
That greatly clears things up. I thought I just wasn't reading the syscall table correctly...
I did run into a rather silly problem, and that's that I'm not sure how you're supposed to create a .elf file from .o files on Windows... MinGW doesn't work because it assumes the .o files are for a .exe file.
I did run into a rather silly problem, and that's that I'm not sure how you're supposed to create a .elf file from .o files on Windows... MinGW doesn't work because it assumes the .o files are for a .exe file.
Re: Single, precompiled program for both Windows and Linux?
What you want is a cross-compiler, and I don't believe MinGW can do that. There do exist solutions that involve Cygwin, though I don't know exactly how they work.Drew Sebastino wrote:That greatly clears things up. I thought I just wasn't reading the syscall table correctly...
I did run into a rather silly problem, and that's that I'm not sure how you're supposed to create a .elf file from .o files on Windows... MinGW doesn't work because it assumes the .o files are for a .exe file.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
P.S. If you don't get this note, let me know and I'll write you another.
Re: Single, precompiled program for both Windows and Linux?
If you're trying to write a cross-platform GUI program, you may find it less frustrating to just start with Win32 or some CLR program and test under wine or mono, instead of going the other direction.
Re: Single, precompiled program for both Windows and Linux?
WSL does not support GUI programs IIRC. It's pretty unclear what you're after, but for cross-platform GUI the usual solutions were Java or tcl-tk.
Re: Single, precompiled program for both Windows and Linux?
QT seems to be an effective choice also, although I've never spent a lot of time working with it.calima wrote:WSL does not support GUI programs IIRC. It's pretty unclear what you're after, but for cross-platform GUI the usual solutions were Java or tcl-tk.
My games: http://www.bitethechili.com
Re: Single, precompiled program for both Windows and Linux?
Qt is write-once only if you write entirely in JS/QML, otherwise it's normal "compile for each platform".
Re: Single, precompiled program for both Windows and Linux?
And even if you cross-compile, you can't practically cross-test on a platform you don't have. (Or what am I missing?)
- Drew Sebastino
- Formerly Espozo
- Posts: 3496
- Joined: Mon Sep 15, 2014 4:35 pm
- Location: Richmond, Virginia
Re: Single, precompiled program for both Windows and Linux?
I wasn't thinking about writing a GUI program, but I was curious why I didn't see any GUI functions when I was looking at the syscall table; I assumed that's what most of the syscalls would be for.
Regardless, I did see that you can get an X server for Windows that uses the native window manager, but I don't know what the performance would be like compared to writing for windows natively, and having to download more software makes this less attractive.
Regardless, I did see that you can get an X server for Windows that uses the native window manager, but I don't know what the performance would be like compared to writing for windows natively, and having to download more software makes this less attractive.
Re: Single, precompiled program for both Windows and Linux?
System called on *IX systems are well-defined and have absolutely nothing to do with GUIs. Syscalls are the way userland programs "talk" to the kernel. The number of syscalls is limited (adding new syscalls is done with extreme prejudice), and the amount of time a syscall takes/its behaviour matters tremendously (often scrutinised down to the cycle). There is often a slight abstraction layer but it has to be kept extremely minimal -- read: assembly is almost always involved. Here you go:
GUIs on *IX systems are implemented in software, through a series of daemons (usually an X server and client, along with a window manager), and other terrible abstraction layers atop all of this. It's up to the X server (commonly here) and/or WM to implement the tie-ins for hardware acceleration, often through a series of *other* interfaces (sometimes through ioctl(2), sometimes something more unique or custom.) For hardware acceleration on Linux and FreeBSD, it varies per video card, and there's a separate driver for each card, and X usually has to support it directly. These days, the latter tends to be what's called DRI/DRM -- Direct Rendering Manager, not to be confused with Digital Rights Management! -- which is often weird and may involve OpenGL. For video encoding or decoding, here's a list of junk.
All of this is stuff you really don't want to delve into if you value your time at all. And I'm not kidding. Don't bother reading any of it if all you want to do is make a GUI for your program, because none of it is relevant to that. Just use the Qt framework and you can essentially end up with the same UI on Windows and *IX. You still have to write the code to be compatible with each OS, however, which is a separate matter. Likewise, if you value your time and sanity, avoid looking at at GTK or GTK3.
And now you know why I stick with CLI software development.
- Linux: https://www.systutorials.com/docs/linux/man/2-syscalls/
- FreeBSD: src/sys/sys/syscall.h (a.k.a. /usr/include/sys/syscall.h) which is generated from src/sys/kern/syscalls.master (addn. reference)
- Windows: https://j00ru.vexillium.org/syscalls/nt/64/ -- there are 32-bit equivalents as well. Most syscalls are prefixed with Nt (taken from the NT kernel (yes, as in Windows NT), standing for "New Technology"); there is also Win32 API functions which are not quite syscalls (they're effectively a subsystem; more here)
GUIs on *IX systems are implemented in software, through a series of daemons (usually an X server and client, along with a window manager), and other terrible abstraction layers atop all of this. It's up to the X server (commonly here) and/or WM to implement the tie-ins for hardware acceleration, often through a series of *other* interfaces (sometimes through ioctl(2), sometimes something more unique or custom.) For hardware acceleration on Linux and FreeBSD, it varies per video card, and there's a separate driver for each card, and X usually has to support it directly. These days, the latter tends to be what's called DRI/DRM -- Direct Rendering Manager, not to be confused with Digital Rights Management! -- which is often weird and may involve OpenGL. For video encoding or decoding, here's a list of junk.
All of this is stuff you really don't want to delve into if you value your time at all. And I'm not kidding. Don't bother reading any of it if all you want to do is make a GUI for your program, because none of it is relevant to that. Just use the Qt framework and you can essentially end up with the same UI on Windows and *IX. You still have to write the code to be compatible with each OS, however, which is a separate matter. Likewise, if you value your time and sanity, avoid looking at at GTK or GTK3.
And now you know why I stick with CLI software development.