[comp.sys.mac.programmer] 32-bit OS

tim@hoptoad.uucp (Tim Maroney) (08/22/89)

In article <1989Aug19.221033.2241@geology.wisc.edu> jct@paz.UUCP (John C.
Terranova) writes:
>Looks to me like it is time for rowBytes to be a 32 bit LongInt.

That's for sure!  *Everything* should be a longword, in fact.  For most
real applications, 32 bits is the same as unlimited, while 16 bits is
equivalent to a limit you will meet very quickly.  The use of 16-bit
integers throughout the MacOS is one of the most pervasive design flaws
in the system.  Yes, yes, I know all about data bus sizes and
efficiency, but efficiency takes second rank behind *possibility*.
It's better to be able to do a wide range of things with a slight
performance penalty than to do a narrow range of things a bit faster.

Want to display a bitmap or picture with more than 32,767 pixels in a
scrolling window?  Better write your own scroll bar CDEF then, and set
up your own versions of the value etc. routines, because the Control
Manager can't imagine you would ever want a 32-bit control.  Same goes
for text -- want to display more than 32,767 lines in a scrolling text
document?  Don't look to the OS for help, except for drawing the
characters!

Admittedly, there are not all that many two megabyte text files running
around, though this is not out of the question for a book.  However,
graphics files (especially TIFF files) with that many pixels resulting
from multiple pages are not at all uncommon.  I don't believe that it
would really have hurt the user-visible performance of the Control
Manager to use 32-bit values, and just as with TextEdit, this stupid
limitation makes me wonder if the writers really expected the Control
Manager to be used anywhere but inside dialogs.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"Do what you wanna, do what you will;
 Just don't mess up your neighbor's thrill.
 And when you pay the bill, kindly leave a little tip
 To help the next poor sucker on his one-way trip."
    - Frank Zappa, "You Are What You Is"

keith@Apple.COM (Keith Rollin) (08/22/89)

In article <8352@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>
>Want to display a bitmap or picture with more than 32,767 pixels in a
>scrolling window?  Better write your own scroll bar CDEF then, and set
>up your own versions of the value etc. routines, because the Control
>Manager can't imagine you would ever want a 32-bit control.  Same goes
>for text -- want to display more than 32,767 lines in a scrolling text
>document?  Don't look to the OS for help, except for drawing the
>characters!

Sounds like a job for MacApp! MacApp allows views to have 32-bit coordinates.
Granted that there are some limitations to this imposed by QuickDraw and
TextEdit (ie, you can't draw a line or square that's larger than 16-bits on
a side, or have longer TextEdit views), but this hasn't shown itself to be a
problem yet.

Also, scrollbars have been hacked to support 32-bit values in MacApp. The
technique it uses can be used in any application.

------------------------------------------------------------------------------
Keith Rollin  ---  Apple Computer, Inc.  ---  Developer Technical Support
INTERNET: keith@apple.com
    UUCP: {decwrl, hoptoad, nsc, sun, amdahl}!apple!keith
"Argue for your Apple, and sure enough, it's yours" - Keith Rollin, Contusions

tim@hoptoad.uucp (Tim Maroney) (08/23/89)

In article <8352@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>Want to display a bitmap or picture with more than 32,767 pixels in a
>scrolling window?  Better write your own scroll bar CDEF then, and set
>up your own versions of the value etc. routines, because the Control
>Manager can't imagine you would ever want a 32-bit control.  Same goes
>for text -- want to display more than 32,767 lines in a scrolling text
>document?  Don't look to the OS for help, except for drawing the
>characters!

In article <34184@apple.Apple.COM> keith@Apple.COM (Keith Rollin) writes:
>Sounds like a job for MacApp! MacApp allows views to have 32-bit coordinates.
>Granted that there are some limitations to this imposed by QuickDraw and
>TextEdit (ie, you can't draw a line or square that's larger than 16-bits on
>a side, or have longer TextEdit views), but this hasn't shown itself to be a
>problem yet.

You must not have done any TIFF document views in MacApp yet.  The Quickdraw
16-bit plane is a nontrivial problem when displaying multi-page documents.

>Also, scrollbars have been hacked to support 32-bit values in MacApp. The
>technique it uses can be used in any application.

I'm very happy for you.  Too bad you haven't chosen to share the
technique with us.  Or do you really think that people are going to
shell out a hundred bucks (plus extra for some apparently neccessary
add-ons) for code they can't even use directly, but have to cannibalize
and port?  And port not only across language lines, but from an object
oriented language to a HLL?  It's really no wonder that MacApp hasn't
caught on -- few of us have any interest in buying a pig in a poke
when just the poke is already too big for our sties....
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"Americans will buy anything, as long as it doesn't cross the thin line
 between cute and demonic." -- Ian Shoales

peirce@claris.com (Michael Peirce) (08/23/89)

In article <8365@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>In article <8352@hoptoad.uucp> tim@hoptoad.UUCP (Tim Maroney) writes:
>                     ... It's really no wonder that MacApp hasn't
>caught on -- few of us have any interest in buying a pig in a poke
>when just the poke is already too big for our sties....
>-- 
>Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com
>

But, but, but..  MacApp *is* catching on.  Look around.  There are lots
of NEW software projects using MacApp (people revving old stuff doesn't
count). 

My personal opinion (not worth much, I'm sure), is that I wouldn't start
a work on a new project NOT using MacApp.

Claris Corp. | Michael R. Peirce
-------------+--------------------------------------
             | 5201 Patrick Henry Drive MS-C4
             | Box 58168
             | Santa Clara, CA 95051-8168
             | (408) 987-7319
             | AppleLink: peirce1
             | Internet:  peirce@claris.com
             | uucp:      {ames,decwrl,apple,sun}!claris!peirce