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
-
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
@foone don’t forget the software that also has arm64 binaries!
-
64bit windows EXE, being run in DOSBox-X:
-
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.
