The funny thing (or actually sad) is Windows cannot run win16 anymore.

They're also responsible for Proton in collaboration with Valve. Codeweavers CTO has been project lead of Wine for three decades.

Too lazy to dig up the PRs, but Flathub doesn't merge Windows applications using the Wine runtime unless the submitter is also the upstream maintainer. They don't mention this requirement anywhere on the docs, they'll only tell you after you've spent 12 hours getting it to work.

Most people can use the LGPL version of Qt.

Flatpak can be pretty buggy with Wine I've had some programs misbehave cause it to eat up all my ram when using bottles for instance.

As someone who has tried this, I agree that Winelib is the way to go. Just don't go into it expecting it to "just work" without any code changes. Since NTFS is case-insensitive, it's likely that you'll have to fix your include paths to use the right case. If you used any MSVC compiler extensions, you'll likely need to modify your code to not use them or add `#ifdef __GNUC__` with alternative implementations for GCC. GCC's `-fms-extensions` can emulate some of them, but not all. Winemaker can help you with some of the more wrote aspects of this conversion, but not all of it. It will also produce Makefiles for you, but if you want a single build system that works on all platforms, I'd recommend that you use CMake with a CMake toolchain file targeting Winelib and `winegcc` instead. Visual Studio has pretty good CMake support these days, so it should look pretty much like any other Visual Studio solution when you open it there too.

Once you do get it working, you'll notice that on first run of your application Wine will create a `~/.wine` directory and populate it just like it would if you created a new Wine prefix to run a standard Windows application in. Other than that, it will feel pretty seamless. You'll even get a native application launcher for it (which is really just a shell script to run your project's `.exe` under Wine, but it's hidden from the user so it feels native if you don't look too closely.) Compiling against Winelib has the added benefit that you'll only be using win32 features that Wine supports, and can use native platform libraries (if you choose to do so when you're compiling your application, as described in the Winelib User's Guide) mixed with Windows libraries from Wine. It's nicer and works more smoothly than just running a Windows application you compiled with Visual Studio under a bundled version of Wine, in my experience.

I'm sure that you'd be able to bundle it as an AppImage, but I haven't actually tried that part myself.

Good luck!

I want to go back to making desktop programs the way we used to before they turned into web apps that bundled chrome. I know I should just use Qt but I have some experience already with win32, and all the programs I have fond memories of are written with it (foobar2000, winamp, Everything, etc).

Because, as they always say, Win32 is the only stable ABI on Linux.

Perhaps a Windows-only RAD framework? (Admittedly, I can only think of VB6...)

Visial Studio is quite good for gui.

Crossover maintained compatibility with 32-bit windows applications even after Catalina.

> https://www.codeweavers.com/blog/jwhite/2019/12/10/celebrati...

Which is kind of funny because yet again windows was a better application in terms of longevity than MacOS native.

It's a bit different. WOW64 is a compatibility layer that intercepts calls into system libraries from 32-bit apps and translates them into calls to 64-bit libraries. macOS shipped both 32-bit and 64-bit versions of all system libraries, no translation involved.

I find Office 2016 feels rather similar to current Office 365 as well. For home office stuff I'd never notice the difference.

Our company just deployed Office 2024, which is not cloud-based. There are plenty of companies that can't/won't use the cloud version.

Yes, I think up to date wine simply build dropped wine vs wine64 difference. You can check winehq builds.

Go does hardcode system call numbers on Linux, but it doesn't on Windows. Instead it follows the normal Windows convention of calling the userspace wrappers from kernel32.dll and similar libraries.

https://cs.opensource.google/go/go/+/refs/tags/go1.25.6:src/...

Unlike on Linux, the low-level syscall numbers on the NT kernel are highly unstable across releases, so programs that try to call them directly will generally only work on a very specific kernel version.

The problem is, Windows syscalls change around a lot. Keeping up with that is Sisyphean.

Pretty sure it is this one: https://github.com/ValveSoftware/wine/pull/310

Some news outlets did report on it. However, in my experience after testing the patch applied on top of Wine 11.0, both the Creative Cloud and the Photoshop installer did not work.

I suppose that the thing that the patch fixes is the "offline" Photoshop installers, which are not provided anymore unless if you ask Adobe nicely... or if you get it from third party sources. The PR's creator did say that they didn't pay for Creative Cloud, so I think it is likely that this is what happened.

This made me wonder if anyone had actually tested the patches with a legit Creative Cloud/Photoshop installer, or if everyone just ran with the PR saying "look it works now!!!" but nobody bothered to actually test it. The creator did submit their own precompiled Wine version, however that version is meant to be run via Proton, so I wasn't able to make it work because I don't know how to run things via Proton outside of Steam.

I was able to get the Creative Cloud app in Wine (set to Windows 10 mode) by using some very dubious methods, as in, I asked Claude Code to implement the stub to see what would happen because if AI is sooo good as how people are saying, it should be able to fix things in Wine... right? And surprisingly, it did actually work.

However you aren't able to use Photoshop CC 2021 (the earliest Photoshop version you can install from Creative Cloud, newer versions crash during startup) because the activation popup does not render the input controls. The reason why I think it is trying to render something is because the activation popup background does have the same color as the Adobe website and, if my memory is correct, in Windows that popup is used to ask for your Adobe account credentials.

(Sadly the PR patch does not fix the activation screen)

Of course, if you bypass the activation using... alternatives means, Photoshop CC 2021 does work under Wine, which is why you can find a lot of "Photoshop CC 2021 in Wine!" repositories on GitHub.

https://www.reddit.com/r/linux_gaming/comments/1qdgd73/i_mad...

https://bugs.winehq.org/show_bug.cgi?id=57980