home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / sun / admin / 9392 < prev    next >
Encoding:
Internet Message Format  |  1992-12-13  |  1.9 KB
  1. Xref: sparky comp.sys.sun.admin:9392 comp.unix.shell:5049
  2. Path: sparky!uunet!auspex-gw!guy
  3. From: guy@Auspex.COM (Guy Harris)
  4. Newsgroups: comp.sys.sun.admin,comp.unix.shell
  5. Subject: Re: Aren't SunOS 4.1.2 and Solaris 2.1 compatible?
  6. Message-ID: <15866@auspex-gw.auspex.com>
  7. Date: 13 Dec 92 20:36:53 GMT
  8. References: <1992Dec4.150456.8605@dragon.acadiau.ca> <jp5q9l@lynx.unm.edu> <1992Dec11.184938.19511@hyphen.com>
  9. Sender: news@auspex-gw.auspex.com
  10. Followup-To: comp.sys.sun.admin
  11. Organization: Auspex Systems, Santa Clara
  12. Lines: 28
  13. Nntp-Posting-Host: auspex.auspex.com
  14.  
  15. >What's changed?  The system calls are numbered differently.  The errnos
  16. >are numbered differently.
  17.  
  18. And some signal numbers and flags to system calls are different, and
  19. "ttyslot()" has to scan "/etc/utmp" rather than "/etc/ttytab", and....
  20.  
  21. No, "ttyslot()" isn't a "system call".  It's a library routine; the BCP
  22. could (and may) still provide binary compatibility, as it only supports
  23. images dynamically linked with "libc", and a dynamically-linked image
  24. gets "ttyslot()" from the shared library, rather than from code in the
  25. image, so it can get a different version when run under 5.x than when
  26. run under 4.x (or, in fact, can get different versions when run under
  27. 5.y than when run under 5.x, or can get different versions when run
  28. under 4.y than when run under 4.x, for that matter).
  29.  
  30. >The executable header format is no longer
  31. >a.out, but something different (I'm not sure, but I think it's COFF).
  32.  
  33. No, it's ELF.  COFF is the pre-SVR4 SV executable/object file format;
  34. ELF is the SVR4 one.
  35.  
  36. >Caveats: BCP can do the right thing if the 1.x program behaves itself.
  37. >That means that it must have been linked dynamically instead of statically,
  38. >and must not make any references to kvm or kmem.
  39.  
  40. And should not try to manipulate any files that 1) changed their
  41. location (without a symlink being planted) or their format and 2) don't
  42. have their format and location hidden behind a procedure in "libc".
  43.