DataMuseum.dk

Presents historical artifacts from the history of:

DKUUG/EUUG Conference tapes

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about DKUUG/EUUG Conference tapes

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - metrics - download
Index: P T

⟦7d67ec497⟧ TextFile

    Length: 2395 (0x95b)
    Types: TextFile
    Names: »PORTING«

Derivation

└─⟦b20c6495f⟧ Bits:30007238 EUUGD18: Wien-båndet, efterår 1987
    └─⟦this⟧ »EUUGD18/General/Crystal/PORTING« 

TextFile

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.