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.
I think that the ThinkPad X13s Gen1 might meet these requirements. It is my favorite ARM Linux laptop I've ever used. It has great support in Debian 13 (trixie), and it feels pretty smooth and fast. It doesn't have any fans, stays cool, and I regularly get a full day's worth of battery life out of it with margin to spare (10-12 hours). It's better than the newer Snapdragon X1 Elite based ThinkPads, in my opinion, even though it isn't quite as fast because it is passively cooled, is easily fast enough that I've never noticed it feeling "slow", has good driver support in mainline Linux and Mesa (which took a few years to be fully worked out, but is there now), and it's readily available for a good price (on eBay).
I haven't really played around with that much, sorry. I don't typically use sleep on my laptops. I prefer to either hibernate or just shutdown and start up again when I need it.
I'd guess that the X13s hardware support in Ubuntu is likely as good as Debian, and switching probably wouldn't help you much. I have noticed that newer kernel versions (notably 6.12 and later) and the latest firmware (as of sometime last year) really fixed a lot of little issues for the X13s. That probably makes a bigger difference than the distro. I'd check to see which versions you're using.
I'm hoping that the new Snapdragon X2 Elite based laptops coming out this year will beat it. Qualcomm seems to have been trying to upstream driver support for them earlier than the X1. Then it's up to what kinds of laptops OEMs offer with them.
Personally I'd still just get a used ThinkPad X13s Gen 1 on eBay at this point if I were going to buy another one today because they're available for around $400, and I don't see anything better that's passively cooled, with great battery life, and great Linux support available at the moment. I hope there will be a better, faster alternative in the near future. I'd gladly upgrade.
It's actually no longer experimental as of the Gitea 1.21.0 release. (It was released in Gitea 1.19.0 as experimental pending some hardening and additional features that they wanted to add, which have now been completed.) It is still under active development, but is a lot more mature now.
Like you, I have been using it since it was experimental, and it has been very nice.
My only complaint with Gitea Actions was that it required Docker specifically, not other OCI-compatible runtimes, but they recently added support for rootless Podman, so even that is no longer a complaint.
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!
reply