>Imagine we made a new Linux distro
Imagine we made a new shade of brown
Seriously, this is the most cliché thing you could do with Linux.
Convert Linux to Windows
311–320 of 459 posts
Re: Convert Linux to Windows
#312Earlier quoted context omitted.
At this point nobody is going to learn a new system. People already know how to write and package exes which is the whole point. > but the hacks used to make one app work can break others and vice versa I think a lot of these problems could be avoided with a singular OS with the sole goal to support windows exes.
It's possible to use docker as a package manager. I worked jobs where did exactly that, because we needed to compile certain dependencies for our application, and it streamlined the whole process. There's zero reason you couldn't create a small abstraction layer around docker so you can install "executables" that are really just launching within a container. I mean, isn't that the whole idea behind flatpak, snaps, an…
This could be done using something like llamafile, in the sense that it would be a small universal executable containing a package.
It could even support running as a self contained application on Windows, with all needed DLLs provided.
Re: Convert Linux to Windows
#313Sounds like someone wants Lindows/Linspire. https://www.linspirelinux.com/
A vendor that has to write a news item on their front page that their product is not dead? Maybe not the most attractive look.
Lindows made a splash in 2001-2002 and its purpose was to bridge the gap and offer proper support for Windows applications on Linux via a 'click and run' service.
After Microsoft sued them and they changed their name, the bubble was burst and when Ubuntu appeared its niche as a beginner distro ebbed away.
I was surprised to hear it was still alive via a Michael MJD video a month or two ago.
Re: Convert Linux to Windows
#314I've read the article and the comments with interest. I just have a question: if Windows ABI is so stable that 20-year-old programs are guaranteed to run, why are there computers with Win95 or NT that nobody dares touching lest some specific software stops working? I see plenty of these in industrial environments, but also in public libraries, corporate databases, etc.
This is usually about drivers, not applications. The Windows driver model didn’t maintain long-term compatibility.
Re: Convert Linux to Windows
#315I still can't get MS Office 365 working on Linux over Wine, while no alternatives make me comfortable. Comparing Linux and Win32 ABI on Linux is nonsense without talking about Wine compatibility.
Have you checked out OnlyOffice recently? If so, I'm curious what are the deal-breaking features you find that it lacks compared to M365.
why am i getting the vibe that onlyoffice is closed-source.
it's actually open https://github.com/ONLYOFFICE
Re: Convert Linux to Windows
#316Earlier quoted context omitted.
Is it just me or wine needs a bit more polish? Dialogs and menus are rendered with some weird microscopic font. GDI text rendering seemingly doesn't use font fallbacks, so even something like Scintilla or ebook reader don't quite work under wine.
Many commonly used Windows fonts are licensed under proprietary terms, preventing their inclusion with Wine. Winetricks[1] can be used to acquire and install a set of default fonts directly from Microsoft. Furthermore, Windows font fallback differs substantially from that of Linux and similar systems, which generally utilize Fontconfig and FreeType with font relationships defined in configuration files. In contrast,…
I installed windows fonts. AIU it's insufficient?
Doesn't wine delegate rendering to FreeType? Might as well delegate font fallback to FreeType.
Re: Convert Linux to Windows
#317Earlier quoted context omitted.
Many commonly used Windows fonts are licensed under proprietary terms, preventing their inclusion with Wine. Winetricks[1] can be used to acquire and install a set of default fonts directly from Microsoft. Furthermore, Windows font fallback differs substantially from that of Linux and similar systems, which generally utilize Fontconfig and FreeType with font relationships defined in configuration files. In contrast,…
Wine should come with fonts with the same metrics as the proprietary ones. Note that while the font file is copyrighted, the letterforms themselves are free to copy. We already had the DejaVu project recreate equivalents of existing fonts, no reason we can't have the same for the Segoe and Calibri families.
I'm more interested in font fallback that works elsewhere in linux. Rendering doesn't match anyway, so metrics isn't very useful.
Re: Convert Linux to Windows
#318I've read the article and the comments with interest. I just have a question: if Windows ABI is so stable that 20-year-old programs are guaranteed to run, why are there computers with Win95 or NT that nobody dares touching lest some specific software stops working? I see plenty of these in industrial environments, but also in public libraries, corporate databases, etc.
Because they just work. Nobody cares if their MRI machine runs Win2000, they care if the machine reveals brain cancer.
Re: Convert Linux to Windows
#319I want the opposite: id like a way to run the windows kernel, drivers and most low level OS stuff by windows, but with a Linux user Interface: Cinammon, apt and all the debian stuff. I run Mint as my main OS, but hardware compatibility is still a headache in Linux for me.
You can resurrect SFU and build a replacement GUI for Explorer. You can't get rid of Win32, but you can cover up most of it. Implementing a Personality would be the Windows-way of doing this as it is designed for just what you ask.
Re: Convert Linux to Windows
#320Earlier quoted context omitted.
It's not just about dynamically linked executables. The userland of Linux simply isn't as stable time-wise as Windows, especially when the timescale is measured in decades. As an example, the latest Atari Jaguar linker (aln) for Linux was released back in 1995. It's a proprietary, statically-linked 32-bit Linux a.out executable. To run this on a modern Linux system, you need to: - Bump vm.mmap_min_addr from 65536 dow…
> It's not just about dynamically linked executables. The userland of Linux simply isn't as stable time-wise as Windows, especially when the timescale is measured in decades. That’s exactly what dynamically linked executables are: user land > As an example, the latest Atari Jaguar linker (aln) for Linux was released back in 1995. It's a proprietary, statically-linked 32-bit Linux a.out executable. That’s not a user l…
>> As an example, the latest Atari Jaguar linker (aln) for Linux was released back in 1995. It's a proprietary, statically-linked 32-bit Linux a.out executable.
> That’s not a user land problem. That’s a CPU architecture problem. Windows solves this WOW64 which provides a compatibility layer for 32bit pointers et al.
In this specific case, it really is a user-land problem.
I've went to the trouble of converting that specific executable into a statically linked 32-bit x86 ELF executable [1], to run as-is on modern x86 and x86_64 Linux systems. Besides rebasing it at a higher virtual address and writing about 10 lines of assembly to bridge the entrypoints, it's the same exact binary code as the original artifact. Unless you've specifically disabled or removed 32-bit x86 emulation, it'll run on a x86_64 kernel with no 32-bit userland compatibility layers installed.
Just for kicks, I've also converted it into a dynamically linked executable (with some glue to bridge glibc 1.xx and glib 2.xx) and even into a x86 PE executable that can run on Windows (using more glue and MSYS2) [2].
> Windows has a similar problem with COM files (the early DOS executable format). And lots of COM executables on Windows don’t work either. Windows solves this problem with emulation, which you can do on Linux too.
These cases aren't equivalent. COM and MZ are 16-bit executables for MS-DOS [3], NE is for 16-bit Windows ; all can be officially run without workarounds on 32-bit x86 Windows systems (NTVDM has admittedly spotty compatibility, but the point stands). Here, we're talking about 32-bit x86 code, so COM/MZ/NE does not apply here (to my knowledge there never has been 16-bit Linux programs anyways).
That Windows has 32-bit compatibility out of the box and that Linux distributions don't install 32-bit compatibility layers by default is one thing, but those on Linux only really apply to programs that at best share the same vintage as the host system (and at worst only work for the same distribution). Again, try running Tux the Penguin: A Quest for Herring as-is on a modern system (be it on a 32-bit or 64-bit installation, that part doesn't matter here), I'd gladly be proven wrong if it can be done without either a substantial rewrite+recompilation or egregious amounts of thunking a 2000's-era Linux userspace onto a 2020's-era one (no, a VM doesn't count, it has to run on the host).
[1] https://boricj.net/atari-jaguar-sdk/2023/12/18/part-3.html
[2] https://boricj.net/atari-jaguar-sdk/2024/01/02/part-5.html
[3] I know about 32-bit DOS extenders, but it's complicated enough as-is without bringing those into the mix.