Why not include the patch description as part of each patch, instead of outside in comments? It would make parsing the description easier.
Also, have you thought about more defined versioning information (with regards to firmware version etc), rather than specifying the version in a comment somewhere?
Why not include the patch description as part of each patch, instead of outside in comments? It would make parsing the description easier.
Also, have you thought about more defined versioning information (with regards to firmware version etc), rather than specifying the version in a comment somewhere?
Cheers,
Sherman
That's actually a great idea about the description. I'll implement it this weekend.
As for the versioning, I was considering it, but decided against it. Firstly, the patches will most likely fail if applied to the wrong version. Secondly, it is very difficult to extract the version info from the binary, and thirdly, it is hard to represent things like ranges in an concise way.
Device: Kobo: KA1, ClaraHD, Forma, Libra2, Clara2E. PocketBook: TouchHD3
@geek1011,
As an occasional patch contributor I'll be happy to test your new system if I can do the testing on Windows. Is this possible at the moment?
Also a comment about Offset/Find/Replace…
I like the new option which places each of these on its own line rather than combining into a single line. It should be less confusing for new users who want to tweak the defaults. For me the single line of the current system is what makes it more awkward to ensure that the before/after strings are the same length.
I'm looking forward to being able to patch nickel zlib css in a more user-friendly way. I'm hoping it will make it possible for users to fine-tune them.
As an occasional patch contributor I'll be happy to test your new system if I can do the testing on Windows. Is this possible at the moment?
You need to replace the file tools/pa32lsb.exe with the "patch32lsb-windows-32bit.exe" or "patch32lsb-windows-64bit.exe" and rename it to "pa32lsb.exe".
@geek1011 it works ok, what the difference between the old and new file.
Edit: never mind I read the README.md, I'm waiting for the zlib support.
One thing that stands out in some of these examples is repeating the search string in the FindBaseAddress and ReplaceString instructions. Is it possible to write the above as
Device: Kobo: KA1, ClaraHD, Forma, Libra2, Clara2E. PocketBook: TouchHD3
Quote:
Originally Posted by oren64
You need to replace the file tools/pa32lsb.exe with the "patch32lsb-windows-32bit.exe" or "patch32lsb-windows-64bit.exe" and rename it to "pa32lsb.exe".
I should have been more specific in my question. I saw a couple of linux files (testalllibnickel.sh and testallnickel.sh) which I thought (perhaps wrongly) were needed to check old-result vs. new-result.
One thing that stands out in some of these examples is repeating the search string in the FindBaseAddress and ReplaceString instructions. Is it possible to write the above as
omitting the Find parameter and the default being the value passed to the FindBaseAddress?
Wouldn't that be less flexible? The FindBaseAddress is used to get you to the vicinity of where the patching needs to happen and needs to be unique. Depending on the specific patch, using the Offset value, the Find/Replace values may (sometimes) be much shorter strings and more specific
Device: Kobo: KA1, ClaraHD, Forma, Libra2, Clara2E. PocketBook: TouchHD3
@geek1011,
I can't help thinking that discussion about your proposed new patching method deserves a new thread of its own. Most of the people coming to this thread aren't interested in the inner workings of a future patching system, they just want help with the current system on the latest firmware.
I can't help thinking that discussion about your proposed new patching method deserves a new thread of its own. Most of the people coming to this thread aren't interested in the inner workings of a future patching system, they just want help with the current system on the latest firmware.
Wouldn't that be less flexible? The FindBaseAddress is used to get you to the vicinity of where the patching needs to happen and needs to be unique. Depending on the specific patch, using the Offset value, the Find/Replace values may (sometimes) be much shorter strings and more specific
Sorry, I didn't make my intent clear. I was thinking that it could be an optional field which would allow both the use case that you're describing and the one I was referring to. Basically "only provide it when it's different from the FindBaseAddress".