I'm just curious about the open vs closed source nature of this project. You haven't been able to re-write it except for parts and plugins to keep it relevant, So it sounds (and feels) like it's patchwork done pretty well.
Patchwork is a decent way of describing large aspects of things though it's not helped with how things have naturally developed over time. WACUP started out as a plug-in pack of some of my key existing plug-ins before evolving into providing replacement dlls / plug-ins for some of the Winamp 5.666 ones.
As part of that second stage I'd also started to make a loader program that'd allow me to inject what's become the WACUP core dll into the original Winamp 5.666 main program (which shows as winamp.original once WACUP is running) to be able to do live patching of some of the code within Winamp's program file which was initially to help change some behaviour that couldn't be done via existing subclassing & apihijacking methods (overriding some of the OS api calls) which were things I'd been using since 2003 when I got into making plug-ins.
I've also done binary patching of the original program file (e.g. disabling some of the anonymous stats collection) for things that it's just simpler to always prevent that code from the original program file to run.
The live patching / subclassing / apihijacking is what's then allowed for much more of what has become the patchwork replacement of things with the core along with replacement of more of the supporting dlls / plug-ins from 5.666 for WACUP provided ones. It was once I'd started doing much more of that at which point I changed the 'P' from pack to project & WACUP moved towards the end goal of being Winamp compatible with using Winamp to run.
In hindsight, if I was going to start out with making WACUP as it's own thing then I wouldn't have done things as I have since I'm now having to spend a lot of time essentially re-doing what I'd done so it doesn't then involve live patching but the piecemeal replacement of things has however had the benefit of better ensuring that plug-in compatibility is far more complete compared to what other players offer (they only offer a limited plug-in api & typically cannot support behaving general purpose plug-ins).
I'm just curious about your statement, "source code without a developer is completely useless", etc. I agree with that, but can I ask why open-sourcing WACUP leave it without a developer? I don't imagine the source code is "pretty" in this specific case, but would you feel a decline in ownership to accomplish tasks that need to be done?
I don't think I've said open sourcing WACUP (which I'm not ideologically aligned with doing) would mean there's no developer, it'd just more likely mean I'm no longer around / involved. I just don't have much faith in the many eyeballs thing that's always thrown about with OSS & how it's going to make software massively better since there's nothing to stop someone offering to make for example some of the input plug-ins that still need to be replaced but there's either not the interest either because of my stance on things or that it doesn't appeal to those that might be able to do it.
Another thing is I just don't want to do project management which especially accepting things on the WACUP core would bring & it's hard enough managing myself let alone others. The other thing is that the scope of what WACUP is doing probably could do with more people working on it for some aspect but there's no way I'd be able to financially compensate them since what I manage to bring in is massively below minimum wage & is just lucky I live a frugal lifestyle to stretch it out nor can I expect them to follow the unhealthy amount of time I do put into this (not helped that I personally think I'm a slow coder).
WACUP is a different case than other music players, but would that stop you from continuing to work on it?
In comparison to other media players which don't seem to have this same level of demand to be OSS, they're typically a few people at most with more often just being 1 core dev doing the majority of the work.
In some respects keeping it to how I'm doing it at that moment also makes it simpler to keep to the vision that's wanted as even from my days when I was working on Winamp proper I didn't agree with the way that it was trying to be taken for which I'm instead with WACUP trying to go in the direction of what I think Winamp should have gone i.e. embrace it for what it is instead of trying to change it more into an iTunes analogy whilst taking the time to look at how people are using it & make sometimes breaking changes where it's going to be more beneficial (this is something that the skinned ui massively hinders at times).
Maybe if I was more aligned with everything is OSS & that's the way to do it then I might've gone that route but there's also a bit of pettiness on my part in not wanting some of my plug-ins to be OSS as it would've allowed Winamp's current owners to then grab them for which I don't want to happen (e.g. JTFE). I do get that it seems conflicting as I'd also not go down the GPL route (which I know would resolve that assuming license compliance) as I don't like the nature of GPL whereas a zlib/bsd-like licensing being more how I prefer to do things which I know is at odds with my prior comment.
Not that it probably matters as they've made it obvious they don't care nor want to invest in the original program whereas I think there's still the scope of that vs going the everything is just a web app wrapped in electron as I'm seemingly a tech dinosaur but it's what I know & generally provides the end result that I want.
Is it mostly just plugins and DLLs? It seems like a potential monster to me. But again, no experience.
A large part of what is Winamp is plug-ins & dlls but there's also the loader program (aka winamp.exe) that manages & brings it all together. Its the replacement of that (the loader) which is where the patchwork nature of things is the most obvious & has caused some WACUP builds to be painful to use but it's ultimately time & perseverance & past experience since I spent over 7years just working against pre-compiled files before eventually working on Winamp so doing WACUP has been a bit like going back to those before times.
I do appreciate it's hard for me to fully convey what I'm doing at times but something that was always part of what I tried to do with my plug-ins was to make them seem like they were native & doing WACUP is ultimately taking what I did for them & stepping things up a few levels. So as long as what is provided works then it probably doesn't matter too much how I've done things (as I doubt most care about patching techniques & the problems between cdecl, stdcall & fastcall conventions) & just that it works preferably without any crashes.
Hopefully that all makes some sort of sense to what you're asking.
-dro