Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!news.funet.fi!funic!nntp.hut.fi!hila.hut.fi!jmunkki
From: jmunkki@hila.hut.fi (Juri Munkki)
Newsgroups: comp.sys.mac.system
Subject: Re: MaxAppleZoom
Message-ID: <1991Jun11.234006.12996@nntp.hut.fi>
Date: 11 Jun 91 23:40:06 GMT
References: <1991Jun8.025731.7019@dhw68k.cts.com>
Sender: usenet@nntp.hut.fi (Usenet pseudouser id)
Reply-To: jmunkki@hila.hut.fi (Juri Munkki)
Organization: Helsinki University of Technology, FINLAND
Lines: 68
Nntp-Posting-Host: hila.hut.fi

In article <1991Jun8.025731.7019@dhw68k.cts.com> emmayche@dhw68k.cts.com (Mark Hartman) writes:
>Has anyone seen a copy of MaxAppleZoom that works properly with System 7?
>
>I have version 1.3, which works fine with System 6.0.7, but when switching
>monitor depths in System 7, the system seems to forget that it has a larger
>monitor.  I expect this is because of unanticipated differences between
>6 and 7.

It seems that MaxAppleZoom behavior varies a lot and the variations are quite
random. When I first upgraded to System 7.0, I used MaxAppleZoom 1.2. It worked
fine for a week and then it started complaining about the system version. I
upgraded to 1.3 and noticed that the narrow monochrome mode wouldn't switch
off.

After some work with ResEdit and a bunch of debuggers, I decided that
it would be quite hard to figure out what MaxAppleZoom really does.
Maybe I should have printed out the disassemblies, since I've always
had more success in understanding printed assembly language than that
displayed in a debugger window (easier to make notes that way).

I then noticed that if I had the monitor initially set to 256 colors,
I could use MaxAppleZoom even in B&W mode and the screen size was not
reduced. I quickly wrote an INIT to change the screen depth from 256
to 2 colors and everything was fine...

Yesterday my hard disk became unreadable when a program I was writing
and TMON Pro decided to rewrite the volume information block. I recovered
99.9% of the files (I think I lost 3 files or something like that) and
rebooted from the newly formatted hard disk.

Guess what? MaxAppleZoom now always compresses the 2-color screens no
matter what the initial screen depth is.

----- Techno-mumbo-jumbo follows:

Since I don't have a deep understanding of how MaxAppleZoom works, I
can't say anything definite. A good guess would be that MaxAppleZoom
is unable to read the configuration resource or it looses it somewhere
on the way.

I haven't paid the shareware fee, but I refuse to pay it for something
that doesn't work reliably and doesn't come with source code. If it came
with source code, I'd be willing to pay $25 for it. If it worked as
reliably as Compact Pro has, I'd be willing to pay for it (I have paid
the shareware fee for Compact Pro).

MaxAppleZoom is a weird piece of code...most of the functionality is
incorporated in an INIT resource called "showinit". The original showinit
code is only about 10% of that resource. Most of the code is dedicated
to making sure that the system is acceptable for MaxAppleZoom. Personally
I would rely more on the users ability to see if the INIT works and worry
less about compatibility. (That way I could still be using version 1.2,
although a quick look at 1.2 revealed that 1.3 is a major improvement
in code quality).

If we had source code, we could easily hunt out all the problems and
fix them. Without source code, it's like trying to read a bowl of
spaghetti. (I think MaxAppleZoom was written is assembly, since it
doesn't look like the output of any compiler that I have ever seen.
Neither would any compiler use supervisor-only instructions and there
was at least one in v 1.2)

Forgive me for the technical nature of this article...

   ____________________________________________________________________________
  / Juri Munkki	    /  Helsinki University of Technology   /  Wind  / Project /
 / jmunkki@hut.fi  /  Computing Center Macintosh Support  /  Surf  /  STORM  /
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~