seiler@chrpserv.gsfc.nasa.gov (Ed Seiler) (10/12/89)
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? Ed Seiler Goddard Space Flight Center Mail code 635.0 Greenbelt, MD 20771 seiler@chrpserv.gsfc.nasa.gov or seiler@dftnic.gsfc.nasa.gov
earleh@eleazar.dartmouth.edu (Earle R. Horton) (10/12/89)
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
seiler@chrpserv.gsfc.nasa.gov (Ed Seiler) (10/12/89)
In article <16055@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: > >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. ... >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. Actually, it's not so much a desire to be rid of stdio that I'm concerned about, but rather why the documentation doesn't mention, right in the beginning of the section about the stdio routines where it belongs, something such as "The C stdio routines are provided for the development of MPW tools. Developers who wish to perform I/O to a console should use toolbox routines (or get a hold of WriteInWindow)". It seems that the documentation assumes the MPW C developer already knows such minutiae. Is WriteInWindow a product available from APDA? Can the redirection of stdin and stdout to a window be described briefly? Ed Seiler
earleh@eleazar.dartmouth.edu (Earle R. Horton) (10/12/89)
In article <502@dftsrv.gsfc.nasa.gov> seiler@chrpserv.gsfc.nasa.gov (Ed Seiler) writes: >Actually, it's not so much a desire to be rid of stdio that I'm concerned >about, but rather why the documentation doesn't mention, right in the >beginning of the section about the stdio routines where it belongs, something >such as "The C stdio routines are provided for the development of MPW tools. >Developers who wish to perform I/O to a console should use toolbox routines >(or get a hold of WriteInWindow)". It seems that the documentation assumes >the MPW C developer already knows such minutiae. You don't expect them to say that if you use this product to link a normal program (i.e. application) then printf() won't work, do you? Somebody might get the impression that MPW is rough around the edges or incomplete. :) Apple seems to have something against programs which use a command line interface, and perhaps they just cannot imagine why someone would want to write such a thing. >Is WriteInWindow a product available from APDA? Can the redirection of stdin >and stdout to a window be described briefly? WritelnWindow is part of MacApp, but it appears separately on "Phil and Dave's Excellent CD" along with a number of other goodies. It's in Pascal, and it comes with a warning that it is intended strictly for private debugging of non-shipping application code. No way are these folks going to help you to create a command-line interface, at least not on purpose. Looking at the Pascal code, I see that it would not be too hard to deduce from it how to write and install a C device handler to associate a window with stdin and stdout. Of course, if you did so the User Interface Thought Police would probably be all over you like stink on fecal matter. Earle R. Horton
jrk@sys.uea.ac.uk (Richard Kennaway) (10/12/89)
In article <16055@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: ... >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. This isnt quite true. To use sprintf/sscanf without pulling in all of stdio, all you need to do is define empty routines of your own called fwrite(), _flsbuf(), and _filbuf(), and make sure those get linked before stdio. I got this technique from the net some time ago (I forget who posted it), and have used it ever since with MPW 2. I forget just how much dead code you save, somewhere in the region of 5-20 K. Just make sure you dont leave the first character off "sscanf" :-). -- Richard Kennaway SYS, University of East Anglia, Norwich, U.K. Janet: kennaway@sys.uea.ac.uk uucp: ...mcvax!ukc!uea-sys!jrk
jrk@sys.uea.ac.uk (Richard Kennaway) (10/12/89)
(Apologies if you see this twice, teething troubles with nn...) In article <16055@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: ... >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. This isnt quite true. To use sprintf/sscanf without pulling in all of stdio, all you need to do is define empty routines of your own called fwrite(), _flsbuf(), and _filbuf(), and make sure those get linked before stdio. I got this technique from the net a long time ago (I forget who posted it), and have used it ever since with MPW 2 and 3. I find it saves about 10K of dead code. Just make sure you dont leave the first character off "sscanf" :-). -- Richard Kennaway SYS, University of East Anglia, Norwich, U.K. Janet: kennaway@sys.uea.ac.uk uucp: ...mcvax!ukc!uea-sys!jrk
jnh@ecemwl.ncsu.edu (Joseph N. Hall) (10/13/89)
In article <16055@dartvax.Dartmouth.EDU> earleh@eleazar.dartmouth.edu (Earle R. Horton) writes: >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. There is relatively little (except the inconvenience of splitting out a bunch of inline assembly) that could keep you from reworking the THINK C runtime libraries for use with MPW. Once you've sprung for MPW, you might as well go ahead and buy THINK C anyway, since it is generally possible to develop in THINK C (i.e., do most of your interim compiles), and do final compiles and the other MPW-related goodies (like archiving your sources periodically with Projector) with MPW. The cost is < $200 more, and that gets you a compiling thoroughbred built for speed (but not necessarily for flexibility). v v sssss|| joseph hall || 4116 Brewster Drive v v s s || jnh@ecemwl.ncsu.edu (Internet) || Raleigh, NC 27606 v sss || SP Software/CAD Tool Developer, Mac Hacker and Keyboardist -----------|| Disclaimer: NCSU may not share my views, but is welcome to.