I want a Linux Subsystem for Windows 9x or MS-DOS :P
Isn't this exactly that but just named incorrectly?
Windows 9x Subsystem for Linux
191–200 of 265 posts
Re: Windows 9x Subsystem for Linux
#192Earlier quoted context omitted.
> 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.
Qt looks nice as a user and gnome gtk isn’t too bad either
Wx isn’t bad either. https://wxwidgets.org/
You don’t get an app that looks the same across platforms. You do get apps that look like they belong on your platform, even though the code is cross-platform. It uses the native toolkit no matter where you run it across Windows, GTK, Qt, Motif, macOS/Carbon, macOS/Cocoa, and X11 with generic widgets.
Older platforms are also supported, like OS/2, Irix, and OSF/1.
https://wiki.wxwidgets.org/Supported_Platforms
It’s a C++ project, but it has bindings for most of the languages you’d use to build an application. Ada? Go? Delphi? Ruby? Python? Rust? Yes, and more. https://wiki.wxwidgets.org/Bindings
Re: Windows 9x Subsystem for Linux
#193Before 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…
Nowadays MSYS2, which does depend on cygwin under the hood, offers such a package manager (pacman of Arch Linux) and it is quite a user friendly to run native POSIX binaries on Windows without a linux VM.
It's annoying to wade through six different versions of the same package for different runtimes and word sizes. Heaven forbid you accidentally install the wrong one.
Re: Windows 9x Subsystem for Linux
#194Earlier 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,…
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 loading.) Having the code page correct is enough to support Unicode filenames and Unicode text in the GUI.
It just won't provide UTF-8 locale support for the standard C library.
Re: Windows 9x Subsystem for Linux
#195Before 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…
I used cygwin pretty heavily in the late 90s and early 2000s. It was slow. I had scripts that took days to run dealing with some network file management. When I moved them over to linux out of frustration (I think I brought in something like a pentium 90 laptop, gateway solo I think?) they were done in tens of minutes.
I'm sure they did the best they could ... it was just really painful to use.
Re: Windows 9x Subsystem for Linux
#196I know there’s a small hobby industry of people creating Windows 9x compatibility shims for later Windows APIs… but who needs that when you can just run Linux apps?
Re: Windows 9x Subsystem for Linux
#197Earlier 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…
I used cygwin pretty heavily in the late 90s and early 2000s. It was slow. I had scripts that took days to run dealing with some network file management. When I moved them over to linux out of frustration (I think I brought in something like a pentium 90 laptop, gateway solo I think?) they were done in tens of minutes. I'm sure they did the best they could ... it was just really painful to use.
This matches me experience as well. Some of my earliest rsync experiences were with the Cygwin version and I can remember scratching my head and wondering why people raved about this tool that ran so slowly. Imagine my surprise when I tried it on Linux. Night and day!
Re: Windows 9x Subsystem for Linux
#198Huh - I didn’t know Linux had a usermode $ARCH! Or maybe it’s an earlier fork? The kernel version looks to be 6.9.
(To clarify: while the kernel is actually running at ring 0, to act as a driver it seems to use the usermode profile.)
Re: Windows 9x Subsystem for Linux
#199> "Much of the actual Win9x kernel integration including context switching lives in the Linux kernel."
Does it live there irrespective of this project? Or is that part of the patching?
Re: Windows 9x Subsystem for Linux
#200VxDs and Watcom C... now those are names I haven't heard in a long time.
Do any screen editors work in the command prompt windows? Try with "export TERM=ansi".