200 Weeks of WACUP (thoughts, plans and tl;dr :) )

If you’ve only been following the blog updates then it looks like I’ve not done much since the last update in April 2019 but that’s not the case with 14 beta builds (some of which where quite substantial!) & half of those also being released as preview builds between late August & mid-October.

Things have slowed down a bit on builds since mid-October due to some of the work that’s been going on to replace more of Winamp for WACUP provided features which has been somewhat of a rabbit hole (e.g. file association & some video related aspects).

However the delay should be worth it plus it’s given me time to make more sense of the automatically uploaded crash reports that now get provided (which has been enabled since preview build & has slowed down development in monitoring & resolving them but it’s worth it for longer term stability improvements).

200 weeks is a lot of time especially in the fickle internet age we live in & it’s fair to say that WACUP development hasn’t gone as smoothly as I or others would like (or maybe it is for some of the haters) but software & life can be a cruel mistress at times.

That’s why I’m most grateful to those who’ve supported me via Patreon & all of the other ways be it financially or just providing feedback, testing things & helping to spread the word about WACUP.

How I view WACUP & what I & others want it to be has changed a lot over the almost 4 years since I started working on updating my Winamp plug-ins again back in January 2016 with the intention to just make a replacement for the Winamp Essentials Pack (WEP) whilst trying to find a job.

As it’s now moved on far beyond being an update pack to aiming to be it’s own thing which isn’t reliant upon the Winamp 5.666 plug-ins which is slowly getting there with around 70-75% of Winamp provided plug-ins & supporting dlls replaced / removed with WACUP versions.

There’s still a lot more to do especially with the likes of modern skin support (a hefty task on it’s own) & removing the need to use the original winamp.exe from 5.666 but it’s all progressing in a forward direction which is all I can ask for.

Another thing is whether I should have taken the approach of replacing plug-ins & doing code patching (which is how I’d been doing plug-ins since 2003) or just begun writing a full replacement from scratch once I’d started to realise WACUP was changing from being an update pack to being a full project.

I’m still uncertain as the current approach has meant it’s easier to check compatibility is good since it’s based against Winamp but in other respects it’s been a hindrance due to the issues that patching can cause (not helped by some of the quirks of how plug-in loading can go at times due to Windows / A/V software).

That’s why a key aim for 2020 is to remove the need to use the original winamp.exe from 5.666 along with anything else that can be dropped / replaced (e.g. the replacement media library core plug-in is almost ready for beta testing).

This is an important change in how WACUP will work as I’d prefer to not to have to do patching (A/V software doesn’t like it at the best of times) & I don’t see there being any continuation of Winamp on Windows (or in general for that matter that isn’t a final bastardisation of the brand name) by it’s current owners when there’s still a demand for support & updates of a Winamp-like solution.

Focusing on this transition away from relying on Winamp program files also should make it easier to sort out issues that have been a persistent hassle to work around whilst also allowing better integration with the setups that are being used.

I’ve also not hidden the desire to make a native 64-bit version of WACUP which using the original winamp.exe prevents & yes that would break all existing plug-in compatibility which is why there would still be a 32-bit version provided for those needing 3rd party plug-in support.

There might also be ways to proxy data between things but in some respects it might be easier to make a clean beak as many Winamp installs never saw 3rd party plug-ins installed in them so not being able to load them isn’t necessarily a bad thing especially when there’ll still be a traditional 32-bit version that can still use them.

Now we’re nearly at the end of this update & what’s happening or aiming to be done this month. The key aim is to have the file association handling completed as it keeps coming up as a reason people don’t want to use WACUP full time.

Once that’s done & hopefully confirmed as working ok then I’m going to be focusing on the replacement local library plug-in (ml_ll) so that it will finally get import / scanning support as well as being able to display albumart within the views.

When both of those aspects have been done & confirmed as usable then I will be dropping the preview moniker on the builds & we’ll be into the 1.1.x releases. Whether that happens in 2019 or I give it a bit more time to happen during January/February 2020 (probably to coincide with the 4 year anniversary) I don’t know but that’s how my plans & scheduling are currently going.

So for the tl;dr:

  • I’ve been working on WACUP for 200 weeks & there’s more to come whether you want it or not :)
  • The key aim for 2020 is to no longer be using the original winamp.exe (or any other files from Winamp 5.666 where possible)
  • File association support & completing the base features of the replacement local library is the main focus for the rest of 2019
  • Non preview builds will be released once the above line is completed & will be released as v1.1 (probably January 2020 but there’s some wiggle room)

Until next time, happy Winamping & all that fun stuff :)



  1.   Arvis Pinkletter  |  Monday, December 2, 2019 - 17:59:38

    So… wait a second … if the aim is to no longer need winamp.exe (or any other files from Winamp 5.666 where possible) then is this now “its own thing”, a completely separate piece of software that just looks and acts like winamp? Once you get past “preview” does that mean there is a possibility that you might run into legal trouble, where the owners of winamp might say “cease and desist” (while also not providing any new software themselves)?

  2. Exciting Times! Thanks for your ongoing hard work.

  3. Arvis Pinkletter: Releasing the preview build was when I thought they’d try & do something along the lines of a tenuous cease & desist even though I’m not using any pre-compiled files from their version nor am I claiming to be Winamp (hence the specific wording on the site, etc) & is why the WACUP installer will install the patched 5.666 install on your behalf instead of including the files directly.

    The skins are also able to be used under fair usage as the origins have been stated plus they were all liberally licensed otherwise spotiamp/spotiamb, webamp & numerous linux players would have had issues long before.

    By getting to the point of providing something that is its own contained program but is as Winamp 5.666 compatible as it can be from the look with ability to load Winamp skins & plug-in support via the open plug-in APIs, etc then I also don’t see how they have any recourse. As they’d then need to go after every other Winamp compatible player & solution which they’d be fools to do as there’s enough bad blood against them as-is without doing that (but you can never know for certain with such a company).

    They’ve made it clear they aren’t wanting to develop the Windows client further & I’m trying to fill that gap. What makes Winamp Winamp is a hard question to answer as a lot of the comments I’ve seen (especially related to webamp) point to people just wanting to load the skins & that’s about it to get that Winamp feel. I’m obviously going further in trying to do things like-for-like in a number of aspects like the preferences (though I’m trying to move them around to make them a bit easier to self navigate) due to trying to maintain compatibility.

    Tim H: Thanks Tim :)

  4. As long as I can use this software to listen to game music files (.spc, -psf etc.) I’m a happy camper.

  5. BTW, can hardly see what I’m typing in the comment field. Light grey text color?

  6. Ninos: That’s the aim to maintain support & where possible integrate the likes of PSF & other VGM related formats natively.

    I’ve also fixed the comment & add button text colouring issue - CSS is a pain at times & I’d missed it when I re-themed the blog earlier in the year, oops.