Usually when we talk about retrocomputing, we want to look at — and in — some old hardware. But [Z→Z] has a different approach: dissecting MacPaint, the Apple drawing program from the 1980s.
While the program looks antiquated by today’s standards, it was pretty hot stuff back in the day. Things we take for granted today were big deals at the time. For example, being able to erase a part of something you drew prompted applause at an early public demo.
We enjoyed the way the program was tested, too. A software “monkey” was made to type keys, move things, and click menus randomly. The teardown continues with a look inside the Pascal and assembly code with interesting algorithms like how the code would fill an area with color.
The program has been called “beautifully organized,” and [Z→Z] examines that assertion. Maybe the brilliance of it has been overstated, but it did work and it did influence many computer graphics programs over the years.
We love digging through old source code. Even old games. If you do your own teardowns, be sure to send us a tip.
“A software “monkey” was made to type keys, move things, and click menus randomly.”
I have no clue what a software monkey is, even if you put it in quotation marks.
Your name checks out… Try this: open article, CTRL+F “monkey”, read -> done.
I can programme FPGAs and design circuits, nothing wrong w my username. It’s just some of us HaD readers are not Americans. Your explanation makes zero sense, thanks for nothing.
As a native born American English speaker the term is a mystery to me too. It is NOT obvious, so F that S PBR! I was visualizing something with stepper motors.
My explanation makes perfect sense as it describes exactly how you find out what “software monkey” means :) After reading those few lines it was very obvious, what that “monkey” was: some script/code that pressed random key strokes and caused actions to test the program.
Btw, I’m on the other side of the tariffs, too. You beat me at programming FPGA’s but I can do some basic search & read operations :)
That’s not an explanation, it’s a reference.
@Dude thanks Dude!
Comment dit-on “un petit peu bitchy”? And what the farming heck is up with HaD writers having some tribal taboo against explaining terms? Jenny List in her article today, explained in the first paragraph what “focal length” means. Brava!
The term “monkey” is probably a reference to the infinite monkey theorem, which would make it a fitting title for a program that generates random input on a computer.
https://en.wikipedia.org/wiki/Infinite_monkey_theorem
From the description, it’s obviously a GUI fuzzer.
And a “GUI fuzzer” is obviously a type of turboencabulator.
From the linked article:
I might still have a copy of that on my archive discs.
Wow. Hackaday readership has really gone downhill. No-one seems to have the capacity to imagine what a software monkey might be, even when given some clues.
Never mind. This article is not for you.
Hi, the blog acknowledges PCPaint and Paintbrush. Thumbs up!
GEM Paint could be seen as historically relevant, too.
It’s quite similar in appearance to MacPaint, too.
The Apple IIGS paint program Paintworks Plus, as well.
GEOS on home computers had geoPaint, which looked a bit differently.
Just like how DR. HALO looked similar, but different.
Black background and its menu system didn’t use ordinary pull-down menus.
Hi-Res Rainbow (’86) had similar look to DR. HALO, I think.
In the 80’s I lived in Palo Alto and worked for Raskin. A lot of this was talked about from time to time. We were working on a totally different idea of his, a text system with no mouse or GUI. But the screen rendering of text did make these subjects come up.
I recall one feature of MacPaint that set it apart or was advantageous. However I can’t remember exactly how it went, but it was related to the choice of coordinate systems. IIRC it was defining coordinates to be the center of the intersections between pixels and not the center of a pixel. Many people had designed using pixel centers and maybe one was Microsoft? Again if I recall, that pixel centered view made everything difficult and rather cheesy looking.
Maybe Bill will read this and pipe up :-)
As I recall, pixels hung down and to the right of the actual coordinates. The whole QuickDraw system was written this way. Except in a few circumstances, it made things easier for graphics programming.
Why would that make any difference whatsoever? Aren’t you still addressing whole pixels regardless of whether you count the grid or the center?
If you use center pixel coords, a coordinate line is splitting the pixels. I don’t recall why it helps. Maybe the lines use Bresenham and the algorithm is easier or infills are easier? By 1989 it was Color Quickdraw and everything was anti-aliased. I was the “code checker” for the first issue of “develope” and that was the topic. I recall some detailed material about this. (develope was the new Apple Developer Journal. Yes, lower case ‘d’. The office space was grouped with Apple DTS for Apple II and Macintosh. I sat in on the morning bug reports and developer issues. This was when the massively documented “Macintosh Programmers Workshop” was the thing.)
The whole point is that you aren’t addressing pixels, but rather virtual points. For example, you can draw a blue box from (0,0) to (10, 10), and a red box from (0, 10) to (15, 15) easily, with perfect registration. Assuming (0,0) is top left, the blue pixels will be above Y coord 10, and the red will be below. They will not share any pixels. You can erase the red box without needing to refresh the blue one. A one-pixel-wide horizontal line would be treated as a skinny box, such as (0,0) to (10, 1). It especially helps with diagonal lines. Two abutting triangles can share an edge without any unwanted overlaps; [(0, 0) (10, 0) (0, 7)] and [(10, 0) (0, 7) (10, 10)] still have completely distinct sets of pixels. With pixel addressing you’d be stuck trying something like (10,0) – (0, 7) and (10, 1) – (0, 8) for the shared edge, leaving gaps and overlaps.
Yes, that is what I was thinking. DO you know of any who did not do it this way? I recall derision of MS over this but was never a MS user and don’t know how they did it.
I remember this not being consistent between Windows 95 and NT on one hand, and Windows CE on the other. From memory, 95 and NT treat the bottom and right-hand coordinates of a rectangle as exclusive (the last pixel painted is immediately above the bottom coordinate and immediately left of the right-hand). However, CE treated it inclusive, and did paint the right and bottom edges. This was frustrating when trying to share code across both platforms!
The online Windows CE documentation says the same as the Windows 11 documentation, but I don’t think it was ever changed: the documentation is incorrect.
But that’s describing vector graphics instead of bitmap graphics. I thought MacPaint was a bitmap editor where all draw operations end up as pixels, not abstract points.
Yes, but it has infill and geometric shapes. The point about adjacent rectangle I think illustrates it well. To describe them in a pixel centered world you need to use less than or equal on the left and greater than on the right, or vice-versa with rules about where and how to apply this. In the coordinates are between pixels world it is always the same everywhere, less than and greater than.
Now for my theory of the brontosaurus…
ahh. Bill Atkinson. a genius. you should also check out his other gem: hypercard. unfortunately never ported to color quickdraw.
MacPaint was fantastic, but SuperPaint was even better – mixed raster and vector graphics… amazing.
Who can make petition to move to open source , free OS system 1 or 7
many languages never been in os 6, network etc.
Please make this,
Hi, have a look at https://www.change.org/
But to be honest, it’s pretty naive to believe this to be really happen.
The code of classic “System” (Mac OS) had been in Mac OS 9.2, still.
Then there’s Carbon API, which implements a sub set of m86k Mac OS..
System 1 to 7 seem old, but are not suddenly worthless because of this.
They may still contain bits of protected material from various companies.
Material that Apple perhaps can’t make free, because perhaps its not theirs.
Then there are softw. pat*nts, etc. They can’t be ignored, either.
The GUI of Mac OS is basically same for ages, so it makes sense to not let it go.
Even Lisa OS, which is older, is still of relevance here, likely.
Best that could become somehow “open” (under MIT style license but surely not GPL) is an very early version.
Say, a beta or prototype version. That can’t run much software, though.
Chances that Apple will make System 6/7 open source
are as high as Microsoft doing same with WfW 3.11/Windows 95.
That’s why retro communities do rather write their own versions of older OSes.
GEM and TOS have gotten free implementations, Amiga OS too.
DOS and CP/M had various implementations, too.
Many companies wrote their own versions in the past that are binary compatible with the originals.