Single, precompiled program for both Windows and Linux?

You can talk about almost anything that you want to on this board.

Moderator: Moderators

User avatar
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?

Post by Drew Sebastino »

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...
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Single, precompiled program for both Windows and Linux?

Post by rainwarrior »

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.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Single, precompiled program for both Windows and Linux?

Post by lidnariq »

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")
User avatar
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?

Post by Drew Sebastino »

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.
Modern Windows ("WSL") supports natively running many Linux ELF binaries now
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?

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.
User avatar
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?

Post by Drew Sebastino »

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?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Single, precompiled program for both Windows and Linux?

Post by tepples »

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".
User avatar
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?

Post by Drew Sebastino »

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.
User avatar
Quietust
Posts: 1920
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Single, precompiled program for both Windows and Linux?

Post by Quietust »

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.
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.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Single, precompiled program for both Windows and Linux?

Post by lidnariq »

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.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Single, precompiled program for both Windows and Linux?

Post by calima »

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.
User avatar
gauauu
Posts: 779
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

Re: Single, precompiled program for both Windows and Linux?

Post by gauauu »

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.
QT seems to be an effective choice also, although I've never spent a lot of time working with it.
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: Single, precompiled program for both Windows and Linux?

Post by calima »

Qt is write-once only if you write entirely in JS/QML, otherwise it's normal "compile for each platform".
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Single, precompiled program for both Windows and Linux?

Post by tepples »

And even if you cross-compile, you can't practically cross-test on a platform you don't have. (Or what am I missing?)
User avatar
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?

Post by Drew Sebastino »

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.
User avatar
koitsu
Posts: 4201
Joined: Sun Sep 19, 2004 9:28 pm
Location: A world gone mad

Re: Single, precompiled program for both Windows and Linux?

Post by koitsu »

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:
For *IX, if you know C, many of those syscall names will look familiar to you, except the versions you're used to are probably from libc (ex. kernel read() vs. libc read(). Yes, the latter uses the former, but there is not a 1:1 connection between the two (ex. kernel malloc() vs. libc malloc()). Now you know where a lot of the commonly-used libc function names effectively originated from.

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.
Post Reply