For Your Inspection: Source Code For Photoshop 1.0 176
gbooch writes "With the permission of Adobe Systems, the Computer History Museum has made available the source code for Photoshop version 1.0.1, comprising about 128,000 lines of code within 179 files, most of which is in Pascal, the remainder in 68000 assembly language. This the kind of code I aspire to write. The Computer History Museum has earlier made available the source code to MacPaint."
Re:Pascal ? (Score:5, Informative)
Re:Pascal ? (Score:5, Informative)
Photoshop 1 was only available on a Mac. I remember receiving the first "public beta" (Photoshop 0.9) some time in 1990 or so and it was awesome - jawdroppping awesome...
In any case, you would use MPW (Macintosh Programmer's Workshop) those days, which I think is still one of the best team-development tools. And the language-of-choice (well, in fact, nearly the only choice) for developing on a Mac at those days was Pascal + Assembler.
So, it makes sense that this code is Pascal.
Re:What Functionality? (Score:3, Informative)
http://en.wikipedia.org/wiki/Adobe_Photoshop_version_history [wikipedia.org]
Re:Still Down (Score:5, Informative)
Re:How much of this is still in use? (Score:5, Informative)
No. Photoshop was long ago rewritten into C++. That's not to say that some of the current code might not have some basis on the original code, but it's doubtful it's that much.
Re:Gimp (Score:4, Informative)
Hopefully the Gimp folks can make some use of this.
Certainly, because GIMP won't be a success until it natively supports CMYK like photoshop.
[ for the impaired, GIMP does and this version of photoshop does not, and noone outside the print industry gives a damn ]
Re:Still Down (Score:3, Informative)
Re:How much of this is still in use? (Score:4, Informative)
Highly unlikely. Photoshop 1.0 was 1990 and it was an application. That's like expecting Windows 3.0 to be using the same code as Windows 8 - sure there might be some similarity but most of Windows 3.0 and its features don't even exist in Windows any more (and haven't for many, many years).
With an application, it's also much easier to just rewrite every version - the only "compatibility" you have to worry about is that you can read the old files generated by the program (writing new file formats is common practice, but you need to be able to read the previous ones back in even if just for a one-time conversion). Think the very first Word for Windows versus Word 2013 / 365. The program itself doesn't even open files that old any more (compatibility only goes back to Word 97/2000 at best nowadays), so the likelihood of any code being more than vaguely similar is almost zero.
Plus, given that the original is in Pascal and 68k assembler, the chance is basically zero. At the point that it had to be rewritten for newer languages / platforms (even if they ran 68k code, it's unlikely to be perfectly compatible), the old code would be ditched and used - at best - as a reference to how the program used to work.
Code evolves or dies. This code-drop is pretty ancient in computing terms and won't be of any practical use any more - like when they released the original Prince of Persia source in assembler. At best, you could use it as a reference to make a pixel-for-pixel identical version by rewriting it in a sensible language and making sure it is equivalent to the old code, but that's about the only use of it.
Have a look here:
http://creativebits.org/the_first_version_of_photoshop [creativebits.org]
You could just about put some text into it. It's like looking at the source code to Word for DOS 5 and saying "Is this any good to anyone?" No. Not really. Maybe 20 years ago, but now it's so obsolete we don't even use the program itself, let alone the code that makes it, and haven't for 15 years.
Re:Pascal ? (Score:4, Informative)
Actually it's pretty close (UCSD dialect) until you get to the OBJECT keyword. Apple made full use of their Memory Manager for Object Pascal, which had a linear address space and supported relocatable objects, while Borland had a horrible memory allocator and was stuck with the 80x86 real-mode memory model and 640k limit. So they implemented "Object Pascal" as some kind of horrible C++ish hack. It was really and truly awful compared to the Object Pascal that Apple had already produced, though I hear they filed down some of the worst warts by the time of Delphi.
Oddly, this code didn't make use of the Pascal UNIT system for its own code, instead using multiple levels of include files, with the main code for a unit in "foo.inc1.p". This was probably done to make it work well with makefiles. Back in the day it took long enough to compile that you really didn't want to re-compile anything you didn't have to, and if you did things the "proper" way, code and headers would be in the same file, causing a lot of unnecessary recompilation.
Re:Run in emulator (Score:3, Informative)
Re:Gimp (Score:2, Informative)
You can pretend that everything is just published on the internet and printing is just something old people do all you like, it is simply not the case yet.
No, I actually stand by my claim.
Only the people at the high end of the print and design industry actually care about things like colour matching and quality.
There are huge swaths of businesses who print stuff who apparently just do not care one bit. Just look around at all the random signage and posters printed for anything that's not a huge advertising campaign and/or by a very large company. The sort of things produced by the large number of smaller regional and local businesses.
The quality is terrible. The typesetting is terrible. The design is terrible.
Just near where I work, there's a barber with a shop sign out the front in the street. It has a picture of a man getting a shave on it. I CAN SEE THE FUCKING PIXELS. I'm not joking, it's eyebleedingly bad. The pixels are huge, the colours are saturated and the kerning on the sign is bad.
Yet the shop seems to do good business.
There are whole bunch of professional people engaged in nothing bud business responsible for comissioning and producing that sign. Given that they didn't care enough to find a picture with adequate pixel density, I think it is fair to claim that they don't care about CMYK.
Almost all stuff is on the low end like that. That's why shops like VistaPrint are popular and very profitable. Most people, even people who need signs and things for professional purposes just do not care.
Yeah, there are some pro photographers and high end design companies, but most of the world is not like that. Most is cheap and cheerful, and most people wouldn't notice pixellation or bad colour matching even if a blue pixellated dog bit them on the leg.
So yeah, most people just don't care and the web has nothing to do with it.
Re:Run in emulator (Score:2, Informative)
By the way, the included makefile has unresolved dependencies and you would need to write a new makefile for it.
Re:Gimp (Score:4, Informative)
Professionals in print production and publishing aren't using CMYK these days. Modern print-production workflows use RGB images (as they have a wider gamut thant CMYK) and use ICC profiles to convert to CMYK at the time it's printed. This way, when the colours are separated, they're done with the intent of the device that will actually be printing the output, not with some generic RGB to CMYK conversion in Photoshop.
If you are working with CMYK images on your computer, you have made decisions about UCR and GCR and ink density that are at best educated guesses as you often have no idea what equipment will be printing your output. Once you've separated it to CMYK, if you need to print it on a different device that has different characteristics, you're in trouble.
Now, whether or not GIMP is a suitable substitute for Photoshop is another argument altogether, but these days it doesn't hinge on CMYK support.