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
-
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).
-
@Kathee_HDS ROUGE.EXE!
@foone ah damn missed the opportunity to say "with bits to match", post cancelled, hit the showers everyone we did good but we're not at our best yet the fans expect better of us pushes a lever and falls into the river
-
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 Win16 programs are NE, but I have no idea if you can combine NE and PE in the same file (would have to look at what each of them needs in the stub .exe header).
-
RE: https://digipres.club/@foone/116195447625031209
@foone Does ARM somehow also fit in?
@max @foone After skimming https://learn.microsoft.com/en-us/windows/arm/arm64x-build again, I'm ... not sure?
There's "Arm64EC" which is a modified Arm64 ABI to play nicer with emulated x86 code (e.g. half the registers are unusable so there's a 1:1 correspondence with amd64?), and Arm64X which is Arm64 and Arm64EC(?) "fat" binaries. Not sure if it supports Arm64+amd64 "fat" binaries, or even all three.
I'd assume that they include the same DOS stub out of habit, but who knows?
-
J jwcph@helvede.net shared this topic
