DeadLock Update?

[Bamajon1974]

Are there any plans to update Dead Lock to ensure compatibility with later builds of Win 10 and Win 11? The program has not been updated in over 5 years.

Thanks!

[CodeDead]

Great question.

I have concerns regarding the future of the .NET ecosystem on which DeadLock and many of our applications are built on.

Using .NET is fine for Windows only applications, but with the recent releases of Windows and more specifically Windows 11, the GNU/Linux application space is one that needs to be respected as well since there are too many advantages to running Linux as a daily operating system versus Windows 11, unless when it comes to gaming, even though Proton is well on its way to make that a non-issue.

This is why I have been experimenting with different technologies and languages such as Java, Rust and JavaScript with Electron to port applications that can be ported to run on a myriad of platforms and hardware.

Noted that this is less of a concern with an application like DeadLock, since a Linux port will never be required, but the thing I am waiting on now, to start working with .NET again, is a framework called MAUI to handle the user-interface side of things. They are close to release, and might spark interest again in developing DeadLock further.

This means that in the future, you could expect to see a DeadLock update that no longer requires users to have to have .NET installed.

In terms of features though, DeadLock is still compatible with Windows 11, because Microsoft goes through heaps of fire to ensure compatibility with 'older' software. The Windows API's that DeadLock uses are still there, still relevant and still do the exact same thing. DeadLock is essentially just a UI in front of Windows API's. Easy, still usable and still perfectly fine.

An update at this stage would only be a refresh of already existing UI elements, which is, simply put, not worth the time and energy until the MAUI platform is ready.

Reason being that Microsoft has a history of providing UI frameworks but never really doing anything worth of interest with them. We now have WinForms, WPF, UWP, Xamarin and soon MAUI and many more frameworks which is quite frankly too much and all except WinForms have stood the test of time, except that WinForms is missing a LOT of functionality when compared to the other platforms. UWP is now essentially worthless, and not worth it to re-build DeadLock or any other application in because it would tie it to the Windows Store which is something we absolutely do not want or need. Plus Microsoft somewhat pulled the plug on UWP. WPF is unfinished and probably never will be finished. It misses a lot of features that Winforms has, while offering new features that WinForms doesn't have. This all means that this is a fractured ecosystem when it comes to desktop application development in .NET. MAUI will hopefully solve these issues going forward.

I hope this answers your question and instills faith that DeadLock is still perfectly fine in its current state, today.

I also hope that Microsoft addresses the issues concerning their desktop application frameworks and makes it interesting and worthwhile again to work with their ecosystem, which, today, is no longer the case as technology is steadily moving over to cloud-based infrastructures and less desktop-oriented than they used to be back when DeadLock was just starting out and before that.

I might just re-build the entire UI in Java and JavaFX because that seems to be the one framework today that isn't too demanding, stands the test of time as well and is relatively easy to work with.

[BinToss]

a framework called MAUI to handle the user-interface side of things.

dotnet/maui#339
MAUI has no official support for Linux. There are some forks that add GTK bindings for Linux desktop support, so they might be merged upstream eventually. From what I understand, this is because there's a ton of work to do to implement the workflows in the SDK.
Because of the lack of official support, cross-platform third-party UI frameworks are appealing alternatives e.g. Avalonia, UNO, GTKSharp, (QtSharp or Qml.NET).

[CodeDead]

MAUI has no official support for Linux. There are some forks that add GTK bindings for Linux desktop support, so they might be merged upstream eventually. From what I understand, this is because there's a ton of work to do to implement the workflows in the SDK.

The (many) file-systems that operate on GNU/Linux are entirely different when compared to NTFS. The concern is not about getting it to work on GNU/Linux, because it doesn't need to work on Linux due to files being locked not being a general issue like they are on Windows.

At least, this is not an issue for the DeadLock application, specifically, but it would be very nice of the dotnet team to include the ability to create desktop apps for GNU/Linux (be it with GTK or Qt,.. anything would be nice at this point).

[CodeDead]

For any developers using .NET; you can now make use of the deadlock library:
https://github.com/CodeDead/deadlock-dotnet-sdk

It is available on NuGet and allows you to customize the functionalities to your liking, in addition to allowing developers to create their own UI-based applications, if they want to do so.

This library will be rewritten entirely in Rust and JavaScript using both Tauri and React. This will produce tiny binaries with a responsive user-interface that does not require the .NET Framework or .NET (Core) to be installed on a user's machine. WebView is an excellent alternative for modern Windows desktop application development because Internet Explorer is being phased out and the time is right. Do note, Tauri does not produce binaries that are as big as Electron applications like Discord, which is why Tauri (WebView) is ideal for the particular problem of updating this application.

[Bamajon1974]

@CodeDead Good morning. Just following up if there are plans to support and develop DeadLock since the last update is nearly 10 years ago. Does Microsoft's plan to kill v3.5 NET support affect DeadLock in the near future?

Thanks!

[CodeDead]

Hi @Bamajon1974 ,

I started out developing this app well over a decade ago while I was still using Windows. I've since then switched over to Linux where the need for an application like DeadLock is non-existent. I highly recommend moving away from Windows, which is a bloated spyware operating system, which also requires apps like DeadLock to perform basic tasks like deleting a file.

All that being said, it is unlikely that I'll update this software because it requires me to run Windows, but it is not impossible. An upgrade to a newer .NET Framework version is not that complicated, and it is something I could see myself doing if there was a real need for it.

For now though, I believe the software works as intended, and there is no real need to update the already existing functionality.

[BinToss]

I've since then switched over to Linux where the need for an application like DeadLock is non-existent

What CodeDead means here is that the Linux file access sharing violations error, EBUSY, is solved by lsof, a tool bundled with practically every distro.

I've also moved to Linux since I'd first learned of this project. Still, this library has its uses.
It's intended for informing API- or end-users which processes are declining to share a file and avoiding embedding executables (e.g. System Informer, SysInternals, Handle/Handle64, LockSmith) or requiring they be installed beforehand.

Technically, this is still useful on non-Windows platforms when running under Wine, on ReactOS, or in Windows containers.

---

I had previously begun contributing to this project with a PoC to forcefully close handles like the aforementioned Windows tools. It worked, but had terrible performance, would require running elevated (as admin), and would inevitably be flagged by anti-malware if the main module (executable) lacks an EV code certificate.

So, although neat, the finished feature would have caused too many problems to be worth merging.

---

that being said, it is unlikely that I'll update this software because it requires me to run Windows, but it is not impossible. An upgrade to a newer .NET Framework version is not that complicated, and it is something I could see myself doing if there was a real need for it.

For now though, I believe the software works as intended, and there is no real need to update the already existing functionality.

I will say that it may be worth maintaining this project's target frameworks so breakages may be discovered sooner rather than later.

[CodeDead]

Well, the source code is now updated to .NET Framework 4.8.1
I'll see about making some more significant changes if needed.

EDIT: I wish Visual Studio 2026 worked though, it keeps crashing whenever trying to open the form designer. Lovely. How I missed MicroSlop.
EDIT2: Of course rider works just fine. It takes a third party to fix microslop code.

[Bamajon1974]

Thank you! Do the updated files need to be compiled or is there still more work planned?