Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!purdue!bu-cs!dartvax!eleazar.dartmouth.edu!earleh
From: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Newsgroups: comp.sys.mac.programmer
Subject: Re: stdin and stdout in MPW C 3.0
Keywords: stdin, stdout, MPW 3.0
Message-ID: <16055@dartvax.Dartmouth.EDU>
Date: 11 Oct 89 21:49:42 GMT
References: <501@dftsrv.gsfc.nasa.gov>
Sender: news@dartvax.Dartmouth.EDU
Reply-To: earleh@eleazar.dartmouth.edu (Earle R. Horton)
Organization: Thayer School of Engineering
Lines: 61

In article <501@dftsrv.gsfc.nasa.gov> seiler@chrpserv.gsfc.nasa.gov
	(Ed Seiler) writes:
>
>  I have what should be a very simple question: Are stdin and stdout of
>any use in MPW C 3.0 unless you are developing a tool? From what I have been
>able to gather, I/O to the console is not supported. Hence, if you are not
>developing a tool, you have no need of stdio, right? If I am missing
>something, please fill me in. If not, shouldn't the documentation be a little
>more obvious about this?

It is possible to redirect stdin and stdout so that output goes to a
window you specify and input comes from the keyboard.  In fact, there
is a package of routines you can get from Apple called WritelnWindow
that sets the whole thing up for you.  WritelnWindow is intended for
debugging only, and you are not allowed to include it in applications
that you ship.  It is, however, not hard to see how WritelnWindow
works, and one could write one's own console emulator, with hooks to
be driven off of stdio, and not violate any Apple stipulations.

If you are not planning to use the "printf debugger" and if you
haven't written your own console emulator, then the only thing you get
from MPW stdio that you cannot get elsewhere is the capability for
formatted input and output.  You might think that you can use
sprintf/sscanf to convert things into strings internally, thus
bypassing stdio.  However, if you use sprintf or sscanf in your code,
the linker pulls in all of stdio.  If you want to save space in your
final application by not linking in stdio, then you cannot even use
the standard string formatting routines.  Tough.

The Script Manager contains a tokenizer that can be used for formatted
input and output of data to strings and such.  Unfortunately, I have
looked at the manual and concluded that actually using it would be
real ugly and not much fun at all.  Not nearly as nice as
scanf/printf.  International compatibility is real nice and all, but
having a computer that you can actually write programs for is good,
too.  [Apple employee comments solicited.]

Now that you mention it, you don't need the default runtime startup
supplied by MPW if you are not using the standard library routines.
In other words, if you are writing a Macintosh application that uses
the routines in Inside Macintosh and those routines in the standard C
library that are relatively stand-alone, then _RTInit, _RTExit, etc.
are mostly dead code.  Try adding a line near the top of your main()
routine that calls _DataInit(), then link your program with "-m main."
If you haven't used any stdio routines, then your program should link
and run as normal, but be smaller.

Surprisingly, the folks who write Macintosh System Software don't
appear to know this, or maybe it makes no difference to them.  The
Backgrounder application calls _RTInit, although doing so serves no
conceivable purpose except to get _DataInit called.  Since the
Backgrounder application is only 5k in size, the percentage taken up
by dead code is quite large.

The arrangement of the MPW runtime libraries is not optimum for the
creation of Macintosh applications.  I believe that that is what you
wanted to hear.  Unfortunately, there is not enough documentation
supplied so that you know enough to rearrange things, without spending
a lot of wasted time hacking around in object dumps.

Earle R. Horton