|
DataMuseum.dkPresents historical artifacts from the history of: DKUUG/EUUG Conference tapes |
This is an automatic "excavation" of a thematic subset of
See our Wiki for more about DKUUG/EUUG Conference tapes Excavated with: AutoArchaeologist - Free & Open Source Software. |
top - metrics - downloadIndex: P T
Length: 2395 (0x95b) Types: TextFile Names: »PORTING«
└─⟦b20c6495f⟧ Bits:30007238 EUUGD18: Wien-båndet, efterår 1987 └─⟦this⟧ »EUUGD18/General/Crystal/PORTING«
This version is "mostly" portable, except for 1) the usual index/strchr things 2) Some very funny (but easily eliminated) UNIX PC hacks. The hacks are all designed to make it hard to read core files or the binary with strings(1). After all, that would give away lots of the game. For hackers wanting to change this, here's some basic information: The stuff in the makefile relating to shlib.ifile does two things. First, it makes the resulting binary use the UNIX PC shared library, which makes it smaller and faster than it would otherwise be. Second, it supplies the addresses of the start and end of the initialized data region to the linker, and thus to cvinit.c. Cvinit.c calls several routines to fix up a few problems with my C compiler (I don't think you have to pay any attention to this) and to encode the ASCII strings in the messages, objects and locations. This encoding is done by encode() in cvspk.c. Finally, the entire initialized data region is written to a file -- this depends on the memory treatment of the linker. This encoded form is written back into the binary by the routine crycopy, since crystal is not allowed to write on itself. Anyway, the result is that the binary contains the encoded forms of all these strings. When strings are written out during play, this is done by putcode() in cvspk.c, which reverses the encoding. Thus, the sources have intelligible ASCII strings, but strings(1) cannot see them in the binaries or core files. ------------------------------------ If all this gives you a headache, you can get rid of shlib.ifile (and also crt0s.o) and crycopy. You will want to reorganize cvinit.c so that it is called regardless of the arguments to crystal, because of the other fixup work that it does. The result will be that the strings are encoded at the start of each run, so that core files are still unreadable, but the binary can be browsed. You will want to remove the invocation of crystal in the makefile. I'm sure there are better ways to do this encoding stuff, my only excuse is that this is my very first C program, and I never even knew there was BSD at the time, and had not a hint about the ways in which UNIX implementations differ. This was written for the AT&T 7300, with no help from (or access to) UNIX or C expertise other than the manuals I got with my machine. What the hey, it works fine on MY machine.