home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.graphics:8168 alt.graphics.pixutils:1821
- Newsgroups: comp.graphics,alt.graphics.pixutils
- Path: sparky!uunet!decwrl!netcomsv!mork!jef
- From: jef@netcom.com (Jef Poskanzer)
- Subject: Re: PBMPLUS
- Message-ID: <#+lmf=b.jef@netcom.com>
- Date: Mon, 27 Jul 92 01:27:05 GMT
- Organization: Paratheo-Anametamystikhood Of Eris Esoteric
- References: <5543@umriscc.isc.umr.edu>
- Reply-To: Jef Poskanzer <jef@netcom.com>
- Lines: 26
-
- johns@mcs213c.cs.umr.edu (John Stone):
- } If anyone out there is using OS/2 2.0, I've got a fair portion of
- }pbmplus ported now... I'm about halfway done... All that had to be done
- }to port each program is build a .lib file out of the libp?m*.c files,
- }and then to edit all of the file I/O stuff so that it uses binary
- }I/O instead of text (OS/2 and Dos both default to text mode on the
- }stdin and stdout)
- }The hardest part about the OS/2 port is that IBM C Set/2 won't let you
- }use setmode() on a stream (which is how a friend of mine did a port of it
- }to dos...) So I had to use fdopen(); to do it.
- }Using fdopen, means that I have to edit every call to a file I/O function
- }and make sure it calls my binary file handle, and not the regular stdout
- }handle etc.
-
- I've seen other people doing DOS ports do the same thing, and I still
- can't figure out why. How about just *replacing* stdout and stdin
- with binary-mode handles? Seems like doing that and then fixing
- any bugs it introduces would be a lot less editing, and more
- importantly would not, if done right, need #ifdefs all over the
- place.
- ---
- Jef
-
- Jef Poskanzer jef@netcom.com jef@well.sf.ca.us
- "If you don't use Saber to develop your next C program, you're a dork."
- -- Brian Reid
-