IK00053@MAINE.MAINE.EDU (The Artful Death Dodger) (06/12/91)
Okay, here's the sad sad story:
I attend a branch of the University of Maine, I won't mention which one
but it's the smallest of them all. We have two minicomputers here that
are our local systems, and we connect to the main campus mainframe for
telnetting and things like that. The problem is our local systems.
We've had a UNIX system here for a long time. It runs on an AT&T 3b2/400
minicomputer, and it doesn't do a hell of a lot, but it's better than no
UNIX system at all. The other system they just got recently is a small
ethernet-linked system called Novell. Novell runs an MS-DOS equivalent
operating system, and it's the most doggish thing I've seen in years.
Okay, here's the problem:
(1) Nobody here who uses the computers likes the Novell system.
(2) The only people who like the Novell system are the Admins.
(3) The Admins are overruling that mass populace and want to dump
the UNIX system in the trashcan and switch over completely to
the Novell system.
Now, I don't know about you all, but that's the worst thing that could
happen here for me. I couldn't stand watching a perfectly good UNIX
system go down the drain in favor of an MS-DOS based minicomputer.
The resolution:
What I propose to do is this: see if there are UNIX pascal and C
compilers that will install on the AT&T 3b2/400. This is what I am
looking for. I want to set up the UNIX system so that the computer
classes can be taught here on the UNIX (instead of using the Novell
quivalent, which is Turbo C and Turbo Pascal, even bigger dogs than
the system itself is) so that they'll trash the Novell system instead
of the UNIX.
This is a desparate situation!
If anyone out there has any knowledge of where to find a C or Pascal
compiler for an AT&T 3b2/400 minicomputer, and knows how to get it and
set it up for operation, I need that information, please! I'd be
grateful to anyone for any information I can get. Thanks in advance
and please send all responses to me via E-Mail, so I don't lose them
and they don't get trashed through the newsnet before I get to read
them. Thanks again for your help in advance.
-------------------------------------------------------------------------------
J. Russell Woodman BITNET: IK00053@MAINE
"Death is dead, long live Death!" INTERNET: IK00053@MAINE.MAINE.EDU
-------------------------------------------------------------------------------sievert@gypsy.ims.fhg.de (Karsten Sievert) (06/18/91)
IK00053@MAINE.MAINE.EDU (The Artful Death Dodger) writes: > [...]I couldn't stand watching a perfectly good UNIX >system go down the drain in favor of an MS-DOS based minicomputer. I agree. > [...] Turbo C and Turbo Pascal, even bigger dogs than >the system itself is) I disagree. Nothing like it on UNIX as far as I know. Try it! It's a pitty that it runns only under DOS. -Clarence
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (06/22/91)
In article <76@gypsy.ims.fhg.de>, sievert@gypsy.ims.fhg.de (Karsten Sievert) writes: > IK00053@MAINE.MAINE.EDU (The Artful Death Dodger) writes: >> [...] Turbo C and Turbo Pascal, even bigger dogs than the system >> itself is) > I disagree. Nothing like it on UNIX as far as I know. Yes, for which I am duly thankful. > Try it! It's a pitty that it runns only under DOS. I did (Turbo C, at least). The only advantages of it I can see over the Sun cc is the fine-grained control over warning generation and a certain degree of ANSIness. Comparing it to gcc, I see no advantages. A partial list of disadvantages I find in 2.0 (these are just the ones I can remember or find in a quick skim of the manuals): - Memory models - Not free - Source not available - "Integrated" environment's editor is almost unconfigurable - "text" vs "binary" stupidity in the I/O libraries - The reference manual says "is available on UNIX systems" about many routines which are not present in 4.3BSD. It's not just a confusion of "UNIX" with "System V", either, because they're careful to draw the distinction at times; eg, see the entries for assert and dup2. - For some routines, they say "is available on UNIX systems" when this is not true: there is a different routine, with the same name and usually with similar functionality, but it is *not* the same. (chmod is an example.) - Make is pretty stupid; in particular, it has no default rules, as far as I could tell. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu
hp@vmars.tuwien.ac.at (Peter Holzer) (06/24/91)
mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes: >I did (Turbo C, at least). The only advantages of it I can see over >the Sun cc is the fine-grained control over warning generation and a >certain degree of ANSIness. Comparing it to gcc, I see no advantages. When I have have to work on an ASCII-Terminal, I see many advantages. E.g. source code and compiler error messages are simultaneously visible. If I have an X-terminal, still one advantage remains. The debugger. Turbo-Debugger is the best debugger I have ever seen. Dbx isn't more powerful, and not nearly as comfortable. >A partial list of disadvantages I find in 2.0 (these are just the ones >I can remember or find in a quick skim of the manuals): >- Memory models That's not the fault of the compiler but of the hardware (of course the compiler could just use 32bit pointers everywhere, but sometimes you want to save space or execution time. If you don't care, just always use the large memory model, and don't care about the rest). >- Not free True, but not expensive, either. TC++ Pro costs $170 and comes with 30cm manuals. >- Source not available That's a pity. But most people don't know enough of compilers to fix bugs anyway. And the library source is available (Though at additional cost). >- "Integrated" environment's editor is almost unconfigurable Yes, I miss vi. But using the integrated environment is faster than using vi, make and a debugger. >- "text" vs "binary" stupidity in the I/O libraries This stupidity is mandated by ANSI for OS's (and almost-OS's like Mess-DOS) where lines are not separated by a single character. You may blame Microsoft (that's what everybody does) or ANSI (only if you have a better idea how you can handle all those different definitions of `line' in different OS's) but the compiler/library-writers didn't have a choice. >- The reference manual says "is available on UNIX systems" about many > routines which are not present in 4.3BSD. It's not just a confusion > of "UNIX" with "System V", either, because they're careful to draw > the distinction at times; eg, see the entries for assert and dup2. >- For some routines, they say "is available on UNIX systems" when this > is not true: there is a different routine, with the same name and > usually with similar functionality, but it is *not* the same. > (chmod is an example.) Yes. The `portability'-paragraph isn't what it should be. Even worse than not distinguishing between UNIX-versions or not telling the differences between UNIX-chmod and DOS-chmod is that they haven't even got the ANSI-functions right. I can't remember it off the top of my head, but I found at least one function which was marked `available on UNIX', when it really was mandated by ANSI, or vice versa. >- Make is pretty stupid; in particular, it has no default rules, as far > as I could tell. I don't know about the default rule (I never used it with UNIX), but Borland-Make has some features that make it better than UNIX-Make. It extracts information about included header files out of the object file (sort of built-in makedepend) and it has conditionals. So you could write: !ifdef __MSDOS__ CC = tcc LIBS = -lmyx.lib !else CC = gcc LIBS = -lX11 !endif which makes configuring easier than for standard Unix make. I think this feature is new in TC++ 1.0, it was not in TC 2.0 Unfortunately, Borland decided to use some obscure binary format for project files, so you can't convert them to/from makefiles by simple sed/awk/whatever-you-like scripts. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |
sef@kithrup.COM (Sean Eric Fagan) (06/25/91)
In article <1991Jun24.163819.3125@email.tuwien.ac.at> hp@vmars.tuwien.ac.at (Peter Holzer) writes: >When I have have to work on an ASCII-Terminal, I see many >advantages. E.g. source code and compiler error messages are >simultaneously visible. If I have an X-terminal, still one advantage >remains. The debugger. Turbo-Debugger is the best debugger I have ever >seen. Dbx isn't more powerful, and not nearly as comfortable. I would suggest you try emacs, gcc, and gdb. compile-mode in emacs will let you go to the line of the error; gdb-mode in emacs points out the line currently under inspection. More, emacs can be reprogrammed relatively easily to handle *your* particular preferences. Also, emacs can work with any C compiler (well, almost any... all that I know of). >Yes, I miss vi. But using the integrated environment is faster than using >vi, make and a debugger. Again, try emacs and gdb. I think you will be pleasantly surprised. >>- "text" vs "binary" stupidity in the I/O libraries This is mandated by non-unix os's which think that file's should not be streams of characters; also, other OS's (such as MS-DOS, although that's not the only one) do not have '\n' as the sole End-Of-Line sequence. It isn't generally a problem. -- Sean Eric Fagan | "What *does* that 33 do? I have no idea." sef@kithrup.COM | -- Chris Torek -----------------+ (torek@ee.lbl.gov) Any opinions expressed are my own, and generally unpopular with others.
hp@vmars.tuwien.ac.at (Peter Holzer) (06/26/91)
sef@kithrup.COM (Sean Eric Fagan) writes: >In article <1991Jun24.163819.3125@email.tuwien.ac.at> hp@vmars.tuwien.ac.at (Peter Holzer) writes: >>When I have have to work on an ASCII-Terminal, I see many >>advantages. E.g. source code and compiler error messages are >>simultaneously visible. If I have an X-terminal, still one advantage >>remains. The debugger. Turbo-Debugger is the best debugger I have ever >>seen. Dbx isn't more powerful, and not nearly as comfortable. >I would suggest you try emacs, gcc, and gdb. EMACS: This is mostly a religious question, but I hate programs that are much larger than (I think) they need to be. If I see a file named emacs.tar.Z which is 12MB large my fingers are already hunting for the 'r' and the 'm' :-). I have played around a little with emacs and I didn't like it very much. If I had to use it I would rebind all the keys to emulate vi, but I would still miss regular expressions (or does emacs use them and the help-file didn't mention them?). What I would really like is vi (yes I like dual-moded editors) with multiple buffers and files, command-line history, and a sane macro-language (Any one got a REXX-Interpreter? :-). GCC: I am using it all the time. GDB: If you know of a port of gdb to the DECstation, I would be glad to hear of it. I know that Michael Meissner put a "lot of ugly hacks" (his words, not mine) into gcc to make it produce Ultrix-dbx compatible debugging info, I don't know if he ever tried to port gdb. There wasn't a gdb version for DECstations last time I looked. -- | _ | Peter J. Holzer | Think of it | | |_|_) | Technical University Vienna | as evolution | | | | | Dept. for Real-Time Systems | in action! | | __/ | hp@vmars.tuwien.ac.at | Tony Rand |
greywolf@unisoft.UUCP (The Grey Wolf) (06/27/91)
/* <1991Jun24.163819.3125@email.tuwien.ac.at> by hp@vmars.tuwien.ac.at (Peter Holzer)
* mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:
*
* >I did (Turbo C, at least). The only advantages of it I can see over
* >the Sun cc is the fine-grained control over warning generation and a
* >certain degree of ANSIness. Comparing it to gcc, I see no advantages.
*
* When I have have to work on an ASCII-Terminal, I see many
* advantages. E.g. source code and compiler error messages are
* simultaneously visible.
Use Jove, or rewrite vi to split your screen! :-).
(Yes, it's a preference which many don't share because they're too used
to vi's paradigm, and this is a "religious" argument, but it is a solution
if one wishes to accept it. Too bad there were no backups when the
machine which held the windowing vi sources happened to lose the disk upon
which said sources resided...)
Truly, it is a pity that there isn't something of a similar environment
on a UNIX box, though I imagine something could be written...
* If I have an X-terminal, still one advantage
* remains. The debugger. Turbo-Debugger is the best debugger I have ever
* seen. Dbx isn't more powerful, and not nearly as comfortable.
Dbx and adb, while powerful to some degree, certainly lack something
when it comes to the user interface. I guess that the rationale was that
"users don't debug programs, programmers do". Also a pity.
What drives ME crazy is that you cannot indirect an arbitrary value in
dbx; also, there is no way to set a radix in which you wish to view values.
Figuring out a mode word (device + permissions) is kind of insane unless
you're very good at doing decimal <--> octal conversions. Addresses are
automagically mapped to hex, which is good, but everything else is either
mapped to a string, a byte or a (decimal) int (I don't use floats much).
Adb is just plain cryptic; it's the closest to write-only coding that
I've ever done.
How about Saber C? I understand that works pretty well.
*
* >- "Integrated" environment's editor is almost unconfigurable
Well, it's configurable, but there are certain keys you cannot map
(like ESCAPE! AARRRGGHH!).koerber.sin@sni.de (Mathias Koerber) (06/27/91)
In article <1991Jun26.080734.15059@email.tuwien.ac.at> hp@vmars.tuwien.ac.at (Peter Holzer) writes: |... What I would |really like is vi (yes I like dual-moded editors) with multiple buffers |and files, command-line history, and a sane macro-language (Any one got |a REXX-Interpreter? :-). check out vile, which was posted to alt.sources a few days ago. It's 80%vi with multi-file/window/buffer etc. If U can't find it swhere else, I' can mail it, but my link is rather expensive. Have fun
mouse@thunder.mcrcim.mcgill.edu (der Mouse) (06/28/91)
In article <1991Jun24.163819.3125@email.tuwien.ac.at>, hp@vmars.tuwien.ac.at (Peter Holzer) writes: > mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes: >> I did (Turbo C, at least). The only advantages of it I can see over >> the Sun cc is the fine-grained control over warning generation and a >> certain degree of ANSIness. Comparing it to gcc, I see no >> advantages. > When I have have to work on an ASCII-Terminal, I see many advantages. > E.g. source code and compiler error messages are simultaneously > visible. This is true anyway. If you have a decent editor (eg, (almost?) any emacs variant) you just split the screen into two windows; if not, use error(1) to stuff the errors into comments in the source.... > If I have an X-terminal, still one advantage remains. Now wait a minute, Turbo-C is a MS-DOS program. What's this about ASCII terminals and X terminals? Since when do DOS machines run terminal lines or X clients? > The debugger. Turbo-Debugger is the best debugger I have ever seen. Have you tried ups? It's been a while since I did anything with Turbo C, so I don't remember too many details, but as I recall the debugger was roughly comparable with ups, as a debugger. And given all the other problems with Turbo C, even if it were a substantially better debugger I would still hold the environment inferior. >> A partial list of disadvantages I find in 2.0 (these are just the >> ones I can remember or find in a quick skim of the manuals): >> - Memory models > That's not the fault of the compiler but of the hardware Mostly so, I suppose. But even if you have a '386 or '486, it doesn't know how to use them, or at least 2.0 showed no awareness of anything past the '286. > (of course the compiler could just use 32bit pointers everywhere, but > sometimes you want to save space or execution time. If you don't > care, just always use the large memory model, and don't care about > the rest). Not even. You cannot ignore memory models unless you are willing to stick with 64Kb. Not even the huge model works - the default pointer type is still far rather than huge. >> - Not free > True, but not expensive, either. Why spend $170 for the privilege of using a binary-only compiler on a brain-dead excuse for an operating system on a badly mangled architecture when you can spend $0 and use a source-available compiler on a real operating system on nearly any architecture you please (including that same mangled one)? >> - Source not available (This alone is enough to ensure I won't use it for anything serious. And let me add that even what source *is* available isn't redistributable.) > That's a pity. But most people don't know enough of compilers to fix > bugs anyway. That hardly excuses it. >> - "Integrated" environment's editor is almost unconfigurable > Yes, I miss vi. But using the integrated environment is faster than > using vi, make and a debugger. Perhaps for someone equally used to both. But in my case, the slowdowns necessitated by fighting against the stupidities hampering me at every turn more than outweigh the (very impressive, btw) compilation speed. >> - Make is pretty stupid; in particular, it has no default rules, as >> far as I could tell. > I don't know about the default rule (I never used it with UNIX), That's the thing that means you don't have to write foo.o: foo.c $(CC) -c foo.c for every .c file. (Or .obj instead of .o for DOS.) I don't think even writing an explicit wildcard rule .c.obj: ; $(CC) -c $*.c worked.... So, most of the problems I see with Turbo C are not actually with the C compiler at all but with the rest of the environment. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu