360 Games Patcher 3.0.5
Gildo Santiago
Take a patch contained within a single patcher window, place it within a patcher object, add inlet s and outlet s, and you can instantiate it as an object (or many copies of that object) capable of its own messaging, embedded within a larger patch.
What is the point of such a patcher, since official Id patches already do this (and updates are seldom only to the IWAD, but to the .exe as well) ?
There's only some room for such a tool in downgrades, provided of course someone can build a database of patches to apply retroactively to a specific version, and the tool can conveniently apply patching to more than one file.
OK, in the (unlikely?) event that you have just lots of loose IWADS floating around without a paired .exe and readme.txt and whatever else comes with a normal vanilla doom shareware or registered installation of Doom, and no way of "guessing" what version they could be ("I took those from the Collector Edition...hmm...maybe they are 1.9 ???") then the auto-detection functionality COULD be useful.
The ID patchers don't do any detection because they only work with one specific version of DOOM (including IWAD and EXE), and either you have it or you don't, they don't "adapt" or anything.
I am not trying to tear down the tool, only pointing out it will be useless without a very detailed version databasing job behind it (that means you have to know which bytes change in EVERY file the user is supposed to have when upgrading/downgrading from/to any two known versions.
Unless the tool comes with a database to do just that, it CAN'T be better than ID's patcher in any way.
Edit: from the docs it seems it actually has a "any version to any other" database, and so far it's good, however it only works for IWADs, not .exes, so it cannot replace official patches yet.
Another essential requirement for a tool capable of replacing official patchers would be 16-bit DOS compatibility, like the patches. In other words, if DOSBOX cannot run it, it kinda misses the purpose. I like those "worst case" scenarios, so imagine the last computer on earth is a 486 that can run vanilla Doom :-p
You'll need a trustworthy and reliable tool to really preserve its legacy ;-)
Moot point, the ID patchers aren't hard to use really. DOS environments exist which are free (DOSbox runs the game, patchers, installers fine; FreeDOS also exists which runs on hardware natively (or you can use it in QEMU)).
Another essential requirement for a tool capable of replacing official patchers would be 16-bit DOS compatibility, like the patches. In other words, if DOSBOX cannot run it, it kinda misses the purpose. I like those "worst case" scenarios, so imagine the last computer on earth is a 486 that can run vanilla Doom :-p
The problem is that unless you compile stuff with an MS-DOS friendly compiler, you will get a nice "This program cannot be ran in DOS mode" error message. Compiled as a console app != compiled as an MS DOS app
And no, I don't have anything against the patchers (by itself it's a good idea) but in its current form it cannot be a replacement for Id's official patchers. E.g. Id's patchers, if need be, can be loaded on a floppy disk and upgrade a copy of doom running on a 386 with MS-DOS 5.0, unless Gator's patcher can do the same it cannot be considered a substitute. Maybe a better alternative for modern machines, but not a total substitute.
Whoah whoah, hold yer horses, that's the first time in the entire thread that the AUTHOR says it's not intended as an Id patcher replacement (and only now I noticed). I respect that, I "got it", let's see when others will "get it" too. So everybody happy?
Considering the discovery lately, updating the patcher makes sense. I'd say, the unofficial tnt.wad patch should be replaced with the official one. And whatever changes were made to plutonia.wad should be available as well.
A patcher object could potentially even include other nested patcher objects. Dividing your overall task into separate tasks (subroutines) and encapsulating each one as an object is a good way to organize your program.
Archive-patcher is an open-source project that allows space-efficient patching of zip archives. Many common distribution formats (such as jar and apk) are valid zip archives; archive-patcher works with all of them.
Archive-patcher transforms archives into a delta-friendly space to generate and apply a delta. This transformation involves uncompressing the compressed content that has changed, while leaving everything else alone. The patch applier then recompresses the content that has changed to create a perfect binary copy of the original input file. In v1, bsdiff is the delta algorithm used within the delta-friendly space. Much more information on this subject is available in the Appendix.
In order to generate spatially efficient patches for zip archives, the content within the zip archives needs to be uncompressed. This necessitates recompressing after applying a patch, and this in turn requires knowing the settings that were originally used to compress the data within the zip archive and being able to reproduce them exactly. These three problems are what make patching zip archives a unique challenge, and their solutions are what make archive-patcher interesting. If you'd like to read more about this now, skip down to Interesting Obstacles to Patching Archives.
Solution: Archive-patcher transforms the input archives into what we refer to as delta-friendly space where changed files are stored uncompressed, allowing diffing algorithms like bsdiff to function far more effectively.
Solution: Archive-patcher iteratively recompresses each piece of changed content with different deflate settings, looking for a perfect match. The search is ordered based on empirical data and one of the first 3 guesses is extremely likely to succeed. Because deflate has a stateful and small sliding window, mismatches are quickly identified and discarded. If a match is found, the corresponding settings are added to the patch stream and the content is uncompressed in-place as previously described; if a match is not found then the content is left compressed (because we lack any way to tell the patch applier how to recompress it later).
Problem: The patch applier needs to know that it can reproduce deflate output in exactly the same way as the patch generator did. If this is not possible, patching will fail. The biggest risk is that the patch applier's implementation of deflate differs in some way from that of the patch generator that detected the deflate settings. Any deviation will cause the output to diverge from the original input to the patch generator. Archive-patcher relies on the java.util.zip package which in turn wraps a copy of zlib that ships with the JRE. It is this version of zlib that provides the implementation of deflate.
582128177f