Howto apply a patch/diff file

[DaleStan]

Well then, install upx, or just make grfcodec.

The error I suspect you remember is that it did strange things with your real-sprites? That was an endian-neutral bug, and was fixed even longer ago.

[Benbo]

It's a shame. I'd really like to see a way to make GRFs on my Mac. I know a bit of Pixel Art, so I'm just learning by Purno Tutorials.

In the meantime, I'll download Wine and run GRF Codec off that.

[Bjarni]

It's a shame. I'd really like to see a way to make GRFs on my Mac. I know a bit of Pixel Art, so I'm just learning by Purno Tutorials.

In the meantime, I'll download Wine and run GRF Codec off that.

There is no need for that. Dalestan is right. The grfcodec itself works on mac now (nice of you guys to tell me that ). I'm messing with an error where it fails to compile with some sort of date support though but it could be a setup issue at my computer. Haven't really looked much into it yet.

[Benbo]

I'll have a go but if you get errors, a doubt I'll get past the download

Edit: Ha-ha I'm not even going to get that far. There's no point in me downloading the files because I don't know how to compile! If anyone comes up with a working file it would be much appreciated.

[DaleStan]

I'm messing with an error where it fails to compile with some sort of date support though but it could be a setup issue at my computer. Haven't really looked much into it yet.

GRFCodec and NFORenum use boost::date_time to support the \w<date> and \d<date> extensions. If the makefiles can't find boost, they'll disable those extensions.

The search paths are
/usr/local/include/boost-$(BOOST_VERSION)/boost
/usr/include/boost-$(BOOST_VERSION)/boost

If boost isn't there, set BOOST_INCLUDE to the location of your boost directory.

BOOST_VERSION is, by default, 1_33_1, since that's the latest Cygwin package. Apparently, boost 1.34.1 is latest; if you have that, set BOOST_VERSION to 1_34_1. I should try to autodetect the boost version, but I haven't found any good way to do that.

[cirdan]

I should try to autodetect the boost version, but I haven't found any good way to do that.

If you have the standard find(1), sort(1) and tail(1) system tools installed, the following piece of code in your Makefile should give you a good guess:

Code: Select all

BOOST_INCLUDE=$(shell \
find /usr/include /usr/local/include -maxdepth 1 -name 'boost-*' | \
sort -t - -k 2 | tail -n 1 )

with the difference that BOOST_INCLUDE will be null if no boost include directory exists, instead of CANNOT_FIND_BOOST_INCLUDE_DIRECTORY. This is how I do it.

[JamieLei]

Heya - I used to use Tortoise SVN and cygwin, which worked fine. I can't be bothered to install them again byt sadly I can't get BuildOTTD to work. Do I need to be using any other program before just loading the diff/patch file into BuildOTTD? It downloads the version but doesn't seem to do anything else. I'm using Vista.

[kaan]

BuildOTTD is having a fair share of problems on vista. Unfortunately most of these problems originate in MinGW and its been years since they made a new stable release.

[JamieLei]

I guess it's back to cygwin and Tortoise then - thanks anyway

[CobraA1]

[STRIP/UPX] grfmrgc.bin
make: upx: Command not found

Well then, install upx, or just make grfcodec.

UPX? Ugh. A few years back executable packers may have been worth it, but not anymore.

a) We've got huge hard drives and lots of memory these days, and we use a lot of media. The largest folders on my system are my music and my movies, not my Program Files. The gains from packing executables are minimal compared to the amount of hard drive space I waste with media storage. I can save more space deleting old podcasts, movies, and music than packing all of my exes with UPX.

b) Executable packers tend to conflict with DEP, which is starting to get turned on more often than not (I think Vista may even have it on by default). By definition, executable packers change executable code. By definition, DEP prevents changing executable code in memory. Programmers are increasingly being advised not to mess around with memory marked as executable code. People running with DEP turned on are very likely to have headaches with packed code.

c) Since they do change the executable, they are often used to change the signature of viruses to hide from virus scanners. Therefore many virus scanners are looking for the presence of executable packers as an indication of a possible virus. This has lead to a lot of false positives in virus scanners with packed software.

Minimal gains, lots of headaches. IMHO executable packers simply aren't worth it anymore.

[DaleStan]

I'll stop upxing the copy of grfmerge embedded in grfdiff when you convince Patchman to change the makefile appropriately. Or produce something that vaguely resembles evidence, instead just saying "I don't like it".

Since they do change the executable, they are often used to change the signature of viruses to hide from virus scanners. Therefore many virus scanners are looking for the presence of executable packers as an indication of a possible virus.

Exactly what definition of "many" are you using here? virusscan.jotti.org tells me that, even with the maximum packing I can produce for TTDPatch[0], out of twenty scanners, a grand total of zero of them consider it something to be worried about. Including quite a few that are notorious for false positives.

And anyone for whom UPX and/or DEP causes problems shouldn't be running grfcodec at all, since they won't be able to test their files properly (ie "in TTDPatch"). The procedure for running TTDPatch is something like:
1) UPX unpack the loader.
2) fopen the Patch executable to get overlaid data.
3) Modify another executable.
4) Start said executable.
5) Feed said modified executable several hundred KB of code and data.
6) Run a substantial portion (one third, maybe?) of the just-supplied code to connect the old code to the new code and data, and to properly initialize/relocate 3700+ addresses, both absolute and relative.

Which of those steps is DEP not going to have problems with? Or are you confusing "modifying executable code" with "moving EIP outside the executable range defined in the PE header"? Not that TTDPatch does any less of the later.

[0] Which is, I think, somewhere under a thousand bytes of unpacked executable code in a 524KB binary: ~200 bytes each for two UPX unpackers (one exe, one dll) and ~450 for the TTD code loader. Everything else is either packed (upx or gzip) or not at all executable.

[rabbit67890]

i hate buildottd because its not works on vista and i have vista

[athanasios]

You should hate Vista instead.

Please do not speak this way about other members hard work. Blame yourself for using a 'garbage', incompatible OS.

[MT3269]

There was a post in this thread that explained what to do with a diff file, but what do you do to get the patch working in the game?

[Bilbo]

You should hate Vista instead.

Please do not speak this way about other members hard work. Blame yourself for using a 'garbage', incompatible OS. :evil:

Vista? Forget current betaversion of Vista, wait for final version (Microsoft calls it Service Pack 2)

[athanasios]

Wise thoughts!

[DaleStan]

Vista? Forget current beta version of Vista, wait for final version (Microsoft calls it Service Pack 2)

Not so. Service Pack 1. "Never install an even-numbered service pack. Including zero." Apparently, this rule first appeared in the days of NT 3.51, with, to date, the only exception being XPSP2.

[Bilbo]

Vista? Forget current beta version of Vista, wait for final version (Microsoft calls it Service Pack 2)

Not so. Service Pack 1. "Never install an even-numbered service pack. Including zero." Apparently, this rule first appeared in the days of NT 3.51, with, to date, the only exception being XPSP2.

Ok, then wait for SP3 ....

[Thalass]

Hey, uh, stupid noob question here. But when you apply a .diff, does it completely override all the previous changes to the game? That is, if I was to apply two .diffs to my game, will the second one wipe the first, or will they both work?

[Bilbo]

If you apply second diff to the source after applying first one, the changes from both would simply merge, so if each diff adds some feature, you'll have both of them. But in case when the diffs change the same piece of code, a conflict would arise and you have to somewhat resolve it manually (patch usually produces a "rejects" file for each file where some part of the diff failed, where you see which parts failed and you now have to apply them manually somehow and join the changes from both diffs)

Also, there can be case when the diffs do not create any conflicts when applying, but for some other reasons they won't work together (like one diff changing some global variables and other diff assuming these variables are not changed)