Hacker News Reader

The concept of containers for Windows applications running in WINE is called "bottles."

https://support.codeweavers.com/en_US/2-getting-started/2-in...

I believe it started with Cedega, but I could be wrong. That's where I first recall encountering it.

TIL. I'm gonna check this out. It's good to see that people are already working on this, because it's one of those things that, to me, just makes a lot of sense. You'd think that with the all of the layers of abstraction we have nowadays, it should be possible to run software on any underlying system in an ergonomic fashion, even if it's not necessarily efficient.

It's extremely efficient: cold starting Word from an old Office suite is much faster than starting Libreoffice. It also uses less RAM.

A few years ago I purchased a few shrink-wrapped Office on ebay for each of the versions Wine claimed to support best, tested then with wine32 and wine64, and concluded the "sweet spot" was Office 2010 in wine32 (it may have changed, as wine keep evolving)

Yes, it's 15 years old software, but it works flawlessly with Unicode xkb symbols! Since it doesn't have any network access, and each app is isolated in a different user id, I don't think it can cause any problem.

And Ii I can still use vim to do everything I need and take advantage of how it will not surprise me with any unwanted changes, I don't see why I couldn't use say an old version of Excel in the same way!

It is interesting seeing Office suites from the 90s and wondering what really needed improved. Google Docs pioneering “auto saving” in the cloud is the only one I can think of.

> wondering what really needed improved

Maybe not much?

A few months ago, I ran out of power (my mistake, I use full screen apps to avoid the distraction, so I didn't realize I was unplugged)

After plugging in and restarting Linux then the ancient version of Word I was using, I got a pleasant surprise: the "autosaved" version of the document I was editing, with nothing lost!

As for llm, Excel 2010 may not have been made for AI, but wine copy/paste and a few scripts work surprisingly well!

Autosave has been part of Excel for ages. I had it enabled back in the early 1990s with the version that was distributed alongside Word 6 as part of Office 4.3 (I don't remember the Excel version number).

Current Excel Autosave when used with ODSP is different -- changes are individually autosaved (change cell, autosave, format table, autosave). They're completely transparent to the end user.

Word is similar.

So you're saying you're using Word 2010 and have no problem with files created recently? I find it surprising that modern word .docx is compatible with 15 year old Word

Not too suprising though. It is zipped xml. Future versions may add to the xml optional nodes that can be ignored by previous versions.

The modern Word suite’s basic format was introduced with Word 2010. So as long as the person who created the doc uses features that were previously present in Word 2010 they’d be fine.

Features from later versions will either not show up or show up as boxes

Collaborative editing? "Track Changes" just doesn't hit the same way.

That’s a good one. Perhaps Google Docs is the pinnacle of office suites.

The auto-save in Google Docs is undoubtedly better, but it was possible to set an auto-save interval in minutes on Word 6.0 for Windows 3.1.

Back then, Word's auto-save updated the file that you were working on rather than creating a separate backup file. I liked that better, though there might have been a good reason for changing approaches in later versions of Word.

> and each app is isolated in a different user id

I always liked this idea; but wouldn't you run into issues with file permissions? And if not, wouldn't that mean that the program in question would have access to all your files anyhow, removing the benefit of isolation?

When I'm using Office, the files come from a shared directory accessible as Z:

I use scripts to automate everything - including allowing wine to use Xwayland (because until I start the application I want, its userid is not allowed to show content on my display)

If you want to try using wine with different user ids, try to start with a directory in /tmp like /tmp/wine which is group writable, with your windows app and your user belonging to the same group.

Cool, hoping this will become more common and easier done with help from distro's!

https://usebottles.com/

I really like the idea of bottles. I wish there was a way to bundle that up into a distro and make it invisible to the user so I could setup my friends and family with it.

Could call it "transparent bottles".

GlassBottle, hopefully the illusion doesn’t get shattered!

If you change a lot of things about a Linux system, then you're making a new distro.

Half of this incompatibility is because Linux is flexible, anyway. My system is different from your system, and did anyone test on both? If you want a more stable ABI then you need a more stable system.

You wouldn't have to change anything about the underlying system, which is the point. Containers work the same regardless of the underlying system, so they get around the various differences in everyone's individual machine. I use identical containers routinely on Fedora and Ubuntu systems at home without any issue, and I produce containers for RHEL and various other systems at work. Half the point of containers is eliminating the variability between dev systems and deployment.

Rather than everyone having to get the software working on their machine, you would get it working once in the container, and then just distribute that.

Containers work because your kernel is close to identical, and ship their own copy of everything else making them bloated, and incompatible at a user-mode level (no graphics drivers!). If my kernel was also very different from yours (which could just be a couple of kernel options or major versions) I'd need a virtual machine.

You could distribute Wine as a Flatpak platform. Flatpaks are already containers that run the same on all distros. Making a Win32 base that works in this same way using the same tooling would not be difficult.

There was Winepak (abandoned, sadly): https://winepak.github.io/

Flatpak could work better because it already knows how to factor out common parts, so it could bring in only one (or just few) version of Wine.

Unfortunately Flathub (the biggest Flatpak repository) doesn't allow Windows apps, despite it working on a technical level

https://docs.flathub.org/docs/for-app-authors/requirements says,

> Windows application submissions that are using Wine or any submissions that aren't native to Linux desktop and is using some emulation or translation layer will only be accepted if they are submitted officially by upstream with the intention of maintaining it in official capacity.

Although, I am curious why; they don't seem to have a general problem with unofficial packages, so I'm not sure why a translation layer makes any difference. It doesn't seem different than happening to use any other runtime (ex. nothing is said about Java or .net).

Probably because it's implicitly pirated. No one is sharing windows freeware this way, because there's no demand for it. It'll be MS Office, Photoshop, CAD, etc. -- stuff for which there's still no good OSS alternative, and for which the barrier to entry is high.

It would take a large organization with enough connections to cut through this. You'd probably need to cut a deal so you could distribute their software, and you'd need to provide a mechanism for users to be able to make purchases. Even then, there are various licensing challenges, because you would be distributing the same install, so thousands (or millions) of "installs" would effectively have the same serial or license number.

It's nontrivial, but the basic idea is straightforward and doable. The challenge is how windows software is distributed and licensed, not anything technical.

I am just thinking out loud. Wouldn't it be better then to just share the reproducible recipes similar to sharing Dockerfiles? For wine, specifically, it could be similar to just using FROM wine-1.23. As long as we keep the recipes maintained and "pinned" to their old dependencies.

I think this could work as a translation layer because containers already abstract away everything on syscall level.

There must be just a GUI for that, which can create multiple sandboxes easily, per application, and remember what you configured and installed there (and add it to the Winefile).

In regards to the sharing serials problem: You can easily diff the .reg file that wine adds there and if anything pops out in \\software, you can assume this is a custom field and offer it as an environment variable for the container?

This is similar to what Bottles [1] does, it uses a YAML file to describe the installation instructions for a Windows app here's an example: [2].

[1] https://usebottles.com [2] https://github.com/bottlesdevs/programs/blob/main/Games%2Fit...

They do cover that in https://docs.flathub.org/docs/for-app-authors/requirements#l... , but I don't buy it in the general case because Windows isn't synonymous with proprietary isn't synonymous with non-redistributable licenses. Sure, I doubt there's a legal way to ship Microsoft Office on flathub, but there are plenty of shareware programs that I think would be fine (though IANAL, ofc) right up to FOSS that happens to target Windows. For instance, Notepad++ is GPLv3[0] and WINE platinum rating[1]; why shouldn't it be on flathub?

[0] https://github.com/notepad-plus-plus/notepad-plus-plus/blob/... [1] https://appdb.winehq.org/objectManager.php?sClass=applicatio...

I don’t think it’s necessarily that either. They probably just want some guarantees that the app will keep working, instead of someone submitting 100s of wine apps and having them break eventually.

> Probably because it's implicitly pirated.

It doesn't have to be. Old software is cheap, even shrink wrapped ("new old stock")

They're just trying to prioritize linux applications, without preventing developers who want to support linux through wine from doing so.

The key difference is that applications ran under wine will always have some subtle quirks and misbehaviors that break the usability, that can be worked around by the dev when given the chance to.

This seems reasonable to me, surely it should be its own repository.

>I don't think a new distro is needed. Most commonly used windows apps can be made to work through wine

I think the idea is to provide a seamless Windows like experience so the user works exact how he expects to work under Windows. Without having to fiddle, modify configurations, wrestle with different settings. Just click and run.

Yes, which is what I mentioned in the rest of the post. You could distribute a container that has wine in it, with just the configuration necessary to get the software working in the container. It would be straightforward to write a thin abstraction layer that pulls the container (installation) and gives you an executable that you can double click on and launch.

An end user wouldn't need to modify configs or wrestle settings, because that's already done for you upstream. You just get an artifact that you can click and run. From the other posts, Proton and Steam Deck already do something similar, and this is also conceptually similar to the way AppImages, Flatpaks etc. work.

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.

That exists, it’s called SteamOS.

And if memory serves one of the important features of Proton is to control how each app is configured individually, precisely to let you do needed tweaks at a local level.

Yes, and you can do this application specific tweaking but it’s largely less required now than it was in the past.

Less required in general or by the user? I sort of had it in my head that part of what Proton did was to just bundle all of those tweaks so you didn't have to think about it, but I haven't actually looked under the hood.

Correct. Parent is misinformed.

SteamOS is very clearly Linux which is not what the blog is suggesting.

as I read it, Linux was exactly what the blog was suggesting.

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, and appimages?

The point is to leverage modern abstraction techniques so that people don't need to learn a new system.

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.

This is how Proton from Steam works