Paint.NET 5.2 Alpha (build 9739) contains extremely experimental support for WINE (which means Linux).
Some of you may be happy to hear this. Some may be not. It may make for some interesting debate, or something like it.
ETA:
This was written by our good friend Claude, without whom this would NOT have been possible and would NEVER have happened.
Quick Important Side Note: If you don’t like AI, if you hate AI, if you refuse to run any software that AI touches, if your favorite pejorative is now “slop” … fine. Whatever. I’m not going to try and convince you otherwise. You’re entitled to your own opinion, I don’t care. But keep that talk out of here. You don’t have to use this. It’s clearly not for you.
Most of this code is, as they say, “vibe coded.” By that I mean that it has not been thoroughly reviewed, it’s more “trust me bro” style. I cannot possibly review 180,000 lines of code, it’s just way way way too much. For reference, the rest of Paint.NET is about 700,000 lines of code and I’ve been working on it for over 20 years. I did thoroughly review any code that had to be changed or added elsewhere in the Paint.NET code base (refactoring and integration points, etc.). Over time I do hope that more of this code will be vetted by real humans and also by more advanced AI models.
At times, Claude was working with the fury of 10 freshly unshackled Einstein genius-level 10x coders. And other times … well, not so much. I had to babysit Claude quite a bit to make sure it did resource management correctly (for awhile it just wasn’t doing the COM equivalent of AddRef() for reference counted objects, oops). I had to slap it a few times when I found some really bad design or architecture decisions. And I was also impressed at some rather clever and tireless reverse engineering work it did to figure out all the formulas needed for implementing Direct2D’s built-in effects library. It never had to decompile/disassemble d2d1.dll, it figured it all out “clean room” style*. And it never got tired, it never got bored, and it never got annoyed when I changed my mind 10 times in a row.
Day and night, it just kept coding, and coding, and coding … writing tests, comparing rendering output to the real Direct2D, making and updating hypotheses and formulas and shaders and error handling and everything until it got things just right …
… And then it worked. It actually booted up. In WINE. Claude got this working in about 3 weeks. This involved a lot of Fable, a lot of Opus, and even some Sonnet (those are the 3 models in reverse order of intelligence/complexity). I finally managed to boot up Paint.NET in .NET 10 win-x64, in WINE, on Ubuntu, in WSL 2, on Windows 11. And then later that day some folks on Discord got it running on real Linux systems. There’s been more work since then in order to further refine and fix up the code, but now it’s at least kinda-sorta ready for others to try out.
It is NOT “production ready.” I wouldn’t even call it “alpha quality”. It “doesn’t not” work.
How does a project literally named “.NET” manage to fuck up so bad as to need WINE instead of just Mono?
From the article:
So basically they hallucinated up a replacement for the Direct2D as a Linux compatibility layer.
.Net hasn’t been Linux-friendly for quite a while. Especially since 2023 or so there’s been a major shift away from cross-compatibility, which was a very strange decision to me. .Net is no longer a Linux friendly or cross-platform development environment; which to me was it’s biggest strength. So I’m honestly not surprised that there’s more components that are just straight up completely incompatible with Linux. Non-Windows platforms are now “second class citizens” in .Net land.
I remember vividly the moment when I upgraded a project from .Net 3.1 to .Net 6. Buried at the bottom of the patch notes, was a brief mention that some libraries (actually, a huge number of libraries) like System.Drawing are no longer supported on Linux. It was a catastrophe, causing so many random bugs and took literal months to recover from. For example, generating a PDF causing an entire web server to hang and use 100% resources. Entity Framework database connection quirks causing data loss and availability issues. Etc.
What do you mean not Linux friendly? Some of the legacy windows components of .net are not being supported, but that’s because there are alternatives that are better. ImageSharp is a huge improvement over system.drawing.
By that I mean you have to be careful which libraries you use. There’s a good chance that a
System.*or random NuGet package will either completely fail to run on Linux, or be horribly buggy if you force it to work via build flags. In fact, they’ve completely removed the build flag in .NET 7+,System.Drawing.EnableUnixSupport. It used to be supported vialibgdiplus.I would expect .Net to be fully compatible with Linux out of the box. Especially system libraries. You can’t say that you support cross-compatibility, and then deprecate cross-compatibility of system libraries; that’s just insane.
I don’t remember the exact details because it’s been several years, but it was far more than just
System.Drawing.Commonthat broke on Linux after updating to .Net 6. Some breaking changes were undocumented, only appearing later in GitHub issues. Some were buried in sub pages or individual library documentation.In the patch notes they even had the gall the claim that our business use case doesn’t statistically exist, and we can just drop in replace SkiaSharp; which was absolutely not the case. It was an unmitigated fucking disaster, even accounting for rolling back to .Net 3.1 for a few months while we sort it out and wait for critical 3rd party libraries to accommodate the change. Before anyone says it, yes we actually paid handsomely for our critical third party libraries; we didn’t mooch off open source and whinge about it. Even so, it never really worked right after that change. A hundred small things, like differences in how SkiaSharp draws differently and handles edge cases. In an enterprise application, it was a big problem.
More reading: https://learn.microsoft.com/en-us/dotnet/core/compatibility/core-libraries/6.0/system-drawing-common-windows-only
It sucks that you had such a rough translation. I never felt hoodwinked, because it was always clear to me that any parts of .net that were for winforms or WPF would never fully supported off windows. And that certainly makes it hard to transition projects that started on the legacy framework before core.
With that expectation on my mind, I haven’t had these experience, most things I’ve wanted to do just work on Linux, CLI and web hosting. For GUI I’ve used Avalonia which has been great, but it’s definitely not a thing you just port to. Its viable for greenfield.
Wouldn’t it be easier to use a cross-platform backend, even if the interface was vibe-coded?
I think the point is that the developers doesn’t want to actually review the code which they can do with a self contained dependency which they then ship on a “take it or leave it” basis.
I kind of get it and I think it’s a more responsible approach than to vibe code the core engine of their application.
Ideally, yes; but cross-platform drawing libraries are like unicorns nowadays. SkiaSharp would probably work, but it functions completely differently and would require a rewrite of the entire program, which is a big ask.
That may be an explanation, but it isn’t an excuse.