dfenyes@thesis1.hsch.utexas.edu (DAVID A. FENYES) (12/11/90)
Hello, OK--here's the 16-bit Compress. Apparently it underwent only one revision since is was last a MINIX compress, so it shouldn't be too hard to re-convert. A couple of notes: This compress uses Coherent's /dev/ram1 device driver, which, to the best of my knowledge, can be used as a ram disk, but doesn't need to be. (i.e., to use it as a ram disk, you need to make a file system on it, then mount it.) I imagine this is similar to the Minix /dev/ram. Second, a word about the canon() stuff. Because different machines have different byte/word ordering in memory, and because the byte ordering must be in a universal form on disk (for portability), Coherent encourages doing a can<type>(var) operation immediately after reading in a numerical (address/offset/size/checksum/etc) value from a file in its 'canonical' form, and doing the same before writing the value back. That way each system can have its own canxxx macros in a canon.h file for portability. e.g. read(0,buf,sizeof(xxx)); canxxx(buf); Coherent has a library routine like long can_long(x) long x; that returns swapped high & low words (for PC Coherent, 80x86). most of the canxxx macros are as follows: #define canint(x) /* for 16-bit entities */ (i.e. do nothing) for canlong, canaddr, cansize, and cantime (all the long ones.) are as follows: #define canxxx(x) ((x)=can_long(x)) I imagine Minix may use something like off_t instead of addr_t, so do a canoff_t. You get the idea. OK, the next postinh (part 2 of 2) is the sharred, Z'd (-b12), uuencoded compress stuff. Good luck, & post the best success to the net for all PC Minixers! (I'm not a Minixer, or I'd do it.) David. - - - - - - - - - - - - - - - - - - - - David Fenyes dfenyes@thesis1.hsch.utexas.edu University of Texas Medical School Houston, Texas =============================================================================