Is this an open source project or a hack

[GigaWatt]

I think the question is pretty simple... I tried to find some more info regarding the project, but this site and forum was all searches came up with .

EDIT: I tried to register an account here under a different username, but the activation email never arrived... I might have typed the email address wrong ... could the forum staff please look into it, thanks .

[Eris Lund]

https://github.com/WACUP

This is probably the only site with some parts of WACUP open sourced (although those are plugins only, nothing deeper than that)
It's more of a 'hack' as the Winamp core is being patched to be more or less a hybrid of WACUP and Winamp itself (dro can correct this if this was explained in a wrong matter), which allows it to do a bit more than what Winamp did

[GigaWatt]

Thought so ... just wanted to make sure that I didn't (somehow ) miss Winamp going open source, LOL .

I installed WACUP last night... I have to say, it's pretty much how Winamp used to be, just the way I liked it . I still have a few more things to check out, like if the MP3Pro plugin works like it should (it didn't work at all, up until v5.8, so I was stuck at v5.24 ), which is a must, at least for me (I converted all my music to MP3Pro years back and... well, I just don't want to have to recode everything again) and see if I can adjust the ID3 tag editor to show both ID3 v1 and v2, side by side .

In any case, this is a great project . Love the fact the some people decided to finally stand up and continue working on something that has been a part of our lives since... well, as long as I can remember . I hate seeing good things go down the drain, and IMO, Winamp was definitely going down the drain .

It would be cool though to see if all of the parts of the player get replaced with open source code . Then, we could finally start working on a native Linux build . Even cooler, a native Linux build that can use native Windows libraries that are closed source, like the MP3Pro plugin for example .

[dro]

You'll need to PM me some details re: the failed user account as I don't appear to have any obvious non-activated accounts.

WACUP is a mismatch of new plug-ins, old plug-ins, some closed source, some open source, live code patches, hard-coded code patches, original compiled code & other aspects in-between that. You could say hack for some parts but then most software & original handling within Winamp is deemed a hack

I don't have plans to go 100% open source & in all honestly a solution for Linux is much better done directly than trying to re-work Windows specific code as Winamp / WACUP & related plug-ins have been coded. For the most part, most Linux solutions can do the classic 2.x style skins & that's alright for most. Plug-ins however aren't platform agnostic so you couldn't do things like running existing Winamp plug-ins within a native Linux / other platform as they're different designs of being run (sure some of the compiled code can probably do it but it's the equivalent of putting diesel into a petrol engine - both are fuel but it's not a good idea to mix & match).

-dro

[GigaWatt]

You'll need to PM me some details re: the failed user account as I don't appear to have any obvious non-activated accounts.

Sent .

WACUP is a mismatch of new plug-ins, old plug-ins, some closed source, some open source, live code patches, hard-coded code patches, original compiled code & other aspects in-between that. You could say hack for some parts but then most software & original handling within Winamp is deemed a hack

From what I've concluded, it's using inline patching (loader, RAM patch) as a deployment method. Is this correct?

I don't have plans to go 100% open source & in all honestly a solution for Linux is much better done directly than trying to re-work Windows specific code as Winamp / WACUP & related plug-ins have been coded. For the most part, most Linux solutions can do the classic 2.x style skins & that's alright for most. Plug-ins however aren't platform agnostic so you couldn't do things like running existing Winamp plug-ins within a native Linux / other platform as they're different designs of being run (sure some of the compiled code can probably do it but it's the equivalent of putting diesel into a petrol engine - both are fuel but it's not a good idea to mix & match).

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 .

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)?

And one other question. I read on the official Winamp forum that you're a former Winamp dev. Is this correct?

[dro]

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

[GigaWatt]

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 .