Jun 90 Mousehole
Volume Number: 6
Issue Number: 6
Column Tag: Mousehole Report
THINK vs MPW and db_Vista 
By Larry Nedry, Mousehole BBS
From: Roembke
Re: MPW vs THINK
I figured this would be the perfect place to find out what the pros and cons of each of
these environments is. I have quickly scanned the messages, but none really jumped off
of the screen at me, so I am asking which is best?
If you need some background, I am a new Macintosh Programmer, I am interested in
learning OOP, I am only interested in real languages like C and Pascal. I have an SE/30
at home and a Mac IIx at work. Currently I am leaning towards MPW- but interested in
getting advice before putting down my hard earned cash on one or the other. I am
interested in ( eventually) producing all types of Macintosh code (XCMDs, DAs,
Applications, INITs, etc.) Any thoughts?
From: Mward
Re: MPW vs THINK
The basic difference is ease-of-use vs power. MPW gives you the power of a command
line interface, and a lot of useful tools, while Think gives you a very pleasant, well
integrated environment. If you are new to Mac programming, I would doubt you’d need
the power offered by MPW for a long time.
I’m curious - what languages do you consider “unreal”?
From: Roembke
Re: MPW vs THINK
Actually, I was using “real” as tongue-in-cheek! At the present time I consider myself
to be pretty well occupied with C and Pascal to consider any other languages. If I had to
pick an “unreal” language it would have to be: IBM PC rom basic... yuk!
From: Walrus
Re: Develop,the Apple Tech. Journal
I’m not sure if you can get it thru APDA (but it is worth a try) but for sure you can
call the Apple Certified Developers number and get the first issue for free, which
includes a CD-ROM. And even if you miss the first couple of issues, never fear, for the
CD that comes with the magazine will include all the articles and source code from all
PREVIOUS issues! Or you could write to:
develop
P. O. Box 3725
San Diego, CA 92025
The first issue is OK, and I’m sure it will get better, but I keep thinking that if they
want to have a first rate magazine, they would do well to emulate MacTutor, adding
some Inside Apple stuff that MacTutor would not necessarily have. They could also have
some of their people that do the Tech Notes work on it. If I were to ever take a job in
technical writing, that’s the group I’d want to work in, good information AND good
writing.
But I digress. Anyway, that’s the info for Apple’s foray into magazine publishing....
From: Walrus
Re: Jasik’s Annual MacTutor Article
I’m not necessarily asking any questions or preaching but I do have a few observations
on Steve Jasik’s “Marketing Mac Tools” article in the 3/90 edition of MacTutor.
He notes the tough job that any developer of Mac programming tools will have in
developing a product and points out that Symantec’s Mac programming tools barely
turn a profit. Actually I’m surprised and not surprised. If Symantec is doing that bad
than how do the other language vendors do it? The major reason for this is
A) the number of installed Macs and
B) the fact that working on the Mac is “hard”.
As for option B, OOP probably won’t help much because there is a learning curve in
object-oriented concepts for procedure-oriented programmers, and although it is
interesting and mind-expanding, it is like going back to school. But the real problem
with the Mac tool developer is the relatively low installed base of Macintoshes. Apple’s
new 1-year warranty and price reduction in the SE line should help, but the time is
getting late. A friend of mine bought an MS-DOZE machine because of warranty and
price. Apple still has to learn that they MUST suck in the beginning user, get them
addicted to the narcotic known as the Macintosh User Interface and they will have a
convert for life, buying Mac software and that X percent of computer users who are
programmers will buy languages, debuggers, etc. The solution? DROP THE PRICE OF
THE MAC PLUS TO A POINT THAT IT CAN COMPETE WITH THE CLONES!
On a related point in Steve’s article, he said APDA loses money, and I’m sure APDA
would like everyone to think so, but I think we’re dealing with one of those accounting
tricks. They offer no discounts on other party products, and the in-house stuff ain’t no
bargain either. Apple may be figuring the cost of the development of alot of the
products put out by APDA into the profits from APDA. The problem with that view is
that Apple would probably be developing much of it anyway for their own consumption,
in which case it would be figured as part of the cost of doing business. For instance, is
the development and maintenance of MPW charged against APDA? In that case, I’m not
surprised that it operates at a loss, that’s a big product and it’s complicated.
Of course, one way to help fix this is to create more members of APDA by converting
the MS-DOS users.
From: Atom
Re: Jasik’s article (cont)
Unfortunately, lots of users reared on MS-DOZE won’t even consider a Macintosh, not
because of the old prejudice against GUIs but because of the Mac’s well- deserved
reputation for frequent crashes. Until the Mac OS is a lot more robust than it is now
you won’t see DOS users coming over in droves, even if Apple decides to undersell the
Clones. (I know, that’s a pipe dream!)
From: Lbp
Re: Detecting MultiFinder Article
In reference to the TechNote article, Vol. 6 no. 3, “Detecting MultiFinder”. This
method is not correct as per Apple tech note #205. It states that in systems later than
6.0 _WaitNextEvent is available including notification if the cursor location is outside
a specified region. Therefore the specified test will not work. What we have tried and
seems to work is testing the Multifinder memory trap against the unimplemented trap.
In our tests this trap #8F is only available when Multifinder is running.
From: Jmoreno
Re: Detecting MultiFinder Article
I use the toolbox call PBGetCatInfo on MultiFinder in the current system folder. It will
tell you if the file is currently open. Just what you need. i.e. set the current WD to the
Referenced by (2):