home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / rec / games / mud / misc / 1736 < prev    next >
Encoding:
Internet Message Format  |  1992-12-26  |  3.8 KB
  1. Path: sparky!uunet!olivea!apple!TIS.COM!mjr
  2. From: mjr@TIS.COM (Marcus J. Ranum)
  3. Newsgroups: rec.games.mud.misc
  4. Subject: Re: Note to any fellow DikuMUD coders...
  5. Message-ID: <9212262223.AA09707@TIS.COM>
  6. Date: 26 Dec 92 22:23:08 GMT
  7. References: <kwt1H$1cnb@atlantis.psu.edu> <9212261801.AA05796@TIS.COM> <1992Dec26.211738.11242@blaze.cs.jhu.edu>
  8. Sender: daemon@Apple.COM
  9. Reply-To: mjr@TIS.COM
  10. Organization: Trusted Informations Systems, Inc.
  11. Lines: 64
  12.  
  13. arromdee@jyusenkyou.cs.jhu.edu (Ken Arromdee) writes:
  14. >>#ifdef    BROKEN_INET_NTOA
  15. >>#ifdef    SUN
  16. >>#else
  17. >>#endif
  18. >>#else
  19. >>#endif
  20. >>    And similar abominations.
  21. >
  22. >Yet, what is the alternative?  The alternative seems to be to not take into
  23. >account broken software at all, and to always write as though it worked even if
  24. >it doesn't.  This creates an _immediate_ "software time bomb".
  25.  
  26.     The least unpleasant alternative (I don't think ANY of this stuff is
  27. exactly pleasant) is to write modular code and provide library functions
  28. that can be specified on a per-system basis. A good example of this is
  29. how large, well-engineered, commercial products (such as Oracle) achieve
  30. portability. Cnews also does this with a pretty high degree of success
  31. and a low #ifdef count. See Henry Spencer's '#ifdef considered harmful'
  32. in the San Antonio USENIX talks for an interesting discussion of the topic.
  33.  
  34.     What you basically need to do is write a module that you can
  35. "library-ize" on a per-system basis. Suppose you need to do low granularity
  36. file locking in a program. This, traditionally, is subtly broken between
  37. various forms of UNIX and network filesystems. You write a lock_file()
  38. routine and an unlock_file() routine and provide a simple interface to
  39. those. Then, your software gets configured at *link* time rather than
  40. at compile time, by linking against a version of the routine that is
  41. known to work for the particular system it is being built on. An example
  42. of doing this would be to assume that the system's inet_ntoa() works[1]
  43. but to provide a library with inet_ntoa() implemented using sprintf()
  44. that could be linked in on specified systems. That way you can reconfigure
  45. the program by changing the makefile, not the *code*. For large
  46. applications this is absolutely the only way to do things. In a
  47. large-scale system it's actually important to keep the *names* of
  48. functional units the same for debugging purposes. At least if you
  49. can assume you have a "lock_file()" function, then you know you
  50. can set a breakpoint there. If you have a file containing a wad
  51. of #ifdefs then you're on your own. This is not a concern for
  52. small programs, but if you write small programs with the care and
  53. attention required for large ones, you'll find your small programs
  54. tend to work a whole lot better than stuff written by folks who
  55. just hammer away in a text editor.
  56.  
  57.     With respect to Ken's remarks about "not everyone is a programmer",
  58. I couldn't agree more. Whenever you're developing software you have to
  59. determine what your target audience is and program accordingly. That's
  60. why a lot of folks go to extreme lengths to write Makefiles and programs
  61. that are "smart" and autoconfigure themselves (or try real hard and
  62. usually fail each time there's a new operating system release). That's
  63. because they're catering to the non-programmer. Unless I'm being paid to
  64. cater to non-programmers (I.e.: I'm *working* instead of *playing*) then
  65. my obligation to them is appropriately reduced. Before you jump up and
  66. down about how it's impossible to design library-configuring code that
  67. is nontrivial but that almost any idiot can install, take a look at
  68. Larry Wall's stuff, or the Cnews distribution. They're amazing pieces
  69. of work.
  70.  
  71. mjr.
  72.  
  73. [1] I tested inet_ntoa() on our Solobourne and a Sun running 4.1 and it
  74. seems to work fine. This is another problem with kludging up your
  75. code because you think vendor code is broken. Sometimes it gets
  76. fixed and sometimes it works fine all along.
  77.