Examining Windows 1.0 Hello.c | Hacker News Reader

Examining Windows 1.0 Hello.c

virtuallyfun.com

100 pointsNarishma49 comments

It's pretty impressive that binaries from Windows 1.0 still manage to run on Windows 10.

I wish desktop Linux had even a fraction of that level of backwards compatibility.

You would think mapping memory, files, pipes and general IO would have stabilized by now, at least in their basic forms.

They did in 32-bit Windows (NT3.1 is pretty much the same on a core level from Win 10). The problem here was that the 8088 suffered from segmentation which put "interesting" constraints on programs, and then Intel's 80286 was alded to the point that it was only successful in the sense of "faster 8088" and not bringing 32-bit computing as was promised.

I was talking about linux in the era of virtual memory.

The 286 is a 16-bit CPU, it never promised 32-bit computing. That was its successor, the 386.

When running Xorg/X11 they do still run, that protocol from the old days has not changed much, its the libs that the programs use are the moving target, but if you have a nice static compiled X11 App, it will still display!

TWM keeps working fine on the latest version of Linux, and TWM predates Linux for many years!.

Desktop Linux has all of that compatibility. Nothing fundamental has changed: You need the libraries, and if you have them, it works, just like in Windows.

No, not really. You can get chroots to run on a command kernel but ABI changes happen without soversion bumps which stupidly complicate matters. Godhelp you if your application tries to use weird ALSA or even worse, OSS features.

I've been down that road, there's nothing good to say about it.

The actual form of backwards compatibility in Linux is "gcc still builds the C and bash still runs the shell script".

Which is nice in that most every distro carries around a gazillion packages of obscure old code that still builds, but it also means that binaries are heavily disrespected, and the development environment is and forever remains centered around the GNU toolchain.

> Godhelp you if your application tries to use weird ALSA or even worse, OSS features.

What's a weird ALSA or OSS feature? What do you expect in its place?

OSS as an API was really dead simple. open, ioctl, read or write... That interface is still working fine on FreeBSD.

There is an OSS to ALSA compatibility driver.

I'm sure whatever you're expecting (pulseaudio? yech.) can fake being an ALSA device enough to fool anyone.

I have plenty of experience which says otherwise, both for Windows breaking compatibility and Linux keeping it.

Are you aware that the original binary format of Linux was not ELF?

Then, the last time I tried to run a binary from the 90s, it required libc5, from the days before distros switched to glibc.

> Are you aware that the original binary format of Linux was not ELF?

Yes, and having an a.out interpreter is just another dependency.

> Then, the last time I tried to run a binary from the 90s, it required libc5, from the days before distros switched to glibc.

It's a library. libc is versioned like everything else.

Nobody is distributing that library anymore. Whereas an equivalently aged binary on Windows will load today without extra dependencies.

I would think that the kernel would have dropped binfmt_aout by now, but I just looked and it's still there. Wonder if any distros build it.

> Nobody is distributing that library anymore.

There exist plenty of archives of old Linux distributions. "Nobody" turns out to be quite a lot of people/servers.

> Whereas an equivalently aged binary on Windows will load today without extra dependencies.

I wouldn't go so far. The 64-bit port of Windows dropped support for all 16-bit applications, whereas they still run flawlessly through Wine.

Devil’s Advocate counterpoint - being able to still run Win1.0 is evidence of the baggage that Windows is carrying around, and maybe it would do them some good to eventually cull out some old cruft. The transitions will naturally be painful, but how much further and faster could they go if maybe they stopped supporting code from 35 years ago?

IBM Mainframes laugh at Windows backward compatibility. 50-60+ years isn't unheard of. I actually want to at some point climb that cliff but my next write up is exploring Windows 3.11's networking features, and then Novell NetWare; the Windows one should go up tomorrow on SN, and NetWare next week.

I look forward to the NetWare one!

Yep, when trying to learn Windows programming in 2020, you can literally see the geological layers of APIs accumulated over time... It does not make things easy. Not to mention that development on Windows team in MS must be a nightmare...

I wonder if it would be a good idea for them to remove a lot of the old APIs and instead provide a seamless virtualization mechanism for running the old binaries.

Have you read an article?

1) It specifically needs the 32-bit version of Windows.

2) It won't run on 32-bit Windows 10 without an additional installation (NTVDM).

I don't see any "baggage" which limits anything, for any "normal" user.

> I wish desktop Linux had even a fraction of that level of backwards compatibility.

Try on Mac!

> I wish desktop Linux had even a fraction of that level of backwards compatibility.

The compatibility is mostly at the level of the source code. You can compile linux programs from 20 years ago and run them. The only friction is that the compiler may print a few warnings. Binary compatibility is a moot point when you can recompile stuff so easily.

I tried to run Soldier of Fortune for Linux (of Loki fame) and it isnt possible due to 32/62bit compatibility issues. I cant imagine running 16bit software...

Linux doesn't have 16-bit software.

https://en.wikipedia.org/wiki/Embeddable_Linux_Kernel_Subset

Does that have any interesting 16-bit software you might want to run on Linux?

Well, it's at least interesting enough to exist, beyond that I couldn't say. Bit subjective of a goal post don't you think?

Only on a 32 bit installation, you can't run 16-bit applications on a 64-bit machine.

This is a copy from an original article which was already posted on HN a few days ago and which did not get any traction.

https://news.ycombinator.com/item?id=23237045

Could you please refer to the original article below and credit the original site it was published on:

https://soylentnews.org/article.pl?sid=20/05/10/1753203

OP's article starts with "The following is a guest post by NCommander of SoylentNews fame!", so I don't think there are any real attribution issues here.

I'm fine with either showing up, although it originally was posted to SoylentNews (which I'm a site administrator), and then sent to neozeed to post as SN deals with news more like HN and I didn't want it to get lost in the archives. It's also on DEFCON 201's blog.

The article links to a place where you can run Windows 1.0 in a browser: https://www.pcjs.org/software/pcx86/sys/windows/1.01/.

Interestingly, even Windows 1.0's notepad had "Insert Time/Date (F5)". I always wondered where that came from, but apparently it's backward compatibility to Windows 1.0.

I wonder if it's to support the fact that Windows 1.0 bugs were tracked in a text file.

Source: https://devblogs.microsoft.com/oldnewthing/20200317-00/?p=10...

> The history of defect tracking in the Windows team goes back to Windows 1.0, which used a text file.

> I was inspired to investigate the original HELLO.C for Windows 1.0, a 125 line behemoth that was talked about in hush tones.

Should that have been "125k line"? Not to get too pedantic, but the units seem needful for "behemoth".

No, windows did not require a 125 thousand line program to display hello world.

The question was serious; the repercussions, severe; the message, received.

Very nice, grace under pressure. Upvoted, along with the original question.

Thanks!

Hotel, Trivago.

Even for Windows 1.0, I can see ways to cut this thing down to size. The point though is that this is what MSFT actually included in the SDK, and I remember reading about in "Programming Windows" and other sources.

It just took me a few years (or maybe decades) from reading about it to actually try it.

No, at the time it did seem monstrous and barbaric to need 125 lines for hello.c, when 5 or 6 was quite properly considered the norm. "Behemoth" is a relative term in this case.

Edit: In the decades since nothing has changed in my mind. The messy Windows boilerplate code that made up the other 120 lines or so should have been refactored architecturally and hidden by a framework, API call, something, anything.

125 lines seems fairly 'behemoth' for a hello world C program to me. This for example is a hello world for sdl:

    #include <SDL/SDL.h>

    int main(int argc, char *argv[]) {
    int gogogo = 1;
    SDL_Event event;

    SDL_Init(SDL_INIT_EVERYTHING);
    SDL_WM_SetCaption("Hello World! :D", NULL);
    SDL_SetVideoMode(800, 600, 32, SDL_HWSURFACE);
    while (gogogo) {
        SDL_WaitEvent(&event);
        if (event.type == SDL_QUIT)
            gogogo = 0;
    }
    SDL_Quit();
    return 0;

}

https://www.badprog.com/c-sdl-simple-directmedia-layer-hello...

Because all of the platform-specific code is offloaded to the library and compiled in. It's still there, hidden behind the abstractions.

Amazing work. Thanks for the trip down memory lane

You're welcome. I just got tipped off on this ending up here. The rabbit hole was incredibly deep, but by time I was out of it, I was determined to share the pain with the rest of the world :)

PASCAL != stdcall

It does in Microsoft's world who #define it like that.

As I remember, and if I'm wrong, I'll correct it, the different on 32-bit was that stdcall and pascal change the order of how arguments are injected.

That's because PASCAL was used for 16-bit Windows. They only define it as stdcall in 32-bit and 64-bit compilers for source compatibility reasons.

The 16-bit Windows SDK does not define PASCAL as stdcall.

PASCAL pushes arguments left to right. stdcall pushes arguments right to left.

Reply on news.ycombinator.com