> 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.
Other than antivirus software and maybe MAYBE kernel-level "anticheat" slop - who in their right mind does straight syscalls to the kernel?
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.
I’d like to thank them for this, specifically! I had some old applications that weren’t working in the old WoW mode.
Which was only installed for special purposes. The majority had Win10 64
64-bit Windows cannot natively run 16-bit apps because...reasons? 32-bit Windows still can, however
Except that Windows 11 is now 64-bit only
Part of Proton only. Proton is a mix of various projects. Esync, Fsync, Wine, DXVK, and more...
> Codeweavers CTO
Yes Julliard is very famous and key to the project
They didn't magically get bundled together. Proton still has a substantial amount of engineering behind it.
they employs many devs of Wine (including the project lead, Alexandre Julliard). but technically Wine is still an independent open-source project, and has many contributors from outside Codeweavers.
ntsync allows efficient and correct synchronization usage that matches logic of Windows and new wow64 allows running 32-bit Windows programs without 32-bit Linux dependencies.
The PR was well documented, does not initially appear to be related to AI, and it makes a PITA installer work FFS. Further, my own PRs to wine were accepted for less decades ago and are still in use now.
Forgive the rant, however the redditor in question was scared to send the PR to Wine due to politics. That tells me there is definitely too much middle management in an open source project.
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...
It's fair game since they don't support Linux.
[0] https://old.reddit.com/r/linux_gaming/comments/1qdgd73/i_mad...
Edit: Even worse, other people are finding it easier to get creative cloud to run on older wine versions [1], meaning that there are regressions in Wine that aren't being spotted.
[1] https://old.reddit.com/r/linux_gaming/comments/1qg9wgz/creat...
Edit 2: Worse yet, people aren't pirating Photoshop, they copy the files of a working activated Photoshop installation from Windows so they can run it under Wine [2].
[2] https://web.archive.org/web/20251105052117/https://forum.mat...
Edit 3: The guy who claimed to have fixed creative commons has posted an update [3], [4].
[3] https://old.reddit.com/r/linux_gaming/comments/1qgybfy/updat... [4] https://github.com/PhialsBasement/wine-adobe-installers/comm...
Seems like all you did is misrepresent basically everyone involved?
You can copy the PR's diffs and apply it on Wine 11.0, it is not like it doesn't work or that OP patched functions that are only available in Proton.
Seeing that people actually got it to work gets me intrigued, sadly they didn't say if they actually used an official Creative Cloud license, or if they downloaded it from the web from third party sources. Because, as I said before, the installers that OP used are not the installers you normally get from Adobe. So, if you know where OP got the installers, please share. :)
Now, it could be that Proton somehow has something else that fixes the installers, or that there is a regression between Wine 10.0 and Wine 11.0 that breaks the creator's patch. But like I said in my own posts that I linked, I can't find the exact installers that OP is using. The only time I've seen similar installers was when I was downloading pirated Photoshop copies to test it out on Wine.
I won't rule out that maybe there's a regression somewhere, I've already reported regression in Wine before (some of them were even fixed, yay!): https://bugs.winehq.org/buglist.cgi?email1=winehq%40mrpowerg...
> Even worse, other people are finding it easier to get creative cloud to run on older wine versions [1], meaning that there are regressions in Wine that aren't being spotted.
I don't think it is a regression. Hear me out:
The user was installing Photoshop CC 2023 with a installer similar to OP's installer, so I suppose that the installer also installs an older Creative Cloud version.
Maybe that Creative Cloud version does not require the stubbed function, nor does it require WebView2.
To get the RECENT, downloaded right off Adobe's website Creative Cloud installer, you will need to install WebView2 on your Wine prefix and set "msedgewebview2.exe" to Windows 7 mode. This makes the Creative Cloud work up until it tries to start it, which makes it use the stubbed function.
To workaround that, you can set Creative Cloud to Windows 7 mode, because that forces a different code path in the app which does not use the stubbed function (SetThreadpoolTimerEx was only added in Windows 8). However, this makes all apps show that it is "incompatible on your system", so you can't actually install anything from it.
My own patch DOES fix Creative Cloud in Windows 10 mode, so you are able to install Photoshop directly from Wine.
However, the patch (nor OP nor my own patch) fixes Photoshop's activation. And let's not rule out that maybe it IS actually a regression.
> Worse yet, people aren't pirating Photoshop, they copy the files of a working activated Photoshop installation from Windows so they can run it under Wine [2].
I'm not sure why you think that linking MattKC's post is a "gotcha", when I explicitly linked that post on my Reddit post AND MattKC's post also says that you need to bypass activation with GenP. So you aren't activating the application in Wine, you are bypassing the activation altogether.
But maybe you didn't notice that because I've only noticed now that my markdown was broken, because I included "(archived link because MattKC's forum is down)" within the URL by mistake, so the link didn't actually work, whoops. I've fixed that now.
I never said that Photoshop doesn't work in Wine. I said that it does work as long as you bypass activation with external tools. If you are using a legitimate copy from a Windows machine, or if you installed it via CC on Wine, or if it is a pirated copy, it doesn't matter, you WILL need to bypass the activation somehow. Which is the point I made in my post.
> The guy who claimed to have fixed creative commons has posted an update
That update was made after my post, and the installers on the creator's post are STILL not the same installers that you can get downloading from Adobe.
Unless I'm missing something and these installers can ACTUALLY be downloaded from Adobe, because I couldn't find them anywhere and the ones that I get from Adobe's website are the ones that I shared the screenshots of on my Reddit post.
___
Now, if you want to prove me wrong, please go ahead and try the creator's patch and try installing the Creative Cloud app, downloaded directly from Adobe's website.
I really want to be proven wrong because it would be really cool if you could get the Creative Cloud app + Photoshop working in Wine without needing external activation tools.
This is probably a skill issue on my part, so someone smarter than me could try getting it to work.
Because after using umu it sets up all of the override DLLs on my Wine prefix, I've tried running the Wine build directly, and I must say that the Photoshop GUI DOES render way better here, however the activation screen is still a empty white box (sometimes it does show "Loading..." in the box): https://i.imgur.com/Jxnga5W.png
But when doing this, the Creative Cloud app does not work anymore, it says that it needs to be repaired, but it fails to be repaired. https://i.imgur.com/jdQeU4t.png
This is very scuffed, maybe I should try Lutris and see what happens
Again, I really want to be proven wrong and it would be amazing if someone that ACTUALLY made it work with a PAID Creative Cloud license and used Photoshop CC 2021 WITHOUT bypassing its activation shows up and says "hey look, I got it to work and you are just stupid".
You also aren't able to install Creative Cloud with that fork, the Creative Cloud installer gets stuck on a loading loop, so I needed to copy my Photoshop + Creative Cloud installation from my other Wine prefix.
This is not me throwing the PR's creator to the curb, it is impressive that they were able to fix the installers, even though they aren't the "main" installers, and I'm pretty sure that the PR creator could fix the activation screen too, because I think the issue is similar to the ones they are fixing, they probably just didn't do that yet because they don't know the activation screen is also borked.
Their post describing their troubles is all procedural, nothing social: https://old.reddit.com/r/linux_gaming/comments/1qdgd73/comme...
That being said, apparently the 2016 version is gold-rated on WineHQ: https://appdb.winehq.org/objectManager.php?sClass=applicatio...
Do you have a version that doesn’t prompt users to use cloud services, and also does not attempt to make outgoing network calls?
I jumped off the MS train about ten years ago, but the office they shipped back then was already cloud encumbered.
That said, I haven't tried Office on wine in the last 2 years, and there have a lot of development in that time...
Is it better now?
I use it semi-regularly for quite a number of years and (consequently) various versions of Wine to run (a near current version of) LTspice. That works perfectly as far as I can tell, but it is my understanding that the maintainer of LTspice puts in some effort to assure compatibility with the then current version of Wine.
* Probably the biggest pain point for me are game launchers that use Edge WebView 2. But many games allow you to bypass the launcher.
* For DOS Games run native DOSBox and not the Windows Version inside Wine/Proton
* Install the games on a native Linux partition. Having the wine prefix on NTFS will cause weird issues.
* Use a tool like Heroic Launcher or Lutris for non-steam games. Especially for GOG games.
Applications on the other hand have problems far more often. Some don't work at all, others have bugs and limitations.
radarroark•2w ago
Rohansi•2w ago
scotty79•2w ago
Rohansi•2w ago
[1] https://avaloniaui.net/ [2] https://dotnet.microsoft.com/en-us/apps/maui
nxobject•2w ago
nine_k•2w ago
radarroark•2w ago
swinglock•2w ago
Rohansi•2w ago
wizzwizz4•2w ago
purerandomness•2w ago
badsectoracula•2w ago
An alternative in C++ would be wxWidgets which has some (light) MFC inspirations, again feeling somewhat Windowsy though not full-on MFC/Win32 since from the beginning it had to work with X Windows / Motif in addition to Win32 (and AFAIK, the Motif backend still works).
Another alternative, even more lightweight would be the aforementioned FLTK. FLTK is also designed to be statically linked with your program (though it can be linked dynamically too if you want) so it only relies on common system libraries (as an example the screenshot in [0] relies only on the C library, the C++ library -because it is needed by FLTK and it is possible to also statically link to that too- and common X11 libraries like libX11, libXft, etc that existed on any Linux desktop system for decades now -- FLTK can also support Wayland, though i haven't tested that).
[0] https://i.imgur.com/W6XbLkr.png
dfabulich•2w ago
cmxch•2w ago
Instead of making your own GUI library, you could just make a shim that translates to whatever framework you want to support.
See: https://learn.microsoft.com/en-us/dotnet/standard/native-int...
circuit10•2w ago
Rayosay•2w ago
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!
foresto•2w ago
Flathub offers the org.winehq.Wine package, which you can use in the base and base-version fields of your own package's manifest. It wouldn't cause your code to be statically linked with Wine. Your package could then be distributed from your own flatpak remote.
There was an announcement about a year ago of an effort to make a paid flatpak market, apparently to be called Flathub LLC. I don't know if that effort is still active.
https://discourse.flathub.org/t/request-for-proposals-flathu...
Winelib might also be worth considering, depending on how you are able to navigate the relevant licenses.
https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User's-G...
I think Qt would yield better results than Wine for most things. Since your comment suggests that you're making proprietary software, you would have to take special care with linking or else submit to the Qt Group's commercial license terms.
TingPing•2w ago
nomel•2w ago
zekica•2w ago
nomel•2w ago
bobajeff•2w ago
OsrsNeedsf2P•2w ago
yellowapple•2w ago
In any case, it's possible to install Flatpaks without Flathub (by distributing a single .flatpak file to be installed with 'flatpak install --user something.flatpak'), though this is obviously not as convenient. Would be interesting to see an alternative Flatpak repository specifically for Flatpak'd Windows apps.
transcriptase•2w ago
mid-kid•2w ago
If this is your distribution method, consider having the user install wine before running your app.
darthcircuit•2w ago
https://github.com/gameimage/gameimage
This started out with bundling wine in appimages, but is expanded a lot. The author created a new appimage alternative that adds some stuff to make games work more reliably. I’ve used this several times to create portable versions of old windows games for my Steam Deck. It’s awesome!
kccqzy•2w ago
treesknees•2w ago
https://github.com/Sikarugir-App/Sikarugir
https://github.com/vitor251093/wineskin