heebiejeebies
Well-known member
I know who he is... If it's that great, I expect him to still use it every day.
Cost, essentially.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?
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.If it's that great, I expect him to still use it every day.
Fair enough if that's what he meant, but it's not what he said. :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.
Hyeah, I'll take Don Knuth's opinion over yours any day of the week and twice on Sundays.HyperCard / It's the only thing I can program in
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.)Someone on here will now compile this for OSX. That's a direct order.
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...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).
;-----------------------------------------------
;
; 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
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 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).
Monkey. The DA for it is in Vault: http://macgui.com/downloads/?file_id=134452. Are there any hidden, unactivated, or otherwise experimental features lurking in this code?