Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!ux1.cso.uiuc.edu!uxa.cso.uiuc.edu!jb10320
From: jb10320@uxa.cso.uiuc.edu (Desdinova)
Newsgroups: comp.sys.apple2
Subject: Re: Tech Questions about GS/OS (and some ramblings)
Message-ID: <1991Jan8.194241.6210@ux1.cso.uiuc.edu>
Date: 8 Jan 91 19:42:41 GMT
References: <353@generic.UUCP> <1991Jan8.072457.198@nntp-server.caltech.edu>
Sender: news@ux1.cso.uiuc.edu (News)
Organization: University of Illinois at Urbana
Lines: 31

In article <1991Jan8.072457.198@nntp-server.caltech.edu> toddpw@nntp-server.caltech.edu (Todd P. Whitesel) writes:
>
>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
[...]
>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've not had any problems using fopen/fread/fclose from an S16.  I used those
to implement the disk storage for a phone book for Telcom (Three lines of code!)
and it still works.  Of course, I don't know about the FFFF in the high
word business- my guess is it's either a bug or just a limitation.

>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.

  That's not a half bad idea-  there's a lot of library type stuff the GS
could use to make porting programs easier. The most useful would of course
be the curses library.  Any ideas on this?  Or how about an ANSI/VT100 console
driver?

>Todd Whitesel

--
Jawaid Bazyar               | Being is Mathematics 
Senior/Computer Engineering | Love is Chemistry
jb10320@uxa.cso.uiuc.edu    | Sex is Physics
   Apple II Forever!        | Babies are engineering