> WoW64 thunks are implemented for essentially all Unix libraries, enabling a 32-bit PE module to call a 64-bit Unix library. Once the remaining direct PE/Unix calls have been removed, this will make it fully possible to run 32-bit Windows applications without any 32-bit Unix library.
Every windows program has to (eventually) call a Linux library, since Wine emulates Windows on top of Linux.
Take for example "decoding an MP3 frame". A 32bit program calls a Windows API to decode an MP3 frame, that gets intercepted by Wine and forwarded to libmpg123. Since it's a 32bit program, you need (or needed, until now) the 32bit mpg123 library to handle the request.
So it's not a matter of a Windows program actually calling a Linux library, but rather Wine forwarding the function call
Forwarding 32bit calls to 64bit functions sounds simple, but it is incredibly complex. It might be simple for a function that only takes an int as argument, but on Windows, functions often take pointers to Windows structures, and those structures are often different between 32 and 64 bit. You have to translate them on-the-fly....
I know how Wine works, and in my example I explicitly said "API". And I don't think I ever said something about ARM or the RaspberryPi?
My point was to explicitly make it simple to understand, as most people don't know what thunks are, or trampolines, or the differences between protected mode and long mode. And yes, I called Wine an emulator, because that's what it is...
The word is overloaded and the implication that emulator means ISA emulation is why Wine for a time adopted that expansion. It still very much emulates the Windows ABI and API.
It's original name was "Windows Emulator", even, hence the abbreviation Wine.
WINE is implemented using Unix libraries underneath. And since it essentially supports and entire modern OS, there is quite a bit of depdencies. The wine package available in Arch Linux for example depends on 72 lib32-* packages. The majority of these are just 32 bit compiled versions of standard libraries that a user on x86_64 will have a native 64 bit version of already.
I used to keep trying it for running various poker clients on Linux but none ever really worked properly.
I also tried DelftShip (hull designer) on MacOS but couldn't get it to work properly, while an old version of FreeShip (from which DelftShip was forked) did however work IIRC.
In short I've tried various apps throughout the years but have found nothing that's actually worked well enough to keep it running to this day. Last time I tried Wine must've been around version 5 though, maybe things have improved since?
Valve's Proton is a fork+bundle of Wine. Proton is widely used, and works fabulously and often seamlessly to play Windows games on Linux, to the degree that Windows games often work better on Linux than they do on Windows, and Windows games often work better on Linux than the Linux versions of the same game.
I would guess that the number of Proton users is orders of magnitudes higher than the number of vanilla Wine users.
Proton is so good that it probably erased 90% of the vanilla Wine gaming community, and if you ask anything about running a Steam game on Wine, the answer is "use Proton." Which is a problem for Mac users wanting to run games (Proton is Linux-only), but then again there was never much of an expectation for that.
Nah, even Wine is quite good these days. Lutris doesn't bundle Proton but still works quite well. I guess really the secret sauce is more DXVK. It's kinda nuts how like 10 years ago we went from maybe 10% of games working well on Wine to 10% of games don't work well under Wine.
Which by the way, are hiring developers: https://www.codeweavers.com/about/jobs (General Wine Developer + Software Support Engineer), I'm not affiliated, just like to game on my Steam Deck and more people making it even better, would be nice for me personally :)
Valve's interest is in selling the Steam Deck handheld, which is an Arch Linux PC that just defaults to a friendly console UI, playing Windows games transparently through Proton. It's probably the best example of average consumers using full-blown desktop Linux.
For now, you can draw the line for what he means at GNU since SteamOS is that while ChromeOS is not. But if someone made a GNU/Linux that holds your hand everywhere like ChromeOS, it would probably be "not real Linux." So maybe the better designation is "Linux for nerds."
I can't say enough how much of an advancement to Linux gaming Valve and Proton has been. The fact that I can pick up my steam deck and play 99% of PC games flawlessly is amazing compared to the state of Linux gaming a decade ago.
I am willing to agree. I am not exactly a super casual user, but I ran into issues with setting up Wine for some games. Proton, by comparison, allowed me to play Fallout 3, Final Fantasy XI and Adom with no special settings ( although admittedly, Adom technically did not need that treatment ). It is crazy how good it has become.
Just for proton work alone, Steam gained a lot of goodwill from me. And that is not to diminish Wine. There is clearly a need for a tool that has the ability to run custom verbose scripts, but Proton mostly solved the gaming piece.
It can't diminish wine, because the work flows mostly from folks employed by codeweavers who contribute to proton, and then when fixes can be generalized, they get merged back into wine proper.
What exactly is the difference between Wine and Proton?
I just use Wine, mostly with older games from GOG.com, and it seems to work alright in all but a few exceptional cases (and has for long before Valve got involved with Proton).
Proton is both a friendly fork of Wine + a wrapper around Wine + forks of libraries and tools used by both Wine & Proton. Some of the forks are more blessed & tested versions than forks.
I don't know what they did exactly, but it sounds way, way better than regular Wine. Like, it's a coin toss whether a game works in regular Wine at all, and another coin toss for whether it works well. Even the Steam client is ultra glitchy in Wine. Which makes sense, it's really hard to emulate a Windows environment.
Steam does a few things at once to make this system work so well. There's just Wine itself and Valve-sponsored work and improvements to it, the automatic usage of DXVK and similar newer translation-to-Vulkan systems for DirectX support vs. Wine's classic alternatives, there's Steam automatically creating wine prefixes per-game, there's a separate but related container system, the "Steam Linux Runtime" that allows both Proton and native Linux games to have a stable, known set of libraries to target and support vs. the dizzying array of distributions and versions that otherwise typifies supporting Linux.
On the other hand, having that corporate support and isolation from the system sometimes cuts both ways: stock Proton often has worse support for audio and video codecs than a classic Wine install with the proper system libraries, because Valve actually has to worry about patents and licensing for them. They've come up with a system where the layer they otherwise use for sharing cached shaders can also share transcoded media files, but it's not always a seamless experience.
Wine is major part of Proton, so if it works on proton it's usually possible to get it working on wine. (Changes to Proton branch of wine are regularly incorporated back into Wine).
What proton is - its a tested distribution of wine and its libraries AND nice wrapper around wine, that helps setting everything up so it just works.
If you want to get games working on linux, proton is the easiest and best way to go. But if you want to get some of the programs running, that are not supported under proton, wine might work.
Ok. So when I'm having issues with a game, probably I'm missing whatever version of a lib I need, or running Wine on M1 Mac is bringing its own challenges.
What does "fork of wine" mean concretely? As in, what does Proton give me that Wine doesn't? The way you make it sound is that it's a "Wine distribution"; is that correct? Or does it do more?
It's not really a fork, more like a distribution as you might be familiar with it, or built on top of Wine. Without Wine, there probably wouldn't have been any Proton.
I think parent mean "fork" in the strict sense that there are two source codes "versions" of Wine: upstream, which is the official wine you get when doing `apt-get install wine`, `pacman -Ss wine` or whatever. Then there is Valves own clone of that same codebase, but with additional patches on top of it. Many changes are game specific, at least in the beginning, but many are also generalized and eventually "upstreamed" to the official Wine repository.
So in a way, they maintain their own fork with their own set of patches, and some of those patches makes their way to the "original" Wine while some don't.
tbf what makes proton unique is that they mostly not use forks and instead work with upstream and just pin point their dependencies and use cherry-pick after they forked a major.
Proton can be used to run non-Steam games. The standard way to do it is to add the game to Steam via "Games | Add a non-Steam Game to my Library" and then enable Proton after it is added.
You can add any other executable into Steam and run it on proton that way. I used it for non-game applications with great success. Proton can also be installed and used without Steam, although the process was so involved last time I checked it was easier to use Steam as a launcher even if you have no need for it otherwise.
Games! Or more specifically, game - with dxvk I've been happily playing through my GoG DRM-free copy of Cyberpunk2077 and combined with Steam+Proton for other games I have no need of my Windows partition anymore. I'm planning on removing it entirely when I have a free afternoon to redo my partition table (I use NixOS too, so if I save my userdata I can rebuild the whole system easily).
I use it to run:
Notepad++ (I just haven't found anything I like better than it) - runs great and developer knows people use Wine to run it and makes sure it works
Kaseya Live Connect / Remote Control (Kaseya RMM system) - the thing is basically a big QtWeb app, and runs surprisingly well
TagScanner (an MP3 tag editing app, also works very well)
Sometimes I think maybe I can run Office 365 on it, but I generally decide it's not worth screwing around with. I can totally get by fine with Evolution + EWS to connect to my Exchange server, and LibreOffice for editing documents.
I remember using Notepad++ back in the day (way over a decade ago when I still used Windows), mainly for it's speed and effortlessness in opening huge files, but also quite advanced feature set.
> I just haven't found anything I like better than it
I can personally highly recommend Sublime Text. The clear downside is that it costs money and is proprietary (the free version is usable though, with a nag screen) but it's lightning fast (and as Notepad++ also handles huge files gracefully) and highly extensible (although the built-in features are way more than enough for text editor use).
For me, I've developed this workflow where I'll use Sublime or VSCode for active development, then Notepad++ for one-off files, or as a kind of on-going scratchpad. There's no reason I couldn't use the other editors the same way, but it's become so ingrained into how I operate it's difficult for me to change my ways.
Put me down for NPP as well, and also PuTTY. Yes, I know that there are hundreds of SSH clients on Linux, but how many of them are also telnet and serial terminal clients as well? More importantly, it's what I'm used to.
If by "SSH clients" you mean terminal emulators, the answer to
> but how many of them are also telnet and serial terminal clients as well?
is "all of them", and they all support way more such things than PuTTY too. I think what you're used to (e.g. the GUI rather than command line switches) is the only thing that counts here, as PuTTY is inferior in almost every other way.
Terminal emulators, in my experience, are not sufficient to establish connections to serial devices on their own, especially not through the GUI. PuTTY does that without me having to look through a man page or --help dump or, as is more often the case, StackOverflow.
I mean SSH clients. Terminal emulators don't do SSH on their own either.
Sorry if I came off a bit harsh. There is no problem with using PuTTY if it works for you and is what you're used to. If you're interested in learning more terminal stuff, you may be able to do better for your purposes. Infodump follows.
A terminal emulator is the interface through which you access programs like SSH clients and Telnet clients, much like a web browser is an interface through which you access videos, news, etc., so it doesn't make much sense to talk about what it does on its own - it exists to run other programs.
Technically, any program on Linux can access serial devices; even basic commands like cp and cat can talk usefully to serial devices for some simple purposes (e.g. short plotter drawings can just be sent to the serial port with cat, and my plotter will draw them - drawings bigger than the plotter's buffer need something a little more sophisticated).
PuTTY bundles together a terminal emulator, SSH client, and Telnet client. When you connect to something it's running the appropriate client in its terminal emulator. It's not an SSH client that supports Telnet, and its terminal emulator doesn't do SSH on its own (e.g. mintty is based on PuTTY's terminal emulator, without the SSH client).
Edit: Actually I apparently already knew this since the Linux laptop next to me has PuTTY native on it. I don't know why I had included it in my mental list of things I always install WINE for.
Wasn't NotepadQQ a supposed Linux alternative?
(I'm normally fine with whatever default GUI text editor there is, so I'm not sure how it compares to Notepad++).
I'm a bit nuts, but I run Wine headless to host a niche product server for software developed on Windows many years ago. Using Wine, I can have one profile/prefix per customer, and run multiple customers on a single box without needing any Windows licenses. The way the original server was developed only expected a single customer per box (since they would be running it on their private network), but many customers have opted to have me host it for them, and a big rewrite was out of the question.
It's been working out nicely for many years, with only a few bumps and bruises in the early stages getting everything stable.
I spent an hour trying to get Ark Survival Evolves server trying to run on wine a while ago. But gave up after a while. I used to host a service providing ark servers :P
I've got some fixes in for wine. But debugging Wine can be quite a challenge, you need a lot of low level understanding.
Agreed, it can be a challenge to debug. I probably spent a couple weeks getting everything working for my app server the first time around. It helps that I control the source code though, so I can lean on some old fashioned text logs to pinpoint problem areas. Wine updates can sometimes break things too (had some problems with early 6.0 releases breaking the network stack), so it's important to hold Wine updates and test new versions thoroughly before updating.
It's an app I coded myself over the better part of 15 years now - it's nothing too exciting, just a LoB app for contract administration with a small but dedicated user base. The version I worked on before the current one was a local-only app. The current version was developed to be client-server. Toyed around with doing a web app all those years ago, but it didn't feel like the web as an app platform was quite there yet. I also had a fair amount of legacy code that was still useful that I didn't want to throw away completely.
Anyway, after focusing so much time and effort on the client-server apps, it is finally time to focus on a web front end (only 10 years or so late!). So I've written a middle-tier (running under Wine) with Nginx in front it. The middle tier translates JSON over HTTP->COM calls, then translates COM->JSON over HTTP on the way back. It's a bit of a Frankenstein's monster, but it works and the approach has meant I can keep a tonne of existing code and keep adding features and improving existing features, which has been nice.
We use mingw to cross-compile binaries for Windows, and wine to run the CI tests. It's quite nice to deliver Windows binaries and never need to touch Windows.
Yeah that makes me nervous. At the very least just use a VM to test your production artifacts before deployment. Must not be a very important product they're releasing.
It has never actually broken (or at least, no one has reported that if it did). But also it's an open source project, we provide the exe's best effort, if it's important you can compile it yourself. I have zero interest in using Windows even for one second if I can help it.
I've always used it for IrfanView ... I haven't found anything close in all in one place functionality which is Linux Native.
EDIT: There are two applications that I wish could be installed/run on WINE, but so far there's no luck: Tidal Music Windows Client, Google Drive Client.
It is amazing that both two companies refuse to have a decent client for their applications in Linux :(
For Google Drive I can deeply recommend paying once for https://www.insynchq.com/ using it myself for years and have not touched the official client for years (and I'm on macOS).
I use Wine on Linux for Carlson Hulls (Delftship and Freeship being not as useful for stitch-and-glue). I tried to install wine on macos recently, and I want to say it wasn't supported for the most recent versions, but I don't remember the details.
Most of my designs have in fact been with hard chines. I must've tried Carlson Hulls at some point (because the name sounds familiar) but I'm not sure why I never started using it. I'll give it a shot next time I get inspired!
It's got a super weird text format for the input. If you're interested, email me at my user id at gmail and I can give you some jupyter notebooks that parse offset tables in excel to make the .hul file.
I use Wine on Arch Linux, and pretty much use it to play games, and occasionally the HP PC Connectivity Kit for my HP48G+ calculator (this program was built for Windows 95. I wonder if it'd even work on modern Windows with a USB serial device that I have... but with Wine, I just symlink /dev/ttyUSB0 to COM1: and I'm good).
It has a very high success rate for me, being able to run almost every game I throw at it flawlessly, both old and new.
Everyone using a Steam Deck, and almost everyone using Steam on Linux, is using Wine to run their games. It is shipped with the Steam client these days.
I use it on Fedora to run Arturia software synthesizers, which I load into my DAW (Bitwig) via yabridge. It runs pretty much everything in their V Collection series (at least I haven't found anything that didn't).
I use it for Total Commander. When I moved to Linux, I tried mc and Double Commander but I missed TC interface. I installed wine and with the help of winepath I could use all my custom tools shortcuts. There is a wiki section on the official TC site with great tips how to use it this way: https://www.ghisler.ch/wiki/index.php/Total_Commander_under_...
Almost exclusively games, under Linux. This includes games that just came out - more and more they work out of the box thanks to dxvk and the wine-staging patches.
I use wine to run the MSVC compiler in a Linux container, making it easier to manage in comparison to the windows containers, which require a Windows/Hyper-V capable host.
Bonus, the wine+msvc combination is still smaller than using a windows container.
Works fine, also for MSI file generation with Wix:
I tried to use Wine on MacOS for 4 beloved Windows programs I still cant live without 10 years after I moved away from M$:
- Foobar2000 (unfortiunatly very CPU heavy with audio problems, some incompatibilities)
- Subtitle Edit
- Advanced Renamer
- Faststone Viewer
All fairly ordinary tools but I didnt find suitable alternatives in all these years. Especially FB2K. Hope the Macos version will soon reach feature parity!
Oh nice, I used to be a passionate Foobar2000 user as well back in the day! Can't say I have a Mac alternative nowadays though, I'm using Navidrome[0] with all my music stored on a cheap VPS, this way I can play the music from wherever (including mobile[1]).
And FastStone Image Viewer is also familiar. :) Seems like I've turned lazy (and "cloudy") in recent years, Google Photos is just so convenient.
I'm big into archiving. It's almost autistic how perfect I want my media to be named and tagged and bpm'ed and with fitting cover art and so on Foobar with the that wealth of addons helped a lot:
- Buttons to search for images with artist and album name
- complex renaming patterns
- replaygaining
- batch editing tags...
There is so much I love (ed) about it!
Haven't tried navidrome yet but was planning on installing a multiroom soundsystem with navidrom and snapcast. But that just serves a different purpise :-)
Some stuff I've successfully used on WINE (on Linux only...I've never owned a Mac):
SRIM/TRIM (http://srim.org/)
u-blox u-center (https://www.u-blox.com/en/product/u-center)
various other vendor software (e.g. power supply control GUI over serial, etc.)
As others have mentioned, gaming. I have a Steam Deck, which runs Arch under the hood using the Steam client to provide an essentially seamless gaming experience with Proton (which is built on Wine). Provides the efficiency and customizability of Linux with the gaming support of Windows in a handheld.
It does indeed, look up yabridge. I have been able to do it almost entirely issue free for many plugins (and even better, I can still keep a low sample rate).
Like the other post said, it works great (for the most part). It can fall apart when the plugin creator has some draconian activation service but I avoid those plug-ins anyway.
Proton (based on wine) for games. Can't say I really have any other uses these days since most other things either work on the web or have been ported or have much better free software alternatives.
Mainly to run stuff like Photoshop, ResourceHacker, IDA, and other Windows-only utilities/programs. For gaming, I almost exclusively use Proton-GE (through the Steam client admittedly).
For years on macOS, I used (try) to run stuff on Wine 2.7, with not terrible success. Since then, Wine has progressed leaps and bounds, although I haven’t actively paid attention to most of its changes.
If you're not using the latest distro (e.g. LTS) and don't want to compile programs from scratch, there are cases where it is easier to run the latest version of a program using the Windows version instead of the latest pre-compiled Linux binary due to requiring newer dependencies. Except for OpenGL issues that I haven't figured out yet, I found it easier to run the Windows Octave 7.3 on Ubuntu 22.04 with WINE.
I would have used it to run Macromedia Director 7 but had to resort to running Windows 98 through UTM (qemu) because I'm on an M1 Mac.
Back in the day, I used it to run Halo: Combat Evolved for PC on my Ubuntu installation. Now I have no need for this, but Wine improved over the years to a point where the game actually ran pretty well. Apparently the 1.0.10 patch for the game from 2014 now has a Gold rating on WineHQ.
I've been using it to try to run Steam, mainly to launch Portal 2 and play with friends. I'm on an Apple Silicon Mac running Ventura. It's a horrible experience. I have the macOS Steam client, and while it's a steaming pile of garbage UX-wise, it mostly works. But under Wine (or specifically CrossOver), it barely works. Here's what happens when I attempt to run Steam:
- It takes around 1 minute to get auto-logged in. The macOS client takes 11 seconds (I just timed them both).
- About half of the UI doesn't work. Fonts are missing, so there are buttons with no labels. If you scroll with the mouse, sometimes that locks up the page you're looking at and you can no longer use that page until you quit and restart the app. You can do other things and come back, but that page is dead for you now until the next app restart.
- The Library screen works about 5% of the time. The other 95% of the time, it hangs during loading the page with the little Steam icon and the 3 dots under it. In order to play Portal 2 in those cases, I have to go to the store, search for it, click on it to go to its specific page, then click on the play button.
- One or all apps will sometimes (about 10% of the time) just abort with no error message or anything. The app window and the macOS process just go away. You might be in the middle of selecting a game in the Steam client, or you might be in the middle of a game (either alone or with a friend) and it just ends.
- When playing Portal 2 everything renders fine unless you're looking at it through a Portal. When looking through a Portal, random bits of geometry from around the level are displayed among the correct geometry, some textures are incorrect or missing while others are fine, etc. Just weird drawing problems. Once you pass through the portal, everything is fine.
- It mostly plays at 60fps, but very rarely (maybe 1% of the time) starts dropping frames. That part is fairly impressive, honestly.
So yeah, there seems to be some happy path for which it works fairly well, and anything off that is just random glitches, hangs, crashes, etc. I'm having a hard time understanding why the HN crowd thinks it's so great. This seems like the main use case, and others have claimed that Valve pays CodeWeavers (who make CrossOver) to make it work with their games, but it barely even works with the Steam client. I'm at a loss to explain it.
The main target of Wine is x86 Linux not ARM macOS. MacOS doesn't support Vulkan and so that version of Wine is missing DXVK and Vkd3d for better game performance and support. It's a completely different experience.
Plus with Steam on Linux you don't need to run the Windows version of Steam at all. The native client will let you install Windows games using Proton (Valve's modified Wine essentially) by checking a box. Most stuff works very well and it's how the Steam Deck does it's thing. Some titles actually work better than they do on modern Windows like Jedi Knight II which has 3D acceleration support on Linux through Wine but not Windows 10 native.
People who use Wine (Proton really) + Steam don't use Wine to run Steam itself, they run the platform native Steam client which manages the Proton installations (multiple versions) for them. So everything is native, up until game launch, then Steam launches the game via Proton (Wine).
It works really well, considering what it is doing. I'm playing all sorts of games on Linux and my Steam Deck that I didn't even dream of being able to play before (including playing through Portal 2 on my Steam Deck currently :) ).
I'm not alone in this, you can browse a user-sourced DB of experiences over here if you want further proof: https://www.protondb.com/explore?sort=popular Everything rated gold or above runs really well and you don't experience any problems at all. Silver is mostly working ok, besides some edge-cases or aggressive anti-cheats stopping multiplayer from working.
I'm guessing that that has a lot more to do with being on Apple Silicon than anything else. Steam and all the games are compiled for x86, which means it's gotta go through Rosetta and then through Wine. Also, on macOS specifically, no Vulkan support means you have to use MoltenVK to convert the DXVK instructions to Metal, and I don't think MoltenVK has completed the work to convert all the instructions Vulkan uses.
I was impressed I could get Windows games running at all, but the experience was pretty bad as you mentioned. Titanfall 2 was real janky, no audio and the graphics were super bugged.
I use it to run my Windows games. In fact this became a bit of a hobby in itself, trying to make a game running by Wine.
If everything else fails, you can always try a full fledged Windows VM. Performance is... not like bare metal, but the results can be surprisingly good.
PDF-XChange Viewer, the only program that I know that can passably be used to fill very complex pdf forms with many fields.
Too bad crossover on mac keeps on breaking...
I'm yet to find another pdf app that can substitute it on mac...
Libs that use C# but nobody wants to try building on Linux, Windows binaries we get as-is from outside the organization, C++ code relying on MVSC non-standardness, C code relying on a custom toolchain that can't be ported...
Wine plus a bit of script has kept me using Sketchup 2016 since, well, 2016 (more or less). Once it tell me I need to get a licence - which is no longer available - a simple call to 'sketchup -r' (for 'reinstall') recreates the $WINE_PREFIX with a fresh install, ready for another 30 days. Since I only use it for personal projects like building a 23x11 meter barn, an extension to my house, a quick mockup to test whether I can transport 16 bales of insulation in a horse trailer or the server_cabinet_annex_produce_dryer I'm fine with using an "outdated" version which doesn't even know what a "cloud" is other than a fluffy thing in the sky.
I've just started exploring Wine, trying to get Windows tools working on it, and finding (with wine-5 and wine-7) that there is some slowdown (~250ms), but can't narrow it down exactly to what causes it.
It's similar times, whether it's WSL, or under crostini (chromebook), and unfortunately in both I either don't have full `perf` support, but do have `strace` working and it kind of shows that `user32` tries to load lots of fonts (but still hard to say for sure).
Wonder if someone here would know and can pin-point me how to debug this easier?
Do you mean it takes about 0.25s for the process you launched to start after you told Wine to run it? Every time you boot a Wine prefix, Wine has to "simulate" a Windows boot process (launch Explorer.exe and any other startup services, enumerate fonts and devices, read the registry from disk, etc). You can leave the prefix running in the background, which means it will start your process without having to do all the cold boot stuff. See the "-p" switch to wineserver.
Yes I have found before that font loading can really slow down wine startup. I've made wine much faster to start before by deleting all references to system fonts in its registry and then hiding system fonts from it while launching it.
That's a nice lead! - I'll try looking into that more. If you have or remember some more details - please share! Thanks!
(One of my use cases is https://github.com/mstorsjo/msvc-wine - and invocation of `cl.exe` or `link.exe` taking 250ms at each is not going to be great (then again `cl.exe` can be made to input several .cpp/.c files, but it becomes more awkward to express that at the build level).
and there's just one TTF font I want to use in the TTF folder. Then there are a bunch of references to systemwide fonts in the user.reg and system.reg registry files that I deleted manually, but I forget the exact keys - you can search for 'font' to find them. I also entered registry keys to redirect system fonts to the TTF I had provided, I think using [Software\\Microsoft\\Windows NT\\CurrentVersion\\FontSubstitutes] or maybe [1]. If you're running CLI tools this might not be needed.
If you ever launch wine in that prefix without these environment variables, it will rescan the system fonts and populate the registry again and that seems to slow down future launches.
Another thing that made a difference that I just remembered is opening winecfg 'Libraries' tab and adding an entry to set 'winemenubuilder.exe' and 'winebus.sys' to disabled. I am not sure what the consequences of the latter are but it didn't seem to break anything for my use case. There might be other inessential libraries you can disable here if they seem slow in WINE_DEBUG output, I also have winehid.sys disabled here but I can't remember if it made much difference.
I did, especially around +listdll, and made me wonder whether going to native vs builtin would do any difference, I'm slowly getting more to know it, as in the past only used it to launch a game or obscure windows thing on Linux, but now I need to know more about it.
I don't know how performance will fare in vkd3d-proton going through two layers of translation. Apple still refuses to provide native Vulkan support, so there isn't much that can be done about it.
Even on Linux there is some performance overhead comparatively to Windows, but at least it's acceptable.
Apologies for hijacking the thread, although other WINE users may have encountered the same problem: ancient software refusing to install due to wrong free space variable size.
Some very very old installers (don't ask :^) from the early 2k if not late 90s report negative free disk space before failing, very likely because they expect a shorter variable as disk free size, probably wrongly defined in the code as signed variable, and are served a longer value they can't use, so the number wraps to negative values.
I tried to mount very small partitions but that didn't work, presumably because the variable is still being overwritten by another wrong size one, so it would need a WINE patch, which is beyond my skills. Given however that WINE is being also used to run historical software that Windows refused to run ages ago, I wonder if that feature is already present and I just missed it.
Wine will report the same free value that df(1) does, and yes this can break old applications' expectation of sizes when it overflows in 32-bit integers.
Since I use ZFS and run ~/.wine on its own dataset, I set the quota to 2t and I'm golden with regards to any app I've seen. Could probably afford way smaller too, but this works for me.
It's been years since I used wine but I do recall you can specify which windows version you mimick. Perhaps if you mimick an old ass version of windows wine will behave properly? A quick Google turns up: https://superuser.com/questions/398178/can-wine-emulate-wind...
Wine works outstandingly well on every laptop where I tried it, even with dual graphics cards (Intel+AMD with the DRI_PRIME switch) etc.
However, on my main desktop with an nVidia GPU and the proprietary driver, most games show no graphics output at all. Sometimes the game windows flicker into view for a split second, so I know it loads them, but somehow the DirectX-to-Vulkan translation is not working correctly with the nv GPU driver. Even the "vkcube" demo shows the spinning cube in a window without decorations that I cannot grab/move/resize, so I guess it's an issue with the nv driver but I don't really want to switch to nouveau...
Might have to do with multiple monitors (one of which is connected to the onboard graphics), I got tired of trying to troubleshoot it after a fruitless 2 hour debugging session...
Interesting, I've never run into Wine-specific problems on my 1080 as far as I can remember (proprietary drivers). Plenty of other typical Nvidia crap, but nothing Wine. Multiple monitors and everything. Tested on Manjaro and Ubuntu 20.
One thing I remember having issues with at some point is not rebooting after a graphics driver update, causing the running programs that tried to use hardware acceleration to fail to communicate with the GPU. This was especially a problem with the 32 bit version of the driver and programs that I needed to install to get Wine installed (unless I only wanted to run 64 bit executables).
Another issue I've had with Nvidia drivers is that their Wayland support isn't as great as advertised, even with the new drivers. I can't plug in an external screen under Wayland on my laptop, for example, and with just one screen the Wayland compositor messes up the graphics state after a while. Perhaps you're (unknowingly) running Wayland and the compatibility problems come from there?
Either way, I hope you figure it out, seeing games and programs just work on Linux is kind of magical.
Hi, thanks for responding. I'm also running Manjaro (same as on my 2 laptops where everything Just Works(TM)...)
I'm running Xorg though, no Wayland, so that's definitely not it. I'll keep trying every now and then, of course, but I guess unless vkcube runs properly (like on my laptops...) things won't change
I have the opposite configurations of my machines (my desktop has an AMD GPU, but my laptop has an Nvidia), and my experience has been that the Nvidia stuff requires a lot more tinkering to get working. Because the laptop is an "Optimus" configuration (i.e. integrated graphics are used for most things, but the Nvidia card can be used for offloading), I need to use `nvidia-prime` (https://archlinux.org/packages/extra/any/nvidia-prime/) to launch things I want to run on the discrete GPU. I've had a lot of issues with the GPU overheating by default the past few driver versions, which I currently work around by disabling `nvidia-powerd` and then invoking `nvidia-smi -pl` with a custom power limit on boot. The power limit feature was only enabled one or two driver versions ago though; before that was enabled, the only setting I could find to try to mitigate the overheating when it first started happening was setting a custom max clock speed with `nvidia-smi -lgc`, which was somewhat less effective. Before the power limiting feature got enabled, I noticed a bizarre related issue during overheating where specific keys (the '1', 'a', and tab keys, but never any of the others around them) intermittently miss inputs. From googling, it seems like keyboard issues due to overheating isn't uncommon, but I couldn't find anyone with as specific issues as I was having. On a whim, I tried switching to using X11 instead of Wayland, and the keyboard issues confusingly didn't happen even when the GPU reached similar temperatures, but instead I started having issues where animations like opening a menu or inventory in games or alt tabbing between my game and something else would cause the screen to brightly flash different colors quickly. I wasn't able to figure out how to solve this, so I ended up swapping back to Wayland and using even more aggressive clock speed settings that tanked my frame rate but managed to keep the heat under control, until finally the update came that enabled the power level settings for my GPU model.
I don't know for certain that the issues were specifically due to Nvidia and not just trying to game on Linux with a powerful, insufficiently cooled GPU, but given how the AMD GPU worked for the same games with no need for any custom configuration, I'm definitely going to stick with AMD graphics whenever I end up getting a new laptop, even if I end up having to pay more to find a model that satisfies all my other constraints.
At the risk of inciting a flame war, I'll politely suggest that, while they're usually good enough, I'm not sure I'd say that AMD's drivers are quality. Not to belittle their engineers, only that I've seen enough issues to not prefer AMD for the quality of their drivers. The fact they're mainlined and FOSS is a big bonus, but that's regardless of their quality.
Beyond that, some of us need/want CUDA or other GPGPU support, which is a total nightmare with AMD GPUs, and other times the price/performance ratio leans in favor of nvidia, or some people just have nvidia cards and can't/don't want to buy new ones.
My experience with AMD (and ati before that) GPUs in the last 20 years were entirely negative. Even on Windows. nvidia has alway been a better experience.
Also, I mainly use Windows and only dual-boot to Linux on that system, so Windows driver quality is my primary concern.
Works for me. Using only AMD cards since 2009, without issues in either OS.
If you use Windows, remember to wipe it clean of NVIDIA drivers before attempting to install the AMD card, using DDU, as presence of NVIDIA drivers is well-known to cause issues.
I first used Wine about 15 years ago. Fast forward to today and I'm astonished at how well some things run.
I'm not a power-user - not even close. I just want things to "work" without any fiddling. Well luckily, most things seem to work flawlessly (for me).
Rocksmith, a video game for playing guitar, worked straight away, even interacting with my USB guitar interface. It even seems to run better than Windows.
It also runs the software for updating my multi-effects pedal & loading effects onto it (Zoom G1 Four).
Pretty impressed as these are the sort of things that force you onto Windows (at least once-in-a-while).
I actually haven't used WINE in years - I pretty much only do dev stuff on my Linux boxen now, and there are generally *nix equivalents for most any utility app you need nowadays.
Classic Windows gaming I assume is the main use case now?
> This is the release notes of a free software project.
Ironically, this statement is _also_ incomplete. It is missing key details that are meant to be inferred from 'free software project'.
> accusing the authors of "gatekeeping"
"Accuse" illuminates the core failure on my part. Gatekeep was the wrong word choice, as it implies _intent_. I do not believe that the release note writer has intentionally left out details.
I'm pointing out that many of us rely on too much assumed knowledge in our writing.
I personally make an effort to write and speak in manner that is understandable even to someone with low domain knowledge and context. I have observed that this skill has been important to my career. Because of this, I am particularly aware of instances where a writer has left out key details in their writing, because I often fill that void for the other stakeholders.
>the activity of controlling, and usually limiting, general access to something.
>the activity of trying to control who gets particular resources, power, or opportunities, and who does not:
Who is trying to control anything? Wine developers have explained PE vs elf in the past (I think even in some past release notes). This is like trying to accuse a math paper of gatekeeping because it uses notation you don't understand.
I'm unfamiliar with the term "jargon". Would you mind not gatekeeping this knowledge? /s
At some point, people have to assume a certain level of knowledge. And as you implied with your article, there's nothing stops someone from Googling jargon for more context. Others have pointed this out, but the Wine devs have talked extensively in other materials about these concepts. This is a REALLY good article about how Wine works with kernel modules end-to-end: https://wiki.winehq.org/Wine_Developer%27s_Guide/Kernel_modu...
And if THAT doesn't make sense, keep adding to the stack with more web searches and videos.
I just don't know how else someone would expect to get into a topic like this. Plus, these are _release notes_, not learning materials.
Being online doesn't change basic social etiquette.
People are giving you stuff for free, they are not forcing anything on anyone. Even if you don't enjoy their stuff, be polite and let them have a good time with people who do like it.
Googling 'PE module' returns nothing of value as 'PE' is a less descriptive, less google-able identifier than those other examples.
I should not have used the word 'gatekeep' in describing my thoughts on this topic. I'm stating that the first section of release notes could be improved by expanding the 'PE' acronym.
That's true, and there is even the Windows Preinstallation Environment (winPE) which makes it more confusing when googling "Windows PE module". Still found this[0] fairly easily.
I think that you deserved a bit of pushback on how you phrased that, but that nothing that you said beyond describing it as 'gatekeeping' was objectionable or even wrong, and that the rest of us should ease up, having seen that the job's been done.
You are completely right, and I appreciate how you didn't let a single poor word choice dominate your entire judgement of my post. You also delivered a novel thought based on the entirety of responses, rather than impulse writing out of emotion. Respect.
Woo! No more giant pile of i386 dependencies!