In theory, if you have X and whatever widget toolkit byuu used (looks like GTK to me) on OS X, you should be able to compile and use the Linux version with few or no modifications. Of course, X is a pretty heavyweight dependancy, and it won't be as nicely integrated as a native port, but it should work.

And besides, why use IPS on smaller files if both would be equal good, it's easier to just have one format.

byuu, there are a few issues with your patcher that needs to be addressed. I'll PM you about it.

I've removed my patcher for now, sorry for the inconvenience. Please see my website here for a detailed explanation. Essentially, there are too many bugs in it. I don't have time to address them all right now, and I'm under way too much stress at home and work to handle the constant bug reports by multiple people. Nach's patcher will be out very soon, it's in beta testing right now. I'll link to it as soon as it is ready.

And we will still be picky then, but hey, that is human nature.

byuu, does this mean that your patcher is still usable?

Gonna submit that to the main site, or is it okay to link others directly to it?

It depends on whether or not Nach and I decide to go with my method of extending files, or his. If we go with mine, then as long as you can apply the patch in both directions, yes it will be fine. I made a UPS patch with Nach's beta and it matches 1:1 on everything except the extended portion of the file.

I'd say wait for the time being, shouldn't be too much longer.

Okay, this all turned out to be FUD.

I was making the patcher fail if the patch was <20 bytes, assuming there would always be at least one patch block. Turns out, just a file resize of all nulls will create an 18 byte patch as the smallest possible, since you don't need to store a change when the extension is 0x00. I can pass all tests I've been provided now. There may be some edge cases that have not been provided to me that I still fail, but it should be simple enough to fix.

Basically, too busy worrying about extreme edge cases (though important), that didn't really affect any real-world use scenarios.

The DL patch is 100% identical in the old and new versions now, and Nach's outputs the same code up to the file extension. Since he converted the file extension to my syntax, ours are pretty much guaranteed to produce identical output now. The only way a new DL patch will be needed is if we change something up before the next release.

When Nach is online again, I'll check with him on the last bits and post a new version. I'm using mmap / MapViewOfFile, now. It makes the patching algorithm twice as small, and now the same code can be used for in-place memory patching (for emulators) as well as for file patching using a simple wrapper.


That's because those same two points are the cause of most of the problems with IPS.

I get the feeling nobody is reading what I'm writing ... but I'll say it again:

With stacked patches, you cannot verify CRCs, because they can be applied in arbitrary order. The best you could do would be to keep a large list of valid outputs CRCs, which is just tacky, error prone, and can never cover every possible scenario.

Because of the lack of CRCs, you can never know if you applied a patch successfully or not. This causes countless problems with applying patches to headered vs unheadered ROMs, etc.

Further, applying multiple patches is absurdly dangerous. If they both modify the same data, that's very likely to cause problems. And if they do not, then UPS will already work just fine if you simply ignore the bad CRC match. Further, you can chain UPS already (eg A+B=P1 and then (A+B)+C=P2), just not the way you want (A+B=P1, A+C=P2, eg stacking.)

You basically want a patching tool to be a development tool, which really isn't what it was designed for. You can write programs in DOS edit binary mode using alt keycodes, but should you?

Nach is opposed to adding both unidirectional and bidirectional support to the same file format, and I have to agree. If only because doing so would mean you'd end up with UPS files and have no idea from a glance what they were supposed to do (eg if I apply this patch, will I be able to reverse it?). Plus it complicates the format.

But I know you all want to eat your cake and have it, too. I wish you all would have been more vocal the last two years I've been discussing the idea of XOR patching.

About the only thing I can say is to come up with another unique file extension, and we can keep that as the unidirectional mode. Unfortunately, we've already chosen UPS for bi-directional, so we can't use BPS+UPS, the current extension stays as is.

With a different extension, we can just make minimal changes. Store Y instead of X^Y, and store a length value after the pointer value. Accept CRC32s of 0 as "irrelevant."