martyp@pnet02.gryphon.com (Martin Peckham) (12/02/89)
I have downloaded all of my uploads and I have run a "diff" on them. I only found errors in part 5 of 5. Because of the difficulties that I have been having getting these files straight, I am only including the differences that I found between the uploaded part 5 of 5 and my original. The first line of a set is what I got by downloading my upload and the second line is what it should be. Approximate line number 305 depending on network overhead < A0gCAAw1k3UF+T92bk6/MvFaBwlLAIgSahEQELABIVhY3ATAfqp0XjigCAC --- > A0gCAAwFlmAv5TiEQ969LIlgz4vFaBwlLAIgSahEQELABIVhY3ATAfqp0XjigCAC Approximate line number 451 < UhZ8UUF9EVXfBpxxU)pgpk4ZAQgwIOCJpCbSFFkrOASk0RVI --- > XNtaATQEUL6CaAwgUhZ8UUF9EVXfBpxxU)pgpk4ZAQgwIOCJpCbSFFkrOASk0RVI If you have APW or ORCA/M with the APW C compiler, you can compile the files in part 2 of 4(should have been changed to part 2 of 5). Or you can link the object files in part 3 of 5. Either way, you will end up with the executable that is in part 4 of 5. I would suggest that the ORCA/C compiler not be used until the next release. With all the bugs and work-arounds in ORCA/C there is no way to compile this correctly with ORCA/C. NOTE: If you recompile the files, you will have different executable file sizes than I have because I have many optimized (read assembler) library rountines. There is one warning not included in the C source files. That is that the calls to memcpy() REQUIRE that memory be copied from low memory to high memory which is the usual way that memcpy() is written in C. If you have an optimized memcpy() it may not (probably won't) work. In assembler, it's easier and faster to count down to zero than to count up to a value. sorry about the inconvenience. marty AMERICA ONLINE: MartinP6 UUCP: {ames!elroy, <routing site>}!gryphon!pnet02!martyp INET: martyp@pnet02.gryphon.com