Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Examining Windows 1.0 Hello.c

virtuallyfun.com

Post reply on HN
Print view View original

21–30 of 51 posts

Re: Examining Windows 1.0 Hello.c

#21

Post by NCommander »

CyberDildonics wrote: post #3
smitty1e wrote: post #2

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

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.

Re: Examining Windows 1.0 Hello.c

#23

Post by NCommander »

eddieroger wrote: post #15
pantalaimon wrote: post #4

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.

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.

Re: Examining Windows 1.0 Hello.c

#24

Post by CyberDildonics »

NCommander wrote: post #20
CyberDildonics wrote: post #5

Earlier quoted context omitted.

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.

Re: Examining Windows 1.0 Hello.c

#25

Post by asveikau »

msla wrote: post #14
pantalaimon wrote: post #4

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.

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.

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.

Re: Examining Windows 1.0 Hello.c

#26

Post by megameter »

NCommander wrote: post #19
msla wrote: post #14

Earlier quoted context omitted.

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.

Re: Examining Windows 1.0 Hello.c

#27

Post by msla »

asveikau wrote: post #25
msla wrote: post #14

Earlier quoted context omitted.

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.

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.

Re: Examining Windows 1.0 Hello.c

#28

Post by asveikau »

msla wrote: post #27
asveikau wrote: post #25

Earlier quoted context omitted.

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.

Re: Examining Windows 1.0 Hello.c

#29

Post by asveikau »

NCommander wrote: post #19
msla wrote: post #14

Earlier quoted context omitted.

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.

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

Post reply on HN