Sun-Spots-Request@RICE.EDU (Scott Alexander) (12/09/85)
SUN-SPOTS DIGEST Sunday, 8 Dec 1985 Volume 3 : Issue 14 Today's Topics: Hooking Macintoshes up to Suns Sun-100 display monitor distortion Apollo vs. Sun - a comparison Re: Sun-2's versus Sun-3's (2) Re: file system panics under 2.0 MIDI on SUNs Re: problems with serial ports on zs board Trivia return address for postings X.25 support for a Sun Need experiences with Mt. Xinu Vax NFS Yellow Pages source code, anyone? Multibus devices on Sun-3, Ethernet transcievers Lisp won't die! A lint problem SunWindows - help ------------------------------------------------------------------------ Date: Thu, 5 Dec 85 14:38:47 cst From: texsun!mehoge!tj@sun.UUCP (Cal Thixton Sun Microsystems Dallas Office) Telephone: (214) 823-2084 Office Phone: (214) 788-1951 Purpose-In-Life: To Spread the Gospel of UN*X to the heathens Subject: Hooking Macintoshes up to Suns Summary: To connect a Macintosh to a Sun over a serial line, use the Macintosh printer cable, NOT the Macintosh modem cable. Penalty for failure to heed this recommendation: The Sun will blow up. Details: The Macintosh serial connector (9-pin) supplies +12V and +5V for powering some unknown device. The Macintosh modem cable presents +12V,+5V on pins 20,6 of the 25-pin connector. The Sun will fail because of the +12 on pin 20. One likely symptom is that the display will stop working (the video problem occurs on the CPU board, not in the monitor). The Macintosh printer cable does not present these troublesome voltages on the 25-pin connector. Failure analysis: Pin 20 is RS-423 "DTR", which the Sun drives with a 26LS29 driver chip. The chip is supplied from +-5V. The chip can withstand overvoltages up to +15V, but ONLY if the overvoltage supply has several K ohms impedance, as would be the case with an RS-232 driver. Since the Macintosh supplies 12V at low-impedance, the driver chip has to withstand quite a bit of current between the external +12 and its own -5V supply. It eventually fails. The failed driver chip draws too much current from the -5V supply, which current limits and starves the ECL video drivers, which use the -5V. To repair the Sun: Replace the 26LS29 chip associated with the port that was connected to the Macintosh. ----------------------------- Date: Sat, 7 Dec 85 13:40:59 PST From: brian@sdcsvax.arpa (Brian Kantor) Subject: Sun-100 display monitor distortion Recently ALL of our sun-100s (the old style tabletop guys with the Phillips monitor) began slowly to exhibit a vertical deflection problem. The image displayed nonlinearity (compression) of scan lines at the bottom, foldover at the top, and a shift in the centering such that there was an unscanned stripe at the bottom and lines at the top were masked off by the edge of the tube. This happened at different rates for the different units we have - the oldest showed it first. This sort of behaviour is typical of component aging, so I went at it with the heat gun and freeze mist, and found that a capacitor on the monitor deflection board (C416, 220uf/25V) was bad. Replacing it repaired the problem - in all four of our units. Total time was about 1 hour to find it, and another to change it in all four of our suns. Total parts cost, about $2.00 (good old Radio Shack to the rescue). This kind of failure, in all our units, points to what is perhaps a bad run of capacitors from Phillips, who sold the monitors to Sun. (All the caps were made by Phillips themselves.) I post this note because other people might be experiencing the problem too, and rather than pay Sun's expensive repair prices might care to fix it themselves. Of course, these systems have been out warranty for a couple of years, so we've been doing our own maintenance for some time. Oh yes: you can order the replacement picture tube (CRT) for a Sun-100 from your friendly local Sylvania dealer (the part number is right on a sticker on the tube) for about $100 or so when it wears out - which they do after 3 or 4 years of constant operation. Symptoms of a bad CRT include dim image, poor focus (lack of sharpness in the individual scan lines), and a "silvery" sort of appearance to the image. We've changed all of ours by now. Make sure you have everything turned off and unplugged before you go poking around inside the monitor. Like most TV sets, monitors have several thousand volts on parts of the circuits for some time after they've been turned off, and touching that is likely to surprise you and make you do things you didn't want to do. Severe laundry problems. Brian Kantor UCSD Computer Graphics Lab c/o B-028, La Jolla, CA 92093 decvax\ brian@ucsd.arpa ihnp4 >--- sdcsvax --- brian ucbvax/ Kantor@Nosc ----------------------------- Date: Wed, 4 Dec 85 17:32:18 est From: mike%bambi@mouton.ARPA Subject: Apollo vs. Sun - a comparison I used Suns at Rice for several years, since the original Sun-1 and Unisoft V7 Unix. (In fact, I used to moderate this list.) I've been using Apollos for about 6 months here at Bellcore. These are a few comments about the merits and problems of the Apollo relative to the Sun. (Note that my Sun experience goes up to Sun 1.3, not 2.0, and my Apollo experience goes to SR9.) First, I have to confess that even on the Apollos, we use Unix exclusively. (For those who don't know, the Apollo runs a kernel operating system called Aegis. Libraries and server processes sit on top of that kernel. The "Domain/IX" product is a Unix emulator for both 4.2 and System V, simultaneously if you like, and provides most of the Unix system utilities, libraries, and system calls.) We use Unix mostly for reasons of portability and familiarity. Regardless of the merits of the native Apollo operating system, there's no way a program written with it will run on another machine, while with Unix, there's at least a fighting chance of writing portable code. APOLLO MINUSES: Because the native operating system is not Unix, there are an entirely new set of system management problems. You have to learn a whole new set of commands, remember where different configuration files are, and so forth, to be an effective system manager. This took me about a month or so. The problem was greatly complicated because most of the Aegis commands have almost exact Unix equivalents, but the names have been changed. For example, "list directory" is "ld", not "ls". "Move file" is "mvf", not "mv". It's an annoyance. Once Domain/IX is in place, these problems almost, but not quite, go away. All of 4.2 BSD is not supported. For example, the syscall interface to the kernel is missing, as is the SIGIO signal. The 4.2 print spooler (lpr, lpd) and the Unix graph(1) command are not present. I'm sure there are other things that I haven't missed yet. I am not too familiar with System V and we aren't using it, so I don't know what's missing there. Because the C compiler is a native Apollo compiler and not the Portable C compiler, there are subtle C language incompatibilities. Also, there is no assembler in the standard distribution, the compiler produces error messages in a different format, and the code quality is different between Apollo C and PCC. (It's not clear which is better. Under SR8, Apollo C was clearly inferior to PCC, but the situation has improved under SR9.) Apollo uses a TCP/IP derived from the old BBN sys.10 process-based TCP, which means there are a different set of management commands from the ones a 4.2 user would be used to (ie, different host tables, no netstat, route, arp). Most of the same functionality is present, it's just different. (The network libraries, sockets and so forth, are identical to 4.2 BSD's.) The object and executable formats are unlike Unix's, so programs that dump memory state don't work. In addition, the symbols etext, edata, and end are not provided. To make a sweeping comparison, the Apollo (with a 68010) is slower than the equivalent Sun. Using the Dhrystone benchmark, an Apollo DN320 with an FPA comes in at 793, while a Sun 2/120 without FPA runs at between 1100 and 1200. I don't know the relative clock speeds of the two machines, or the memory wait-state situation on the Apollo, or whether the 68020 versions will be different. In addition, an Apollo with 3 meg, diskless, "feels" slower than a diskless Sun (running ND, not NFS) with 2 meg. One should take into account that this includes the (presumably) extra overhead of running Domain/IX programs as opposed to native Aegis commands, which we don't use much. Some commands, particularly those that deal with directory reading or writing (like "find") are painfully slow. The standard Unix debuggers (adb, dbx) are not supported on the Apollo. The standard editor is nicer in some ways, worse in most, to the Sun dbxtool. It's certainly different - another training problem. The Apollo's performance is not "predictable" to me. There are sometimes long pauses for no good reason. This may well be an artifact of my unfamiliarity with the internals of Aegis, and strange interactions with the Apollo virtual memory and single level store. The Apollo documentation for Domain/IX is almost a straight printout of the Berkeley VAX documentation. Usually the differences and limitations of Domain/IX are not mentioned. As documentation for someone unfamiliar with Unix, it suffers from the typical Unix problem - you have to know a lot about Unix already before the documentation makes sense. Apollo should make an effort to try to expand on the conventional documentation. They have a short guide for new users, but nothing really for systems programming. (Sun has more or less the same problem, but since they've had Unix longer, their documentation is somewhat further along. It still suffers from emphasis on novice users, though. I don't know if the 2.0 documentation is better.) I like the Sun keyboard and optical mouse much better than the Apollo keyboard and mechanical ball mouse. The Sun window interface has somewhat better mechanics; Apollo window placement, cursor treatment, and general user interface have some problems. APOLLO PLUSES: Aegis is a much "cleaner" operating system than Unix in a number of ways. For example, the single level store allows very nice shared libraries to be implemented. Rather than including the object code for all of the C library with every program, as Unix does, Aegis does dynamic binding at run time. The executables are much smaller, and the system can be changed without rebinding anything. I have executables from 4 major releases of Aegis ago that still run with no changes. One could claim that from a design standpoint, Aegis is more consistent than Unix. It has more support for record-oriented files, which might be important for some applications, like databases. (You can't use this and remain Unix-compatible). Apollo has had transparent access to files for much longer than Sun has. Therefore, the performance seems to be much better (I have only limited experience with NFS, but long waits for file opens don't occur on the Apollo.) The performance of Sun ND seems superior to Apollo's distributed access, but remember that ND didn't allow read/write file sharing among machines. In order to run a single ring of machines, much less system administration per processor is needed on the Apollos. It is almost as simple as plugging a new machine into the ring, turning it on, and using it. The Sun requires a much more complicated procedure to configure a new machine. A diskless Sun has to be administered like a separate machine, while a diskless Apollo doesn't have any separate administration problems. The Apollo user interface has some nice features that the Sun lacks, like scrollable back histories, and command resubmission and editing. There is a simple (almost too simple) pervasive editor that is always available on the Apollo to do input editing. The Sun is much more oriented towards multiple ASCII terminal windows. The Apollo graphics package is considerably easier to use than the Sun package, although of course neither is the least bit portable to other kinds of machines or each other. The Apollo error messages, both from system routines and the compilers, are much better than the standard Unix messages found on the Sun. We experienced a large number of CRT failures at Rice, and other groups at Bellcore continue to lose Sun CRTs commonly. We have never had an Apollo CRT go out on us (in two years with four to seven nodes). In general hardware reliability seems higher on the Apollo. Apollo seems to have a much higher commitment to software compatibility and support across releases and different Apollo hardware than Sun does. With Sun, we went through a large number of completely incompatible software upgrades (Unisoft to Sun 0.1 to 0.3 to 1.0 to 2.0) across which most graphics software broke completely. Apollo guarantees compatibility from release N to release N+1, and in practice, across many more release levels. The documentation for Aegis has a rich set of examples in several languages for how to use most of the system interface. As a company, Apollo has exhibited somewhat different tactics than Sun. In the early days, Sun made a lot of promises and then failed to deliver. Apollo delivered a product with full function but bad performance, then concentrated on making it fast. Now that Sun can deliver, the difference is less pronounced - but I still remember a year of not being able to do much with Suns because the graphics and network software wasn't there yet. THE BOTTOM LINE We are getting our work done with the Apollo, working around the problems caused by lack of full Unix support. In general we're happy, but we're also scared that the CS research community is moving to Suns exclusively. It seems clear that Sun's commitment to full native Unix is stronger than Apollo's. We have already had some problems porting programs from Sun or VAX to Apollo. While this can be chalked up in large part to sleazy programming practices, that doesn't make the problem any more manageable. In brief: For applications involving exclusive use of Unix, and contact with the general research community, the clear choice for now seems to be Sun. If you don't have the constraints of Unix and Unix portability, you should give Apollo a look. Mike Caplinger mike@bellcore.arpa ihnp4!bambi!mike ps. I'm still looking for the perfect workstation. It's beginning to look as though I'll have to build it. :-) ----------------------------- Date: Thu, 5 Dec 85 10:50:13 est From: Sid Stuart <linus!sid@mitre-bedford.ARPA> Organization: The MITRE Corp., Bedford, MA Subject: Re: Sun-2's versus Sun-3's First I would like to apologize for spelling your name wrong Phil. I promise to write William LeFebvre 100 times on the blackboard before I go home today. Second I guess I should try to clear up my muddled arguments so that they make more sense. The original paragraph said: "The first problem is that Sun has not set up the capability to boot different kernels from /pub. The second is the 2K versus 8K page sizes for the swap space, thus the nd server would need to work for both and is not currently set up to do so. The third is that the systems are running different releases of the OS and will do so until the promised release..." Let me rewite my arguments including what I thought were obvious assumptions. I should admit that the assumptions become less obvious as I try to remember them. 1) The nd server distributed by Sun at the present time can only have one copy of the kernel for the diskless nodes to boot from and, in the initial distributions at least, Sun 2's will not run off of the same kernel as the Sun 3's. I doubt the same kernel will ever run on both Sun 2's and Sun 3's, their architectures are too different. This is a point of contention between Phil and I, he thinks that Sun will meld the kernels, I think they will introduce a mechanism to boot different kernels. The only reason I have for my belief is that I heard this from a salesperson. With that in mind you may want to go along with Phil on this one ;-). 2) The Sun 2 has a 2K page size. The Sun 3 has an 8K page size. The nd server would need to handle swapping for both and is not currently set up to do so. (at least one argument makes sense without explanation ;-) 3) The systems will be running different releases of the OS, with the the Sun 3's having a later release than the Sun 2's. The Sun 2 binary code should run on the Sun 3 (68010 code on a 68020), but may not be able to grok the system calls from a kernel that is a different release. The Sun 3 binary code will not be downward compatible with the Sun 2 processor. Thus the binaries in /bin, /usr/bin ... will not be compatible between the two systems. This last problem can be gotten around, but it would cause one to set up and keep multiple copies of all binaries on the same server. I would hesitate to do this if I were handling the distribution. sid@linus ----------------------------- Date: Thu, 5 Dec 85 00:09:19 EST From: Chris Torek <chris@mimsy.umd.edu> Subject: Re: Sun-2's versus Sun-3's I find it hard to believe that a change in packet size should affect ND. The protocol includes the I/O request size, and there is no particular limit to this size (aside from memory constraints, but that is 2048*64 or 128K of buffer space---64 is NNDMAP, the number of read buffers that can be mapped, and NDMEMSIZE is 2K times that value). (We have source for ND, though it is not Sun source, so their names may vary. This source is available, by the way, for both Suns and Vaxen, though you must have a Sun source license.) My guess is that Sun-2s will talk to Sun-3s and vice versa, all protocols, modulo the 3Com Ethernet board problems of course. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu ----------------------------- Date: Thu, 5 Dec 85 14:36:50 cst From: texsun!mehoge!tj@sun.UUCP (Cal Thixton Sun Microsystems Dallas Office) Telephone: (214) 823-2084 Office Phone: (214) 788-1951 Purpose-In-Life: To Spread the Gospel of UN*X to the heathens Subject: Re: file system panics under 2.0 the /etc/zz* sounds like an Alis file. if you seem to be getting random file system errors, first check the controll, but then go through /etc/nd.local and make sure that you do not have any over-lapping partitions. I had a problem a while back that randomly appeared; somehow a new client in the office was allocated swap space in the middle of one of the file systems. the server panic randomly when the client started swapping to this partition. Since the client was not heavily used, it took a while to find this. cal ----------------------------- Date: Thu, 5 Dec 85 11:38:31 PST From: sdcarl!dgl@ucbvax.berkeley.edu (D. Gareth Loy) Subject: MIDI on SUNs In response to a querey re. MIDI interfaces and software for SUNs, we at sdcarl have developed both a Multibus and VME-bus interface for the Roland MPU-401. The design is public domain and available to anyone requesting it. In addition, we have a device driver for SMI 2.0 UNIX, and a host of applications programs. Lucasfilm has augmented our software with some offerings of their own, different enough to be called a variant, though the core routines are the same. The Computer Music Laboratory at Northwestern University is also developing MIDI-based software and hardware. We are attempting to negotiate design strategies so as to come into commonality with them. =Gareth Loy, Computer Audio Research Laboratory, UCSD ----------------------------- Date: Thu, 5 Dec 85 14:38:22 cst From: texsun!mehoge!tj@sun.UUCP (Cal Thixton Sun Microsystems Dallas Office) Telephone: (214) 823-2084 Office Phone: (214) 788-1951 Purpose-In-Life: To Spread the Gospel of UN*X to the heathens Subject: Re: problems with serial ports on zs board If you leave a getty running on a serial line that does not have an actual terminal tied to it, the lines will float and the serial chip will think that it is getting Nulls. Getty is then fed these and will sit and happily eat up a lot of cpu cycles, die and init will fork another getty. Solutions: 1> turn off getty's on ports not being used. 2> always leave a terminal on the line. 3> make a connector with a resister to pull the carrier detect high and enable the system to notice CD's. Or Pull the data line up. 4> changes in auto-bauding sequence in /etc/gettytab to overcome the Nulls. i suggest the following 2 "fixes" for the getty cycling problem. Trouble is, neither definitely works, they just tend to alleviate the problem. As always, the real "answer" is keep terminals plugged in and turned on, or disable logins in /etc/ttys. Fix 1. ====== In gettytab, add a "pf#2" capability to the entry for your favourite terminal. From gettytab(5), this sets a 'delay between first prompt and following flush(seconds)'. This may quiet the static "ringing" the line. Fix 2. ====== Change the ttys entry to point to one of the sets of looping line types. For example, entry 'p' is also for a 9600 baud terminal, but it switches to entry'q' when you hit the break key. For some reason, this sometimes alleviates the problem. You may run into problems if your terminals don't have break keys, or if your users don't know what to do when their login prompts appear at the wrong baud rate. tty | port | 2 ---------------- \ on sun | \ | 3 ------x--------- > to customers equipment | | / | 7 ---------------- / | | | | | | | | | | 4.7k resistor, 1/4 watt | | | | | | 25 -----x | | | 2 -------------\/-------------- 2 | 3--------------/\-------------- 3 | 7 ----------------------------- 7 | 8 ----x---------\ | | \------------- 20 | \ | / | \ 4.7 Kohms | / | | |25-----x you get the idea.... cal ----------------------------- Date: Thu, 5 Dec 85 17:13:55 est From: Barry Shein <bzs%buit4%bostonu.csnet@CSNET-RELAY.ARPA> Subject: Trivia In the file <sundev/kbd.h> there is reference to keyboard slang called 'buckybits'. Later on in a comment an explanation of the term is given as the bits set on systems that support META, TOP etc keys, but that the derivation of the term is unknown. I was always under the impression that the term came from the fact that on these systems META-foo (or ALT-foo) echoed as '$foo' on the screen, dollar == buck, hence buckybits. Note the strong relationship between META-foo and ESC-foo and the fact that most DEC systems still echo ESC as $. Just thought that should be cleared up, hope you feel better now. -Barry Shein, Boston University ----------------------------- From: texsun!mehoge!tj@sun.UUCP (Cal Thixton Sun Microsystems Dallas Office) Telephone: (214) 823-2084 Office Phone: (214) 788-1951 Purpose-In-Life: To Spread the Gospel of UN*X to the heathens Subject: return address for postings Can anything be done to provide better or more accurate return addresses for postings to sun-spots? Sometimes people will post items that you might want to talk to them about off-line, but the addresses provided are generally of no use. cal [I just discovered how disastrous some of the addresses are. I am now checking more carefully that the ``From:'' line matches the ``From '' line and that both of them bear some relation to the ``Received:'' lines. If worse comes to worse, send a note to sun-spots-request and I'll try to figure out what the original address was. ---dsa] ----------------------------- Date: Thu, 5 Dec 1985 11:09 O From: Henry Nussbacher <Vshank%Weizmann.BitNet@ucbvax.berkeley.edu> Subject: X.25 support for a Sun I recently heard of X.25 support for a Sun. The specific example is we have an Ethernet of Unixes, IBM and Suns and we wish to connect an X.25 9600 baud Telenet line. Can someone please send me the necessary information or user experience with this program and whether the X.25 program has PAD emulation built in. Many thanks in advance, Henry Nussbacher Weizmann Institute of Science Rehovot, Israel ----------------------------- Date: Fri 6 Dec 85 14:08:34-EST From: Ralph W. Hyre Jr. <Ralph.Hyre@C.CS.CMU.EDU> Subject: Need experiences with Mt. Xinu Vax NFS Work-Phone: (412) 578-2847 We have an 11/780 and an 11/785 that we'd like to use as file servers for each other, and we'd also like to use them as file servers for our Suns. NFS seems to fit the bill, but I'd like to know if anyone else has had experience (good or bad) with NFS from Vax to Vax and Vax to Sun. Any information would be greatly appreciated. - Ralph ------- ----------------------------- Date: Fri, 6 Dec 85 17:09:12 pst From: fluke!jeff@uw-beaver.arpa (Jeff Stearns) Subject: Yellow Pages source code, anyone? Do you have distributable source code for the Yellow Pages client routines? I have a collection of Suns which all speak Yellow Pages, and I'd like to add my vaxen as YP clients. The Sun documentation makes it look possible (and I already have the needed RPC code); does anybody have the rest? thanx, Jeff Stearns John Fluke Mfg. Co, Inc. (206) 356-5064 {uw-beaver,decvax!microsoft,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!jeff ----------------------------- Date: Thu, 5 Dec 85 12:07:03 est From: allegra!phri!roy@seismo.CSS.GOV (Roy Smith) Subject: Multibus devices on Sun-3, Ethernet transcievers We've finally (almost) made up our minds to forget about buying Sun-2's and get only Sun-3's for the network were setting up. There is, however, a custom-built Multibus board that was designed for Sun-2's that we want to get. Lacking any further details (I don't know them yet) does anybody know if it is possible to put Multibus boards on the VME-bus Sun-3? I know there is some sort of VME-bus to Multibus adapter available. Does anybody have any practical experience with it? Unfortunately, while I have lots of Unibus experience, I've never worked with either VME-bus or Multibus hardware so I don't even know what kinds of problems to expect. Are there any pitfalls I should watch out for? On the software side, are there any vague generalities that can be made about porting a Sun-2 driver to a Sun-3? What software considerations are involved in going through a bus adapter? If it involves tearing out and rewriting half the bus mapping stuff, that's probably more than I care to deal with. As a side question, what kind of Ethernet hardware does Sun use? I like the looks of the Interlan NT100 transcievers; is this what they use? The removable tap assembly looks like it should be very easy to install and move around (you just leave the tap in place and move the xciever box to another one). ----------------------------- Date: Fri, 6 Dec 85 09:11:31 pst From: bcsaic!michaelm@uw-june.arpa Subject: Lisp won't die! There seems to be a strange bug when you mouse the "Exit" item in the suntools menu (the Root Window's default menu). It won't kill Lisp! For instance, if you have the following line in your .suntools menu: shelltool lisp and you Exit, the terminal switches back to the 80 x 25 display--almost. But the mouse pointer is still there, and when you move it over where the Lisp window was, the pointer changes to a circle with a dot. And the keyboard hangs; the only way out is to reboot. Likewise, if you have a /bin/csh window, bring up Lisp in it, then mouse Exit (without first exiting Lisp), the /bin/csh remains, as does Lisp (according to ps). This time the keyboard won't hang, although sometimes the new /bin/csh window occupying the same place that the /bin/csh window with Lisp was in, hangs. I haven't been able to reproduce this bug with any other program--rlogin, nroff, vi, Gnuemacs, etc. all seem to behave OK. So why does Lisp behave like this? I've gotten around the problem by always exiting from Lisp before exiting suntools, but this is a nuisance. It seems like you should be able to set up the root menu so it first kills off Lisp (using kill), then exits; but I'm not a C programmer, and I can't figure out how to get the pid of lisp from within C, so I'm not about to try to modify the routine which handles exiting from suntools (root_winmgr, I guess). (Or could I use kill (0, 9)? Will this work in csh?) By the way, I'm using suntools 2, Frantz Lisp opus 38.91. Long live Lisp! (by default, I guess) ----------------------------- Date: Fri, 6 Dec 85 11:52:14 est From: montanaro@ge-crd.arpa Subject: A lint problem I am using lint on a very small program (which follows). I include one lint library (which follows also). When I use the command "lint -ltpl5 junk.c", I get the following error message: /usr/lib/lint/llib-port.ln: No such file or directory I can't find the named file on our Sun. What's it for? Can I get rid of this message? When I leave out the "-ltpl5" qualifier, no error message is issued. Thanks, Skip Montanaro montanaro@ge-crd.arpa [ copy of "hello, world" and llib-ltpl5.ln deleted by moderator.] [ A bit of investigation and comparing of VAX manual pages and SUN manual pages shows that there is a -p option on the VAX and SUN which is only documented on the VAX. The p option checks compatibility with IBM and GCOS C. The shell file /usr/bin/lint (which fires up all the various pieces of lint & the pre-processor) checks the arguments twice: in particular, first for -*p* and then for -l*. Thus, if your library has a 'p' in its name you turn on portability checking as well as checking your library. (Similarly, n in the name of the library will turn off portability as a side effect.) Since you don't have a llib-port.ln, you can delete the first case in /usr/bin/lint and the problem should go away. ---dsa] ----------------------------- Date: 4 Dec 1985 15:10:52-EST From: clapper@NADC Subject: SunWindows - help I have been attempting to use SunWindows from within applications code for the first time. I typed in the example from page 2-3 of "Programmer's Tutorial to SunWindows." (I've appended a listing of the code at the end of this letter.) While in the suntools environment, I tried to run the program - and got the following error message: EMT trap - core dumped Next, I compiled the program with the "g" toggle, and used "dbxtool" to step through its execution. The error seemed to occur somewhere during my call to tool_select() (tool_select() seems to be calling write.) The error displayed by dbxtool was: EMT instruction in write at 0x36c10 00036c10 bad op A message on the console window corroborated the dbxtool message: dbx: internal error: couldn't decode op at address 0x36c10 Does anyone out there have any clues? Thanks in advance. Brian M. Clapper clapper@nadc.ARPA Naval Air Development Center Warminster, PA -- the code -- #include <stdio.h> #include <suntool/tool_hs.h> #include <suntool/msgsw.h> struct tool *tool; int sigwinched (); main (argc, argv) int argc; char *argv []; { struct toolsw *msg_sw; if ((tool = tool_make (WIN_LABEL, argv [0], 0)) == NULL) { fputs ("can't make tool.\n", stderr); exit (1); } if ((msg_sw = msgsw_createtoolsubwindow (tool, "" TOOL_SWEXTENDTOEDGE, TOOL_SWEXTENDTOEDGE, "Hello world!", (struct pixfont *) 0)) == NULL) { fputs ("can't create subwindow.\n", stderr); exit (1); } signal (SIGWINCH, sigwinched ()); tool_install (tool); /* install tool in window tree */ tool_select (tool, 0); /* main loop to read input */ tool_destroy (tool); /* clean up. */ } sigwinched () /* Note window size change and damage-repair signal */ { tool_sigwinch (tool); } ----------------------------- End of SUN-Spots Digest ***********************