I accidentally the whole codebase and also maybe fixed some bugs.

[roflcopter4]

I wanted to investigate and address the Task View problems by forking the repository. In review I reformatted the code for readability and ended refactoring more than I'd intended to. I understand that these changes are substantial, which is why I am not opening a pull request right away.

I think there is merit in this significant refactor, even if it may not be acceptable outright. Some of the changes include making most functions and variables static, eliminating the usage of rand, resolving the right-click menu issue over the Start button, enabling clang to compile the codebase with the option -Werror=format enabled, fixing the console sometimes being opened twice, wiping debugging messages, removing duplicated code where possible, and attempting to encapsulate some of the global state. In the process, I also added a bit of C++ code. This addition can be reversed if needed.

I corrected one of the GUIDs used with the XAML libraries, though this didn't change much, and Task View remains non-functional.

I'd appreciate any commentary or advice. I can open a pull request with some or all changes if there is interest, or they could be worked in by other contributors.

Or, in other words, I spent a lot of time failing to solve the problem and want to pretend the time wasn't totally wasted.

https://github.com/roflcopter4/ExplorerPatcher/tree/dev

[Amrsatrio]

Hi, just to let you know I have been fixing EP this week with successful results. You could take a look at what I've done in my fork and add it to your fork and help me improve the patterns by testing across more builds.

Though, unfortunately, given Valinet's response against prior PRs, it doesn't seem like your fork will be merged into the main repo.

[roflcopter4]

I don't really expect it to be, which is why there's no PR, but I hope someone looks at it anyway.

I'll try out your fix. I had to change it a bit to merge it with my fork, and to get it to compile. It really ought to be an error for functions with a return type not to return anything, so I make it so. Also, use #ifdef _WIN64 not #if _WIN64, and you can't print a pointer or 64-bit value with %lX. Safer to use %p or PRIX64, or at least go for %llX.

[patriq]

@Amrsatrio thanks for your repo, it fixed the troubles I had with taskview and windows 10 bar 👍

[Darth-Postal]

@Amrsatrio thank you! Your brunch fixed most issues on my machine.

[valinet]

@roflcopter4 Thanks for the contribution, looks promising. Let me break down my opinion into a few key points.

First, I do not have anything against PR and third party contributions. In fact, I strongly actually encourage this. I am actually glad that finally there are more people looking into the code and suggesting changes. I am open to collaboration, if you want to get involved with the project big time, I can make you a maintainer and start contributing directly. I just have a few tiny "requirements" so to say:

• Write good code that makes sense.
• Try to limit the amount of commits in the sense of encapsulating each major task into a single commit. Prefix commit names with the component that is improved or fixed (i.e. "Taskbar10" for the Windows 10 taskbar, "Start11" for the Windows 11 Start menu, "GUI" for the Properties window etc, check past commits to get an idea of this). This makes it easier to sort commits and review them.
• What I had issues with in the past are big changes that need maintaining, but no one is willing to do it. If you want to commit some big change, commit to also maintaining it; it's rather difficult for me, especially when a feature becomes popular, to pick it up, understand it from scratch and maintain it (the nature of this program a lot of times makes it so that you forget a few days since you wrote the patch how it actually works, idk 😂). You get the idea, I think.

Regarding C++, yeah, initially, when I started EP, it was during the pandemic, so I had a lot more free time. I picked it up and wrote it in C because I wanted to be more "bare metal", to learn how things worked, to have less abstractions etc, and to this end writing in C achieved me this goal. Although yeah, from a production standpoint, writing at this scale in C is becoming cumbersome. The code base is now rather large, yet there is some boilerplate code (function pointer tables that are very verbose, for e.g.), and indeed, I fell that in some cases in this project, having to write in C is maybe slowing implementations, making code harder to understand (although that can happen with C++ as well when abused), and may even be a barriere for 3rd party contributors (?). Idk... Nowadays, I have made my mind, at work where I pick how I do things, I write C++ only for quite some time now, so I'd guess it may be time to slowly move to C++, although I still like that "C" badge on the project home page 😂. Yeah, we can think about it...

So yeah, my invitation to collaboration is as open to you as it is to @Amrsatrio. And to everyone after all - if people want to contribute and help this project grow and get maintained, I am more than happy and open for collaboration.

[packetdog]

@valinet What an awesome response! I'm really heartened to see this.

[roflcopter4]

@valinet That all makes quite some sense, actually. Regarding your other comments, I'm not entirely confident the "nuke it from orbit" approach I took to changing everything is well suited to being broken up in a sane way. I can separate out the important changes and make a PR for them separately.

In general I re-wrote stuff, moved functions between files, moved inline functions out of headers, moved global variables together, added headers, added files, made 187 global variables in dllmain.c static, most of the functions too... As I said, it's a nightmare and I would not exactly be surprised if it just can't be accepted.