Path: utzoo!attcan!uunet!nih-csl!lhc!adm!husc6!purdue!smb From: smb@cs.purdue.EDU (Scott M. Ballew) Newsgroups: comp.unix.programmer Subject: Re: Why use U* over VMS Message-ID: <12234@medusa.cs.purdue.edu> Date: 30 Oct 90 13:50:36 GMT References: <1990Oct25.160937.28144@edm.uucp> <1809.272c3135@dcs.simpact.com> Sender: news@cs.purdue.EDU Reply-To: smb@tristram.cs.purdue.edu (Scott M Ballew) Organization: Department of Computer Science, Purdue University Lines: 61 In article <1809.272c3135@dcs.simpact.com> kquick@dcs.simpact.com (Kevin Quick, Simpact Assoc., Inc.) writes: >4. Overall, the C RTL is very similar between Unix and VMS, with the effort > for VMS C being to adhere to the C "standard" (chuckle, chuckle :-) and > make non-destructive language enhancements where needed. There are some > changes, but those are usually documented, and are found by the linker > under worst case. If my memory serves me correctly, the VAX C compiler is identical for VMS and Ultrix (DEC's Unix). It was originally written for the Ultrix world and then retro-fitted to the VMS world. Similarly, VAX Fortran was originally written for the VMS world and then retro-fitted to the Ultrix world. >5. VMS supports a very large number of third-party terminal devices, so > it is not probable that you are going to have problems here. Although > VMS C implements curses, I find the native VMS SMG screen management > utilities much more pleasing. While this is true, the most frustrating "feature" of VMS if ran into in my VMS days was trying to get the VAX editors (EDT, EVE) to actually talk to these third-party terminals. I did the whole bit of describing to VMS (via there termcap-like method) what our terminals sent and expected only to find that for reasons of speed and efficiency, EDT (and perhaps EVE, I don't remember) did NOT use the SMG routines so would still not talk to our terminals correctly. In contrast, I have not yet run into a Unix program that did not use either the termcap library or curses (which uses the termcap library). >4. The VMS synchronization is much more specific and explicit, and in > some cases much better than Unix synchronization, but that is partially > because VMS is specific to Digital machines, whereas Unix is forced > to be much more general. Actually, since Unix was originally designed for DEC machines, this is not a valid statement. The difference really lies in the philosophy underlying the systems' designs. See Bach's book on the design of Unix for a discussion. Having worked under both systems, I agree that each has its relative strengths and weaknesses. However, being a bit of a hacker at heart, I prefer a system where the operating system gets in my way as little as possible, allowing me to get my work done. Unix, because of its research origins, does just that (though at times, it STILL gets in my way). VMS, on the other hand, is a much friendlier environment for the user who is not a programmer. It has a (fairly) regular set of options to (rather) intuitive command names. If the user does not wish to do anything that requires programming, it is a comfortable, secure enviroment. Unix is, however, far more customizable and extensible, in my opinion, than VMS and so, I have found it a much more comfortable environment in which to work. By the way, no one has mentioned Unix's biggest strength: since most implementations can be obtained with complete sources on line, it is realitively easy to repair bugs in or add features to any part of the system, something that VMS makes nearly impossible. Scott Ballew Cypress Network Operations Center Purdue University Department of Computer Sciences