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

Windows 9x Subsystem for Linux

social.hails.org

Post reply on HN
Print view View original

81–90 of 265 posts

Re: Windows 9x Subsystem for Linux

#81

Post by keepamovin »

anthk wrote: post #38
defrost wrote: post #9

I am going to run this in Windows 95 on a Sun PC card under Solaris 7. from the same commenter who effused jesus fucking christ this is an abomination of epic proportions that has no right to exist in a just universe and I love it so much

Wait until you find IE was released for Unix, using some Win32 shims. And... die hard Unix sysadmin ran it under FVWM and compared to Netscape wasn't half bad. Both propietary, but sadly NScape didn't open Mozilla yet, and the rest of the alternatives such as Arena/Amaya coudn't compete with 'modern' CSS features and the like.

Speaking of vintage IE and Netscape on old Win, it's actually still possible to use them to browse the modern web if you proxy it.

I built a Win9x compatibility mode for BrowserBox that does exactly this (https://github.com/BrowserBox/BrowserBox/blob/main/readme-fi...). Ur modern server does all the rendering, and it outputs a client link specifically designed for legacy browsers like IE5, IE6, and Netscape running on Windows 95/98/NT, streaming them the pixels. It's definitely an abomination, but there's something magical and retro that I like about viewing the 2026 internet through an IE6 window ;) ;p xx

Re: Windows 9x Subsystem for Linux

#82

Post by mrweasel »

foldr wrote: post #65

Incredible that current Linux kernels still have 486 support!

Which is really weird because I thought it didn't, per https://www.theregister.com/2025/05/07/linux_kernel_drops_48...

Maybe there's some detail I don't quite follow, like is has support for 486, but only those with a built in FPU?

Re: Windows 9x Subsystem for Linux

#83

Post by GranPC »

mrweasel wrote: post #80
GranPC wrote: post #55

Earlier quoted context omitted.

No? WSL is Linux on Windows — so W9xSL is Linux on Windows 9x. I think… :)

WSL is "Windows Subsystem for Linux", so this should be "Linux Subsystem for Windows 9x"

By Microsoft’s convention, that would be a way to run Windows 9x on Linux. It’s a bit confusing. Another example is “Windows Subsystem for Android”, which is what they use for running Android apps on Windows. I think the idea is that it’s not a “Windows Subsystem” for X, but rather a Windows “Subsystem for X”.

(Edited: mixed it up on the last sentence.)

Re: Windows 9x Subsystem for Linux

#84

Post by DaSHacka »

pjmlp wrote: post #23
Fnoord wrote: post #20

Earlier quoted context omitted.

Cygwin is way older than CoLinux. CoLinux is from 2004. Cygwin was first released in 1995. The problem with Cygwin as I remember it was DLL hell. You'd have applications (such as a OpenSSH port for Windows) which would include their own cygwin1.dll and then you'd have issues with different versions of said DLL. Cygwin had less overhead which mattered in a world of limited RAM and heavy, limited swapping (x86-32, limi…

Meanwhile those that complained about Java, now ship a whole browser with their "native" application, and then complain about Google taking over the Web.

I think those are two solidly different camps of people

Re: Windows 9x Subsystem for Linux

#85

Post by radlad »

Fnoord wrote: post #20
rahen wrote: post #10

Before WSL, the best ways to run unmodified Linux binaries inside Windows were CoLinux and flinux. http://www.colinux.org/ https://github.com/wishstudio/flinux flinux essentially had the architecture of WSL1, while CoLinux was more like WSL2 with a Linux kernel side-loaded. Cygwin was technically the correct approach: native POSIX binaries on Windows rather than hacking in some foreign Linux plumbing. Since it was me…

Cygwin is way older than CoLinux. CoLinux is from 2004. Cygwin was first released in 1995. The problem with Cygwin as I remember it was DLL hell. You'd have applications (such as a OpenSSH port for Windows) which would include their own cygwin1.dll and then you'd have issues with different versions of said DLL. Cygwin had less overhead which mattered in a world of limited RAM and heavy, limited swapping (x86-32, limi…

> Cygwin had less overhead which mattered in a world of limited RAM and heavy, limited swapping (x86-32, limited I/O, PATA, ...).

Maybe so, but my memory of Cygwin was waiting multiple seconds just for the Cygwin CLI prompt to load. It was very slow on my machines.

Re: Windows 9x Subsystem for Linux

#86

Post by anthk »

keepamovin wrote: post #81
anthk wrote: post #38

Earlier quoted context omitted.

Wait until you find IE was released for Unix, using some Win32 shims. And... die hard Unix sysadmin ran it under FVWM and compared to Netscape wasn't half bad. Both propietary, but sadly NScape didn't open Mozilla yet, and the rest of the alternatives such as Arena/Amaya coudn't compete with 'modern' CSS features and the like.

Speaking of vintage IE and Netscape on old Win, it's actually still possible to use them to browse the modern web if you proxy it. I built a Win9x compatibility mode for BrowserBox that does exactly this ( https://github.com/BrowserBox/BrowserBox/blob/main/readme-fi... ). Ur modern server does all the rendering, and it outputs a client link specifically designed for legacy browsers like IE5, IE6, and Netscape running…

There are better ways:

- Retrozilla with some about:config flags disabling old SSL cyphers and new keys to enable newer ones

- Iron TCL maybe with KernelEx and BFGXP from https://luxferre.top reading gopher and gemini sites such as gemini://gemi.dev proxying all the web bloat and slimming it down like crazy

- Same Gemini URL, but thru http://portal.mozz.us/gemini . Double proxy in the end, but it will be readable.

Re: Windows 9x Subsystem for Linux

#87

Post by anthk »

maybewhenthesun wrote: post #61
keyle wrote: post #30

I thought this was about running windows 9x within linux. Is there such thing without virtualisation?

You can setup handlers to automatically launch windows executables using wine/proton . This trickery is called binfmt_misc , which is a linux kernel system to associate random binary files with custom userspace 'interpreters' I have had it working in the past. And while it is kinda neat I prefer manually running 'wine program.exe' to have a bit more control. I have seen reports that a binfmt_misc setup + wine is good…

Is wine compatible enough with Iloveyou.vbs?

Re: Windows 9x Subsystem for Linux

#88

Post by toast0 »

Fnoord wrote: post #20
rahen wrote: post #10

Before WSL, the best ways to run unmodified Linux binaries inside Windows were CoLinux and flinux. http://www.colinux.org/ https://github.com/wishstudio/flinux flinux essentially had the architecture of WSL1, while CoLinux was more like WSL2 with a Linux kernel side-loaded. Cygwin was technically the correct approach: native POSIX binaries on Windows rather than hacking in some foreign Linux plumbing. Since it was me…

Cygwin is way older than CoLinux. CoLinux is from 2004. Cygwin was first released in 1995. The problem with Cygwin as I remember it was DLL hell. You'd have applications (such as a OpenSSH port for Windows) which would include their own cygwin1.dll and then you'd have issues with different versions of said DLL. Cygwin had less overhead which mattered in a world of limited RAM and heavy, limited swapping (x86-32, limi…

> Java specifically had a bad name, and back then not even a coherent UI toolkit.

Java was ahead of its time, now nothing has a coherent UI toolkit.

Re: Windows 9x Subsystem for Linux

#89

Post by aa-jv »

actionfromafar wrote: post #37
aa-jv wrote: post #25

Oddly enough, I could kind of use this right now. I have some software which used SCSI (Adaptec WNASPI32.dll) calls to administer a device over the SCSI bus .. would this Subsystem be usable for that, or does it still require I build a WNASP32.dll shim to do translation?

So, you have Windows software. This "Windows 9x Subsystem for Linux" just boots Windows 95. I don't know what you would use the Linux part for. Care to explain more what you want to do? If you want to run your windows software in Linux, you could try Wine. Wine seems to have support for WNASPI so it's possible your software would just work. (You might have to run Wine as root I guess, to get access to the SCSI device…

I need raw SCSI I/O to be virtualizable in the linux context, so I could run a Windows app (yes it already works in Wine), and have it 'see' a SCSI device as if it were real hardware.

Wines WNASPI32.dll is really just a facade - it doesn't provide actual SCSI services, its just there for SCSI-using apps to think they have ASPI onboard - so for my case I would need to write a shim to pass through SCSI IO requests to a Linux service - or loopback file? - to actually process the requests. I've been meaning to do this for a long time, but if there is some way I can set up a loopback file under Linux to 'pretend' to be a SCSI block device for a Windows app, I'd sure like to know if its possible ..

Post reply on HN