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

31–40 of 51 posts

Re: Examining Windows 1.0 Hello.c

#31

Post by chungy »

asveikau wrote: post #28
msla wrote: post #27

Earlier quoted context omitted.

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

Re: Examining Windows 1.0 Hello.c

#32

Post by mister_hn »

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.

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

Try on Mac!

Re: Examining Windows 1.0 Hello.c

#35

Post by enriquto »

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.

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

Re: Examining Windows 1.0 Hello.c

#36

Post by xtracto »

enriquto wrote: post #35
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.

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

Re: Examining Windows 1.0 Hello.c

#37

Post by heinrich5991 »

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.

Re: Examining Windows 1.0 Hello.c

#38

Post by badpun »

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?

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.

Re: Examining Windows 1.0 Hello.c

#39

Post by krapp »

grawprog wrote: post #9
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".

125 lines seems fairly 'behemoth' for a hello world C program to me. This for example is a hello world for sdl: #include 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; } htt…

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

Re: Examining Windows 1.0 Hello.c

#40

Post by Narishma »

xtracto wrote: post #36
enriquto wrote: post #35

Earlier quoted context omitted.

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