Macpaint and quickdraw source code posted

[heebiejeebies]

I know who he is... If it's that great, I expect him to still use it every day.

 

[Mouse]

I never understand companies that are so reluctant to release source code for software/OS that haven't been used in a significant number of production systems for quite some time. What compelling reason could they have for not releasing it?

Cost, essentially.

If the code for a project is fully owned by Apple, for example, then even slapping on a small disclaimer like "this is for noncommercial educational use only" etc requires a few levels of internal authorisation and their own legal dept, as we've seen. For a project that's coming up to 30 years old, to even get to the state of knowing the code was entirely in-house may require digging through documentation - not all of which may exist by now - and validating that legal rights to the code do indeed lie with the company as it is today, and that's before checking that there aren't other issues with code release like trade secrets, in-house wilful copyright violations of competitors, or other illegal code. Who in a company really remembers precisely which code is unlawfully involved in making competitor's products look bad, if that were ever implemented in just a tiny fraction of coding projects?

For flagship products where the history is interesting in itself, like macpaint, that may be relatively simple and only require a small amount of digging. For the tens of thousands of jobs spanning five decades like Apple have, that could get really tedious really quickly.

 

[Mac128]

If it's that great, I expect him to still use it every day.

Perhaps he does, I find it just as productive for some things as the latest graphics software. Nevertheless your reply holds him literally to the original MacPaint program released on January 26, 1984.

A more reasonable interpretation is that he is referring to the concept of the software and the most current successors of it, regardless if it is a direct descendent, or another company's who built their code from the ground up, but still utilizes all the fundamental principles originally first introduced in MacPaint. Sure, newer programs are loaded with bells and whistles the original didn't have, but aside from that, has anything been written for the computer that is as revolutionary? Not yet as far as I can tell. We're still pretty much using the computer exactly the same way we were in 1984, just faster, slicker and more flavors of the same idea. I think iOS may open new avenues for revolutions in how we use the computer as groundbreaking as the GUI and MacPaint did, but only time will tell.

 

[Scott Baret]

Some folks still do use older software if they consider it to be "the best". I remember a few years back someone reported Bill Atkinson still used HyperCard (it may have been MacWorld, but I'm not certain of the source). Interestingly, WordPerfect 5.1 for DOS is still in demand. Check the prices on eBay. (I know law offices used to love WordPerfect since it was easier to format documents properly, not sure if there are still some who have been reluctant to upgrade and I know there was a project not too long ago where drivers were being developed for newer printers so they could be used with 5.1).

Personally, I still use BannerMania because I feel it is top-notch, especially since it takes full advantage of the ImageWriter II's color printing capabilities and the output looks great. Anyone else out there still make dot matrix banners?

A better question--how many of you get called to produce banners for friends since you're the only one they know with a dot matrix printer?

 

[heebiejeebies]

A more reasonable interpretation is that he is referring to the concept of the software and the most current successors of it, regardless if it is a direct descendent, or another company's who built their code from the ground up, but still utilizes all the fundamental principles originally first introduced in MacPaint.

Fair enough if that's what he meant, but it's not what he said. :

I actually still use HyperCard sometimes too. ;D It's the only thing I can program in, and heck, it does nearly everything I need anyway. I actually wouldn't have objected if Knuth had said it was the best programme ever, since there's not much else that does what it does.

 

[Bunsen]

HyperCard / It's the only thing I can program in

Hyeah, I'll take Don Knuth's opinion over yours any day of the week and twice on Sundays.

 

[Gorgonops]

Someone on here will now compile this for OSX. That's a direct order.

Compiling this code for anything but a 68k Macintosh is a pretty tall order. Between Quickdraw and MacPaint over half of it is dense 68000 assembly language, and both the assembly and Pascal code makes raw calls to parts of the Mac OS and ROM APIs that we *don't* have the source code for. Porting this to a modern platform would mean translating all the assembly code to either x86 assembly or C (commercial tools exist to help with either, but the end result would need a lot of massaging to be at all useful), porting the archaic Pascal to something that works on a currently available compiler, fixing all the internal calls, and writing replacements for the Mac API elements not included. (Or patching the original code to use the modern OS's native API instead.)

On the bright side the assembly language seems to be pretty well commented. The Pascal... not so much.

 

[Scott Baret]

There are a few things I'd like to find out from this code:

1. Why does MacPaint malfunction on color monitors? Many other older programs (including MacWrite) work fine.

2. Are there any hidden, unactivated, or otherwise experimental features lurking in this code?

3. What exactly conflicts with OS 9 in MacPaint? (I tried running it on OS 9 once but to no avail).

4. With regards to QuickDraw, was there any foundation for color in the original programming? I remember reading somewhere about the classic Macs having colors built in somewhere despite not being able to show them on the screen natively (I know there were some color boards available for older Macs many moons ago, not sure if they relied on QuickDraw, the ROM, or something else).

5. That being said, how hard would it be to add color capabilities (at least the equivalent of a CGA monitor on an IBM) to MacPaint?

I still haven't gotten a chance to examine what's in here, but I'm not sure how much of it I'd really find useful. I took courses in BASIC, C++, and JAVA, plus I know HyperCard very well, but have never studied regular C (not sure how different it is from C++) and don't have a good grip at all on assembly language. (I do want to learn a bit more about this down the line, perhaps I'll study it a bit this fall in my spare time).

 

[Gorgonops]

4. With regards to QuickDraw, was there any foundation for color in the original programming? I remember reading somewhere about the classic Macs having colors built in somewhere despite not being able to show them on the screen natively (I know there were some color boards available for older Macs many moons ago, not sure if they relied on QuickDraw, the ROM, or something else).

I remember reading on folklore.org that the original Macs supported "spot color" in some fashion in order to run the color Imagewriter, but undoubtedly someone else knows far more about that. Let's see... Here's a link to an InfoWorld review of a color board for the Macintosh SE. It mentions that it works with "... some programs that use Color Quickdraw, provided they support the Imagewriter in eight colors...

A quick grep of the code shows definition blocks like this:

;-----------------------------------------------
;
;  QuickDraw Color Separation:
;
normalBit       .EQU    0                       ;normal screen mapping
inverseBit      .EQU    1                       ;inverse screen mapping
redBit          .EQU    4                       ;RGB additive mapping
greenBit        .EQU    3                       ;for photos from screen
blueBit         .EQU    2
cyanBit         .EQU    8                       ;CMYBk subtractive mapping
magentaBit      .EQU    7                       ;for ink jet printer
yellowBit       .EQU    6
blackBit        .EQU    5

That looks suspiciously like "eight Imagewriter colors". So it doesn't really look like there's inherent general-case "arbitrary depth" RGB color support.

I still haven't gotten a chance to examine what's in here, but I'm not sure how much of it I'd really find useful. I took courses in BASIC, C++, and JAVA, plus I know HyperCard very well, but have never studied regular C (not sure how different it is from C++) and don't have a good grip at all on assembly language. (I do want to learn a bit more about this down the line, perhaps I'll study it a bit this fall in my spare time).

None of it is in C, actually. The assembly language is very well documented, so even if you don't do assembly at all you can pretty much grasp what an individual function is doing. (Where it gets hard is there are a *lot* of variables and constants to keep track of, many of which appear to be globals. So tracking the code path across modules rapidly turns my brain into mush.) As for the MacPaint code I've never written Pascal but it "reads" fairly easily. Again, the issue is that there really isn't that much done inside the main program itself. It's essentially a huge collection of calls to EXTERNAL functions and API hooks, so to understand it you'll have to backtrace everything through the referenced assembly code or the "Inside Macintosh" API reference.

I'll admit I have a terrible time following other people's code once it grows beyond a certain size. If you don't suffer that limitation it should be less daunting than I'm finding it.

 

[Dog Cow]

2. Are there any hidden, unactivated, or otherwise experimental features lurking in this code?

Monkey. The DA for it is in Vault: http://macgui.com/downloads/?file_id=13445