I have perhaps a relatively unusual situation. I’ve made software with RB/Xojo (Mac/Win/Linux) to accompany a textbook and the software is distributed on CD with the book. In the past, I used some simple tools like iPatch to put updaters online, which worked reasonably well. But now my old tools are broken or just really long in the tooth. I’d like to avoid putting full versions online as updates (though that isn’t off the table; I am not going to the trouble of managing serial numbers, this is low volume stuff), but generating simple GUI patches just seems slightly out of reach. Asking users to use console commands to run a patch is off the table. Looked at the Monkeybread Updater package but it seems you have to buy the complete set of extensions and then the Updater package separately, and that is about $450 I’d rather not spend. I suppose I could make a separate app that basically just contains the diff file and some simple calls to the patch command (for Macs, in any event; would have to see what equivalent I could do for Windows), but an example of such a creature would be nice to see. I’ve seen mention of using the Apple Installer for patching programs, but that won’t help on Windows and I can’t seem to find anywhere a description of how that would be done. Sparkle needs some adjusting to use with Xojo and is Mac only anyways. Anyways, this seems like a terribly common thing to have to do and so I’m just baffled at how hard its been for me to find either simple tools or a concise description of how to get this done. Any pointers greatly appreciated.
Have you looked at the open-source Kaju self-updater project?
Nope, but I will now…
I can relate, I was in the “patch-update” frame of thinking for many years. I changed to just replacing the whole *** thing. The reasons why were that download speeds are so much faster where the whole point of “patching” made itself less important.
Patching is a complicated thing and the entity that usually pays the price is the customer, unfortunately. I can understand it where you have a modular app, or an app that relies on external data that needs to be updated (like UPS Worldship or Stamps.com) but I don’t consider that patching, more like self-maintenance.
Thanks on kaju. Looks relatively simple to use. I have to look through it to see what is going on on the server side–if this ends up just putting a full version of the software where it could be downloaded without having had the app, not so wonderful. There might be server-side issues I need to examine (as this is courseware, the updates have been hosted on a university machine which lives behind various and ever shifting firewalls).
In response to Garth, the preference for updating is kind of a simpleton’s piracy protection. If you bought the book, you have the CD and would have to patch that version; finding the URL for the patch does you no good unless you have a version already. Obviously this is not very significant protection (and I am aware that the apps from the CD have been shared in different places, but it is generally via email from what I have seen), but it is just enough to discourage some from theft. As the software is not sold separately from the textbook, this is kind of unusual these days.
Where you put it is up to you. You could always make the download link a custom url that includes some registration information. That could connect to a PHP script that redirects to the download based on the info in the URL.
Or something like that.
Patching a binary isn’t really practical
The dependencies in libraries etc make it unlikely that a patch would be much smaller than just replacing the app with a new version
Yeah, I understand that also. However, it’s easy to just delete 1-2 files from the updaters and make sure your executable can’t startup without those files. In other words, simpler methods rather than the complex tediousness of patching.
That’s what Kaju does.
A cheap workaround might be an invisible file on the disc you include with the book and when the app is launched you require the disc. Requiring the disc an old DRM tactic, but without setting up yourself a licensing system it might be your best solution. However it is very frowned upon anymore.
You have to replace the complete application bundle under OS X, otherwise you invalidate the code signature, and then the app won’t run.
Sam, isn’t that if you code-sign your app? I don’t code-sign my apps (yet) so this isn’t necessary for everyone.
Still, this is just one of many problems “patching” runs into. I still like the idea of patching apps - hey, it’s efficient - but the amount of problems today kills the idea. In the old days where security and permissions and bundle bits and etc. etc. etc. didn’t exist it was fathomable. Nowadays not so. Evven if you came up with a thorough complicated patching method, just the mere complexity ruins the idea and because a service nightmare.
When the code used to be in code resources writing a patch to replace one was sensible
Now with the dependencies on DLL’s / dylibs etc I think you’d find a “patch” for an existing binary would be so large you might as well just replace the whole thing whether you code sign or not
Thanks all for the thoughts. Size of the update was never the issue, it was just that a patch is worthless (well, for most users) without the original file while the full file would be useful to anybody. Since the software is with a textbook, there is no serial number or anything like that. However, I am thinking that I might just require a “registration” by having the user enter a word from a specific page of the text before any update could occur. Each update would have a different word used to unlock any future update. Pretty easy to beat, I am sure, but I don’t expect many would be interested in trying. Might spoil the beauty of an automatic update, but would emphasize that the software is sold with the book (if I ever make this freestanding, the App Store looks mighty appealing).
lol that’s another archaic DRM! There were some games that asked for a color from the manual because the copiers of the time were black and white only which was pretty clever. I would recommend requiring the disc over word from the book.
Nostalgia blast here
Why not just encrypt the update using the hash of the executable included in the book as the encryption key? Then only those people who have the version from the book could install the update. Gets to be a pain for incremental updates but you would have that pain for patching too.
Yes, obviously requiring the disc a better solution than asking for stuff from the book and many of these are fine suggestions. But we are seeing more students without access to CD players on a regular basis and this is a concern with some used book things as well. I am well aware that asking for a word from the text is exceptionally weak (libraries still exist) and not a deterrent to anybody who really wants to steal the software, the point is to simply remind a user that the software belongs with the text and so poke them in the ribs to get them to buy the book if they haven’t already.
May I ask why you are not code signing your applications?
For most developers, they’ll want to code sign their apps. Without, in-experienced users will not be able to run the application.