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

41–50 of 51 posts

Re: Examining Windows 1.0 Hello.c

#41

Post by acqq »

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?

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.

Re: Examining Windows 1.0 Hello.c

#42

Post by Narishma »

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.

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

Re: Examining Windows 1.0 Hello.c

#43

Post by tonyedgecombe »

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.

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

Re: Examining Windows 1.0 Hello.c

#44

Post by amaccuish »

NCommander wrote: post #23
eddieroger wrote: post #15

Earlier quoted context omitted.

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!

Re: Examining Windows 1.0 Hello.c

#45

Post by Zardoz84 »

jrwr wrote: post #8
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.

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

Re: Examining Windows 1.0 Hello.c

#46

Post by speps »

heinrich5991 wrote: post #37

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.

Re: Examining Windows 1.0 Hello.c

#47

Post by c22 »

Narishma wrote: post #40
xtracto wrote: post #36

Earlier quoted context omitted.

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

Re: Examining Windows 1.0 Hello.c

#49

Post by c22 »

Narishma wrote: post #48
c22 wrote: post #47

Earlier quoted context omitted.

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?

Re: Examining Windows 1.0 Hello.c

#50

Post by dblohm7 »

NCommander wrote: post #33
dblohm7 wrote: post #22

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.

Post reply on HN