Photoshop 1.0 Source Code | Hacker News Reader

Photoshop 1.0 Source Code

computerhistory.org

192 pointsConstantineXVI78 comments

Github repo/mirror of source code, for those so inclined:

The site is down, but I mirrored the source code here: http://cl.ly/061Z0b463V2f

(license: https://gist.github.com/micheljansen/4949042)

The article (cache: http://webcache.googleusercontent.com/search?hl=en&clien...) also has some cool screenshots of early Photoshop :)

Could someone with an appropriate background analyze the license in-depth?

Looks like it allows you to produce derivative products, which is great, however, it also forbids commercial use, meaning it's at least not at the same level as FSF- and OSI-approved licenses.

IMHO, the license is pretty clear that you can't even post the source on GitHub.

Yeah, that and the the "It may not be distributed to third parties" bit at the top of each file.

What really blows me away is how comparatively little the interface has changed over the years...not to sound dense, but it looks exactly like you'd expect Photoshop to look.

Much of Photoshop's interface came from Apple's own MacPaint which shipped at the launch of Macintosh:

https://en.wikipedia.org/wiki/File:MacpaintWP.png

http://www.folklore.org/StoryView.py?project=Macintosh&s...

Coincidentally, the CHM has MacPaint's source[0] as well.

(I've honestly not heard much about CHM before. Making sure to find my way there next time I manage to end up in the Bay Area)

[0] http://www.computerhistory.org/atchm/macpaint-and-quickdraw-...

Some might say this is precisely why Photoshop is better than The Gimp.

Why would they say that? GIMP hasn't changed much, aside from adding a single window as an option recently.

This is a pretty good look at how litte the Photoshop interface has changed over the years. http://ipod-touch-max.ru/wp-content/uploads/2010/02/27721.jp...

The first version of Photoshop was written in Pascal?!?

Pascal was the Mac OS programming language. The API had data types Str255 (Pascal string, maximum 255 character, in a 256-byte memory block), Str15 (same, max 15 characters, in a 16 byte block) and the like, and many of the higher-level calls used Pascl calling conventions (lower-level calls used a mish-mash of conventions for speed. For example, low-level file calls used a register to pass pointers to parameter blocks.

In the rather unlikely case you want to know, read http://filibeto.org/unix/macos/lib/dev/documentation/Carbon/..., which details how you (sort of) transparently could call 68K code from PPC code and vice versa.

The section "Special Case Calling Conventions" lists all special cases. You get such cases as "Parameters are passed to the routine in registers A3 and D7, and output is returned in registers D2, D3, and D4".

Amazingly this looks a lot like Borland's Turbo Pascal (later Borland Pascal, later Borland Delphi, then Embaradero something), which had lots of OO extensions over the years, designed by Andreas Hejlsberg (who went on to make C#).

In the golden age of Delphi, the language was pretty on par with today's Objective-C: Classes, late binding, properties, reference counting, modern strings, etc.

I wonder how much influence there was between the two.

Turbo Pascal 5.5 objects were based in Object Pascal done by Apple.

Makes sense. As far as I can see, it was not directly copied from the Mac dialect; there are some differences, like how the Mac code requires methods in the declaration to be declared fully qualified with the full class name ("PROCEDURE TEraseAll.IEraseAll (view: TImageView);").

Not to be pedantic, but because I think it's interesting:

The Lisa's OS was written in Pascal.

http://www.cs.oberlin.edu/~jwalker/lisa-legacy/

"The majority of Lisa programs were written in the Pascal language by Apple with a few programs written in 68000 assembly language. To give an idea of the size of this effort the Lisa operating system was written in around 90,000 lines of Pascal and each Lisa program (eg LisaWrite) contained somewhere around 50,000 lines each."

http://en.wikipedia.org/wiki/Pascal_(programming_language)#H...

Like others in this thread, I learned Pascal early on and was befuddled by C for a long time. I wrote some Pascal on my Apple //e, played with Lisa (had access thru work), completely missed the Mac boat, cut my teeth on TurboPascal. Gods, I loved Borland.

Mac programming in that era was a mix of assembly and Pascal.

As other's note: Assembly and Pascal were the original system languages for the Macintosh. As I recall, C was not used until a year or two after the launch of the Mac when Lightspeed C was released. (Lightspeed was later renamed Think C)

Apple did not use C heavily until the OS was re-written in C++ in System 7 in 1991

Which spawned Apple's MPW IDE and their MacApp C++ framework, which ultimately gave way to Metrowerks CodeWarrior and the PowerPlant C++ framework. It's actually pretty amazing that for most of the 90s Apple let Metrowerks own the developer experience.

I always thought that Jobs' greatest triumph in pushing Rhapsody was bringing their developers back to using their own tools (though I suppose Carbon could be considered a short term loss).

You can get lots of nice information about it here,

Revolution in The Valley http://shop.oreilly.com/product/9780596007195.do

C only took over because of UNIX.

Not only that, but an OOP version of Pascal created by Apple with input from Niklaus Wirth.

I love Pascal. Clean, concise, rigid, fast. Haven't touched it in 10 years though.

Turbo Pascal 3.0 was my first serious programming language (after Apple ][ Basic). 30kb of editor/compiler in one package.

Then used Turbo/Borland Pascal 5.0/5.5 for quite a while, a bit of 6.01, short Delphi, and by that time already moved to C/C++

I moved of a reasonably stupid thing. The MoveFile() function exposed in Borland Pascal was not able to move files between folders. Although I knew some assembly, and Ralph Brown Interrupt List was the greatest thing ever, I did not consider rewriting routines in it (For some reason I was thinking - this language supports this, and this one that... much later I realized - these were just libraries, even if they were builtin ones - CRT). But for that reason I moved to C/C++ - because it had the function... lol.

I loved how .TPU/.DPU files worked, much more efficient than headers.

It is really sad that C eventually took over.

Now we need to force everyone to move to safer languages.

One thing I like in C++ over C, is that the language + libraries gives me enough freedom to achieve a Pascal like programming safety, thanks to references, STL and stronger type checking than C.

You might want to have a look at what Wirth designed afterwards.

I specially like the Native Oberon and Active Oberon operating systems.

Yes, regardless of what C preachers like to spread, Pascal is also good for application development.

Although the original version lacked a few features, most dialects had them. Turbo Pascal and Mac Pascal were considered the dialects to achieve compatibility with.

Eventually in 1990 there was a revised version of the standard, Extended Pascal which contained such features. However by then the Pascal world searched for Turbo Pascal compatibility on most compilers.

Any hope of being able to compile this on a modern system? I wonder what it would take...

Likely rewriting the assembly sections.

The Pascal parts ought work, if you have a compiler for the same pascal dialect.

You'd also need the MacApp framework, which I don't think was ever ported to OSX.

Well I'll be damned; after some more research, it looks like it WAS ported (unofficially) to OSX. That said, I'm not sure it works with the original language anymore.

there are some Mac OS 8 and 9 images around; probably you'd have more luck trying to compile it under a VM booting one of those

100,000 lines. Wonder what it would take to crowd source a port? Best "modern" language? Java? Javascript? Go?

Why would you need to port it to anything? Pascal is still a useful language.

Even if the core logic were left in Pascal, the assembly language would need porting to x86/x86_64 and the GUI code would need to be ported to a modern GUI library.

It would attract a wider range of developers. The idea is to crowd source the task.

Think the main challenge would be writing a compatibility layer for the Mac OS APIs circa 1990. It might not be so hard to compile the Pascal source.

Edit: Maybe it could be built as a 32 bit Carbon app for OS X with some modifications. That's all a little before my time, so I'm not sure how much was changed by the time OS X came around.

What would the motivation be for doing this? If for anything other than historical interest, is there anything a 23 year old version of Photoshop has over GIMP?

The license prohibits any sort of redistribution. It's valid for personal use, research, and study only.

As usual, Adobe doesn't "get it".

Doesn't get what? There a billion dollar company. Unlike some other of companies that "got it" (OSS) that have perished.

My implication was that if you're going to share source code, share it in a useful way.

This particular source code is from an extremely old version of Photoshop, there would be no potential commercial harm whatsoever from allowing people to reuse this source code however they want.

I could have lived with the "no commercial use" restriction that's typically used, but to not have a right to redistribute at all severely restricts its utility.

Given that the commercial value of this particular source code drop is effectively zero, I fail to see what Adobe being a billion dollar company has to do with anything. Nor do I see what this has to do with the "OSS" movement of "Free Software" in general, neither of which were mentioned in my original post.

This was provided to a museum for historical purposes. It could also be useful for other research or educational purposes potentially. And one day the copyright will expire.

Except lack of redistribution rights also complicates research and academic study since technically you can't even share any derivative work among colleagues.

Copyrights that may expire long after my death also don't seem like something I should be grateful for.

>This particular source code is from an extremely old version of Photoshop, there would be no potential commercial harm whatsoever from allowing people to reuse this source code however they want.

It's not that easy I guess. Even Photoshop 1 has tons of patents in it's algorithms.

Photoshop 1 is old enough that any such patents should have expired.

If that is true you could reimplement Photoshop 1.0 with the clean room method [1] and have a perfectly legal clone, which you would then be free to expand.

[1] https://en.wikipedia.org/wiki/Clean_room_design

Does Photoshop 1.0 have significant features that are missing in Gimp?

> I could have lived with the "no commercial use" restriction that's typically used, but to not have a right to redistribute at all severely restricts its utility.

As long the web site stays up, everyone is free to go there and download it for himself/herself.

It means that something like the excellent annotated source reviews by Fabien Sanglard of Quake[1], Quake2[2], Q3[3], etc.. aren't possible.

Nor any ports to attempt ot make it compileable/runnable.

Code isn't supposed to be hung on a wall. If you can't even collaborate to make it work again, it does lose a lot, and waiting ~95 years isn't really a practical alternative.

Will the website stay up that long? Is archive.org allowed to preserve it?

[1] http://fabiensanglard.net/quakeSource/index.php

[2] http://fabiensanglard.net/quake2/index.php

[3] http://fabiensanglard.net/quake3/index.php

You could always make references to the original code.

"There" a billion dollar company alright. "There" are also many companies that embraced OSS and realized it was profitable as well.

Few and far between. Actually only one that makes any big money: IBM, and they sell services on top of OSS as they did on top of proprietary stuff. Nothing very OSS about them.

On the other side, the road is paved with failed OSS companies that were praised as "really getting it", starting with the archetypal one: VA Linux.

(btw, is my typo that amusing to you? Wait till you find out about cat videos then...)

Pascal is modern.

At an older company that ran (old) Pascal code in production systems, the race was on to find a supported pascal compiler nowadays.

But that's not possible, so the port to C had been started.

(Oh but Delphi - this systems are not Windows)

What about FreePascal?

I do recognize that Pascal sadly was never strong on UNIX/Mainframe systems, which I imagine is your case.

My move from Turbo Pascal/Delphi to C and C++ happened around the time I needed to target UNIX systems. Given the choice I always take C++ over C, because I can achieve a Pascal like safety.

But I do miss coding Delphi.

If Sun hadn't pushed Java so hard and Borland didn't went schizophrenic with what to do with their products, Delphi would probably still be quite strong nowadays.

Still the best way to code native applications on Windows though.

The key is 'supported'. As in "we are willing to pay money to have someone fix if this breaks"

Not sure they looked into FreePascal (and it is a couple of years already)

About C vs C++, I agree

> The key is 'supported'. As in "we are willing to pay money to have someone fix if this breaks"

Fair enough. Thanks for pointing it out.

Surely you have no idea what you're talking about. Pascal is modern, perhaps you are the one that's not up to date. Java? Err.. assuming everybody has a lot of RAM, maybe. JavaScript? Forget about it, unless you can find a compiler producing native executables. Go? Has anything useful ever been written in it?

For anyone interested in retro graphics programs, you should check out Wright Design. I wrote up a post about it and it includes a zip file of the actual program and tutorial files. I have always secretly hoped that someone would make an FOSS version of this software since I have yet to see anything like it even though it is now more than 15 years old. It seamlessly combined bitmap and vector artwork and was twice as fast as Photoshop in its day. Sad that Adobe was able to kill it off...

http://mikewilliamson.wordpress.com/2010/02/16/12-years-old-...

The first call ever made by the main module (MPhotoshop.p) is

InitToolbox(8);

However, there is no other mention of InitToolbox in the sources. Is it part of the Mac OS API? Which compiler were these sources meant for?

It's part of the MacApp framework, which isn't included in this source dump since it's copyright Apple.

http://en.wikipedia.org/wiki/MacApp "MacApp was based on Object Pascal, Apple’s object-oriented extension to Pascal, developed in consultation with Pascal inventor Niklaus Wirth."

http://c2.com/cgi/wiki?MacApp

And for something a little more modern (OpenPDN - a fork of Paint.Net which is comparable to photoshop in some ways):

http://code.google.com/p/openpdn/source/browse/

I'm curious, how does this compare to something like The Gimp, which I've always considered comaprable to Photoshop in almost every way)

Comparable? Care to quantify? MS Paint is 'comparable' with Photoshop. Just not very positively except in startup time.

I mean comparable, in the sense that it has a similar set of features, and allows you to perform similar tasks with similar amount of effort.

That can only be true if you choose to ignore a lot of photoshop features.

I love the Gimp.

I never ever try to say it's comparable to Photoshop.

Really, there's a whole bunch of stuff which is trivially easy in photoshop and not so much in Gimp.

Paint.Net has many fewer features then Gimp, but the features it does have are fast, clean and simple to use (for reasonably small files). It's my go to tool on Windows for basic editing tasks.

It's missing fractional selection and per-layer alpha channels. With those two features, it would be almost usable. Without them, most photo editing tasks are highly difficult.

Fractional selection lets you apply adjustments and effects without harsh boundaries between the adjusted part and the unaffected part. Per-layer alpha channels are needed to blend together different layers smoothly. And actually, you could implement the effect of the former with just the latter.

So yeah; Paint.NET needs editable per-layer transparency channels.

Ironic: a rant and rave about how it's important to keep Paint.NET free so it can be maintained and developed by the community unlike the now more-restrictive Paint.NET license by Rick Brewster (author).

OpenPDN repo history: initial commit, circa 2009.

Pretty sure that doesn't even qualify as a fork!

It's there if you want to help :)

The reason it was forked is due to people selling recompilations of it.

This is hilarious! Gimp's interface (separate windows) is based on Photoshop 1.0?

Photoshop on Mac has separate windows up to the present day.

Fascinating story after the standard AOL-inspired blog spam.

http://www.computerhistory.org/atchm/adobe-photoshop-source-...

Does anybody know how to build this, or if it's even possible on the current Mac architecture and OS?

Nope, it will require porting. Only the pure Pascal part is portable. The Assembly and MacApp parts are not, and MacApp no longer exists in OS X AFAIK.

503 Service Unavailable No server is available to handle this request.

About 75% of the code is in Pascal

old good Pascal

Reply on news.ycombinator.com