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

221–230 of 265 posts

Re: Windows 9x Subsystem for Linux

#221

Post by pabs3 »

foresto wrote: post #177
bityard wrote: post #141

Direct link without the social hop-through: https://codeberg.org/hails/wsl9x

Thanks. Mastodon still requires executing javascript just to read a post, so I usually ignore it. https://github.com/mastodon/mastodon/issues/23153 https://github.com/mastodon/mastodon/issues/19953

Here is a CLI for reading Mastodon instances, no account required.

https://github.com/jwilk/zygolophodon

I've been working on a WebExtension that calls out to zygolophodon and returns plain HTML to the browser. In the process of rebasing it over recent changes but here is the working webext-old branch:

https://github.com/jwilk/zygolophodon/compare/master...pabs3...

Re: Windows 9x Subsystem for Linux

#222

Post by keepamovin »

ErroneousBosh wrote: post #188
keepamovin wrote: post #76

Earlier quoted context omitted.

If you're dealing with weird legacy 9x systems in 2026, another headache you've probably run into is getting them to talk to the modern web (since modern TLS and JS completely break old browsers). I actually built a win9x compatibility mode into BrowserBox specifically for this kind of weirdness. You run the server on a modern system and launch it with bbx win9x-run, and it proxies the modern web to legacy clients. I…

Ah! I solved that easily enough. Internet Explorer 8 works okay for the webby front ends to operate the transmitter equipment. How do you run that, in this day and age, safely? Run it in Windows XP, in a VM. Now here's the clever bit - qemu will allow you to expose the keyboard, mouse, and framebuffer as a VNC server. So you set up Apache Guacamole to point a VNC client at the VM, and then "normal people" can log in,…

That is pretty cool, man. VM with XP in QEMU sending VNC frames to Guacamole clients on the web.

BrowserBox is basically the same pattern as this setup (streaming graphics from some browsing substrate somewhere to web clients) except architecture is different: a modern box on the same private network runs the BrowserBox server, and the win box (QEMUd or otherwise) connects to its http endpoint, using whatever browser it has (tested back to IE5 even, tho that's a way more buggy browser than IE6. IE8 should be golden). That way you get the full modern web, no compromises. But crucially the web is not actually accessing your legacy box. So, no comrp0mises, ie., no easy vulns. Especially a concern for older browsers. Plus, we've got policy controls to lock down capabilities (copy, paste, URL lists, internal IP access controls, etc).

In your case it sounds like you are running the webby servers on the XP box, too, so BrowserBox would link back into those over the same private network, render them on the modern box, send it back to the XP box, then clients can connect over the QEMU VNC bridge you already have.

Alternately you could just do away with the Win XP browsing, and have BrowserBox connect to your webby endpoints for transmitters wherever you run them, and then expose that browsing graphics stream to clients over whatever endpoint you want. Many options!

I like your ffmpeg out setup. How did that go? Share more about that? Pretty interesting, I love this old architectures, and legacy systems compatibility quests.

Re: Windows 9x Subsystem for Linux

#223

Post by keepamovin »

anthk wrote: post #173
keepamovin wrote: post #76

Earlier quoted context omitted.

If you're dealing with weird legacy 9x systems in 2026, another headache you've probably run into is getting them to talk to the modern web (since modern TLS and JS completely break old browsers). I actually built a win9x compatibility mode into BrowserBox specifically for this kind of weirdness. You run the server on a modern system and launch it with bbx win9x-run, and it proxies the modern web to legacy clients. I…

Kernel-Ex and Basilisk and friends (Serpent browser or whatever it's called) plus some TLS stuff can browse the modern web just fine. JS, OTOH... get NoScript ASAP and block selectively. Or better, ditch the web completely and head to Gopher/Gemini.

I agree there seem to be other options. But they all have fractal-edged interfaces to the legacy stuff, and you need to be careful about, as you said, script issues and vulns. That's the BrowserBox advantage - a fully modern, remote rendering system that can still be accessed from the legacy box, but securely. And easy setup. Admittedly, doing it the way you're doing is probably free - BrowserBox is not free - but it saves you lots of this delicate management of config, etc. Because the interface model is cleaner: just one HTTP endpoint that legacy browsers can actually access, streaming them fully modern browsing that's rendered elsewhere, securely.

I get the degradation to Gopher as a way to solve many issues, but many things just don't work there. And it may have its own vulnerabilities.

Re: Windows 9x Subsystem for Linux

#224

Post by jasomill »

Dwedit wrote: post #194
jasomill wrote: post #190

Earlier quoted context omitted.

And just to add insult to injury, you probably don't want MINGW64 either, as it relies on the ancient MSVCRT.DLL C runtime library that lacks support for "new" features like C99 compatibility and the UTF-8 locale, and that Microsoft never supported for use by third-party applications in the first place. Instead, you either want UCRT64 or CLANG64, depending on whether you want to build with the GNU or LLVM toolchains,…

It's still useful to use MSVCRT in certain circumstances, such as targeting the earliest 64-bit versions of Windows. As for UTF-8 support, it's the manifest file that determines whether Windows sets the ANSI code page to UTF-8. (There's also an undocumented API function that resets the code page for GetACP and the Rtl functions that convert ANSI into Unicode. But this would run after all the other DLLs have finished…

Sure, or older 32-bit versions of Windows for that matter, or for building software that hasn't been ported to UCRT.

I can certainly relate to this: I'm currently sitting on a request for an enhancement to a product (currently running on a 32-bit Windows 10 VM) with a build system that has never been updated to support any Microsoft platform other than MS-DOS, or toolchain newer than Microsoft C 5.1.

Re: Windows 9x Subsystem for Linux

#225

Post by mech422 »

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…

I used to use LOADLIN.exe - worked pretty, IIRC

Re: Windows 9x Subsystem for Linux

#226

Post by jasomill »

red_admiral wrote: post #33
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…

Developing on cygwin, however, was a right pain. If a C library you wanted to use didn't have a pre-built cygwin version (understandable!) then you end up doing 'configure, make' on everything in the dependency tree, and from memory about two thirds of the time you had to edit something because it's not quite POSIX enough sometimes.

Reminds me of a fun weekend I spent ~5 years ago building the newest version of every GNU program I could get to build on NEXTSTEP 3.3 (running on 68k NeXT hardware) without major changes.

Re: Windows 9x Subsystem for Linux

#227

Post by dataflow »

jibal wrote: post #213
dataflow wrote: post #133

Earlier quoted context omitted.

I believe this wasn't really even a joke, but a real story that got distorted as joke: https://hsm.stackexchange.com/a/8054

I don't think you understand how jokes work. They are mostly "distortions" of real dialog or events to add incongruous or absurdist elements. Here, Hardy's not uncommon momentary doubt about whether a statement really was obvious, while faintly amusing, is made into a joke by turning the momentary doubt into a 15 minute excursion. People then riff on the joke by turning that excursion into a mathematician presenting…

> I don't think you understand how jokes work.

That makes sense, I was just born yesterday.

Re: Windows 9x Subsystem for Linux

#228

Post by Borg3 »

chungy wrote: post #102
Borg3 wrote: post #47

Hmm I wonder how stable it is.. It cannot render correctly Window control buttons (Minimize, Maximize, Close). If it fails on such basic task, I wonder where it crashes...

That's a graphics driver problem. Fairly common to see when running Windows 9x/Me under QEMU.

Hah, amazing.. And unresolved for all those years?

Re: Windows 9x Subsystem for Linux

#229

Post by da_chicken »

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…

It's not just DLL hell. Cygwin was also notorious for being really out of date. Security vulnerabilities and missing features were both very common at one point.

Re: Windows 9x Subsystem for Linux

#230

Post by ErroneousBosh »

keepamovin wrote: post #222
ErroneousBosh wrote: post #188

Earlier quoted context omitted.

Ah! I solved that easily enough. Internet Explorer 8 works okay for the webby front ends to operate the transmitter equipment. How do you run that, in this day and age, safely? Run it in Windows XP, in a VM. Now here's the clever bit - qemu will allow you to expose the keyboard, mouse, and framebuffer as a VNC server. So you set up Apache Guacamole to point a VNC client at the VM, and then "normal people" can log in,…

That is pretty cool, man. VM with XP in QEMU sending VNC frames to Guacamole clients on the web. BrowserBox is basically the same pattern as this setup (streaming graphics from some browsing substrate somewhere to web clients) except architecture is different: a modern box on the same private network runs the BrowserBox server, and the win box (QEMUd or otherwise) connects to its http endpoint, using whatever browser…

I should do a blog post and stick it on here, right?

> In your case it sounds like you are running the webby servers on the XP box, too,

Yeah - it's a web front end to some specialised software written on I guess Microsoft C++ (if I had time, enthusiasm, and a copy of it lying around I suppose I'd wave Ghidra at it and see what happens).

I'll look into BrowserBox, that sounds handy.

> I like your ffmpeg out setup. How did that go? Share more about that? Pretty interesting, I love this old architectures, and legacy systems compatibility quests.

Surprisingly well. I think you could probably stream it straight to Twitch or something if you wanted. Yeah, this sounds like a blog post.

Post reply on HN