Now that we're out of our 0.9.1 "stabilization mode" coding, it's time to start working on some more interesting things.
First up is the resurrection of the "Program Update" code. Updated the URLs to point to a PeerBlock-specific website, uploaded my own latest-update-checking script, and BOOM . . . nothing. Well, that's not entirely accurate - the program's updating the "Updating" UI to change the status to say "Update available, see (url)". The thing is, the program's supposed to pop up a window and tell you to download a new version, loading up the website in your browser for you if you choose to do so. Doesn't look like this code was working even in the PeerGuardian base code, but then again since the PeerGuardian update URL says the latest official version was built in 2005, I suppose nobody would really remember all that well whether it worked or didn't.
Either way, it's working now! PeerBlock will now check for updates, and will actually let you know if a new version is available. And it will pop up that window asking you if you'd like to be taken there. And it will take you there if you so choose.
Not as slick as an automatic update routine that does everything under the covers for you, but it should suffice for now. Speaking of which, I need to add an Enhancement Request to our issue-tracker to track that idea for future implementation...
The diffs are actually relatively straightforward, and the tracelog routines sprinkled throughout should help let you know what's going on in each section.
That said, there are a few hairy bits...
The way it works is the program stores a date-string for when it was compiled, sticks a number on the front of it to identify build-type, and calls this the BUILDSTR. We then open the URL for a PHP-based update-script, and pass it this BUILDSTR. The update-script then returns a string (in the same format), identifying the latest release for that build-type. PeerBlock then checks to see if the returned latest-version is greater than its BUILDSTR number, and if so gets ready to perform the update operation.
I updated this a bit to add a build-version to the end of it, and ended up needing to update a few key variables to type "unsigned long long" as a result - those numbers are getting awfully big! Also note that we should probably reduce the build-type #defines by a factor of 10 once 2010 rolls around; they're only so high because otherwise STRINGIFY ends up stripping the leading 0.
And for what it's worth, we never seem to real the else clause that starts on line 638 in updatelists.cpp. This is why the updatepg was never being set, which caused the "Update available, would you like to go there?" window to never be displayed.