You realize that if the update happened to be just the bits that should change at certain offsets of the previous version that the update then failing would probably make trying to reapply that same update impossible (due to different offsets, even using AoB). Now I've no idea if that IS how it's implemented, I've never looked tbh, but if that's the case or something similar then having access to the update files does nothing for you. As to the logger, if it IS the updater itself messing up due to something being changed in rare circumstances (not interrupted) then the logger would help with that, and even it it isn't, a log isn't a horrible ideamalokin wrote:Releasing the update files as executable
Should the outside interruptions be true (which does seem somewhat likely to me) then a logger might also be able to tell exactly where and how to prevent that, for instance, a popup saying it failed and ask for reversing privileges at the least so that you can continue with the previous version.edit: though it would seem to me that the simplest method would be to backup the files before modification/replacement, then if the next launch (configurable? for bug reasons) is successful then they can be removed.
MWAHAHA) why dont you want update executable style? Is it development time it would take for past versions? Fuck past versions, your still beta anyhow. I'm aware of how the update looks for changes and only gets the necessary files, very much like linux software package libraries deal with dependencies. Very high tech bro, but if you botch my exe again to the point it wont run, then your just pretending to yourself that you fixed the bug with checksums and loggers.
