bh11+@andrew.cmu.edu (Braddock John Hathaway) (10/11/89)
From: Braddock John Hathaway <bh11+@andrew.cmu.edu>
I'm doing a semester long project for Carnegie Mellon's Information
Systems department requiring:
1) my code be written in C
2) the use of graphics
3) that the final version be
a) UNIX-based
b) portable to ALL UNIX SYSTEMS
What my question boils down to is:
"Is there any such thing as a UNIX graphics package that works for all
systems?"
The first thing I asked my professor when I received the assignment was
if I could assume X-windows on all of the systems. She told me to
explore other options.
Does anyone have any ideas?
Thank you,
Brad
Volume-Number: Volume 17, Number 30gwyn@BRL.MIL (10/14/89)
From: gwyn@BRL.MIL In article <400@longway.TIC.COM> Braddock John Hathaway <bh11+@andrew.cmu.edu> writes: >I'm doing a semester long project for Carnegie Mellon's Information >Systems department requiring: >1) my code be written in C >2) the use of graphics >3) that the final version be > a) UNIX-based > b) portable to ALL UNIX SYSTEMS Wow, taken literally this would be EXTREMELY TOUGH. >What my question boils down to is: >"Is there any such thing as a UNIX graphics package that works for all >systems?" No, unfortunately. The nearest thing is the old UNIX PLOT(4 or 5) format using its associate PLOT(3X) library; however, some UNIX systems no longer provide any useable version of this. If you're allowed to provide your own graphics library, you could use one similar in nature to UNIX PLOT or even X, but there would still be a need for device-dependent interfaces that would vary from system to system. At one time, BRL distributed a "TIG-plot" graphics library that was similar to UNIX PLOT. We currently have a "BRL-CAD" package that includes frame- buffer and vector-oriented more-or-less device independent facilities. Contact Keith@BRL.MIL for availability information. >The first thing I asked my professor when I received the assignment was >if I could assume X-windows on all of the systems. She told me to >explore other options. Sounds like you need further clarification from the professor. Volume-Number: Volume 17, Number 31
kre@cs.mu.oz.au (Robert Elz) (10/15/89)
From: kre@cs.mu.oz.au (Robert Elz) In article <401@longway.TIC.COM>, gwyn@BRL.MIL quotes someone: > >1) my code be written in C > >2) the use of graphics > >3) that the final version be > > a) UNIX-based > > b) portable to ALL UNIX SYSTEMS and then says .. > Wow, taken literally this would be EXTREMELY TOUGH. No, taken literally, this would be very easy. Written in C is no problem. Unix based is no problem, portable to all unix systems is easy if the result is simple enough. Graphics seems to be the complication, but remember, that "literally" characters are graphics, so why not try submitting ... main() { printf("Hello world\n"); } which I believe literally meets all the (stated) requirements. kre Volume-Number: Volume 17, Number 32
std-unix@longway.TIC.COM (Moderator, John S. Quarterman) (10/18/89)
From: uunet!dg-rtp.dg.com!dg-rtp!meissner (Michael Meissner) In article <402@longway.TIC.COM> kre@cs.mu.oz.au (Robert Elz) writes: | In article <401@longway.TIC.COM>, gwyn@BRL.MIL quotes someone: | > >1) my code be written in C | > >2) the use of graphics | > >3) that the final version be | > > a) UNIX-based | > > b) portable to ALL UNIX SYSTEMS | | and then says .. | | > Wow, taken literally this would be EXTREMELY TOUGH. | | No, taken literally, this would be very easy. Written in | C is no problem. Unix based is no problem, portable to | all unix systems is easy if the result is simple enough. | | Graphics seems to be the complication, but remember, that "literally" | characters are graphics, so why not try submitting ... | | main() | { | printf("Hello world\n"); | } | | which I believe literally meets all the (stated) requirements. You still lose. Under ANSI C the above program is not valid, since printf is a varargs function that has no prototype in scope. While we are at it, main should return a valid exit status. Ok, the revised program is: #include <stdio.h> main() { printf("Hello world\n"); return 0; } -- Michael Meissner, Data General. If compiles where much Uucp: ...!mcnc!rti!xyzzy!meissner faster, when would we Internet: meissner@dg-rtp.DG.COM have time for netnews? Volume-Number: Volume 17, Number 33
gwyn@BRL.MIL (10/19/89)
In article <403@longway.TIC.COM> uunet!dg-rtp.dg.com!dg-rtp!meissner (Michael Meissner) writes: >| In article <401@longway.TIC.COM>, gwyn@BRL.MIL quotes someone: >| > >3) that the final version be >| > > b) portable to ALL UNIX SYSTEMS >| and then says .. >| > Wow, taken literally this would be EXTREMELY TOUGH. >| [yet another contestant's entry here] >You still lose. Under ANSI C the above program is not valid, since >printf is a varargs function that has no prototype in scope. While we >are at it, main should return a valid exit status. Ok, the revised >program is: > #include <stdio.h> > main() > { > printf("Hello world\n"); > return 0; > } UNIX systems are not general ANSI C conforming at present. Some of them may not even support main() with no parameters.. I know that some of them ignore the value retuned by main() and pretend it returned "success" status (0), but that doesn't break the above program. Certainly, back in prehistory, some UNIX systems did not have <stdio.h>. One would hope there are none like that still in operation, but I wouldn't bet on it. What Mike says is correct in the context of Standard C. If there is this much variation possible simply in the UNIX portability of the "Hello, world" program, imagine how much more difficult it would be for a GRAPHICS program (as in the original specification). By the way, we all understand the "graphics" requirement to not be satisfied by a text-oriented program. Volume-Number: Volume 17, Number 34
kre@cs.mu.oz.au (Robert Elz) (10/19/89)
From: uunet!munnari!cs.mu.oz.au!kre (Robert Elz) > From: uunet!dg-rtp.dg.com!dg-rtp!meissner (Michael Meissner) > | In article <401@longway.TIC.COM>, gwyn@BRL.MIL quotes someone: > | > >1) my code be written in C > | > > b) portable to ALL UNIX SYSTEMS > You still lose. Under ANSI C the above program is not valid, since > printf is a varargs function that has no prototype in scope. Nowhere does it mention ANSI C. What's more, its clearly impossible to meet the requirements if ANSI C is required, since not ALL Unix systems have ANSI C compilers... > While we are at it, main should return a valid exit status. No quibbles there, though its not needed for the program to run. > #include <stdio.h> You just blew it away, it was no accident that I didn't include stdio.h .. 6th edition unix (v6) and previous had no stdio.h (until the 6th edition stdio upgrade). Your program no longer runs (even compiles) on ALL versions of unix. And OK, I admit it, neither does mine, since I don't think there ever was a C compiler for 1st edition (PDP-7) unix. If you want to get this technical (and I see no reason not to, given the absurd requirements laid out by the professor who set this assignment) there is truly no possible solution. kre Volume-Number: Volume 17, Number 35
mark@cbnews.ATT.COM (Mark Horton) (10/21/89)
From: mark@cbnews.ATT.COM (Mark Horton) In article <404@longway.TIC.COM> gwyn@brl.arpa (Doug Gwyn) writes: >If there is this much variation possible simply in the UNIX >portability of the "Hello, world" program, imagine how much >more difficult it would be for a GRAPHICS program (as in the >original specification). By the way, we all understand the >"graphics" requirement to not be satisfied by a text-oriented >program. I think it should be possible, but you have to stretch the notion of "graphics" a bit. Back in the dark ages when we all used character oriented output devices, there were programs that plotted graphs like this: for x from start to stop y = f(x) nblank = y * 80 /* assumes function range 0..1 */ for i from 1 to y putchar(' ') putchar('*') putchar('\n'); This isn't really in C, but you get the idea. Assume a 66x80 resolution output device and draw with stars and blanks. Do all I/O with getchar and putchar and I think it works everywhere (unless there's some gotcha with ANSI C) with no #include files. If you want to get really fancy, use graphcap (see the source to vfontinfo in 4.2BSD for the tables and an example of using them) and you can get better resolution: 164x160 on that same printed page. This does assume lower case, which many early UNIX systems didn't have, but that just makes the output ugly if you have only upper case, it will still run. Mark Volume-Number: Volume 17, Number 45