From: mikeh@starnine.com (Mike Haas)
Subject: Re: More Amiga OS weaknesses and strengths
Date: Wed, 13 Jan 1993 06:07:14 GMT
Organization: StarNine Technologies, Inc.

In article <torrie.726629055@Xenon.Stanford.EDU> torrie@cs.stanford.edu (Evan Torrie) writes:
>mikeh@starnine.com (Mike Haas) writes:
>>>>
>>>>It happens on mine... to be specific, when I create an alias for an
>>>>application and move it to the desktop, double-clicking will (about
>>>>half the time) bring up a dialog box saying it can't find the
>>>>application!  I have to find the folder holding that app and open it!
>
>  I've never experienced this. Can you reproduce this?

On any of several machines.

>>to fix you).
>
>>But you were the one talking about how you could intermic graphics & text
>>in Apples simple little Teachtext app.  I just pointed out that
>>you were wrong.
>
>  Well, you can, but TeachText doesn't have an interface to do so.
>There are lots of TeachText files with graphics mixed with text.  They
>just have to be created in a separate app (the shareware Belgian Postcards).

Why that's a GREAT system utility.  You need "other applications" to create
something that TeachText can display!

And it's limited to 32K text!!!  Gettin' better all the time...

>
>>>>Open a mac window that has one icon way off screen.  You have to scroll
>>>>the window over there and drag it, scroll the window, drag it, scroll
>>>>the window... to get it to be next to the others.   That's cause the
>>>>"Cleanup Window" menu item only moves icons to the next "grid" spot,
>>>>unlike the WB "CleanUp", which re-arranges all icons to be as visible
>>>>as possible.
>
>  Try holding down the Option key when choosing Cleanup.  This is documented
>on the first screen of the online help.

Pretty Intuitive!  Lesseee.. the option key, eh?  That's opposed to
the Command key...and the SHIFT-command key... and the SHIFT-option
command key...

Great GUI.

>
>>Here's a mac example, Marc.  Open a small window, Open a big window.
>>Cover the small window with the big window so that it's completely
>>covered.
>
>>Now... there is no way on the mac to get at the small window without
>>either MOVING or CLOSING the big window... both of those operations
>>are "permanent" i.e. remembered by the mac until you change them again.
>
>  I see you're not using NextPrev, which lets you cycle through windows
>and applications with a Command-Tab keypress.

Buy the mac... buy all the 3rd party software to make it work something like
an Amiga...

Hat's off to whoever wrote NextPrev!!!  They too must understand
the crummy HI that is standard.

>
>
>>>   Have you tried loading an icon larger than 80x40 into IconEdit?  The icon
>>>gets truncated.  Commodore is trying to enforce size limits, too.  Good idea,
>>>because the Amiga's rather large icons are the reasons that things like 
>>>automatic feedback during drag&drop can't work very well.  
>
>>So?  There is still a range of sizess available... not just one like on the
>>inflexible macintosh.
>
>  Actually, cicns are not limited to 32x32.  It's just that the Finder only
>supports 32x32 icons.

Oh... that's OK then.  So where can I get a 3rd party Finder?


>
>>>>instead of fixing it, Apple released tech note #14 which lamely tries
>>>>to justify why it's OK for GetNewDialog() to NOT return an error
>>>>code!  (Basically sez if the user has mucked with a programs resources,
>>>>he DESERVES TO CRASH!)
>
>>But we're talking user-interface here, marc, and USER'S AREN'T SUPPOSED
>>TO MUCK WITH MAC RESOURCE FORKS.
>
>  What position are you trying to argue for?  You castigate Apple for
>their excuse in one sentence, and then seem to agree with
>their excuse in the next.

Not at all.  The original context of the 2 stements obviates the
difference.

>
>>  The fact that they can get themselves into
>>so much trouble doing it is a liability.
>
>  So, the Amiga handles users binary editing executable files, and
>deleting parts of the data?  That is the analogous situation to the use
>of ResEdit.

The two-fork mac files are the scourge of networking and interoperability
with standard systems.  They cause so much trouble when trying
to move data between platform it isn't funny.  Many companies
have to jump through hoops to get mail gateways and the like to TRY to work
around this wierdness, but there's always gotchas.


>
>>And just think about the implications of Apples engineering fiasco of
>>GetNewDialog().  It means that ANYTIME A MAC APPLICATION OPENS A DIALOG,
>>IT MIGHT CRASH AND THE APPLICATION CAN'T DO A THING ABOUT IT.
>
>  Yes, the application can do a thing about it.  Read the Tech Note.
>If you're really worried about your app crashing when some user
>has hacked out part of your program, then you can use GetResource
>to check whether the dialog is there before displaying it. 

That won't help if the resource is corrupt.

So, as I've said before, you can't use the mac system calls simply.
To use GetNewDialog(), you need to check beforehand that the required
DITL and DLOG (and any other supporting resources like ICONs, ICN#s,
STR#'s etc...) are all available and valid.

Like OpenDriver()... you can't just call it... you have to find an
open driver slot to load it into.  Despite the fact that DRVR's have a
slot ID associated with it... the problem is, LoadDriver() will load it
into the slot ID it sez it wants, EVEN OVER AN ALREADY INSTALLED AND
OPENED (read: in use) driver in that slot (causing, of course,
a crash).

I've had MacWrites spell checking driver (WHY they need a driver for that?)
load in, replacing an OSI network driver, and all of a sudden, the
OSI protocol stack was making calls to MacWrites Spell Checker!!!

Probably some programmer made the assumption that LoadDriver() was
system software and therefore could be used like the book sez (NOTE:
the book desn't say ANYTHING about this).  Silly guy.


Newsgroups: comp.sys.amiga.advocacy