Info-Mac 3/Info_Mac_1994-01.iso/Periodical/TidBITs/TidBITS#187

Text File | 1993-12-31 | 29KB | 627 lines

 1-Aug-93 23:39:32-GMT,29100;000000000000
Return-Path: <tidbits![e-mail]>
Received: from terminator.rs.itd.umich.edu by CAMIS.Stanford.EDU (4.1/inc-1.0)
    id AA06338; Sun, 1 Aug 93 16:39:32 PDT
Received: from nwnexus.wa.com by terminator.rs.itd.umich.edu (5.67/2.2)
    with SMTP id AA01121; Sun, 1 Aug 93 19:39:24 -0400
Received: by nwnexus.wa.com id AA10404
  (5.65c/IDA-1.4.4 for [e-mail]); Sun, 1 Aug 1993 16:39:16 -0700
Received: by tidbits.com (uA-1.6v2); Sun, 1 Aug 93 14:54:53 PDT
From: [e-mail] (Adam C. Engst)
To: [e-mail]
Subject: TidBITS#187/02-Aug-93
Date: Sun, 1 Aug 93 14:54:53 PDT
Organization: TidBITS
Reply-To: [e-mail] (Adam C. Engst)
Message-Id: <[e-mail]>
X-Mailer: uAccess - Macintosh Release: 1.6v2

TidBITS#187/02-Aug-93
=====================

Roy McDonald's article on software acceleration spawned numerous
   interesting comments, and other bits of note include changes in
   three Internet gateways, AOL, Prodigy, and GEnie. We also have
   a look at Claris's new strategy, some notes on handwriting
   recognition and communication on the first Newton, and finally,
   an article detailing how to make MacsBug automatically reboot
   your server when the server crashes.

This issue of TidBITS sponsored in part by:
* APS Technologies -- 800/443-4199 -- [e-mail]
   Makers of hard drives, tape drives, memory, and accessories.
   For APS price lists, email: [e-mail]

Copyright 1990-1993 Adam & Tonya Engst. Details at end of issue.
   Automated info: <[e-mail]>. Comments: <[e-mail]>
   ---------------------------------------------------------------

Topics:
    MailBITS/02-Aug-93
    Software Acceleration Comments
    Internet Gateway News
    ClarisWorks Reigns
    ResEdit Hacking MacsBug
    Newton Notes
    Reviews/02-Aug-93

[Archived as /info-mac/per/tb/tidbits-187.etx; 28K]


MailBITS/02-Aug-93
------------------
  I'll be making the semi-annual pilgrimage to Macworld Boston as
  you read this. Although I will be ably accompanied by Sally, our
  PowerBook 100, I won't read email except on CompuServe until
  11-Aug-93. Tonya will check my email for important messages, but
  please refrain from sending unnecessary mail until I return. Truly
  important email should go to the CompuServe address at
  <[e-mail]> until then. I'll try to check in every
  day.

  I'll release the next issue of TidBITS while on the road, but
  since I will be using different connection methods, it may not
  work, at which point it may be a day or two late.


**Header Quibble** - I've noticed a bunch of failures from the
  fileserver recently, and in most cases, the failure stems from a
  strange header, most commonly the information in the From: line.
  Many people put their names in the From: line along with the email
  address. That's fine, but if you include your full name,
  department, organization, and telephone number the email address
  ends up wrapped down to the second line where the fileserver
  software can't find it. Try putting extended contact information
  in a signature instead. Also, try to avoid commas or quotes in
  your name since email programs tend to spit up over them. In an
  ideal world, your email would have a single From: line looking
  something like this:

    From: Ferdinand The Bull <[e-mail]>

  Some people use QuickMail gateways that like to duplicate the
  internal From: line in a pseudo-header below the Internet header.
  These requests fail because the pseudo-header does not contain the
  correct Internet address. If you can prevent that pseudo-header
  from appearing, the fileserver will work better for you.

  I realize that you may not know how to change your name in the
  From: line in your mailer, but if you have trouble receiving files
  from the fileserver, fixing your From: line will increase your
  chances of success, and I'll see fewer bounces. Everyone wins.


**Subscribing to TidBITS** -- Recently more personal subscription
  requests have come in as well, so I guess it's time to publish the
  instructions for subscribing automatically again. This information
  is also always available from <[e-mail]>.

  To subscribe to the TidBITS mailing list, send email to:

    [e-mail]

  with this line in the body of the mailfile:

    SUBSCRIBE TIDBITS your full name


**Legal Queries** -- TidBITS is in the process of researching an
  article on software licensing with a view toward the actual law,
  standard agreements, nonstandard agreements, what happens if you
  break the agreement, and how it all applies to shareware/freeware.
  We also hope to look at the details in terms of upgrades, selling
  software, donating software to non-profits, and otherwise
  transferring the license.

  With that in mind, we could use some help. If you could send Brady
  Johnson information on the following, we'd appreciate it (there's
  no need to send the stuff to me as well). Brady's address is:

    [e-mail]

  We're looking for strange licensing clauses, how different
  companies allow you to transfer the license (or not), if you as a
  individual have had any experiences with enforcement of the law,
  and any other brief comments you might have. Thanks!

  And yes, Brady actually is a lawyer, he doesn't just play one on
  the nets.


Software Acceleration Comments
------------------------------
  We received a number of well thought-out comments abut Roy
  McDonald's article on software acceleration in TidBITS #186_.
  Although we don't have room for all of them, here are a few notes:


Larry Rosenstein <[e-mail]> and several others disagreed
  with Roy's statement that "OOP is an obvious formula for
  inefficient code." Larry felt that this is a myth, pointing at the
  fact that the System 7 Finder is a new program that hasn't been
  optimized, in contrast to the System 6 Finder, which had gone
  through several iterations that would help speed it up. Larry also
  noted that many commercial Macintosh applications have been
  written with object oriented techniques, including popular
  programs like Photoshop (and incidentally, Akif Eyler's Easy
  View), and that it's impossible to tell which were written with
  object oriented techniques based solely on performance.


Jeffrey A. Porten <[e-mail]> wonders if hardware
  advances are not often the reason for software inefficiencies. He
  remembered discussions circa 1985, when programmers would code
  their software for the Apple //e and then spend months picking
  over their code paring out five bytes of code here and ten bytes
  of code there, simply because they had to - they were programming
  for machines with only 64K of RAM, and disks only stored 143K of
  information. Today's higher expectations require larger programs,
  but Jeffrey can't believe that the 1985 philosophy produced his 8
  MB word processing folder or his 3 MB System Folder.


Tom Lane <[e-mail]> passed on an old item of computer
  science wisdom about there being multiple levels of system design,
  with independent speedups possible at each level. For example, you
  can describe a system independently at the levels of:

* software architecture (module structure)
* high-level algorithms (e.g. Roy's sorting example)
* low-level coding practices
* compilation (translation to machine code)
* hardware architecture (buses, caches, etc.)
* hardware realization (circuitry)

  If we imagine that sufficient work can produce a speed increase of
  10 times at each of these levels, then we see how to solve our
  problem **one million times** faster.


Michael Crawford <[e-mail]>, author of Working
  Watermarker, the Word Services Apple Event Suite, Webster's
  Electronic Dictionary and Thesaurus for the Macintosh, and others,
  writes:

  I greatly enjoyed Roy McDonald's article on software speed that
  appeared in TidBITS #186_. I've been contemplating the same issues
  for the last several years and have some comments. I think Roy's
  ideas on the lack of good algorithms in commercial software can be
  summarized as follows:

1. Productive software engineers often don't know computer science.
2. Computer scientists can't ship a commercial product.
3. Many software engineers can't program either.

  It has been my experience everywhere I have worked that few, if
  any, of the production engineers follow any of the academic
  literature on algorithm or operating system design. For this
  reason, good ideas from academia either never show up on the
  market, or only show up after many years when a developer comes up
  with it independently, claiming it as an innovation.

  Few commercial publishers really use "computer science" in their
  products. Connectix is a notable exception to this sad fact.

  There is another issue that Roy didn't address - software quality.
  I think that the crux of the speed problem lies in quality. The
  fastest software is useless if it crashes frequently.

  I've spent most of my career on the Mac, on the PC, and on Unix
  fixing someone else's broken code. I have been astonished at the
  awful quality of the software rats' nests I've debugged.
  Commercial developers often avoid tricky algorithms, not just to
  get to market quickly, but to get to market at all. With the
  poorly structured code often found in commercial products,
  attempting an n^2 algorithm to nlog(n) would often result in
  failure because the code would never work at all.

  I believe this occurs either because programmers have no formal
  training - I got my start in programming as an astronomy student -
  or because the traditional teaching of computer programming over-
  emphasizes the teaching of algorithms by coding simple homework
  problems that take a few days to a week to do.

  A software engineering curriculum, as opposed to a computer
  science curriculum, would teach project management, team
  programming, and version control, and engage an entire class of
  students in the coding of a single program that would take from
  one semester to one year to complete. [Sounds like a great way to
  produce incredibly useful software for the community as well.
  -Adam]

  Much of the industry's problems in software quality could be
  fixed, not by doing object-oriented programming, but by learning
  proper structured programming, and having the discipline to
  program in a structured manner. OOP has gained in popularity, not
  so much because it is inherently superior, but because it is
  impossible to make a program work unless one has the discipline to
  design the class structure of the program in an intelligent manner
  to begin with.

  I've read much spaghetti code written by (pardon my tirade)
  imbeciles who claimed they wrote structured code. I have three
  tests for good structure that work well in practice and have
  helped me repair many a broken program:

1. Well-structured code can be easily modified for a purpose
  different than that for which it was originally intended.

2. Pieces of well-structured code can be understood fairly well
  without understanding the program as a whole.

3. Modules of code that perform general utility functions can be
  easily removed from a project and incorporated into a completely
  different project without changing header files, or bringing along
  a bunch of other utility functions.

  Object oriented code usually does not pass the third test, whereas
  structured code often does. It is my experience that any code
  which can satisfy the above criteria is easily fixed when a bug is
  found, and can be easily modified to use faster algorithms.


Internet Gateway News
---------------------
  This information will end up in my book, but it's worth
  mentioning, since it may be of use to you now.


**AOL now splits** long Internet email messages. In the past the
  America Online gateway software truncated incoming files at 27K,
  which put a damper on receiving long text files like TidBITS and
  BinHexed programs. I tested the splitting by sending myself a test
  issue of TidBITS and found that it came out broken into three
  chunks, the first two about 15K long and the third only 1K long.
  This isn't quite ideal, but we can't argue with progress, I
  suppose, and with this new feature, AOL's Internet gateway becomes
  significantly more useful.


**Prodigy's Internet gateway** won't come cheaply. Jeff Needleman
  <[e-mail]> clarified the terms of the current gateway - 15
  cents for each 3,000 character block received. No word on the cost
  to send email through the gateway yet. Jeff said the gateway is in
  alpha testing, so only a few authorized users can receive mail
  through it now. I think the cost will have to come down for the
  gateway to be of serious utility to Prodigy users. If you assume
  an issue of TidBITS is 30,000 characters, it would cost $1.50 to
  receive an issue on Prodigy from our Internet mailing list. That's
  expensive. The Prodigy gateway will have a 60K limit on incoming
  messages, which will prevent users from requesting large programs
  from mailservers, even if the cost doesn't.


**GEnie opened up** its Internet email gateway to all of its users
  as of 01-Jul-93. Previously, GEnie users had to sign up and pay
  more to receive Internet email. If you wish to send someone on
  GEnie email from the Internet, address it to:

    [e-mail]

  where the username is the person's GEnie username. To send email
  from GEnie to the Internet, the GEnie user must, much like
  AppleLink, append @inet# to the Internet address. So my address
  from GEnie would be <[e-mail]@inet#>. The only cost is for
  the connect time, and GEnie recently revamped its rates to be more
  like America Online's rate structure (OK, I don't know who started
  it, but they're similar now). GEnie costs $8.95 per month with
  four free hours each month. After those four free hours, users pay
  $3 per hour in connect time, except in a few free administrative
  areas. Thanks to <[e-mail]> for the details.


ClarisWorks Reigns
------------------
  We've come across an intriguing rumor. It might or might not be
  true, as with all rumors, and I'm sure Claris reserves the right
  to deny everything or to change its mind, but it appears that all
  of Claris's major products are doomed in favor of ClarisWorks.

  That sounds radical and rash, since even the slick ClarisWorks 2.0
  doesn't boast anywhere near the stand-alone power of MacWrite Pro,
  FileMaker Pro, Resolve, or MacDraw Pro. Those products will
  continue to exist in name, but their current code will be based on
  the newer and theoretically better code in the ClarisWorks.

  If you think about it, this strategy makes sense. MacDraw and
  FileMaker have been around a long time, possibly with the same
  code base, Resolve has never competed seriously with Excel, and
  MacWrite Pro shipped two years late to mixed reviews. In contrast,
  ClarisWorks is a recent arrival and has proven immensely popular
  with its method of contextual editing where simply clicking on a
  spreadsheet object, for instance, makes spreadsheet menus appear.
  The only major fault in ClarisWorks is its lack of power and
  expandability for high-end users.

  Consider what would happen if you could have the tight, contextual
  interface of ClarisWorks and the power of MacDraw Pro, MacWrite
  Pro, FileMaker Pro, and Resolve. At that point you could complain
  only about specific features not being what you personally wanted,
  or perhaps about the cost of purchasing all four programs.


ClarisImpact & ClarisDraw
  Although we may have to wait a while to see the benefits of
  Claris's decision in this respect, the company is hard at work on
  new technologies, and just announced two new cross-platform
  applications that use a new graphics engine. ClarisImpact is aimed
  at business users working on projects such as flow-charts and
  diagrams, whereas ClarisDraw replaces MacDraw for general purpose
  graphics. Both programs sport the same basic ideas embodied in
  Aldus IntelliDraw - features like automatic sizing, aligning, and
  connection of objects. Claris's propaganda implies that the Mac
  versions of these programs are available now - presumably slated
  for a splash at Macworld, and the Windows versions should appear
  in the first half of 1994. Suggested retail will be $399 all
  around, and upgrades from MacDraw go for $99, unless you bought
  MacDraw Pro after 01-Jun-93, in which case the cost is $29 for
  ClarisDraw or $49 for ClarisImpact. Finally (I hope you're keeping
  track of this), registered users of other graphics applications,
  MacDraw II, or ClarisWorks can buy either ClarisImpact or
  ClarisDraw for $149.


OpenDoc
  As long as we're rethinking Claris's application code base, why
  not consider the addition of Apple events and Apple's OpenDoc
  compound document technology to the mix. OpenDoc is Apple's answer
  to Microsoft's OLE 2.0 (Object Linking and Embedding), and
  apparently when Bill Gates found out about the project (code named
  Amber) he had a fit over the phone at David Nagel, who was in
  charge of the project at Apple. Could Bill be worried about
  competition? There might be some, since IBM, Lotus, WordPerfect,
  and Borland have all announced their support for OpenDoc, a cross-
  platform, open standard.

  OpenDoc allows you to do in any compatible application what you
  can do today within ClarisWorks. Eventually you should be able to
  create a document without worrying what type of document it is,
  and then create the data that you want within your generic
  document. If you added a picture using a graphics application and
  then needed to edit it, you would be switched right into the
  graphics package. However, it wouldn't be like the clumsy linking
  we have now, but like in-context editing that would provide the
  appropriate tools and menus when you selected an object.

  Although OpenDoc isn't out yet, it in theory bests OLE in two
  ways. First, the OpenDoc alliance has set up a certification
  program to ensure that all OpenDoc applications will work
  together, and second, OpenDoc will work over a broader range of
  platforms, including DOS, Windows, OS/2, and of course System 7.
  Unix is slated for later support. The certification program seems
  to be the most important aspect, because there's no sense in
  having applications that theoretically work together under OLE if
  they don't work reliably.

  Information from:
    Pythaeus


ResEdit Hacking MacsBug
-----------------------
  Anyone who runs an unattended server Mac will appreciate a little-
  known feature of MacsBug 6.2.2. You can define a
  FirstTime/EveryTime macro that automatically restarts the Mac if
  it crashes into MacsBug, rather than sitting with an error message
  on its screen. You need ResEdit to do this, and all standard
  warnings about ResEdit corrupting the moral fiber of today's youth
  apply.

  But first, some background. MacsBug is a free low-level debugger
  from Apple that normally only programmers use. However, MacsBug
  has a few commands useful to non-programmers, and I find that
  MacsBug sometimes helps me identify guilty applications when I
  have strange crashes. Here are the basic MacsBug commands for
  non-programmers:

    ?  --  Gets help from MacsBug. Issue the command ? g for help on
           the g command, for instance.

    g  --  Tells MacsBug to start executing the program at the point
           where MacsBug was entered. This is normally not too useful
           because you enter MacsBug primarily in a crash situation,
           and you can't generally continue from that point. You use
           the g command when you accidentally enter MacsBug (such as
           by pressing the interrupt switch).

    es --  Tells MacsBug to "exit to shell." On the Mac, the Finder is
           the shell, so you're telling MacsBug to quit the current
           application and go to the Finder. Try this first after
           crashing into MacsBug. There is a related command, ea, which
           stands for "exit to application," which tells MacsBug to
           quit the current application and restart it. I find that
           this almost never works, so I don't even bother trying it.

    rs --  Tells MacsBug to unmount all volumes other than servers
           and then reboot the Mac. This is generally what you do
           when es doesn't work and you want to reboot. There is a
           related command, rb, which unmounts the boot volume only
           and then reboots the Mac. I have multiple volumes, so I
           generally use rs. I haven't noticed any real difference.

  As I said, you can define a macro that will run automatically when
  MacsBug is entered. Note that this by no means solves any problems
  - it's like replacing a fuse immediately after it blows without
  checking why the fuse blew. It's useful for keeping a Mac that
  crashes occasionally running most of the time. A MacsBug wizard
  might be able to modify the macro to open a log file, do a few
  things (like a stack crawl, or at least log the reason MacsBug was
  called), close the log, and then restart. The user would then have
  a record of what happened and why, which could be shared with the
  developer. However, that's beyond my MacsBug skills, although I'm
  willing to accept clarifications or modifications. On to the hack!

* In ResEdit 2.1.2, open a copy of the file Debugger Prefs.

* Open the mxbm resource.

* From the Resource menu, choose Create New Resource.

* Click on the first entry, 1) *****, and then go to the Resource
  menu and choose Insert New Field(s).

* In the Macro name box, type "FirstTime", and in the Expansion
  box, type "g" (both without the quotes).

* Click on the second entry, 2) *****, and then from the Resource
  menu select Insert New Field(s).

* In the Macro name box, type "EveryTime", and in the Expansion
  box, type "rs" (again, both without the quotes).

* Close the "mxbm ID = 128 from Debugger Prefs" window, make sure
  that resource is still selected (it should be), and from the
  Resource menu choose Get Resource Info.

* In the Name: box, type "Works FirstTime/EveryTime", close the
  Info window, save the file, and quit ResEdit.

  Make sure that both MacsBug and the modified Debugger Prefs file
  are loose in the System Folder (not in any special System 7
  folders), and reboot. The next time the Mac crashes and enters
  MacsBug (this won't help when the Mac just freezes), the macro
  will restart the Mac. Test it by hitting the interrupt switch.

  MacsBug is available on <ftp.apple.com> as:

    /dts/mac/tools/macsbug/macsbug-6-2-2.hqx

  If you use the Centris 610 and low-end 650 with the 68LC040 chip,
  you need a special version of MacsBug, which is available as:

    /dts/mac/tools/macsbug/macsbug-68040lc.hqx

  Unfortunately, this special version doesn't include the Debugger
  Prefs file, so you'll have to get both versions of MacsBug if you
  have one of the affected Centris models. Rumor has it that you
  need a new version of MacsBug for the most recent PowerBooks as
  well, but that might best be a question for APDA, your dealer, or
  800/SOS-APPL.


AutoBoot
  Those who want more functionality at the risk of patching a few
  traps should check out the shareware AutoBoot utility from Karl
  Pottie. AutoBoot is a Control Panel/Extension that reboots your
  Mac if a certain amount of time has passed after a System Error or
  freeze. I haven't used the latest version of AutoBoot, but since
  it can reboot the Mac after a freeze, it is potentially more
  useful than my MacsBug hack. However, as an extension, there's
  always a chance that AutoBoot could conflict with something. If
  you want to try AutoBoot, it's available for anonymous FTP on
  sumex-aim.stanford.edu as:

    info-mac/cfg/auto-boot-122.hqx

  Information from:
    Karl Pottie -- [e-mail]


Newton Notes
------------
  By the time you read this, Apple will have released the Newton, in
  the form of the MessagePad, which we talked about in TidBITS
  #185_. Several thousand units will be for sale at the Macworld
  Expo in Boston, although unless the price to the press is lower
  than for normal folks, I'm not coming home with one. I do hope to
  try one out, although no guarantees. In the meantime, Pythaeus has
  played with one and has these comments about handwriting
  recognition and communication:

  The MessagePad has a preferences area, called Extras, that lets
  you vary the speed of recognition, trading accuracy for speed. I
  don't know how accurate the recognition could have been
  ultimately, since you must work with the MessagePad for a few days
  before it completely adjusts to your handwriting, and I had only
  one day. But I achieved satisfactory results for entering
  appointments and similar simple tasks if I waited for about a
  second every five words. Not bad!

  You meet the Newton halfway on recognition. It has a number of
  different versions of each letter and symbol it recognizes. So, in
  another part of Extras you get to go through each letter and
  symbol and choose which forms you use most often and least often
  (your rendering of the letter "E" will change according to whether
  it's cursive or not, capital or not, and what letters are on
  either side of it).

  You cannot train the MessagePad to recognize unsupported
  characters; you must fit one of the characters supplied, or learn
  to use it. This may prove a handicap for people with truly abysmal
  handwriting. No shorthand yet, although there's room there for a
  third party to step in and make some money fast.

  Once you and MessagePad agree on what characters you'll be using,
  you can practice in another area. It flashes words up from the
  dictionary to let you write them, and it tells you how sure it is
  that it will recognize the word later. Pretty soon I'm sure we'll
  have a game that helps you practice handwriting recognition.
  Should help while away commuting time if you have a MessagePad as
  well.

  I believe I could be up to 100 percent accuracy in a month or so.
  Like any new device, it takes adjusting to, although far less
  adjusting than is necessary with a computer.


Beaming Etiquette
  Apple has anticipated the social gaffes that might be committed in
  a room full of people beaming information around with Newton-based
  products (the beaming is done via infrared). The MessagePad lets
  you temporarily hold all incoming "beams" ("beam" is Apple's way
  of describing both the act and the information itself). Future
  models will include a polite message in reply to hopeful beams,
  like "Sorry, but Adam prefers not to receive your beam right now."
  You also get confirmation that your beam was received by the
  correct person at the end of transmission. Can you imagine the fun
  that people could have using MessagePads to send each other love
  letters, cheat on tests in school, and otherwise perform acts that
  could be thoroughly embarrassing if made public?

  I'd like to see this functionality used more seriously in the
  future to limit the unnecessary paper waste at trade shows and the
  like. Instead of picking up a glossy brochure that you're going to
  later lose or throw out, why not just point your MessagePad at a
  special transmitter to pick up contact and product information
  automatically? I'm sure it won't happen soon, even if everyone
  does have a MessagePad, because it would require marketing
  departments to adapt to the way people absorb information,
  something they have trouble doing.

  Information from:
    Pythaeus


Reviews/02-Aug-93
-----------------

* InfoWorld -- 26-Jul-93, Vol. 15, #30
    17" Color Monitors -- pg. 68
      (too many to list)


$$

 Non-profit, non-commercial publications may reprint articles if
 full credit is given. Others please contact us. We don't guarantee
 accuracy of articles. Caveat lector. Publication, product, and
 company names may be registered trademarks of their companies.

 This text is wrapped as a setext. For more information send email
 with the single word "setext" (no quotes) in the Subject: line to
 <[e-mail]>. A file will be returned shortly.

 For an APS price list, send email to: <[e-mail]>

 For information on TidBITS: how to subscribe to our mailing list,
 where to find back issues, how to search issues on the Internet's
 WAIS, and other useful stuff, send email to: <[e-mail]>
 Otherwise, contact us at: [e-mail] * CIS: 72511,306
 AppleLink & BIX: TidBITS * AOL: Adam Engst * Delphi: Adam_Engst
 TidBITS * 1106 North 31st Street * Renton, WA 98056 USA
 ----------------------------------------------------------------