Sent 
.
I've just replied to the pm.
From what I've concluded, it's using inline patching (loader, RAM patch) as a deployment method. Is this correct?
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.
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).
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 thought it might be a bit far fetched to try and make the native Windows closed source plugins work with "native" Winamp Linux binaries (if they were released, some day) 
. Still, a nice idea IMO 
. WINE does a perfectly good job so far, and yeah, I'm not using anything else than the default Winamp 2.x skin, so things are fine the way they are now IMO .
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.
But why not go fully open source? I mean... I can understand in places where there are licenses attached to binaries, but why not go fully open source if every module in Winamp gets replaced with adequate code and does everything that Winamp 5.x did (and much more in some cases)?
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.
Additionally I don't want Winamp's owners getting their hands on things. Its unlikely they'd use anything but you never know with them & it's probably petty but that's the legacy they've helped cause & not wanting the snake to bite again.
Also when the likes of webamp have much more traction & barely receives patches / contributions, its reasonable that there will be even less interest in working on a win32 program as it's just not "cool" nor where interest is for others from what I've determined.
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.
And one other question. I read on the official Winamp forum that you're a former Winamp dev. Is this correct?
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).
Did a load more plug-ins & was then contracted to work on Winamp directly a few months prior to the v5.5 release (localisation implementation & some on-going support which meant I provided some bug fixes outside of the remit of my work because I was foolish unlike some of the others who just did they're contracted work & no more).
Then was I contracted on a rolling basis from 2010 until September 2015 when Radionomy ended things, with a split between SHOUTcast & Winamp over that time. It was more so on SHOUTcast but during the Winamp Cloud phase (late 2012 to mid 2013) & potential closing process in the second half of 2013, Winamp then was the focus (along with a bit of time after things were sold until it was officially halted mid-2014).
I was then convinced by some to do something around the start of 2016 after pretty much not having used Winamp since the September before & what was starting out as an update for the deprecated Winamp Essentials Pack has grown into WACUP & an attempt to provide a Winamp compatible replacement for Windows that is still supported (unlike the mess that is the 5.8 beta & its state as "not an on-going project").
-dro
Show Posts