frontpage.
newsnewestaskshowjobs

Made with ♥ by @iamnishanth

Open Source @Github

fp.

Start all of your commands with a comma

https://rhodesmill.org/brandon/2009/commands-with-comma/
58•theblazehen•2d ago•11 comments

OpenCiv3: Open-source, cross-platform reimagining of Civilization III

https://openciv3.org/
637•klaussilveira•13h ago•188 comments

The Waymo World Model

https://waymo.com/blog/2026/02/the-waymo-world-model-a-new-frontier-for-autonomous-driving-simula...
935•xnx•18h ago•549 comments

What Is Ruliology?

https://writings.stephenwolfram.com/2026/01/what-is-ruliology/
35•helloplanets•4d ago•31 comments

How we made geo joins 400× faster with H3 indexes

https://floedb.ai/blog/how-we-made-geo-joins-400-faster-with-h3-indexes
113•matheusalmeida•1d ago•28 comments

Jeffrey Snover: "Welcome to the Room"

https://www.jsnover.com/blog/2026/02/01/welcome-to-the-room/
13•kaonwarb•3d ago•12 comments

Unseen Footage of Atari Battlezone Arcade Cabinet Production

https://arcadeblogger.com/2026/02/02/unseen-footage-of-atari-battlezone-cabinet-production/
45•videotopia•4d ago•1 comments

Show HN: Look Ma, No Linux: Shell, App Installer, Vi, Cc on ESP32-S3 / BreezyBox

https://github.com/valdanylchuk/breezydemo
222•isitcontent•13h ago•25 comments

Monty: A minimal, secure Python interpreter written in Rust for use by AI

https://github.com/pydantic/monty
214•dmpetrov•13h ago•106 comments

Show HN: I spent 4 years building a UI design tool with only the features I use

https://vecti.com
324•vecti•15h ago•142 comments

Sheldon Brown's Bicycle Technical Info

https://www.sheldonbrown.com/
374•ostacke•19h ago•94 comments

Hackers (1995) Animated Experience

https://hackers-1995.vercel.app/
479•todsacerdoti•21h ago•237 comments

Microsoft open-sources LiteBox, a security-focused library OS

https://github.com/microsoft/litebox
359•aktau•19h ago•181 comments

Show HN: If you lose your memory, how to regain access to your computer?

https://eljojo.github.io/rememory/
279•eljojo•16h ago•166 comments

An Update on Heroku

https://www.heroku.com/blog/an-update-on-heroku/
407•lstoll•19h ago•273 comments

Vocal Guide – belt sing without killing yourself

https://jesperordrup.github.io/vocal-guide/
17•jesperordrup•3h ago•10 comments

Dark Alley Mathematics

https://blog.szczepan.org/blog/three-points/
85•quibono•4d ago•21 comments

PC Floppy Copy Protection: Vault Prolok

https://martypc.blogspot.com/2024/09/pc-floppy-copy-protection-vault-prolok.html
58•kmm•5d ago•4 comments

Delimited Continuations vs. Lwt for Threads

https://mirageos.org/blog/delimcc-vs-lwt
27•romes•4d ago•3 comments

How to effectively write quality code with AI

https://heidenstedt.org/posts/2026/how-to-effectively-write-quality-code-with-ai/
245•i5heu•16h ago•193 comments

Was Benoit Mandelbrot a hedgehog or a fox?

https://arxiv.org/abs/2602.01122
14•bikenaga•3d ago•2 comments

Introducing the Developer Knowledge API and MCP Server

https://developers.googleblog.com/introducing-the-developer-knowledge-api-and-mcp-server/
54•gfortaine•11h ago•22 comments

I spent 5 years in DevOps – Solutions engineering gave me what I was missing

https://infisical.com/blog/devops-to-solutions-engineering
143•vmatsiiako•18h ago•65 comments

I now assume that all ads on Apple news are scams

https://kirkville.com/i-now-assume-that-all-ads-on-apple-news-are-scams/
1061•cdrnsf•22h ago•438 comments

Learning from context is harder than we thought

https://hy.tencent.com/research/100025?langVersion=en
179•limoce•3d ago•96 comments

Understanding Neural Network, Visually

https://visualrambling.space/neural-network/
284•surprisetalk•3d ago•38 comments

Why I Joined OpenAI

https://www.brendangregg.com/blog/2026-02-07/why-i-joined-openai.html
137•SerCe•9h ago•125 comments

Show HN: R3forth, a ColorForth-inspired language with a tiny VM

https://github.com/phreda4/r3
70•phreda4•12h ago•14 comments

Female Asian Elephant Calf Born at the Smithsonian National Zoo

https://www.si.edu/newsdesk/releases/female-asian-elephant-calf-born-smithsonians-national-zoo-an...
29•gmays•8h ago•11 comments

FORTH? Really!?

https://rescrv.net/w/2026/02/06/associative
63•rescrv•21h ago•23 comments
Open in hackernews

Wine 11.0

https://gitlab.winehq.org/wine/wine/-/releases/wine-11.0
439•zdw•3w ago

Comments

radarroark•2w ago
Anyone have experience with distributing win32 programs for Linux and/or MacOS by bundling wine? I take it that statically linking is out of the question, but I am guessing you could make an AppImage binary for linux that includes wine, and for MacOS you could include wine in the app bundle. I haven't tried either though. I'm interested in this so I can use win32 as a cross-platform desktop GUI library.
Rohansi•2w ago
I'm curious why you'd want this over using a GUI library that is actually cross-platform? The way you've worded things suggests to me that you're building something new.
scotty79•2w ago
Visial Studio is quite good for gui.
Rohansi•2w ago
It is. But if you mean .NET WinForms then you don't really need Wine because Wine uses Mono to run .NET executables. If using WPF then you should check out Avalonia UI [1] which is a cross-platform alternative that is also probably better (and has good tooling in VS). There's also .NET MAUI [2] but it's maybe not as good for desktop apps.

[1] https://avaloniaui.net/ [2] https://dotnet.microsoft.com/en-us/apps/maui

nxobject•2w ago
Perhaps a Windows-only RAD framework? (Admittedly, I can only think of VB6...)
nine_k•2w ago
Delphi!
radarroark•2w ago
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).
swinglock•2w ago
Win32 and Wine being a lightweight alternative to HTML and Electrum is a fun idea.
Rohansi•2w ago
Wine is going to require at least as much disk space as Electron. Performance and memory usage should at least be better though.
wizzwizz4•2w ago
Have you considered Tk? Visually, it's quite like Win32, but it's fully cross-platform and (as of Tcl 9.0) has basic screen-reader support – so no mucking around with OLEACC shims or IAccessible2, as you'd need for COMCTL32. And it supports virtually everything Win32 does, with the ability to drop down to platform-specific sorcery (i.e., Win32) if the need arises.
purerandomness•2w ago
You might like https://www.lazarus-ide.org/
badsectoracula•2w ago
Someone else mentioned Lazarus, though that is Object/Free Pascal, not C/C++. The API is based on VCL for Delphi which was designed for the Windows API and even though Lazarus is cross-platform and can use multiple backends (actually i've been playing with writing a FLTK backend[0], though it is in primitive stages and FLTK doesn't really like exposing much of its guts), the API has some windows-isms (e.g. colors are 4 bytes where one byte is used a special marker to indicate system colors, just like in Windows) and the backends even have to implement a small subset of the Windows API to work :-P.

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
Because, as they always say, Win32 is the only stable ABI on Linux.
cmxch•2w ago
Depending on the use case, you might be able to get away with PowerShell with Pinvoke bindings if your code is more script-like than compiled code.

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
Winelib sounds like what you’re describing about static linking: https://gitlab.winehq.org/wine/wine/-/wikis/Winelib-User's-G...
Rayosay•2w ago
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!

foresto•2w ago
You might consider Flatpak packaging.

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
Most people can use the LGPL version of Qt.
nomel•2w ago
"People" or "professionals"? Our legal department said we had to buy licenses.
zekica•2w ago
Both. LGPL doesn't distinguish between commercial and non-commercial use.
nomel•2w ago
Sure, but there's a clear practical difference. Most professionals don't have the agency or company backing to allow LGPL, with their companies source code. Most personal users do.
bobajeff•2w ago
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.
OsrsNeedsf2P•2w ago
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.
yellowapple•2w ago
It sounds like in this case the submitter would indeed also be the upstream maintainer.

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
That sounds antithetical to the “never just works” philosophy of Linux software.
mid-kid•2w ago
I've seen a few russian pirated game releases for linux do this, they just bundle a copy of wine (downloaded from the same places as e.g. lutris gets it from), and a start script that sets the WINEPREFIX variable to a pre-populated prefix, with the game already installed and all the needed registry configurations already present. I suppose you could bundle all this in an AppImage, the annoying part however is that the WINEPREFIX is supposed to be read-write, so you'd have to set it to some place specific to your app, to avoid messing with the user's main prefix. These prefixes are huge (hundreds of MB upon creation), so I'm not sure I'd consider this a desireable solution.

If this is your distribution method, consider having the user install wine before running your app.

darthcircuit•2w ago
Check out GameImage!

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
I don’t have experience but I have heard of winelib which is a library implementing Win32 APIs. I suppose you don’t compile your code as PE executable, but compile to Linux natively while dynamically linking to winelib.
treesknees•2w ago
For MacOS there is Sikarugir (formerly Wineskin.) It lets you bundle a win32 program with a wine runtime as a .app

https://github.com/Sikarugir-App/Sikarugir

https://github.com/vitor251093/wineskin

sbinnee•2w ago
I didn't know about WoW64 mode. I remember when trying to install an old windows program I had to install a bunch of 32-bit translation library for audio and stuff. This WoW64 means that I can just simply use 64-bit arch. This is fabulous.

WoW64: https://en.wikipedia.org/wiki/WoW64

TMWNN•2w ago
Is the MacOS equivalent what was deprecated in Catalina, ending compatibility with 32-bit applications?
kcb•2w ago
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.

wat10000•2w ago
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.
mr-ron•2w ago
Seems like also 16bit apps????
throwaway2046•2w ago
Yes, as of Wine 10.16 (the version number is a lucky coincidence!) 16-bit Windows applications can run on 64-bit Linux without any special libraries.
wat10000•2w ago
Apparently the real WOW64 doesn’t, but WINE’s version of it does. Wow indeed.
TMWNN•2w ago
So Microsoft continues to support something that is presumably harder to maintain than Apple just continuing to ship existing 32-bit libraries?
wat10000•2w ago
I’m not very familiar with the Windows side, but it sounds harder to create but easier to maintain. Once the 32->64 translation shims are implemented, you’re done. They’ll keep working. If you’re not adding new 32-bit APIs then there’s no more work to be done. Maintaining a parallel set of libraries means each change has to work on both targets.
yshui•2w ago
It's a bit different. WoW64 is the technology used to run 32-bit applications on 64-bit Windows. Wine has support WoW64 for a long time. The difference is the "old" wine WoW64 mode required 32-bit libraries on the host side, whereas this "new" WoW64 mode doesn't.
MarsIronPI•2w ago
I remember I was using Gentoo when I first tried WoW64. I tried it because I didn't feel like compiling all those 32bit libraries. And it turned out that Wine's WoW64 mode worked just fine. It was really handy.
mschuster91•2w ago
> NT system calls use the same syscall numbering as recent Windows, to support applications that hardcode syscall numbers.

Other than antivirus software and maybe MAYBE kernel-level "anticheat" slop - who in their right mind does straight syscalls to the kernel?

StrauXX•2w ago
Some programming language compilers generate asm that does call systemcalls directly. Go for example.
teraflop•2w ago
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.

nasretdinov•2w ago
I wonder if due to C slowly fading away things like syscall ABI, kernel numbers, etc, will start getting more stable, not just on Windows but on macOS too
mschuster91•2w ago
There still needs to be a cause for working directly with the kernel interface instead of going via the userland interfaces (libc on Linux, kernel32/user32 on Windows, macOS frameworks) to justify the required effort, and the use cases are basically only DRM, malware, malware detectors and anti-cheat.
tux3•2w ago
Userland DRMs do all sort of nonsense. Kernel anticheats wouldn't use the syscalls, they're already able to call the kernel routines they want directly.
kachapopopow•2w ago
anti tamper, drm, library call obfuscation and they all do it wrong, really wrong.
userbinator•2w ago
Does it matter? The closer they get to being indistinguishable from Windows, the better.
mschuster91•2w ago
The problem is, Windows syscalls change around a lot. Keeping up with that is Sisyphean.
embedding-shape•2w ago
Wine, from the first moment I saw it decades ago, seems to be all about doing the sisyphean tasks no one else wants to be doing. I'm still in awe how they managed to get Wine to where it is today, so if someone can do it, it's the wine devs :)
wat10000•2w ago
I'd argue that anyone who willingly attempts to program these infernal beasts is not entirely in their right mind to begin with.
realusername•2w ago
This change was motivated to improve anticheat support indeed.
yshui•2w ago
If you think directly calling Windows syscall is crazy, some applications parse binary code from ntdll.dll to figure out what the syscall numbers actually are, since they change across different Windows versions :)
snarfy•2w ago
Hats off to the Wine team for all the amazing work! Myself and I'm sure many others wouldn't be able to switch to Linux without you. Thank you!
sevensor•2w ago
> 16-bit applications are supported in the new WoW64 mode.

I’d like to thank them for this, specifically! I had some old applications that weren’t working in the old WoW mode.

snvzz•2w ago
The funny thing (or actually sad) is Windows cannot run win16 anymore.
M95D•2w ago
It was since Win XP 64bit, ~20 years ago.
themaks•2w ago
You could run win16 apps on Windows 10 32bits though (supported until May 2020) https://learn.microsoft.com/en-us/windows/compatibility/ntvd...
hulitu•2w ago
> win16 apps on Windows 10 32bits though

Which was only installed for special purposes. The majority had Win10 64

vintagedave•2w ago
This is amazing. I may be asking too much here, but does this mean you can run Win16 apps on ARM, eg macOS?
CursedSilicon•2w ago
Unlikely.

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

lordleft•2w ago
Truly amazing software. I only recently learned that Crossover, which enables running windows software (mainly games) on MacOS, is built on Wine and significantly contributes to Wine Development.
ekianjo•2w ago
Crossover is made by Codeweavers who are the devs of Wine.
tomnipotent•2w ago
They're also responsible for Proton in collaboration with Valve. Codeweavers CTO has been project lead of Wine for three decades.
ekianjo•2w ago
> responsible for Proton

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

tomnipotent•2w ago
> Proton is a mix of various projects

They didn't magically get bundled together. Proton still has a substantial amount of engineering behind it.

embedding-shape•2w ago
I think the point was that there is way more people involved in Proton that the people/work coming from Wine, not to trivialise the amount of work integrating a bunch of projects take.
ekianjo•2w ago
Yes. Wine for one never had a high performance DX11 rendererer and DXVK was a revolution for gaming.
CodesInChaos•2w ago
I assume Esync and Fsync will not live much longer, now that NTSync is supported by the both Wine 11 and the kernel 6.14.
yshui•2w ago
> who are the devs of Wine.

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.

shmerl•2w ago
Congrats on ntsync and new wow64 support! Those are two huge features released last year.

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.

kccqzy•2w ago
I’ve always installed both wine and wine-32bit on Linux. Does this mean I can now delete wine-32bit after this?
shmerl•2w ago
Yes, I think up to date wine simply build dropped wine vs wine64 difference. You can check winehq builds.
bastawhiz•2w ago
This is all amazing work. Is there a list of applications/games that previously didn't work that now do (like what Dolphin puts out)? I'd love to understand what the improvements mean in a practical sense.
OsrsNeedsf2P•2w ago
They usually include this info in the point releases[0]. It would be far too much to fit in the 11.0 release notes

[0] https://gitlab.winehq.org/wine/wine/-/releases

yshui•2w ago
see also the proton release notes: https://github.com/ValveSoftware/Proton/releases
eek2121•2w ago
While I agree that it is amazing work, I feel the need to call out the wine team because, as many likely know, a redditor (admittedly of unknown origin, to me at least) felt the need to go to Valve prior to the wine team. Valve, of course, kicked the PR back over to the wine team, which I actually think is fine. The issue, I think, "may possibly" be the wine team.

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.

skissane•2w ago
I am sure I am not the only person who has no idea what you are talking about. Do you have a link to the PR?
MrPowerGamerBR•2w ago
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

drnick1•2w ago
> 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.

It's fair game since they don't support Linux.

imtringued•2w ago
You know what's weird? You being late by 3 days and not bothering to read the comments on reddit [0], then going ahead and trying a Wine 10 patch on Wine 11. Like, what exactly did you expect?

[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?

MrPowerGamerBR•2w ago
> then going ahead and trying a Wine 10 patch on Wine 11. Like, what exactly did you expect?

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.

MrPowerGamerBR•2w ago
Because I really want to be proved wrong, I tried using the patch creator's pre-compiled build with umu-launcher. However I couldn't get it work because umu-launcher kept complaining about a missing container runtime after I set the PROTONPATH to the pre-compiled build. It also did not work with umu's default Proton fork (it did run something, but even after I tried starting winecfg with umu, it just didn't do anything)

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".

MrPowerGamerBR•2w ago
To be SURE that I'm not "misrepresent basically everyone involved": Right now I tried the Proton build the PR creator made... and Photoshop still does not work. It shows the activation screen with "Loading..." written on it (sometimes it is just a blank box). https://i.imgur.com/QN2rxoO.png

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.

Philpax•2w ago
What? What does the behaviour of one random open-source contributor submitting to a downstream fork have to do with the Wine team?

Their post describing their troubles is all procedural, nothing social: https://old.reddit.com/r/linux_gaming/comments/1qdgd73/comme...

1hackaday•2w ago
Is Wine ever going to be able to run the current version of Microsoft Office? This is the main app keeping people in Windows.
bigyabai•2w ago
The "current" version is a cloud-encumbered MS365 product with Copilot+ integration, so probably not.

That being said, apparently the 2016 version is gold-rated on WineHQ: https://appdb.winehq.org/objectManager.php?sClass=applicatio...

venusenvy47•2w ago
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.
hedora•2w ago
They said “cloud encumbered” not cloud based.

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.

accrual•2w ago
I find Office 2016 feels rather similar to current Office 365 as well. For home office stuff I'd never notice the difference.
Ballas•2w ago
That gold rating was last tested with wine 5.0 in 2020. I have tried many times to install Office 2016 after that, and failed because Microsoft keeps changing their login/activation front-end. The last time the issue was with some Edge-dependency. For a while it was possible to get it working with Crossover, and then it broke again. Currently I'm using WinApps for the infrequent project that requires MS Office.

That said, I haven't tried Office on wine in the last 2 years, and there have a lot of development in that time...

rkagerer•2w ago
Any chance this will improve Solidworks support?
unsupp0rted•2w ago
Every few years I try Wine for whatever app or game and it spits out some obscure error messages I have to Google, and the suggestion is to recompile this or that, after downloading some DLLs from a random Russian honeypot on Yandex.

Is it better now?

notachatbot123•2w ago
Yes, whatever works well for me.
guenthert•2w ago
Not all functionality is perfectly replicated, so the user experience depends on the application being used.

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.

nasretdinov•2w ago
As a Russian I do feel a little bit of pride whenever people complain about something like this. Not hugely proud because you're using it in a negative light, but still proud nevertheless :)
CodesInChaos•2w ago
In my experience most games that don't use an anti-hack just work (probably around 95%). Occasionally a bit of tweaking is needed.

* 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.