With everything that has gone on over the last 4 weeks (which I suspect most following things already know about or it can worked out from the title of this update) I can only apologise that the blog didn’t get updated at the same time (it’s all been a bit hectic between WACUP work and un-related personal matters).
With this update I’m not going to cover everything as I’m not sure that’d be too interesting or even if I could do that from the notes I’ve made about things as I’ve gone on. If you just want a quick summary of things over these last few weeks then it’s best to have a look at the beta changelogs for the builds that have been provided so far to the beta testers (and due to some of the issues covered later in this post a build wasn’t released during this week).
So lets start at the beginning which was the work done in Week 41 which was a super busy week as I’d set down that the first WACUP beta build would be made available by the end of week - so no pressure at all due to some of my prior deadlines having been missed (albeit for the better in the end).
This was thankfully achieved with an hour to go before at 11PM (GMT) on Sunday November 6th with the release of v0.9.9.1316 to the beta testers. You can still join in with beta testing (the more the merrier as they say) by making an account on the Community Forum and following the instructions in the activation email.
Getting the build into a releasable state during this week left me a bit torn at times as there were things that I wanted to include but needed more work to make them stable enough to be included. The biggest one was the disabling of the File Association handling (within my re-worked code and also what Winamp natively is trying to make use off).
There was also just in general looking at what if it was provided as-is would be safe for beta testers to work with and try out. The end result was the first beta build not having everything that is detailed on the development changelog. I mention this as there was a bit of confusion but the aim is for when the first non-beta release is made available (as it’s going to stay in beta for a few months) that the changelog is the same as the development changelog.
So the summary of things that were done from my notes are as follows:
- in_url usability improvements from better cached url handling to deal with temporary urls through to auto-downloading youtube-dl.exe to save having it bundled in the installer
- Ensured the included libcurl is making use of a current cacert.pem file for correct certificate handling when making HTTPS connections
- Disabled a swathe of un-finished features from embedding the video window into the media library to file association & shell integration preferences
- Added option to toggle the no registry mode on the portable mode preferences page
- Added option to open the paths.ini file editor on the portable mode preferences page
- Updated libcurl to 7.51.0 (security fixes mainly) & improved it’s scope to accept compressed responses & http/2 connections
- Added a ‘path’ option to the /PATHSEDIT command-line option to override the automatic detection based on the last install
- Improved some issues with the elevator replacement not registering correctly & few other minor things to make it easier to expand it without breaking backwards compatibility (joy of vtable ordering)
- Made a slew of installer & build related tweaks to make it much easier to just set a version and build against that
- Added basic means to see the latest WACUP version (final and beta) on the about WACUP preference page
- Added initial placeholder page for the beta installer information between the license and directory pages to make it more obvious (especially if there’s anything breaking) to take account off prior to installing the beta build
- Change more of the plug-ins get some of the required Winamp locations directly without having to go though the Winamp api (minor optimisation to prevent potential blocking on loading, etc due to going through too many subclassed window procedures)
- Removed the file association aspect during installation so it’s just skins now (and so have hidden the next / back buttons)
- Added basic download / install & run options for the Winamp Backup Tool (though the quirks with it need to be resolved later with koopa)
Moving onto Week 42’s work and it wasn’t as I’d expected as I got feedback (and bug reports) a lot sooner about the first beta build than I could have imagined (only after a few hours).
So this week primarily became a triage and bug fix week which led to the release of v0.9.9.1322 only 5 days later on Friday November 11th.
The changes ranged from a number of crash fixes (some which I should have caught before the release but then that’s the downside of fixed deadlines at times) through to changing installation defaults that make for a saner initial install (though there’s more to do about that moving forward towards a non-beta release).
Otherwise there was a fair bit of social media related things, sorting out some issues with the forum to resolve some login issues and just working out plans based on what was being reported for work to later on be done.
Moving onto Week 43’s work it was a bit more of the same in dealing with with the more trickier to resolve issues which weren’t resolved prior to the second beta build.
The end result was the release of v0.9.9.1328 on Friday November 18th and resolved the majority of the stability related issues which had been reported.
It also helps for me to re-read Windows API documentation to make sure I’ve understood it correctly as the main cause ended up being due to using a Windows API incorrectly but which under Windows 10 is gracefully handled compared to Windows 7 where it will crash. So in that respect it’s nice that Windows 10 is more resilient against issues in programs but in this case wasn’t helpful for me trying to track down the issue on Windows 7 (which hasn’t been my primary OS since moving to Windows 10 at the end of July).
The only other thing to comment on from Week 43’s work was in trying to work out some of the odd stability issues being reported which took almost 2 days to come to a solution.
The eventual fix (which related to live-patching some of the CRT string functions to deal with invalid parameters from the modern skin engine) wasn’t quite as I’d expected it to be. As for a while it looked like I’d need to do some deeper level x86 assembly patching (i.e. the low level code that’s actually run) and was trying to work out how best to do that within certain limitations (i.e. only so many bytes of data being able to be changed).
Thankfully it worked out being able to code a fix normally but for some of the things that WACUP is trying to achieve, it involves x86 assembly patching and it’s an area in general that I’d like to become a bit more proficient at.
And now we get to Week 44’s work (i.e. what should just have been this update if I’d been doing them like before the week of the first beta). I had been hoping that from the third beta build that having gotten the main issues resolved that I could look into getting on with adding some newer & previously incomplete features not included with the first beta build though that didn’t really come to be.
I’m not complaining as the feedback I’ve been getting from the beta testers who’ve been posting issues has been brilliant and as I want WACUP to be more stable than Winamp and because I appreciate the beta testers time, I’m happy to take longer to get a newer build out if it means I can finally resolve issues that are being reported.
The first was looking into issues related to the ‘Big Clock’ plug-in which mainly stemmed from the plug-in trying to re-query information about Winamp’s current playback state around 100 times a second when most of it doesn’t need to re-queried so much. The not yet released fixed version of the plug-in drops it down to around 30 times a second which is only needed for knowing the current playback position and for getting the audio data for the visualisation modes.
Additionally by adding in additional caching of most of the information as well as better control of when the plug-in does it’s work and making better use of the more ‘modern’ Winamp API (if you can call things from 2003-5 that ;o) ) rather than working as though it’s Winamp 2.x.
From the user view point such low level things probably don’t matter or make sense (if it worked for Winamp 2.x then it’s got to be OK yes…? - I’d have to say no) but to a plug-in developer it means you can go from ~3-4% CPU at idle (i.e. Winamp not playing anything) to effectively 0% CPU at idle. Also when Winamp is now playing and the plug-in is present then there is now no noticeable effect of it compared to general playback overheads so I call that a successful fix :o)
The next thing which took a while to work out related to the ‘Waveform Seeker’ plug-in which due to a load time ordering issue was sometimes creating waveseek_in_*.dll files if Winamp was started from clicking a file in Explorer and was not already running.
The issue itself probably shouldn’t have happened but is one of those things that can occur due to assumptions of when those events should be happening vs trying to only have the plug-in to do things only when needed (which is a sensible way to improve load time and reduce resource usage to only what’s needed when it’s actually needed).
The next area of work related to my build process (primarily the auto-generation of SHA256 hashes of the WACUP beta installers) and based on the previous 3 weeks of beta builds what I could to help make it quicker for me once I was at a stage that I was happy enough to make the build.
So between leveraging the NSIS 3.x !finalize command and a bit of Windows PowerShell magic) I saved myself some pain in generating the SHA256 hashes. There’s still some more things that I want to get done which primarily relates to the build publishing process but I’ll work on them later on.
The final things to cover related to starting to look into 2 issues, the first being the Not So YASAPI Output Plug-in not saving all of it’s settings which then got halted mid-process to attempt to determine why a WACUP install in some cases was taking a few minutes to load.
The loading delay now appears to be related to issues with the replacement UAC / elevation handling I’ve implemented (which is needed to be able to achieve a number of additional fixes and features).
So that is where I’d gotten to be the end of Friday and due to the nature of the bug I made the decision not to release a newer beta build for this week partly due to running out of time and due to the bug manifesting in some other areas I want to get that resolved first before putting out a newer build.
Sadly that means I’ve broken the chain of Friday builds but in this case I hope it makes sense and as soon as I’ve got it resolved I’ll be releasing a newer build to the beta testers. Once that is done then more of the fun things can be worked on again instead of just bugs & stability fixes as everyone likes to try out new things :o)
So that’s if for this jumbo 4 week update :o)
Finally I just want to re-state my deepest appreciation for those who’ve provided feedback about the first few beta builds as it’s been very constructive and I’m using it to help determine where WACUP is going, so thank you!
-dro
Thanks DrO!
I don’t think anyone minds if we wait 1 week or 10 weeks for an update. It’s just so great to see Winamp alive and kicking once again.
Tim
Fantastic work Darren! Congrats on the beta releases!
Glad to see things are moving along. I wish I had time to beta test, but alas.. though I still very much enjoy reading about your progress. :)
Keep up the good,no great, work that was started decades ago!
Thanks for keeping Winamp alive! Cant believe I still prefer it over all the other players, just seems to have better performance and I love the modern Bento now Playing skin / view etc… would love to see improvements to the Album Art view for smart views, where to add feature requests?
Thank you for keeping this alive it’s one of my favorite applications for almost 20 years. I bought the Pro release to thank them, just as development was going down hill. THANK YOU!
The two things I’d like to see continue in addition to possibly CD burning is a Lean version, fast and mean all about the playlist and simple VU bars, open and closes better than anything built in and visualizations, which might be tricky as many were lost due to changes in OpenGL. If CD burning is on the table I’d go for bin/cue sheets and ability to burn continuous mix with tracks, which would add much value to many.
Thank you for keeping this alive it’s one of my favorite applications for almost 20 years. I bought the Pro release to thank them, just as development was going down hill. THANK YOU!
The two things I’d like to see continue in addition to possibly CD burning is a Lean version, fast and mean all about the playlist and simple VU bars, open and closes better than anything built in and visualizations, which might be tricky as many were lost due to changes in OpenGL. If CD burning is on the table I’d go for bin/cue sheets and ability to burn continuous mix with tracks, which would add much value to many.