RFC: StartAllBack interoperability going forward

[Hexality]

is the latest version of startallback dll supported? cause I saw the hash of the dll in the readme.md and it doesn't match.

Yes, I'm afraid of breaking my system.

@valinet edit: let's turn this into a request for comments; please read my post below and help me reach a resolution regarding this issue. Thank you.

[Hexality]

[valinet]

No, only the DLL with the listed hash. And it probably will never be. It's not a feature I want to keep supporting, it was there until I ported over the 2 settings which I was interested in. I haven't yet pushed the commits containing this port because I don't really know if it's something I should really do.

It's a much broader discussion; the port for these 2 functions and some other small snippets is obtained from the disassembly of the StartAllBack DLL. I did it just because I want a few features that are implemented there, and also generally to learn how things are done. I have learned indeed a lot from it and not only from it. I usually disassemble a variety of binaries to inspect how they work and enhance them, and also very much to learn. For my personal use, dynamically loading the library or porting over the disassembled code is fine, as I already have a StartAllBack license, for example, and also, idk, it is something I am okay with doing. Of course I prefer integrating the code in the main code base, but when the disassembly is too big or don't have time to port it over, I usually just dynamically link.

The problem with publicly releasing this is that, idk, it reimplements a subset of features which are available only in StartAllBack, and that is paid for... also, the EP project is an original idea, having come out before the first betas of StartAllBack. And these features are not really "core", or "essential", or "must have", these are more like "nice to have", so there's an even weaker argument there regarding them. It is just that I liked these 2 features from SB mainly, and linked to them, and also looked on the disassembled DLL to learn stuff and improve my methods. But yeah, releasing this publicly is not a problem from my side, but idk, may be from StartAllBack's side. The project is paid for, and there's some overlapping between the features that offers vs the features of ExplorerPatcher, kind of an interest conflict. I obviously don't have the time or resources for writing specifications, assembling teams of clean and tainted developers and doing clean room reverse engineering, so... I don't want to be caught in offside. I don't want to piss anyone off, or to take down the project because I went above someone's radar. The disassembly of course is different from the original source code, but obviously it comes from the binaries distributed. As a matter of fact, even messing up with Microsoft's libraries is not okay from a license perspective, but they obviously probably won't bother. I mean, I am not talking about civil lawsuits, I am talking about the mere fact of receiving a take down notice which one would really have to comply with, as this is not 100% clean room, so to say. On the flip side, what other fucking place to learn from other than the disassembly, as there is no documentation, but whatever, these are the laws and how the judicial system works... it's mainly good to stay under the radar, in my opinion, rather than to fight a questionable battle.

So yeah, I don't know how to proceed, so it's simply on hold. I was thinking about removing the features all together, or maybe just go along and publish them anyway. For me personally, I am now reorganizing the project, moving forward I don't want to maintain interoperability with SB, as I don't use many of the features from there, and also because I don't want to answer a "does it work with SB v xyz?" question every time SB releases a new version. And no, I also cannot redistribute their binaries, I don't think it is allowed from what I read on their web site and I also don't want to do it. It's a gray area so to speak and it's more problematic now since this project is getting quite some attention. If it were just a regular GitHub project of my own that almost no one knows about, it would just sit there happily and be done with it, no one would notice anything anyway.

I could also make this private, and move on with the port and just backport from time to time things in the public repo, but I don't want to do that either: I don't want to maintain 2 repos, nor do I want to make this private, as I want to publicly publish some new capabilities developed 100% in-house. The need to disassembly comes mainly from the necessity of reenabling the old functionality and the lack of any kind of documentation on this topic.

In the end, no resolution yet, what's the opinion of the community on this?

[Gaurav-Original-ClassicShellTester]

I will have StartAllBack forever installed alongside ExplorerPatcher since both fix some unique core usability issues for the Windows taskbar so I don't really care about having the DLL in EP's folder or its interoperability that way.

[valinet]

Thank you for your opinion, I will take it into consideration.

[Robertof]

I think there is no right or definitive answer to @valinet's extremely well thought matter. The basis of this project is obviously fruit of the hard work of reverse engineering MS' implementation to improve it - almost like doing work for them, for free! There are countless other legitimate examples which do the same: console and game emulators, jailbreaks on closed systems, vulnerability research, etc.

IMHO, all of those -- including this project -- perfectly fall into fair use as there are no EULA'd binaries being distributed or internal industrial secrets being leaked. At the same time, I don't think you should be overly concerned about competition. Open/LibreOffice are literal alternatives (competitors) to the proprietary Microsoft Office package and I am sure their work (especially on the not-well-documented binary legacy doc formats) is based on reverse engineering the actual implementation. (Obviously, don't quote on me as I am speaking based on intuition, so I might be wrong for this specific example, but I am sure there are countless others.)
The FUSE NTFS driver ntfs-3g is another example comes to mind where a fully functional read-write driver for a closed filesystem was produced without any available specification.

Regardless, I would say that it's absolutely legit for @valinet to decide to not maintain interoperability with StartAllBack, as that requires taking away time that could be dedicated to implement new things of his liking or to actually fix the interoperability with Windows! I would also not hold back features because a competitor is also implementing them. However, I would definitely try to avoid to use directly disassembled code, as that could be considered violation of intellectual property -- simply basing off disassembled code, though, should be mostly fine, as long as you keep a certain degree of originality. Again, I am not a lawyer, just a mere opinionated developer, so my opinions might be terribly wrong. I do strongly support the development of this project though.

In the end, I don't think that a cautious approach would be wrong either -- if @valinet doesn't feel comfortable releasing those features anyway to avoid any headache, it's his project, provided as-is and open source, so anyone desperately in need of any feature could technically attempt to replicate the same amazing work he's done here.

People will also have different opinions based on what they need or use. I am a simple person and just need my good ol' taskbar back -- once I had it, I was happy and called it a day! People with different needs, instead, will obviously be more pushy to have other features, especially if that means they won't have to pay to get them. Still, I am simply amazed at the speed this is evolving, and would like to iterate a shout out to @valinet for polishing this to extreme degrees!

[valinet]

Thank you for weighting in on the matter, I will take your opinion into consideration.

[valinet]

I have thought about it, have taken into consideration the replies here and have come to a conclusion: I have decided to remove the StartAllBack interoperability code from the library. I will try to explain as best as I can the reasons below:

• The original goal of this product is to enable features from Windows 10, like the old taskbar, on Windows 11. That's still one of the goals today, and further I have expanded this with my desire to bring new experiences, soon. With that being said, Mica effect in Explorer or skinned Windows 11 system tray icons were never available in Windows 10 and are not paramount to obtaining the core Windows 10 experience on Windows 11
• As you all know, StartAllBack is a paid product. Although you can technically build a wrapper around its binary interfaces, and use the functionality in there circumventing some other parts of the software, as was clearly shown with this interoperability, distributing this to the general public comes down to a trust issue: every party is more or less okay with this, let's say, provided that you acquire a license to use each of the products involved. That's because you are still running StartAllBack's code, only invoked via different means. Although I personally do not feel like paying for the core functionality provided by StartAllBack (that's one of the reasons ExplorerPatcher is free, for example; but I also own a license for StartAllBack, as I clearly have used/use it from time to time), I also believe in respecting other's rights to decide how to distribute, license or provide a product, and also believe in obeying the law in general (except jaywalking). While providing functionality to link in this manner to other products doesn't make ExplorerPatcher illegal in itself, it makes users who run it technically break the license agreement with StartAllBack, which you are required to accept to run it, and which you still run even though you do so via EP's wrapper, or at least, if not that (I do not want to get into legalese stuff), it makes you use the product (SB) in a manner not sanctioned by the developer. To be honest, I don't really want to take an active role in helping people break other software's license agreements, or at least not when I feel it is ethically/morally wrong (remember, EP already messes with Windows' internals which also kind of breaks the Windows EULA, but for that, I do not feel remorse). Also, most users aren't even conscious that they're doing that. And a note in README won't suffice, as most users anyway ignore almost all the written documentation for this project anyway. Tihiy (the developer of StartAllBack) is a great developer, he has provided some great utilities over the years from which I also have learnt a lot, even though I did not have access in source code form, I disassembled and looked on them, so I do not want to cause him any kind of prejudice in this, especially in this way, which this interoperability feature had a potential to do: 1. we can't verify all people also pay for StartAllBack when using this and 2. considering 1, some people may stay off StartAllBack and just use EP considering it included some of the features there via this mechanism.
• But, you may ask, why linking against Windows' DLLs is fine, while against SB's is not, while technically it is the same thing: enabling functionality from there, circumventing some kind of thing that generally keeps it inactive. Well, it comes down to causing harm to the other party: even though you enable the Windows 10 taskbar in Windows 11, Microsoft does not really care, you are still using Windows, while with SB, some people may decide not to use it because of this. Also, it's my own personal decision, we could also say I feel ok like providing this functionality with regards to Microsoft, but not with regards to SB. Nothing stops you from providing that, if you want, though, it's your call.
• Also, I don't want to maintain this kind of thing some people keep asking whenever StartAllBack releases a new version: a database of links to where you find the right DLL, people post issues that the feature gets broken, it is expected that the code base is updated to fix compatibility with the new version, people redistribute old files they do not own without permission from the owner etc.; I do not want to take an active part in people breaking the law, or agreements, or someone else's wishes when I feel like it is ethically/morally wrong to do so. And also, I want to invest energy in developing new functionality, not keeping updated some offsets in someone else's DLL. And technically, no, I can't get those automatically because StartAllBack does not distribute symbol files, like Microsoft does for Windows' libraries, for example.
• So, the solution could be to port over the functionality from StartAllBack, right? Well, it depends on what you mean by porting. As pointed out by @Robertof above, I am also not comfortable with disassembling SB's DLL and just slightly fixing but basically copy-pasting that in EP's source code, especially considering the implementation is kind of specialized, kind of vast, and also, as mentioned previously, not essential at all to this project's original purpose. Also, most users, from what I gathered, felt the same, few people used this and were just happy with what the software provided already, so the impact on users should be minimal and the people affected should be few.
• I am not against, on the other hand, of reimplementing SB's features of interest. The problem that arises is that I honestly did not know how to achieve that icons skinning, for example, so I learned off the disassembly. I could rewrite it from scratch, but I do not have the incentive to do so, honestly. It's quite some code. Also, I am just fine with running the slightly fixed disassembled code integrated in the source code just fine. As I said, I prefer investing energy in doing other stuff rather than writing this port. Also, to make it 100% clean let's say, the right thing to do would be to have someone else write it, someone that has never looked on StartAllBack's disassembly, with me maybe providing him/her at most with a specification on that.
• So, to reiterate, this is not about not overlapping with each other's feature. I am 100% not against that. I will never subject this project to a clause of not implementing stuff available in any other product, including StartAllBack, because I enter into some "competition" with them, or hurt their sales or whatever. So, it's totally not about that. I am pro implementing everything SB offers, I just want that to be a clean room implementation, or as clean room as it can get, that is all, and I felt that the current stuff that we had was not meeting that criteria. That's all.

So, with the above being said, moving forward, public builds of ExplorerPatcher won't include that functionality. The ep_private.h header file contains disassembled code from SB regarding that, and that will not be open sourced, for the reasons outlined above. Builds published in releases will be compiled without that file. It means a small annoyance each time I build for the public, but eh... nothing better I can do. For your own builds, don't worry, you can build without that file, as private interfaces are guarded against a #define USE_PRIVATE_INTERFACES, and that gets defined only #if __has_include("ep_private.h").

The good thing is that now the upstream is yet again in sync with my development local clone. I don't have to keep 2 folders to build into, so yeah, it saves me a headache.

I hope this does not turn this into some people creating forks, maintaining download links for old versions which had this functionality etc. Also, please make me aware if I ever leak and upload a private build of ExplorerPatcher in the releases section.

Thank you all for the support and for the suggestions and opinions provided. It helped me a lot to develop a decision on the problem, and I hope you all understand the reasons outlined, and that we are all fine and we can meet together happily and enjoy new experiences coming up in ExplorerPatcher.

Thanks,
@valinet

[Gaurav-Original-ClassicShellTester]

I have a somewhat related question. Even if in the future suppose there is no plan to support StartAllBack DLL (nor do I expect such interoperability), but let's say I paid for a StartAllBack license and have it installed side by side along with ExplorerPatcher (not the DLL in %appdata%\ExplorerPatcher, which is a different approach). Now naturally since both are more or less focused on the same enhancements, some conflicts, or functionality in either one not working as intended is bound to happen. But then should I report such issues - as in - is it a supported configuration for this project? Or it depends in each feature or setting's case? I certainly don't wish to be annoying about every incompatibility created because of coexistence of both projects. But I do care about ExplorerPatcher functionality working right in maximum scenarios.

For example, just casually I discovered recently that Open Start to All apps by default does not work when StartAllBack is enabled. It does not bother me the least bit since I use Open Shell anyway. But should I report it since I will definitely have this particular configuration only for the foreseeable future - EP+SAB and I happened to notice it? Or it is an unsupported configuration anyway so I shouldn't annoy you with such issues created by both of them enabled? 🙂

Update: It's now working fine even with SAB enabled! The Windows 11 menu is opening to All Apps by default. I don't know what happened. I swear it wasn't working for quite some time and then it started working. Anyway the question remains - should I report or shouldn't I - such issues arising from both being enabled?

[valinet]

I don't know what the right answer is. I don't fix the issues just for the sake of fixing them, I am not some sadomasochist, I actually enjoy doing a million other things rather than working out issues. I do it because I care that the users get an ok experience, if there is a bug/problem/issue that bothers people, I feel like it is right to at least attempt to patch it. But like, there are probably a million other bugs/problems/issues that are just there, and no one bothers or they may even be undiscovered because no one uses that software in that configuration. I don't aim for a mathematically correct, functionally verified project. I have more down to Earth expectations, like it working in most of the scenarios the users are using it. So yeah, I don't know if opening 20+ issues with each particularity of this software not working with whatever software that not even the OP uses in that configuration is the best thing to do.

Furthermore, as you can see, I am still mostly the only maintainer on this project. Besides the fact that I am kind of tired of working on it at the moment, if we fill whatever time I have with fixing issues created just for the sake of correctness, there won't remain any time to implement new capabilities, for example. It's the same today, the more the community steps in and answers the 90% trivial issues/questions that are raised by new users every day, the more I have time to work on the actual bugs and then implement new capabilities. If I "waste" 5 hours daily answering the same questions as yesterday, for most of which the answer is clearly written in the docs, fixing README typos that people just bother pointing at but not also fixing them as well etc, very few time actually remains for implementing stuff. I kept expecting some people to step in and assume the roles of moderating some of the issues, but unfortunately, that hasn't happened. Also, many use this platform, but don't want to move a bit further and learn how to use it fully and properly. I have said it a few times already, anyone can fork the project, fix whatever typo they found in the README for e.g., and then make a pull request, one does not have to be a "developer" or have 2 pairs of brains for it, one just has to be willing to get involved a bit more than the basic "I will throw this on the developer's desk and call it a day". Btw, what I said does not apply in any way to you in particular, let me make it clear from the get go, I was just ranting in general about what I feel wastes a lot of my time unnecessarily.

So yeah, it's your call, my opinion is kind of the one above, but I do not like imposing unnecessary rules, I fell like everyone can judge for themselves and behave in an orderly manner; I like liberal places. The only rule here, as you have seen, is to discuss general stuff here and post bugs in issues, only so that some kind of organization is maintained, besides that, it is as opposed to communism as possible. Idk, you can decide on a case by case basis... it depends on what we as a community value more... program correctness, new capabilities, mix of both etc.

I hope my reply does not make you mad on me or something like that, as I said, it is referring to situations in general, it's not targeted against you or your question here, or anyone else's issue/question/whatever in particular, it is just in general, I don't want it to sound acidic or whatever. If you feel like what I said is inappropriate or I was acting cocky or I have offended you in any way, I apologize in advance. Thanks.

[Gaurav-Original-ClassicShellTester]

Oh ok :) , I absolutely understand the challenges you face as a single developer. Besides, in the above case, the issue resolved itself after a while. Hopefully such conflict issues between the two projects will be minimal and I will try my best to troubleshoot on my own and get them fixed by reporting to Tihiy also if in some cases SIB is the problem. Of course, it's not that you MUST FIX something - you can see the issue and decide not to address it due to time constraints or whatever - I am sure no one will get mad over this because you have already done more than enough for the huge billion user Windows community. There are no expectations from you, only our eternal gratitude because otherwise this Windows release would have been a total nightmare :)

[valinet]

Thanks. Yeah, as I said, I actually believe in helping people, I just don't like it when people don't help themselves. Take this latest bug report, for example: #87. Please tell me, objectively, what you understand from it at first glance. Do you think the provided info is enough to start addressing the issue, or is it justified that I yet again have to beg the OP to post a more intelligible description. I appreciate the initiative, sure, but it just wastes more time initially unless well documented from the get go.

[valinet]

And like, I understand English is not everyone's native language, it isn't mine either, and that not every one has the same comprehension and level on this language, I for one could definitely improve in this area as well, but I'd rather battle through a comprehensive description with more English-related problems, for example, rather than though this always happening lack of enough information report, for example.

[Gaurav-Original-ClassicShellTester]

Oh lol yes that issue is extremely vague. People also don't use or know the correct terminology. It is not difficult to troubleshoot but wastes a lot of time - I agree. I remember this on the Classic Shell forum. It is full of such vague problem reports :D that both Ivo and I couldn't understand AT ALL.

[Gaurav-Original-ClassicShellTester]

Well right now there are 2 main features why I use StartAllBack on Windows 11/StartIsBack++ on Windows 10. I wouldn't need it if not for those 2 features, because for the Start Menu I use Open Shell and I will always have ExplorerPatcher installed anyway. Here are those 2 features:

• The ability to apply msstyles to change the appearance of the taskbar to make it easier to use. I use this functionality to make the button of the active window look pressed down/pushed down. I blogged about it here: https://www.techydecisions.com/fix-windows-taskbar-appearance-with-startisback/ It is a massive usability/functionality improvement for myself. Windows 95 to Vista all had the ACTIVE (foreground) window button on the taskbar look sunken (the 9x/2000 classic look even had the text bolded for the active window). That's what that SIB/SAB theme/msstyles allows restoring to Windows 10. (Earlier on Windows 7 and 8.1, I directly used patched msstyles for the whole OS (https://winaero.com/make-active-window-more-visible-on-windows-8-1-taskbar-with-pressed-button-look/) but that became difficult with Windows 10's constantly updated releases).

Notice how the active window button looks pressed down/pushed down up to Vista and then Windows 7/8/10/11 break it. Windows 10 does not even bother to draw vertical lines separating the buttons.

• I set the icon margins to Xtra Small (XS). Since I never combine taskbar buttons, nor group them and always have large icons (32 x 32) and text labels on, this saves a lot of space for me that 7+ Tasbkar Tweaker's "Remove extra gap between items" does not achieve.

I am not requesting that you implementing those features :) just stating why I use them side by side. If while having fun with Explorer code, you discover some easy way around these issues, that would be golden.

[valinet]

Yeah, I understand. Personally, I am not that interested in those, so they won't be up high on my priority list. I don't care that much about looks, to be honest, for me, the Windows 10 look is the best because I am so used to seeing it; I hated that initially as well, when the OS released, but then got used to it. In the long term, I figured out it is just easier to try to use as much of the upstream as possible, as maintaining forks is kind of difficult. Even for this patcher, I hope that as some point the new Windows 11 taskbar will add back the features the old one had, so we can migrate again in sync with the upstream, even though, personally, I don't know why they have bothered redesigning the taskbar completely... centered icons without labels could be achieved very easily with the existing code base as well, just fine.

With that being said, yeah, applying msstyles is a value adding feature of StartAllBack, I am sure there is quite an implementation in the backend regarding it, an to be honest, I barely have any experience in this area. Maybe someone steps in and helps grow the project in this direction as well.

[Gaurav-Original-ClassicShellTester]

Oh yes I agree with you about appearance of the UI/how it looks. Personally I only care how it works, not really how it looks. But since Windows 98/IE4 Windows Desktop Update on Windows 95, the taskbar has this feature where one click switches to the app if it's in the background but if the app is focused (in the foreground), the click minimizes it.

Now since with the Windows 10 taskbar (actually since Windows 7), they sort of stopped making the active window button look sunken, - and I've so many decades of muscle memory of training my brain that the pressed down button is the active window, I find it hard to figure out the active window when it's in just a lighter shade. And that's why I end up dozens of times accidentally clicking the wrong window (mistakenly, the one in the background hoping to minimize it) but end up restoring it.

Also with certain themes like the light theme in Windows 10 and 11, the difference in color/shade between active and background windows on the taskbar is so subtle that I find it really difficult again to figure out which is the active window. So in my case at least, this is one area where the modified appearance is either aiding or hampering ease of use/usability for myself (a very few users I am sure). 😆 Most have just adapted to the new look and trained themselves that the lighter shaded taskbar button is the active window - even if it no longer looks pressed down/pushed down.😊

[valinet]

I mean, yeah, the light theme isn't something that should be taken too seriously =)))) they just... tried...