Live data from Hacker News

Examining Windows 1.0 Hello.c

virtuallyfun.com

11–20 of 51 posts

Re: Examining Windows 1.0 Hello.c

#11
post #10

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.

Re: Examining Windows 1.0 Hello.c

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

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

Re: Examining Windows 1.0 Hello.c

#13

Earlier quoted context omitted.

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.

Re: Examining Windows 1.0 Hello.c

#14

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.

Re: Examining Windows 1.0 Hello.c

#15

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?

Re: Examining Windows 1.0 Hello.c

#18
post #10

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.

Re: Examining Windows 1.0 Hello.c

#19
post #14

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.

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.

Re: Examining Windows 1.0 Hello.c

#20

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.
Post reply on HN