Live data from Hacker News

Convert Linux to Windows

philipbohun.com

401–410 of 459 posts

Re: Convert Linux to Windows

#401
post #135

Earlier quoted context omitted.

The next step is to isolate the Windows applications: you could use different WINEPREFIX, but I think the better way is to do it like android: one "user" per application. It's not just to prevent applications to read other applications files, but also to firewall each application individually For example, if you don't want the application you've mapped to user id 1001 to have any networking, use iptables with '-m own…

> The next step is to isolate the Windows applications: you could use different WINEPREFIX, In case you're not aware, wine prefixes each use their own settings, but are not isolated from one another. https://gitlab.winehq.org/wine/wine/-/wikis/FAQ#how-good-is-... > but I think the better way is to do it like android: one "user" per application. This would help somewhat, assuming you don't run them all in one user's X…

> In case you're not aware, wine prefixes each use their own settings, but are not isolated from one another.

That's a great point!

I'm aware, which is why recommend instead that wine apps should each be run under a different userid: I don't want any given app to have access to anything that it doesn't absolutely need

> This would help somewhat, assuming you don't run them all in one user's X session

When I start a given wine app, the script starting it allows this user id to render on my Xwayland

It is not as secure as running each on its own X session, but wayland compositors can offer more isolation as needed.

Re: Convert Linux to Windows

#402

> I can pull down a 20 year old exe and still run it today on Windows. Try doing the same with a Linux binary that's just a year old. There's no guarantee that it will be able to run based off some update that has happened IMHO, you just compare two different things. Traditional method of installing apps on Windows is packing all dynamic dependencies with it. While on linux dynamic dependencies are shared between app…

You don't need to bundle anything from the system layer on Windows programs distributed as binaries. On Linux there is no proper separation of system libraries or optional libraries, everything could be both and there are no API / ABI guarantees. So "just bundle your dependencies" simply doesn't work. You cannot bundle Mesa, libwayland or GTK but you cannot fully depend them not breaking compatibility either.

On Windows side nobody bundles Windows GUI libraries, OpenGL drivers or sound libraries. On Linux side, system libs have to be somewhere in the container and you have to hope that it is still compatible.

You cannot link everything statically either. Starting with Glibc, there are many libraries that don't work fully or at all when statically linked.

Re: Convert Linux to Windows

#405
post #360
post #266

Earlier quoted context omitted.

Office 2013, last non Click2Run version, worked wonderfully on Wine few years ago

When I did my tests, Office 2007 and 2010 were the most stable I will try Office 2013 (I'd like a version that works well in wine64!)

I don't have the specific setup archived, but I believe my basis for it was a script included in winetricks at the time which installed Office 2013 professional based on offline 2013 proplus 32bit iso.

WineHQ reports that installer for 2013 64bit is "gold", but apps required few tweaks to be applied and Access sometimes failed.

Generally seems 2013-2016 era works on wine per few applications I checked

Re: Convert Linux to Windows

#406

Earlier quoted context omitted.

What about it

Breaks compatibility. They remove or rename functions often and openly say they are not going to maintain compatibility.

There are lots of alternative ssl libraries.

Point still stands: fixing the situation with these libraries seems like less fuss than turning Linux into windows.

Re: Convert Linux to Windows

#407

> I can pull down a 20 year old exe and still run it today on Windows. Try doing the same with a Linux binary that's just a year old. There's no guarantee that it will be able to run based off some update that has happened IMHO, you just compare two different things. Traditional method of installing apps on Windows is packing all dynamic dependencies with it. While on linux dynamic dependencies are shared between app…

I need to buckle down and watch a YouTube video on this that gives examples. It obviously comes up in computer engineering all the time, but it's something I've been able to skate by without fully understanding; from time to time I see comments like this one that seem perfectly clear, but I'm sure there's still quite a lot of nuance that I could benefit from learning.

Re: Convert Linux to Windows

#408

Earlier quoted context omitted.

Wine bottler works well for that.

Does wine and wine bottler work on the new Apple silicon macs? Maybe for the old intel machines it does but not quite sure for the new macs though.

Yeah, it does! You probably need Rosetta 2 installed first though.

Re: Convert Linux to Windows

#409

I don't think a new distro is needed. Most commonly used windows apps can be made to work through wine, but the hacks used to make one app work can break others and vice versa. Similarly, everyone needs to play around with settings individually to get things to work. What works on one person's machine might not work on another's, because there's no consistency in, effectively, configuration. The simplest solution, to…

This is how Proton from Steam works

Re: Convert Linux to Windows

#410

Earlier quoted context omitted.

> Only if you want to distribute a dynamically-linked binary Even statically linked code tends to be dynamically linked against glibc. You’ve basically said “it works but only if you use the package manager in your OS”. In other words, it’s broken and hostile for commercial 3p binary distribution which explains the state of commercial 3p binary ecosystem on Linux (there’s more to it than just that, but being actively…

Glibc is fantastically stable and backwards compatible in all the same ways , and I think you're overstating how backwards compatible windows is as well. Microsoft has the exact same dynamic library issues that Linux does via it's Microsoft Visual C++ distrubutables (as one example). Likewise, there's forwards compatibility issues on Windows as well (if you build a program in Windows 11 you'll have a hard time runnin…

Im pretty sure it’s safe to distribute Windows 11 built binaries to windows 7 and windows 10 if it’s a valid target set in Visual Studio. The c++ runtime is its own thing because of a combination of c++ BS (no stable runtime) and c++ isn’t an official part of Windows. It’s a developer tool they offer. But you can statically link the c++ runtime in which case you can build with the latest runtime on Windows 11 and distribute to an older Windows.

Linux is the only space where you have to literally do your build on an old snapshot of a distro with an old glibc so that you can distribute said software. If you’re in c++ land you’re in for a world of hurt because the version of the language is now constrained to whatever was available at the time that old distro from 5+ years ago snapshotted unless you build a newer compiler yourself from scratch. With Rust at least this is much easier since they build their toolchain on an old version of Linux and thus their binaries are similarly easily distributed and the latest Rust compiler is trivially easy to obtain on old Linux distros.

Source: I’m literally doing this today for my day job

Post reply on HN