Week 88 Progress Update (three in a row, hacking involved)

It’s now 3 weeks since resuming the blog updates and I know a few of you are happy to see these being done again so here’s another one for you :)

Like before, development is a rolling process, you may want to check out last week’s update as a few of this week’s work is a continuation of it and even the prior week.

The following things were worked on (in no particular order as taken from my internal development progress changelog):

  • Finishing off some small bits related to the installer size de-duplication work
    - This mainly involved re-assessing some of the install dependencies

  • Added some WACUP theming to the Bento and Big Bento skins
    - This matches with the classic base skin & just leaves Winamp Modern to be WACUPified

  • Changed one of the WACUP specific messages for skin changes to reduce the number of times it’s sent
    - This was more of an issue when loading a modern skin which gets new skin and colour theme related change notifications. This change (which isn’t used by the worst culprit gen_ml until it’s replaced) helps reduce some of the duplicate processing that can happen when loading skins (more so modern ones).

  • libcurl and cacert.pem were updated to their latest releases
    - This is one of the benefits of an active project in that dependent libraries used by Winamp and WACUP are updated (especially to address security issues found within those libraries).

  • More work was done towards an eventual gen_ml (media library core) plug-in replacement
    - This mainly involved looking at some of the skinning handling and trying to move more of it towards the WACUP core. More about this was covered last week.

  • Looked into some reported issues via different methods which will require a newer beta build to resolve
  • Changed the ‘Big Clock’ plug-in to not have shadowed text enabled by default and some other related minor optimisations
    - For some weird reason, shadowed text (which is just the doing the normal text offset by a few pixels to cause 2 text draws to be done) causes a 3-4% CPU load increase when enabled on my dev machine (it’s probably less noticeable on higher spec machines than my old Q8400).
    - To avoid issues I’ve made the plug-in use a different configuration entry which forces the option off for all existing and new installs with this plug-in.
    - I also added a ‘none’ option for disabling both of the visualisation modes in one click as well as using the preferred method from IPC_GETSADATAFUNC for getting the data used to drive the plug-in’s visualisation modes.

  • Investigated how to get the main playlist editor window to work with classic skin double-size mode
    - This took up large chunk of time and most of the things tried out didn’t work ranging from trying to reproduce how the modern skin engine embeds the playlist window into it’s containers and a few other things that sadly didn’t work properly which was very frustrating.
    - However… I found something that was better :) (see below)

  • Located the internal list & related data structures used by the main playlist editor
    - This is really important as it allows for direct access of the playlist data so that a replacement UI can be implemented (e.g. double-size playlist editor window) without breaking plug-in compatibility under classic skins.
    - It also opens up the ability to change the visual format of playlist editor entries too (e.g. album artwork next to the item) which I know has been a long complaint with people switching to other players just because they can do it.
    - The final key aspect is that it should allow for making the JTFE queue work a lot better & resolving the long-standing “bug” of how it works when there’s duplicates of the same file present (it picks the first of the duplicates in the playlist). This leads onto the next point (see below)

  • Determining the format of the main playlist editor data structure and then attempting to patch out code within the main playlist handling that uses some of the members for features Winamp no longer has access to
    - This is primarily about how to leverage the main playlist editor’s handling to associate data to the playlist items it handles (e.g. if an item is part of the JTFE queue).
    - By patching out things that are no longer used (e.g. from when certain AOL videos came with ad pre-rolls) this opens up a decent amount of space within the playlist editor item data structures so a) I don’t have to maintain a duplicate (and updated later on) copy with the JTFE plug-in to get it’s queue working correctly when changes are made and b) makes it all faster :)
    - This is going to take a while (will likely be most of next week’s update) but should be worth the effort as some of the work done to remove things from the JTFE plug-in and be done via the WACUP core has made the queue act up at times which this would resolve once and for all (big claims but I believe that to be the reality of this work).

That’s it for this week’s update post which overall was a step forward though not as much coding was done as I’d have liked due to the time spent on researching and trying to make sense of x86 disassembly (which plug-in developers have been doing on / off for most of Winamp’s existence when the APIs needed aren’t there of the Winamp default behaviours aren’t wanted).

Until next week, happy Winamping!



  1. Sweet. Looking forward to these updates. Thanks for all the work you are doing.

    Mark H.

  2. Indeedy, the blogging side may be a pain but we thank you from the hearts of our bottoms.
    ..bottoms of our hearts.

  3. Thank you both of you :)

  4. Nice to see someone is doing some(many)thing(s) to keep the llama walking. Sadly those pack donkeys can be terribly stuborn… Hope you manage to make it fly, but have the feeling it would be better to start afresh, maybe with one of the current open source players, so it will be easier on you and also could allow diferente platforms (i.e. Mac, Ux, Android, Xbox, etc).

  5. Starting fresh or forking an already existing player comes with a lot of issues & baggage & somewhat defeats the whole point in keeping Winamp proper working. So working on new / replacement plug-ins for what already ships with Winamp (which also comes with certain issues & baggage) is no different.

    For me & my prior experience of doing Winamp plug-ins & having worked on Winamp directly, it’s easier to go the way I’ve done instead of starting _everything_ from scratch (which means even longer to get something that’s finished & stable) or trying to get to know an existing code base (just doing that with some of the smaller plug-ins I’ve updated can be hard let alone a full media player).

    As for other platforms, I honestly don’t have an interest in anything other than the Windows version as you cannot realistically have what can be done on Windows on most of those other platforms due to them just not lending themselves to the level of flexibility (hence why the likes of UWP apps are typically ‘dumbed down’ versions compared to the true native win32 versions that pre-date them). It can also be a pain to support just a few versions of Windows let alone a range of different platforms which I don’t have the time, resources or inclination to deal with. Finally, there are much better people & existing apps on those platforms that are designed specifically to work within their limitations and really those should be used rather than trying to force a Winamp for Windows like experience onto Android, etc.