The loader injects the wacup core dll into the winamp.original process when it's started as a suspended process with detours used since a few builds back to re-write the IAT to have that dll be the first one loaded so it can hook into things a lot earlier once it's allowed to run.
Cool, that's a great idea
.
There's then my age old favourite of apihijack used for some aspects, RAM patch of some aspects (not much at all unless I've no choice) & subclassing (in combination with some of the apihijack handling) to override the window messages as needed (mainly for ensuring replacement API handling via WACUP is used vs the original winamp code).
Super cool
. Did something similar to capture encrypted content from an application
... much easier than RCEing the whole thing from scratch, LOL
.
It's not a permanent thing but just a means to keep things going whilst changing the engine as we're still driving. As I go along the aim is that there will be no winamp.original usage eventually nor the need for the loader & it'll then be back to a single exe (probably with the core maintained in a dll) & it'll be it's own thing separate of winamp but as winamp-compatible as I can make it (somewhat less of an issue when most plug-ins barely got beyond the 2.x api or any of the early 2.9x/5.x api additions).
Yeah, I agree, but why include the whole thing in a dll? I get it it was for security reasons, but I can't think of any other reason... and, as far as I know, WACUP and Winamp is (more or less) freeware
.
WINE is fine & seems to have come on well & from some of the others who are using WACUP on WINE, it does a bit better than Winamp itself which wasn't always intentionally done but always nice to find out. Ideally there would be a way to do like is proposed but the design of the platforms just prevent that & other than some manner of proxying things such as from a mini WINE encapsulated handling to a native solution just rules it out.
Still haven't tested it on Linux/WINE, but will definitely do so
(probably at work, since we dual boot there all the time, not so much at home).
And the WINE encapsulated "loader" for Linux is actually a great idea
. Not having to install WINE and running WACUP almost natively
.
I have personal issues with open source as for the most part I see doing it as giving up on a project & some others have badly tainted my overall view of OSS as a negative experience. Then there's so much changing & being in flux at times I just don't think there's any benefit to me by going open source on the core or a number of the replacement plug-ins & everyone re-writes any released code so going for what works for my style isn't necessarily conducive for anyone else to help out with it being annoying for both sides. I know these sort of things can be resolved with time, setting down rules & all that but I'd also prefer to just get on with coding than the potential of managing things.
I see your point and yes, I do agree that managing open source code can be time consuming... heck, I know a few pretty popular open source projects that don't even have forums because they hate the idea of maintaining/managing the GitHub page and the forum at the same time
. Hell, I'm having a hard time just maintaining a single forum, LOL
.
And yeah, authors do usually release the source of popular projects only when they finally give up on the project. But, I see that as a good thing. Classic Shell is a perfect example of that
. Open Shell wouldn't exist if the author didn't publish the Classic Shell source on GitHub
.
I have not ruled it out as something that can be considered later on but that would most likely happen when I loose interest &/or can no longer work on WACUP full-time which with the likes of patreon & other donations & being frugal in how I live to start with not being something I need to think about for a few more years.
Exactly what I was thinking of politely asking you, but you already gave me the answer
. It would mean a lot to a lot of people if you release the source for WACUP if/when you decide to stop working on WACUP
.
Guilty as charged. I was a 3rd party plug-in developer from late 2003 (used Winamp from 1999) & had the JTFE plug-in included in the early 5.x builds in 2004 (non-paid addition which is why it was allowed to have a donation button on its preferences).
Oh, so you're the on that, thank god, thought of including JTFE in the install, LOL
.
It's good things started with a former dev
. You're more familiar with the guts of the whole thing, so you're probably most qualified to run this whole thing
.
Good luck and I hope more people start joining in and participating in something that (at least in my mind) will have a great future
.
Show Posts
.
. I'm also guessing that Winamp's API changed considerably since 2004, 2005, and that's why the last version that allowed taking over all MP3 decoding was 5.24... and the plugin didn't work with a single version since 5.24 
