Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!jarthur!nntp-server.caltech.edu!toddpw From: toddpw@nntp-server.caltech.edu (Todd P. Whitesel) Newsgroups: comp.sys.apple2 Subject: Re: Tech Questions about GS/OS (and some ramblings) Message-ID: <1991Jan8.072457.198@nntp-server.caltech.edu> Date: 8 Jan 91 07:24:57 GMT References: <353@generic.UUCP> Organization: California Institute of Technology, Pasadena Lines: 32 ericmcg@pnet91.cts.com (Eric Mcgillicuddy) writes: (In response to this bit which I wrote) >>Note that this is not always sufficient. Parts of the Orca/C stdio library >>depend on the shell being present, and barf if you S16 them. >I think that this is not a problem. If you want to do I/O use the Toolbox. Are >you complaining that Orca/C does not use Toolcalls when you generate a SYS16 >file? ^^in lieu of shell calls Here's the situation. I compile an EXE that uses fopen/fread/fclose. It works but >64K reads return $FFFF in the high word (if I read $1fde8, the return value from fread() would be $fffffde8 instead). When I Filetype that load file to S16 (note: I didn't specify S16 compilation in Prizm, I used compile and link commands in the shell) and launch it from finder, fopen() returns an error ($100, whatever that means). When I replace fopen/fread/fclose with my own little subroutines that rely on gsos.h (GSOpen/GSRead/GSClose is what I call them) my executable shrinks by about 2K and everything works like a charm. I'm really tempted to start writing a real stdio library for Orca that uses GS/OS for everything (even stdin/stdout/stderr) but I have enough projects already to keep me busy. Todd Whitesel toddpw @ tybalt.caltech.edu P.S. Lord High Giffer can display pictures now. Decompression is still entirely in C (slow, but easier to debug and tune) but I expect to be screaming past GIF3200 by the end of the week. I still won't have any conversions other than pre-scale color, so if you know of some really hot color-crunchers let me know.