Roadmap discussion

[mrexodia]

In #3728 I had a discussion with @torusrxxx about the future of the project and I wanted to create a space to discuss this longer-term:

---

But look at the issue tracker, we have more supported features that have unresolved issues for years.

Yeah, this is exactly the problem I am dealing with. Adding more and more features only creates more unresolved issues. Additionally it widens the surface area for bugs, even to existing features. My time on the project has been quite limited recently, due to other priorities in life, but I still would like to deliver a good product to our users.

Similar to the discussion in #3599 where you said:

As for maintenance, I think adding a feature is part of maintenance. Otherwise there will be little to no maintenance. Everything already works, what maintenance are needed? Why touch it?

There are hundreds of issues, some of which contain pretty serious bugs in existing features. There is a lot of old (bad) code without tests to support refactoring them, the debug engine is still not moved from TitanEngine to something different and lots of abstractions are leaking making it very difficult to support things like remote debugging. Much of the UI was copied from Olly in 2017 and is a super bad user experience (#3692 as just an example).

Of course this PR is just a place for discussion, I don't see any real risks from merging this trivial change. However, I do notice that we have a different way of thinking about the project and I think it's good to discuss. You are the only consistent contributor after all!

---

Unresolved issues is only part of the problem. Actually I would like to consider "what are the use cases that we can support while not expanding project scope, complexity, number of bugs, compatibility problems etc." The top wanted features: small memory breakpoints, WINAPI SDK, arguments labels in stack, extract everything from PDB, etc, are still unsupported.
My contributions to this project are kind of random, probably because I decide to do it for something unrelated to this project, or I just did that for an unrelated project, all some totally outside factors. Recently, the only carefully thought coding tasks are the trace features and AVX-512 support. Surprisingly, nobody has raise an issue for the new trace features. Is it because these features are useless or unknown and everybody uses custom tracers, or because it works flawlessly? That's mystery as x64dbg does not phone home. Either way, I don't think some features, even major ones like the new trace features, have that much maintenance burden for you. Of course if you indeed have problems with it, let's discuss it.
And, if you want to invite me to complete your task list, feel free to do so by sharing your ideas!

---

The top wanted features: small memory breakpoints, WINAPI SDK, arguments labels in stack, extract everything from PDB, etc, are still unsupported.

Actually we are getting there

• small memory breakpoints -> supported by commands
• winapi sdk -> supported with the ManyTypes plugin (a lot of work was done for this
• arguments labels in stack -> not supported, but the infrastructure is (almost) there
• extract everything from PDB -> not supported, but the work on ManyTypes actually allow this fully now (I think)

Surprisingly, nobody has raise an issue for the new trace features.

Yeah this is the famous chicken-and-egg problem that plagues all x64dbg features. We do not have a well-funded marketing machine to market all the new ideas, so hardly anybody even knows about it. I recently added the 'Release notes' feature to try and improve this situation, as well as changing the release model to have bigger releases where we can announce things.

I think part of it is that the trace features in x64dbg have very limited use cases in my experience. For larger projects it is much easier to use something like PIN/Frida/DynamoRIO or even inject your own DLL to perform some hooking. This is why I personally hardly ever use these features...

And, if you want to invite me to complete your task list, feel free to do so by sharing your ideas!

Thanks! I currently do not have a concrete plan, just scattered notes from private discussions with people, but I will try to share a more concrete roadmap in the coming year. Overall I am trying to focus on stability and the move to VS2022 because it can also attract new developers, but I agree that without a roadmap or clear direction it is kind of difficult to move the project forward...

[torusrxxx]

Well, my roadmap is at Rambling (not sure how to make it public). I also have further plans on tracing not on the issue tracker.

And sometimes random tasks gain high priority for random reasons. For example, accessibility support in time for Christmas. It is the largest improvement to the GUI in 2025 suddenly completed in a short time not previously planned...