Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Is multifinder or finder running??
Message-ID: <9276@hoptoad.uucp>
Date: 13 Dec 89 02:24:40 GMT
References: <17708@ea.ecn.purdue.edu> <9190@hoptoad.uucp> <17695@dartvax.Dartmouth.EDU> <9247@hoptoad.uucp> <17864@dartvax.Dartmouth.EDU> <1989Dec11.172400.25746@agate.berkeley.edu>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 79

In article <1989Dec11.172400.25746@agate.berkeley.edu>
silverio@brahms.berkeley.edu.UUCP (C J Silverio) writes:
>This whole train of thought is veering rapidly in the direction of the
>absurd. I think the original theory was, "since there is absolutely no
>RIGHT way to tell if MultiFinder is running (which is a shame for the
>few applications that absolutely need it), here is a SIMPLE way."

Another point, which should have been made earlier, is that MultiFinder
incompatibility is simply not acceptable for production software.  I
took the original message as meaning that a program was in development
and had not yet been made MultiFinder compatible, and the check for
MultiFinder's presence was to be made solely to prevent inadvertant
system crashes among people using development versions.  All this stuff
about international usage is beside the point, since no development
version with flaws this serious should be propagated beyond the local
site.

>Obviously, if one wanted to be very clever, one could merely compare
>the last Apple-menu item against the 30 or so strings that comprise
>the Apple International System strings. One could then simply allow
>the user to tack on whatever strings his or her little heart desires.

One could instead search the menu for an item corresponding to the name
of the application, gotten from a PBGetFCBInfo on the application
resource file descriptor.  This would work regardless of
internationalization or user reconfiguration.

>But this begs a further question: Did I miss something, or isn't there
>a RIGHT and OFFICIAL way (I presume through the use of SysEnvirons) to
>tell which International System an app is running under? 

There is, but I don't know of an easy one; much of the Script Manager
documentation is opaque to me, and I believe the fault is in the
quality of the documentation, not in my reading abilities.  In any
case, the way seems to be to call GetSysFont and compare it numerically
to the fixed international ranges.

>Wouldn't this be nice? Then one could ship a really international
>version of the program that automatically (if possible) come up in
>whatever language was appropriate. Too much disk space? Pish and
>poddle! I'll betcha people like it.

I think this idea should be discussed by the group; it's a good one.
(I imagine most of us have toyed with the idea already at some time or
other.)  First, the disk space issues are not as trivial as you seem to
think.  It would involve a virtual duplication of most of the resource
fork, excluding code resources; a 250K application with resources for
ten languages could easily become well over a megabyte and a half.
This is not acceptable.  However, if you *were* going to do it this
way, perhaps for a small program, it seems likely you would use an
anlogy to the "resource base" idea already used for desk accessories.
All accesses to possibly internationalizable resources (which includes
MENUs, STRs, STR#s, DLOGs, DITLs, WINDs, CNTLs, FONTs, FONDs, etc.)
would not be by means of direct resource id, as in most current
applications, but relative to a resource base id determined by the
language code.  Each resource would have an id consisting of the
relative id plus the resource base id.  The base id would be stored in
a global and computed at application startup.  This involves a
nontrivial, but not enormous, amount of programmer work.

The alternative is to give each country's resources the same ids, and
to customize the application by putting an external resource file into
the same folder as the application.  The application would contain in
itself the default resources (those for the language of its origin,
usually American English), but if it detected a different language code
on application startup, it would open the appropriate international
resource file.  Because of the way resource search paths work, these
resources would override the defaults automatically, provided the
application kept the resource search path including the international
resources file.  This way, no one would have to have hundreds of K of
unwanted resources, but the application could be distributed with all
necessary resource files for running in many countries.  Rather than
separate applications for each language, each language would have only
a single resource file which must sit by the side of the application.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"Mere opinion without supporting argument is no more than the American
 Bandstand school of literary evaluation."  -- Tom Maddox