yfcw14@castle.ed.ac.uk (K P Donnelly) (01/23/91)
We are currently thinking about buying a Unix fileserver which will also be required to run our program libraries from terminal sessions. Obvious candidates are something like a DEC system 5100 or a similar Sun machine. Among many other factors affecting the decision is the relative merit of the SunOS and Ultrix versions of Unix. Can anyone tell me anything about this? I am not familiar with either of them. e.g. I have heard that SunOS has "shareable libraries". I am not sure what these are, but they sound very like the dynamic linking of object files at load time which Edinburgh University's EMAS operating system (now disappearing) has had for over ten years, and the lack of which I find intensely frustrating as I try to move our program libraries to Unix. Makefiles are a very poor substitute. Can anyone tell me whether SunOS shareable libraries are really that good, or whether Ultrix is likely to aquire anything similar. Another thing which I find frustrating as we try to move to Unix is the way that many utilities strip the eighth bit at every opportunity. Does Ultrix have better 8-bit character set support, perhaps carried over from the DEC multinational character set on VMS? Kevin Donnelly
mjr@hussar.dco.dec.com (Marcus J. Ranum) (01/24/91)
yfcw14@castle.ed.ac.uk (K P Donnelly) writes: #define NONPARTISAN_MODE >I have heard that SunOS has "shareable libraries". I am not sure >what these are, but they sound very like the dynamic linking of object >files at load time which Edinburgh University's EMAS operating system >(now disappearing) has had for over ten years, and the lack of which I >find intensely frustrating as I try to move our program libraries to >Unix. Makefiles are a very poor substitute. Can anyone tell me whether >SunOS shareable libraries are really that good, or whether Ultrix is >likely to aquire anything similar. Ultrix is not going to have shareable libraries in the near future, but OSF/1 will eventually. I'm not sure of time frames. Right now, though, SunOs has 'em and Ultrix doesn't. What does that mean? It means that the size of your executable under SunOs is smaller than under Ultrix, but otherwise it doesn't make a whole huge difference, depending on the way you run your applications. If you are running the same application a great deal, Ultrix' not having shared libraries doesn't make a difference, because there's a good chance that application will already be at least partially in memory [eg: the shell, or mail, or something like that]. SunOs' libraries are useful for keeping disk space usage down for binaries, and you can get some situations where parts of your shared library are already in memory when an application starts, and don't need to be reloaded, so shared libraries can be a win. SunOs' virtual memory subsystem is different from Ultrix', too - the buffer cache and virtual memory are sharing a common pool, which means that SunOs machines tend to be a little better performers as single-user workstations, and can get ground down a little faster in a timesharing envionment, depending very much on the applications you are running. [IE: on a Sun, when your buddy's on your machine running something memory intensive he is effectively stealing *your* I/O bandwidth, and vice versa]. As far as Makefiles go - SunOs' shared libraries *act* just like compiling and linking a normal executable - you still have to link it just about the same way as you would under any other UNIX. I can't recall if you need to relink applications or not if the shared library is updated. There are some slight constraints required in your code if you want to write position-independent code for your own shared libraries, I think [unless that has changed since SunOs4.0]. >Another thing which I find frustrating as we try to move to Unix is the >way that many utilities strip the eighth bit at every opportunity. Does >Ultrix have better 8-bit character set support, perhaps carried over >from the DEC multinational character set on VMS? Ultrix is well-behaved about 8-bit data, and has a lot of nice internationalization tools for supporting various character sets. I never played with that part on a Sun. mjr.
vixie@wrl.dec.com (Paul Vixie) (01/24/91)
Sharable libraries are a huge win, period. Ultrix does not have them yet and I consider this an embarrassment. OSF/1 has them, so at a time no later than when a version of Ultrix is based on OSF/1, Ultrix will have shared libraries. (Not speaking as a Digital employee here.) If you don't like Makefiles, you have a different sort of problem. With shared libraries, your Makefiles become even more important since there are many fiddlin' details about creating and linking with shlibs that simply cannot be done by hand. Make is your friend -- trust me. If you can get over the initial "why did they make it so complicated?" doubts, you'll embrace Make and wonder how you ever did without it. Ultrix is very good about 8-bit support. They've also fixed things like backspace not working when echo is off; in general, a user gets what they expect from the Ultrix tty system. I don't know how well SunOS is doing in this area. Probably it depends on how many systems they sell overseas. Cheers, -- Paul Vixie DEC Western Research Lab <vixie@wrl.dec.com> Palo Alto, California ...!decwrl!vixie
krs0@gte.com (Rod Stephens) (01/24/91)
In article <8012@castle.ed.ac.uk> yfcw14@castle.ed.ac.uk (K P Donnelly) writes: : : > >e.g. I have heard that SunOS has "shareable libraries". I am not sure >what these are, but they sound very like the dynamic linking of object >files at load time which Edinburgh University's EMAS operating system >(now disappearing) has had for over ten years, and the lack of which I >find intensely frustrating as I try to move our program libraries to >Unix. Makefiles are a very poor substitute. Can anyone tell me whether >SunOS shareable libraries are really that good, or whether Ultrix is >likely to aquire anything similar. Shareable libraries mean 2 applications using the same library functions can share the same image of the library and do not need to include the library in their executables. This is REALLY nice for X windows where a "hello_world" program takes about a megabyte -- mostly X library code. "Dynamic linking" (late binding) is a seperate but related issue. DEC says Ultrix will be OSF/1-based around the end of 1991 and OSF/1 specifies shareable libraries and late binding. DEC will probably implement them in Ultrix. >Another thing which I find frustrating as we try to move to Unix is the >way that many utilities strip the eighth bit at every opportunity. Does >Ultrix have better 8-bit character set support, perhaps carried over >from the DEC multinational character set on VMS? > > Kevin Donnelly OSF/1 also apecifies "8-bit clean" functions which means functions are not allowed to strip off the 8th bit. +---------------------------------------------------------------+ | Rod Stephens | "Haven't I told you not to play | | GTE Laboratories, Inc | with my super-weapons? You might | | (617)466-4182 | devastate yourself!" | | krs0@gte.com | | +---------------------------------------------------------------+
fingerhu@ircam.fr (Michel Fingerhut) (01/24/91)
Paul Vixie writes: >Ultrix is very good about 8-bit support. Except for this csh bug in command completion where it does not know how to deal with it, and will display garbage on the screen. SPR posted by the local support group.
klee@wsl.dec.com (Ken Lee) (01/25/91)
While it's true that you will see large disk space savings by using shared libraries, it's my understanding that no 3rd party software vendors will use them because of the huge QA and support problems. Any software vendors care to comment? Thanks. -- Ken Lee DEC Western Software Laboratory, Palo Alto, Calif. Internet: klee@wsl.dec.com uucp: uunet!decwrl!klee
evans@decvax.DEC.COM (Marc Evans) (01/25/91)
In article <1991Jan24.102601@wsl.dec.com>, klee@wsl.dec.com (Ken Lee) writes: |> While it's true that you will see large disk space savings by using |> shared libraries, it's my understanding that no 3rd party software |> vendors will use them because of the huge QA and support problems. Any |> software vendors care to comment? Thanks. Well, I can make a couple of comments, though I am not really vendor. Apollo in its early years did not provide anything but shared libraries for use by vendor's applications. Even with the latest versions of the OS's from Apollo, the shared libraries are by far the more common libraries used. Why did they start providing static libraries? Because the standards they were targeting required them is what I've heard. DEC, on its VMS systems have been using shared libraries for quite some time. Most third parties make extensive use of these. The majority of the 386 unix vendors provide shared libraries. Most of the programs that I have purchased for my 386 box make use of these. My experience with SunOS and third parties is unfortunately limited, so I can't really say if vendors are using them, but as you have read above, other groups make use of shared libraries. I personally don't buy the argument that QA and support issues are good reasons to not use/provide shared libraries. - Marc -- =========================================================================== Marc Evans - WB1GRH - evans@decvax.DEC.COM | Synergytics (603)635-8876 Unix and X Software Contractor | 21 Hinds Ln, Pelham, NH 03076 ===========================================================================
mcnally@wsl.dec.com (Mike McNally) (01/25/91)
In article <518@decvax.decvax.dec.com.UUCP>, evans@decvax.DEC.COM (Marc Evans) writes: |> The majority of the 386 unix vendors provide shared libraries. Most of the |> programs that I have purchased for my 386 box make use of these. While it's true that System VR3 includes static shared libraries, my experience has been that only the system utilities actually use them. Of many products my former employer had, including WordPerfect, Q-Calc, 20/20, Informix, and Oracle, *none* used the shared libc.a. Things might be different with newer R4 systems. -- * "In the Spirit as my automatics, * Mike McNally * Lystra and Zelda were one third * Coolie * as large as the infinite Cosmos." * DEC Western Software Lab * --- D. S. Ashwander * mcnally@wsl.dec.com
ggm@brolga.cc.uq.oz.au (George Michaelson) (01/25/91)
Shared libs on suns are a bit of a two edged sword. If you install
code compiled against a newer libc.so you don't stand much chance
of getting it to work. As long as there are major upgrade steps
in motion, multiple releases in the field and different dates for
release of code across the planet, taking s/w off the network from
far away is a bummer. I might point out I am still using Ultrix 3.1D
so I find all this discussion a bit academic...
Secondly, dumb mistakes can smash the system completely. I think
Sun should be more careful about making a subset of the commands
statically linked so you dont loose ls ldconfig cat mv tar etc when
you barf over libc. Perhaps I misunderstand what should be done in
these cases, but based on smashing libc on a SunOS 4.1 3/60 earlier this
year, I know of no way to recover other than reloading MUNIX or the
miniroot onto swap and pulling code off the tapes. If you have 3rd
party drives this can get interesting (does the miniunix understand
*your* flavour of SCSI?)
Lastly, It seems very odd that DEC didn't do this much earlier.
Are shared libs really that hard to do?
-George
--
G.Michaelson
Internet: G.Michaelson@cc.uq.oz.au Phone: +61 7 365 4079
Postal: George Michaelson, the Prentice Centre,
The University of Queensland, St Lucia, QLD Australia 4072. alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.) (01/25/91)
In article <518@decvax.decvax.dec.com.UUCP>, evans@decvax.DEC.COM (Marc Evans) writes: > In article <1991Jan24.102601@wsl.dec.com>, klee@wsl.dec.com (Ken Lee) writes: > |> [ Ken makes the first comment about Q/A and support problems and shared libraries. ] > > [ Marc comments about Apollo, VMS and 386 vendors. ] > > My experience with SunOS and third parties is unfortunately limited, so I > can't really say if vendors are using them, but as you have read above, other > groups make use of shared libraries. I personally don't buy the argument that > QA and support issues are good reasons to not use/provide shared libraries. IF you trust the vendor not to change the function and interface to the parts of shared library, then the Q/A is easy. As long as it still runs then it probably runs correctly. The problems come if the vendor changes the function of something so that it isn't quite the same as before. Or changes the size of data structure. Presumably the vendor will have a method of applying version numbers to shared libraries that the dynamic load checks to make that things haven't changed (ident mismatch in VMSese). Even if the vendor uses these version numbers correctly, if they change the version numbers to often (every new release or maybe every other release) it requires the 3rd party company to re-link at each library change. And if you have to re-link you have to re-test. The 3rd party company also has to be careful about taking advantage of mis-features in a shared library function. If the vendor decides that feature was a bug and fixes it, the application may break. Still not an excuse for not having shared libraries, but these some of the problems that 3rd party people can run up against. > > - Marc > -- > =========================================================================== > Marc Evans - WB1GRH - evans@decvax.DEC.COM | Synergytics (603)635-8876 > Unix and X Software Contractor | 21 Hinds Ln, Pelham, NH 03076 > =========================================================================== -- Alan Rollow alan@nabeth.cxn.dec.com
kocks@jessica.stanford.edu (Peter Kocks) (01/26/91)
From what I hear Sun has good costumer support as far as software goes (is this true?). Dec has great hardware support but their ultrix support has much to desired. Many times they don't know the answers to questions regularly discussed in this group. I think this is mostly because DEC has for years concentrated on their VMS product and is not up to speed on ultrix. I have not used Suns much, but I had one horrible experience. When you buy a Sun out of the box it does *not* come with a fully ANSI C compiler. Specifically, I tried to port my programs to a Sun only to find that they do not support function prototyping. I use prototyping all the time to avoid making simple errors (I think everybody should) and cosequently I could not compile on the Sun. (By the way if you prototype you can change the order of the functions and so when you remove the prototype, you may also need to change the order of the functions). Now it is possible that I just did something wrong with this, but a Sun employee told me this was in fact the case. The way around it is to get gcc or some other compiler that actually works the way it should. Of course, most people have made programs compatible with suns, so you should not have a problem. Of course, you may have problems with you own programs. On the other hand, there is not nearly the same software base in ultrix that there is in sun, but most of what you need is there. I compared the manuals from Sun and Ultrix and found the Sun ones much better as regards system management. They made nfs and yp and it shows in their documentation. Peter Kocks kocks@jessica.Stanford.EDU
fisk@netcom.UUCP (Benjamin Fisk) (01/28/91)
In article <1991Jan24.102601@wsl.dec.com>, klee@wsl.dec.com (Ken Lee) writes: > While it's true that you will see large disk space savings by using > shared libraries, it's my understanding that no 3rd party software > vendors will use them because of the huge QA and support problems. Any > software vendors care to comment? Thanks. > Shared libraries not only save on disk space but they are also usefull in cotrolling software releases. One person can change a central library and effectively change a number of other users library. This can cut down on the amount of chaos that can occur when lots of developers are making changes to a common module. This kindof software develpoment is common in VM shops. I am supprised to find out that it is not common place in the UNIX world. Shared libraries can lead to problems if its administration is not done with great care. Shared libraries are a feature that developers enjoy. It is not necessarily a feature for production software soaks B. Fisk
davecb@yunexus.YorkU.CA (David Collier-Brown) (01/28/91)
alan@shodha.enet.dec.com ( Alan's Home for Wayward Notes File.) writes: | IF you trust the vendor not to change the function and interface | to the parts of shared library, then the Q/A is easy. As long | as it still runs then it probably runs correctly. The problems | come if the vendor changes the function of something so that it | isn't quite the same as before. Or changes the size of data | structure. Presumably the vendor will have a method of applying | version numbers to shared libraries that the dynamic load checks | to make that things haven't changed (ident mismatch in VMSese). This does not appear to be implemented **or implementable** with an unchanged sun/bsd interface... | Even if the vendor uses these version numbers correctly, if they | change the version numbers to often (every new release or maybe | every other release) it requires the 3rd party company to re-link | at each library change. And if you have to re-link you have to | re-test. Compatable roll-forward and -back is a known solved problem in computer science **for cases of a client program requesting a service via an invariant interface**. The tricky part is evolving an interface, which tends to cause one to pore over lint output. This may be solved in the domain of formal spcification of the interface, where a change in the specification can yield, by a somewhat exhaustive procedure, a partial specification of the change required to the code. I just don't know if anyone has done the work yet... --dave -- David Collier-Brown, | davecb@Nexus.YorkU.CA | lethe!dave 72 Abitibi Ave., | Willowdale, Ontario, | Even cannibals don't usually eat their CANADA. 416-223-8968 | friends.
mjr@hussar.dco.dec.com (Marcus J. Ranum) (01/28/91)
fisk@netcom.UUCP (Benjamin Fisk) writes: >Shared libraries not only save on disk space but they are also >usefull in cotrolling software releases. One person can change >a central library and effectively change a number of other >users library. I did exactly this and managed to totally break nearly everything on my system at once. It was a pretty neat trick. Fortunately I was able to repair it, after a little running about red-faced. I think in the early 4.0 releases (the first with shared libs) SunOs had a bug in fgets() that was rather serious - fixing it was simply a matter of repairing the system library - so it's a useful feature if used carefully. The earlier versions of 4.X used to have a really amusing feature in which the program that the systems administrator could use to manipulate shared libraries was compiled with dynamic linking. So, if you *DID* trash your shared-load cache, you couldn't fix it because the fixer was broken too. mjr. -- Q: How many Real Programmers does it take to screw in a lightbulb? A: It depends.
barnett@grymoire.crd.ge.com (Bruce Barnett) (02/15/91)
In article <1991Jan23.223402.28704@decuac.dec.com> mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: > What does that mean? It means that the size of your executable > under SunOs is smaller than under Ultrix, but otherwise it doesn't make > a whole huge difference, depending on the way you run your applications. The big difference is when you run several different window-based applications. Sun use to link several SunView applications into one executable, and by examining the name of the command, jump to the proper branch of the executable. Therefore 5 different programs were really one, and only required one copy in memory. I don't know if this could be done with common DECwindows applications. If you don't have enough memory to run all of the applications at once, shared libraries can make a big difference. -- Bruce G. Barnett barnett@crd.ge.com uunet!crdgw1!barnett
sfreed@ariel.unm.edu (Steven Freed CIRT) (02/15/91)
In article <BARNETT.91Feb14130525@grymoire.crd.ge.com>, barnett@grymoire.crd.ge.com (Bruce Barnett) writes:
-> applications. Sun use to link several SunView applications into one
-> executable, and by examining the name of the command, jump to the
-> proper branch of the executable. Therefore 5 different programs were
-> really one, and only required one copy in memory.
-> I don't know if this could be done with common DECwindows applications.
Look again...DECwindows applications already do this.
--
Thanks,
Steve. sfreed@ariel.unm.edufrank@croton.nyo.dec.com (Frank Wortner) (02/15/91)
In article <BARNETT.91Feb14130525@grymoire.crd.ge.com>, barnett@grymoire.crd.ge.com (Bruce Barnett) writes: > Sun use to link several SunView applications into one > executable, and by examining the name of the command, jump to the > proper branch of the executable. Therefore 5 different programs were > really one, and only required one copy in memory. > I don't know if this could be done with common DECwindows applications. Sure is possible, and it is already done. On my system (DECstation 3100, ULTRIX 4.0) dxwm, dxterm, dxue, and dxsession are one binary. Dxcalc, dxcalendar, dxpuzzle, and dxclock are another, while dxcardfiler, dxpaint, and dxvdoc are a third. Frank
grr@cbmvax.commodore.com (George Robbins) (02/16/91)
In article <1928@riscy.enet.dec.com> frank@croton.nyo.dec.com (Frank Wortner) writes: > In article <BARNETT.91Feb14130525@grymoire.crd.ge.com>, > barnett@grymoire.crd.ge.com (Bruce Barnett) writes: > > Sun use to link several SunView applications into one > > executable, and by examining the name of the command, jump to the > > proper branch of the executable. Therefore 5 different programs were > > really one, and only required one copy in memory. > > I don't know if this could be done with common DECwindows applications. > > Sure is possible, and it is already done. On my system (DECstation 3100, > ULTRIX 4.0) dxwm, dxterm, dxue, and dxsession are one binary. Dxcalc, > dxcalendar, dxpuzzle, and dxclock are another, while dxcardfiler, dxpaint, > and dxvdoc are a third. Wouldn't shared libraries be a better solution than mashing sources together to mimimize the overhead from multiple library copies??? -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
trost@reed.bitnet (Bill Trost,Box 607,ext 640,) (02/26/91)
In article <BARNETT.91Feb14130525@grymoire.crd.ge.com>,barnett@grymoire.crd.ge.com (Bruce Barnett) writes:
Sun use to link several SunView applications into one executable,
and by examining the name of the command, jump to the proper
branch of the executable. Therefore 5 different programs were
really one, and only required one copy in memory. I don't know if
this could be done with common DECwindows applications.
If I remember correctly, dxwm, dxuil, dxterm, dxsession, and one other
program were actually all the same program under some version of RISC
Ultrix (probably 2.2).