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

241–250 of 265 posts

Re: Windows 9x Subsystem for Linux

#241

Post by mynameajeff »

jasomill wrote: post #190
Dwedit wrote: post #178

Earlier quoted context omitted.

MSYS2 is very confusing. When you pick "MSYS2", you are building exclusively for the MSYS2 target environment, and might not have proper compatible windows headers. When you pick "MINGW32/64", you are instead building for the normal windows environment, and get proper windows headers. But if you didn't know that, you would end up confused about why your program is not building. It doesn't help that the package simply…

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,…

> lacks support for "new" features like C99 compatibility

This made me laugh. It reminded me of course work I did in university that was clearly written many years before I took the course as it recommended we manually enable the "new" c99 standard in our compiler, which I guess survived in the documentation up through when I took the course, at which point it was still relevant since GCC was otherwise defaulting to C11 by the time I was using it.

Re: Windows 9x Subsystem for Linux

#242

Post by electroly »

skissane wrote: post #232
electroly wrote: post #96

Earlier quoted context omitted.

Technically correct by some estimation, perhaps, but Cygwin is a crazy approach, was slow (contrary to the implication of the "low cruft" claim), was not as compatible as these other approaches, required recompilation, and was widely disliked at most points in its life. There's a lot of crazy voodoo stuff happening in cygwin1.dll to make this work; it totally qualifies as "hacking in some foreign Linux plumbing", it'…

> but Cygwin is a crazy approach, was slow A lot of this is issues Microsoft could fix if they were sufficiently motivated e.g. Windows lacks a fork() API so cygwin has to emulate it with all these hacks Well, technically the NT API does have the equivalent of fork, but the Win32 layer (CSRSS.EXE) gets fatally confused by it. Which again is something Microsoft could potentially fix, but I don’t believe it has ever be…

> A lot of this is issues Microsoft could fix if they were sufficiently motivated...

They did fix it, in a sense, with WSL1 picoprocesses. Faster and more compatible than Cygwin. Real fork and exec on the Windows NT kernel. Sadly, WSL2 is even faster and more compatible while being much less interesting. WSL1 was pretty neat, at least, and is still available.

In any event, this diversion doesn't change my analysis of Cygwin. Cygwin still sucks regardless of whose fault it is. I intentionally left this stuff out of my post because I thought it was obvious that Cygwin is working around Windows limitations to hack in POSIX semantics; it's the whole point of the project. None of us can change Windows or Cygwin and they're both ossified from age and lack of attention. We have to live with the options we've actually got.

If you need a Windows build of a Linux tool in 2026 and can't use WSL, try just building it natively (UCRT64, CLANG64, MSVC, your choice) without a compatibility layer. Lots of tools from the Linux ecosystem actually have Windows source compatibility today. Things were different in the 90s when Cygwin was created.

Re: Windows 9x Subsystem for Linux

#243

Post by chungy »

Borg3 wrote: post #228
chungy wrote: post #102

Earlier quoted context omitted.

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?

There's not a whole lot of interest in making Windows 9x run well on QEMU.

These days especially, it's better to just use 86Box for those operating systems.

Re: Windows 9x Subsystem for Linux

#244

Post by tracker1 »

ErroneousBosh wrote: post #187
jesterson wrote: post #68

Earlier quoted context omitted.

And likely in ATM servicing. Just few months ago seen windows 95 error message on HSBC ATM.

For a long time all the IBM ATMs ran OS/2 Warp 4. I recently saw that running on special 16 channel DAT recorders used by the 999 service, recently as in "within the past five years". I believe they've been retired but kept around in case they need to recover tapes off them. I kept my mouth ABSOLUTELY FUCKING SHUT about knowing my way round OS/2 Warp 4.

I've completely forgotten pretty much everything about OS/2... worked support for iomega for a while covering OS/2, Jazz and 2nd level zip calls in the late 90's. I have very little desire to look back to those days.

Except it would be nice if computers were as snappy as back then... so many layers of cruft that nothing really pops. I remember I used to just disable all the NT/2K animations and it felt so nice. I built a career on web apps, but most are just really poorly written it pisses me off.

Re: Windows 9x Subsystem for Linux

#246

Post by Dylan16807 »

chasil wrote: post #208
barrkel wrote: post #108

Earlier quoted context omitted.

Cygwin bash isn't slow either. The problem is a typical bash script isn't a series of bash operations, it's a series of command line program executions. For example, someone might do something like this ( completely ignoring the need to quote in the interests of illustrating the actual issue, forking): for x in *; do new_name=$(echo $x | sed 's/old/new/') mv $x $new_name done Instead of something like this: for x in…

No, seriously, give an ash-derivative a try. Dash has been benchmarked as 4x faster than bash. The bash manpage ends by stating that "bash is too big, and too slow."

> No, seriously, give an ash-derivative a try.

To solve the problem or because you saw "slow" and "bash" and wanted to bring up something cool but unrelated?

If I go from 10 seconds of forking and .04 seconds of shell to 10 seconds of forking and .01 seconds of shell, I don't actually care about how cool and fast the shell is. And I've never had the speed of bash itself be a problem.

Re: Windows 9x Subsystem for Linux

#247

Post by ogurechny »

spijdar wrote: post #206

What's a good resource going over the architecture of Windows 3.x and 9x? I know bits and pieces, like that it has a "VM Monitor", and there's support for this sort of thing, though the details are all over the place. Most people summarized Windows as just "running on top of DOS", which is clearly not correct. Obviously, it doesn't use "virtual machines" in exactly the modern sense of the word, but there's clearly so…

Before Windows Internals book we all know (called Inside Windows NT in its first editions), there was Windows Internals and other books and articles by Matt Pietrek. It starts from disassembly of WIN.COM studying the insides of DOS to figure out under which more or less common version of MS-DOS Windows is being run.

Other well known anecdotes and pieces:

https://jacobfilipp.com/msj-index/

https://web.archive.org/web/20240318233231/https://bytepoint...

Re: Windows 9x Subsystem for Linux

#248

Post by l8rlump »

andai wrote: post #93

Is this person a wizard? To me, this seems an impossible feat. But I wonder how it seems to people who understand how it works? I'm reminded of this joke: Two mathematicians are talking. One says a theorem is trivial. After two hours of explanation, the other agrees that it is indeed trivial.

Now I know two mathematician jokes. The other one is "A mathematician is a device for converting coffee into theorems."

Re: Windows 9x Subsystem for Linux

#249

Post by ErroneousBosh »

tracker1 wrote: post #244
ErroneousBosh wrote: post #187

Earlier quoted context omitted.

For a long time all the IBM ATMs ran OS/2 Warp 4. I recently saw that running on special 16 channel DAT recorders used by the 999 service, recently as in "within the past five years". I believe they've been retired but kept around in case they need to recover tapes off them. I kept my mouth ABSOLUTELY FUCKING SHUT about knowing my way round OS/2 Warp 4.

I've completely forgotten pretty much everything about OS/2... worked support for iomega for a while covering OS/2, Jazz and 2nd level zip calls in the late 90's. I have very little desire to look back to those days. Except it would be nice if computers were as snappy as back then... so many layers of cruft that nothing really pops. I remember I used to just disable all the NT/2K animations and it felt so nice. I bui…

> Except it would be nice if computers were as snappy as back then... so many layers of cruft that nothing really pops.

You should try Haiku: https://www.haiku-os.org/

It's actually pretty usable these days, at least on Thinkpads and other "generic Intel chipset" machines.

Re: Windows 9x Subsystem for Linux

#250

Post by roytam87 »

rep_lodsb wrote: post #180
dlcarrier wrote: post #168

Earlier quoted context omitted.

The primary function of modern operating systems is to allow multiple programs to run, without interfering with each other, even if they try too. This means that each program can only read its own limited amount of memory and only gets to use the processor for a limited time, before another program gets a turn. Windows did not start using those features until Windows NT, which XP is based off of. Through Windows 98,…

That's greatly oversimplified, or less generously, just flat out wrong. Win32 programs have always had their own isolated address space. That infamous BSOD is the result of memory protection hardware catching an access to something outside of that address space. When you open a DOS box, it uses the paging and V86 hardware mechanisms to create a new virtual machine , even though it shares some memory with the instance…

win32 programs in win32s shares same address space.
Post reply on HN