I like how Windows managed the 32bit/64bit migration in the most sensible way, by making us pick from two copies of every installer/binary forever
-
technically windows does use fat binaries, they're just DOS/windows.
which is really only ever used to display a "you need windows to run this program" if you accidentally run it in DOS.
@foone surely NTFS binaries are more common these days
-
64bit windows EXE, being run in DOSBox-X:
fun fact: although that DOS stub usually just says that and quits, there's nothing that stops it from doing other things.
You could write a program that runs on DOS and win64, it'd just need to be implemented twice and embedded in the same binary
-
64bit windows EXE, being run in DOSBox-X:
@foone i suppose it's not really a big deal, it's hardly the biggest thing you're going to ship in the binary
-
technically windows does use fat binaries, they're just DOS/windows.
which is really only ever used to display a "you need windows to run this program" if you accidentally run it in DOS.
@foone I feel like I remember certain Win 3.x binaries also prepending a DOS executable of the same program, so that the same binary runs on both systems.
But Win 3.x isn't PE. So maybe I'm misremembering.
-
fun fact: although that DOS stub usually just says that and quits, there's nothing that stops it from doing other things.
You could write a program that runs on DOS and win64, it'd just need to be implemented twice and embedded in the same binary
so you could fat-binary a program to run on DOS/win32/win64 this way, by making it a 32bit program which win64 can run though backwards compatibility.
I'm not sure if you can include win16 though: it won't run the DOS stub, and it'll not be able to run the win32 version.
Unless you can set up win32s on win16 in such a way that it works in both 16bit windowses (through win32s) and 32bit-native windowses
-
I wonder if it still does that for 64bit EXEs?
@foone@digipres.club it's even still a thing in arm64 exes (iirc with an x86 dos stub) and bootmgfw.efi, even though no reasonable person will ever try to run those on dos
-
@foone But you *can* use that for so much more....
-
@gsuberland @dalias nasty
-
so you could fat-binary a program to run on DOS/win32/win64 this way, by making it a 32bit program which win64 can run though backwards compatibility.
I'm not sure if you can include win16 though: it won't run the DOS stub, and it'll not be able to run the win32 version.
Unless you can set up win32s on win16 in such a way that it works in both 16bit windowses (through win32s) and 32bit-native windowses
RE: https://digipres.club/@foone/116195447625031209
@foone Does ARM somehow also fit in?
-
so you could fat-binary a program to run on DOS/win32/win64 this way, by making it a 32bit program which win64 can run though backwards compatibility.
I'm not sure if you can include win16 though: it won't run the DOS stub, and it'll not be able to run the win32 version.
Unless you can set up win32s on win16 in such a way that it works in both 16bit windowses (through win32s) and 32bit-native windowses
@foone but fat as it is tall and with tits to match or are we being cowards?
-
@foone but fat as it is tall and with tits to match or are we being cowards?
@Kathee_HDS ROUGE.EXE!
-
fun fact: although that DOS stub usually just says that and quits, there's nothing that stops it from doing other things.
You could write a program that runs on DOS and win64, it'd just need to be implemented twice and embedded in the same binary
@foone An example of this is Bleep!, an NSF player for DOS/Win32
https://www.zophar.net/utilities/audio-multi/bleep-.html -
@foone@digipres.club it's even still a thing in arm64 exes (iirc with an x86 dos stub) and bootmgfw.efi, even though no reasonable person will ever try to run those on dos
@foone@digipres.club the .efi file for systemd-boot on my system doesn't include a dos stub though, so that's why i specifically said bootmgfw.efi
-
so you could fat-binary a program to run on DOS/win32/win64 this way, by making it a 32bit program which win64 can run though backwards compatibility.
I'm not sure if you can include win16 though: it won't run the DOS stub, and it'll not be able to run the win32 version.
Unless you can set up win32s on win16 in such a way that it works in both 16bit windowses (through win32s) and 32bit-native windowses
-
RE: https://digipres.club/@foone/116195447625031209
@foone Does ARM somehow also fit in?
@max presumably but I know nothing about windows-on-ARM, I don't believe in it.
-
fun fact: although that DOS stub usually just says that and quits, there's nothing that stops it from doing other things.
You could write a program that runs on DOS and win64, it'd just need to be implemented twice and embedded in the same binary
@foone that was the whole shtick of the HX DOS Extender.
The DOS stub could start it, and in turn that extender supports enough Win32 API to allow some limited software to run.
And I think I vaguely remember some other software doing crazy stuff with their DOS stubs.
-
fun fact: although that DOS stub usually just says that and quits, there's nothing that stops it from doing other things.
You could write a program that runs on DOS and win64, it'd just need to be implemented twice and embedded in the same binary
@foone I remember Visual Basic 3.0 "correcting" by trying to run Windows, and telling Windows to run VB in turn on startup.
-
I wonder if it still does that for 64bit EXEs?
@foone Not just 64-bit EXEs, EFI binaries also usually (but not always) contain the DOS stub.
-
I know programmers who use fat binaries and they're all cowards
@foone my favorite type of fat binaries probably are cosmopolitan libc/ape binaries.
I find it fascinating and entertaining but note that I don't think it's an actual good idea.
https://justine.lol/cosmopolitan/index.html -
@foone I remember some utilities from back in the day that did this; I even wrote one (QB 4.5 for DOS .exe, VB 5.0 for Win32; IIRC, I had to run the VB linker manually, which let me specify the .exe to use as DOS stub).
