Adobe Photoshop 1.0 Source Code (1990) | Hacker News Reader

Adobe Photoshop 1.0 Source Code (1990)

computerhistory.org

440 pointstosh152 comments

Quite the praise by Grady Booch:

"There are only a few comments in the version 1.0 source code, most of which are associated with assembly language snippets. That said, the lack of comments is simply not an issue. This code is so literate, so easy to read, that comments might even have gotten in the way."

"This is the kind of code I aspire to write.”

> the lack of comments is simply not an issue

I'm looking at the code and just cannot agree. If I look at a command like "TRotateFloatCommand.DoIt" in URotate.p, it's 200 lines long without a single comment. I look at a section like this and there's nothing literate about it. I have no idea what it's doing or why at a glance:

  pt.h := BSR (r.left + ORD4 (r.right), 1);
  pt.v := BSR (r.top + ORD4 (r.bottom), 1);
  
  pt.h := pt.h - BSR (width, 1);
  pt.v := pt.v - BSR (height, 1);
  
  pt.h := Max (0, Min (pt.h, fDoc.fCols - width));
  pt.v := Max (0, Min (pt.v, fDoc.fRows - height));
  
  IF width > fDoc.fCols THEN
    pt.h := pt.h - BSR (width - fDoc.fCols - 1, 1);
  
  IF height > fDoc.fRows THEN
    pt.v := pt.v - BSR (height - fDoc.fRows - 1, 1);

Just breaking up the function with comments delineating its four main sections and what they do would be a start. As would simple things like commenting e.g. what purpose 'pt' serves -- the code block above is where it is first defined, but you can't guess what its purpose is until later when it's used to define something else.

Good code does not make comments unnecessary or redundant or harmful. This is a myth that needs to die. Comments help you understand code much faster, understand the purpose of variables before they get used, understand the purpose of functions and parameters before reading the code that defines them, etc. They vastly aid in comprehension. And those are just "what" comments I'm talking about -- the additional necessity of "why" comments (why the code uses x approach instead of seemingly more obvious approach y or z, which were tried and failed) is a whole other subject.

This actually looks surprisingly straightforward for what the function is doing - certainly if you have domain context of image editing or document placement. You'll find it in a lot of UI code - this one uses bit shifts for efficiency but what it's doing is pretty straightforward.

For clarity and to demonstrate, this is basically what this function is doing, but in css:

.container {

  position: relative;

}

.obj {

  position: absolute;

  left: 50%;

  top: 50%;

  transform: translate(-50%, -50%);


}

Man I just don’t know who to believe, you or the Chief Scientist for Software Engineering at IBM research Almaden.

It’s not a myth, it’s a sound software engineering principle.

Every comment is a line of code, and every line of code is a liability, and, worse, comments are a liability waiting to rot, to be missed in a refactor, and waiting to become a source of confusion. It’s an excuse to name things poorly, because “good comment.” The purpose of variables should be in their name, including units if it’s a measurement. Parameters and return values should only be documented when not obvious from the name or type—for example, if you’re returning something like a generic Pair, especially if left and right have the same type. We’d been living with decades of autocomplete, you don’t need to make variables be short to type.

The problem with AI-generated code is that the myth that good code is thoroughly commented code is so pervasive, that the default output mode for generated code is to comment every darn line it generates. After all, in software education, they don’t deduct points for needless comments, and students think their code is now better w/ the comments, because they almost never teach writing good code. Usually you get kudos for extensive comments. And then you throw away your work. Computer science field is littered with math-formula-influenced space-saving one or two letter identifiers, barely with any recognizable semantic meaning.

>> Every comment is a line of code, and every line of code is a liability, and, worse, comments are a liability waiting to rot,

This is exactly my view. Comments, while can be helpful, can also interrupt the reading of the code. Also are not verified by the compiler; curious, in the era when everyone goes crazy for rust safety, there is nothing unsafer as comments, because are completely ignored.

I do bot oppose to comments. But they should be used only when needed.

No. What you are describing is exactly the myth that needs to die.

> comments are a liability waiting to rot, to be missed in a refactor, and waiting to become a source of confusion

This gets endlessly repeated, but it's just defending laziness. It's your job to update comments as you update code. Indeed, they're the first thing you should update. If you're letting comments "rot", then you're a bad programmer. Full stop. I hate to be harsh, but that's the reality. People who defend no comments are just saying, "I can't be bothered to make this code easier for others to understand and use". It's egotistical and selfish. The solution for confusing comments isn't no comments -- it's good comments. Do your job. Write code that others can read and maintain. And when you update code, start with the comments. It's just professionalism, pure and simple.

For all we know, the comment came from someone who was doing their job (by your definition) and were bitten in the behind by colleagues who did not do their job. We do not live in an ideal world. Some people are sloppy because they don't know, don't care, or simply don't have the time to do it properly. One cannot put their full faith into comments because of that.

(Please note: I'm not arguing against comments. I'm simply arguing that trusting comments is problematic. It is understandable why some people would prefer to have clearly written code over clearly commented code.)

> colleagues who did not do their job.

That doesn't justify matching their sloth.

Lead by example! Write comments half a page long or longer, explaining things, not just expanding identifier names by adding spaces in between the words.

I have mixed feelings on this. In most respects, I am a diligent worker who tries to lead by example. On the other hand, part of my work is managing people. While I have employees who follow my example, even when I am not intending my habits to be an example, and I adore those employees immensely -- I also have to face the reality that very few employees do so. They need direction on what is expected. Even then, the direction has to take the form of intense instruction otherwise ... woosh ... the details go over their heads.

That, and I have mixed feelings about commenting code. (Thankfully I don't managed developers. I simply exploit personally since it a skill that I have.) I understand why we do it. I especially appreciate well documented libraries and development tools. On the other hand, I fully understand that comments only work if they are written, read, and updated. The order is important here since documentation will only be updated if it is read and it will only be read if it is (well) written. Even then you are lucky if well written documentation is read.

The flip side is that comments are duplication. Duplication is fine if they are consistent with each other. In some respects, duplication is better since it offers multiple avenues for understanding. Yet there is also a high probability that they will get out of sync. Sometimes it is "intentional" (e.g. someone isn't doing their job by updating it). Sometimes it is "unintentional", since the interpretation of human languages is not as precise as the compiler's translation of source code into object code. (Which is a convoluted way of saying that sometimes comments are misinterpreted.)

Generally, high standards can only be achieved through enforcement, not merely through begging and pleading.

I like to add myself as a mandatory reviewer of all PRs and then reject changes that don't come with some explanatory comment or fail to update comments.

Even if huge swaths of the codebase are undocumented boring boilerplate, you still have to draw the line somewhere, otherwise you get madness like ten pages of authentication and authorization spaghetti logic without a single descriptive comment.

I appreciate your attempt to defend this position and I, and others, wish you good luck. In my many decades of working with humans writing code it simply has never happened.

It definitely happens.

I've worked at places (early on) that were basically cowboy coding -- zero code review, global variables everywhere, not a comment or test to be seen. Obviously you can't enforce good comments there.

And I've worked at places that were 100% professional -- design documents, full code review, proper design, tests, full comments and comments kept fully up-to-date just like code.

It's just the culture and professionalism. If proper comments are enforced through code review, they happen. Ultimately, the head of engineering just decides whether it's part of policy or not. It's not hard. It's just a top-down decision.

No amount of good names will tell you why something was done a certain way, or just as importantly why it wasn't done a certain way.

A name and signature is often not sufficient to describe what a function does, including any assumptions it makes about the inputs or guarantees it makes about the outputs.

That isn't to say that it isn't necessary to have good names, but that isn't enough. You need good comments too.

And if you say that all of that information should be in your names, you end up with very unwieldy names, that will bitrot even worse than comments, because instead of updating a single comment, you now have to update every usage of the variable or function.

BSR = bitwise right-shift

ORD4 = cast as 32bit integer.

BSR(x,1) simply meant x divided by 2. This is very comment coding idom back in those days when Compiler don't do any optimization and bitwise-shift is much faster than division.

The snippet in C would be:

    pt.h = (r.left + (int32_t)r.right) / 2;
    pt.v = (r.top + (int32_t)r.bottom) / 2;

    pt.h -= (width / 2);
    pt.v -= (height / 2);
  
    pt.h = max(0, min(pt.h, fDoc.fCols - width));
    pt.v = max(0, min(pt.v, fDoc.fRows - height));
  
    if (width > fDoc.fCols) {
      pt.h -= (width - fDoc.fCols - 1) / 2;
    }
  
    if (height > fDoc.fRows) {
      pt.v -= (height - fDoc.fRows - 1) / 2;
    }

Reading the full function here https://github.com/amix/photoshop/blob/2baca147594d01cf9d17d...

If I understand it correctly, it was calculating the top-left point of the bounding box.

That particular code is idiomatic to anyone who worked with 2D bitmap graphics in that era.

pt == point, r == rect, h, v == horizontal, vertical, BSR(...,1) is a fast integer divide by 2, ORD4 promotes an expression to an unsigned 4 byte integer

The algorithms are extremely common for 2D graphics programming. The first is to find the center of a 2D rectangle, the second offsets a point by half the size, the third clips a point to be in the range of a rectangle, and so on.

Converting the idiomatic math into non-idiomatic words would not be an improvement in clarity in this case.

(Mac Pascal didn't have macros or inline expressions, so inline expressions like this were the way to go for performance.)

It's like using i,j,k for loop indexes, or x,y,z for graphics axis.

Xyz makes sense because that is what those axes are literally labeled, but ijk I will rail against until I die.

There's no context in those names to help you understand them, you have to look at the code surrounding it. And even the most well-intentioned, small loops with obvious context right next to it can over time grow and add additional index counters until your obvious little index counter is utterly opaque without reading a dozen extra lines to understand it.

(And i and j? Which look so similar at a glance? Never. Never!)

ijk are standard in linear algebra for vector components.

> (And i and j? Which look so similar at a glance? Never. Never!)

This I agree with.

What if not ijk? I know only uvw.

Pretend to be a physicist and use μ and ν.

i came from imaginary numbers which were extended to make quaternions.

i, j, k comes from FORTRAN's implicit types -- by default, names starting with I-N are integers and all other names are real.

this is much older ; Joseph Fourier was already using "i" and "j" for indices in the 1800s. See page 209: https://www.google.ca/books/edition/OEuvres_de_Fourier_Th%C3...

The context is i, j, k as indices in programs. No doubt FORTRAN was influenced by prior use such as you cite. But in no case does i used as an index come from i designating an imaginary number, which is what I aimed to refute.

Representing dimensions as indexable rows and columns of vectors or matrices was done on paper in the 1800s.

> but ijk I will rail against until I die.

> There's no context in those names to help you understand them, you have to look at the code surrounding it.

Hard disagree. Using "meaningful" index names is a distracting anti-pattern, for the vast majority of loops. The index is a meaningless structural reference -- the standard names allow the programmer to (correctly) gloss over it. To bring the point home, such loops could often (in theory, if not in practice, depending on the language) be rewritten as maps, where the index reference vanishes altogether.

I respectfully disagree.

The issue isn't the names themselves, it's the locality of information. In a 3-deep nested loop, i, j, k forces the reader to maintain a mental stack trace of the entire block. If I have to scroll up to the for clause to remember which dimension k refers to, the abstraction has failed.

Meaningful names like row, col, cell transform structural boilerplate into self-documenting logic. ijk may be standard in math-heavy code, but in most production code bases, optimizing for a 'low-context' reader is not an anti-pattern.

If the loop is so big it's scrollable, sure use row, col, etc.

That was my "vast majority" qualifier.

For most short or medium sized loops, though, renaming "i" to something "meaningful" can harm readability. And I don't buy the defensive programming argument that you should do it anyway because the loop "might grow bigger someday". If it does, you can consider updating the names then. It's not hard -- they're hyper local variables.

In a single-level loop, i is just an offset. I agree that depending on the context (maybe even for the vast majority of for loops like you're suggesting) it's probably fine.

But once you nest three deep (as in the example that kicked off this thread), you're defining a coordinate space. Even in a 10-line block, i, j, k forces the reader to manually map those letters back to their axes. If I see grid[j][i][k], is that a bug or a deliberate transposition? I shouldn't have to look at the for clause to find out.

If you see grid[y][z][x], is it a bug or a deliberate transposition?

> Converting the idiomatic math into non-idiomatic words would not be an improvement in clarity in this case.

You seem to be missing my point. It's not about improving "clarity" about the math each line is doing -- that's precisely the kind of misconception so many people have about comments.

It's about, how long does it take me to understand the purpose of a block of code? If there was a simple comment at the top that said [1]:

  # Calculate top-left point of the bounding box

then it would actually be helpful. You'd understand the purpose, and understand it immediately. You wouldn't have to decode the code -- you'd just read the brief remark and move on. That's what literate programming is about, in spirit -- writing code to be easily read at levels of the hierarchy. And very specifically not having to read every single line to figure out what it's doing.

The original assertion that "This code is so literate, so easy to read" is demonstrably false. Naming something "pt" is the antithesis of literature programming. And if you insist on no comments, you'd at least need to name is something like "bbox_top_left". A generic variable name like "pt", that isn't even introduced in the context of a loop or anything, is a cardinal sin here.

[1] https://news.ycombinator.com/item?id=46366341

It all depends on how much context the reader has. For some audiences a comment explaining bounding boxes would be helpful; for others your example comment adds nothing that isn't immediately apparent from the code.

Part of figuring out a reasonable level of commenting (and even variable naming) is a solid understanding of your audience. When in doubt aiming low is good practice, but keep in mind that this was 2D graphics software written at a 2D graphics software company.

I think at certain calibers of work, like graphics programming in lower level languages, the best you can do is be readable and clear to others who are experts in your field. In other words, you aren't the target audience. There is likely no way to write this specific kind of code in a way that satisfies all audiences. I'm willing to concede then that the 'best' way to write this type of code is determined by the ones writing it, not us with standard views on software.

A graphics programmer does not need that.

To help understand, you need to see this code as math. Graphics programming algorithms are literally math.

You're asking for training wheels comments, which just get in the way for those who are familiar with the domain.

I'm sure a few graphics programming engineers might want calls to react useState(), useEffect(), etc. to be documented in a codebase, yet a react programmer would scoff at the idea.

Exactly this.

To a graphics programmer this can feel like call for comments to explain that

i++

increments the loop variable. A newbie to programming might find such a comment useful, but to people who are maintaining such a piece of code that would be distracting line noise.

It all depends on who your professional peer is that you are writing the code for. It's totally fine to write for a peer who is familiar with the domain, as it's fine to write for a beginner, for pedagogy, such as in a text book.

As other comments have mentioned, context does matter, and as someone with a lot of 2D image/pixel processing experience, other than the 'BSR' and 'ORD4' items - which are clearly common in the codebase and in that era of computing, all that code makes perfect sense.

Also, breaking things down to more atomic functions wasn't the best idea for performance-sensitive things in those days, as compilers were not as good about knowing when to inline and not: compiler capabilities are a lot better today than they were 35 years ago...

The code's functionality is immediately obvious to me as someone who works a lot with graphics coordinate systems.

I'm sure the code would be immediately obvious to anyone who would be working on it at the time.

Comments aren't unnecessary, they can be very helpful, but they also come with a high maintenance cost that should be considered when using them. They are a long-term maintenance liability because by design the compiler ignores them so its very easy to change/refactor code and miss changing a comment and then having the comment be misleading or just plain wrong.

These days one could make some sort of case (though I wouldn't entirely buy it, yet) that an LLM-based linter could be used to make sure comments do not get disconnected from the code they are documenting, but in 1990? not so much.

Would I have used longer variable names for slightly more clarity? Today, sure. In 1990, probably not. Temporal context is important and compilers/editors/etc have come a long way since then.

Are you familiar with the domain?

Because it's quite clear, everything is well named, and the filename also gives the context.

Finds the center of a rectangle r Positions a width × height region centered on that rectangle.

Clamps the result so it doesn’t go outside the document.

If the region is bigger than the document, it re-centers instead of snapping to (0,0).

"His brother John, working at the movie visual effects company Industrial Light & Magic" is underselling John Knoll a bit - he became one of the more prominent figures there and won two Oscars for his work (and was nominated for more).

Taking his contribution for Photoshop into account, one could say that if you saw mainstream motion or still pictures in the Western world in the last three decades, you'll probably saw something influenced by him in one way or another.

When this got released I really expected someone in the opensource community to run with it, but as far as I know no one has. Back around 1990 a Graphic designer that had his office n the same building as my mom worked in let me copy his Photoshop 1.x disks and nothing has ever compared to it for me. When will we get the linux port of Photoshop 1.0? I would love to see how it develops.

If they did, they can only send you screenshots

> 2. Restrictions. Except as expressly specified in this Agreement, you may not: (a) transfer, sublicense, lease, lend, rent or otherwise distribute the Software or Derivative Works to any third party; or (b) make the functionality of the Software or Derivative Works available to multiple users through any means, including, but not limited to, by uploading the Software to a network or file-sharing service or through any hosting, application services provider, service bureau, software-as-a-service (SaaS) or any other type of services. You acknowledge and agree that portions of the Software, including, but not limited to, the source code and the specific design and structure of individual modules or programs, constitute or contain trade secrets of Museum and its licensors.

I was talking about more than just a literal port, running with it is broader than just a literal port. I guess my general point is that I am disappointed that all these releases of historical code have so little to show for being released.

Edit: Disappointed is really not the right word but I am failing at finding the right word.

I think there's two parts to this:

1) these historical source code releases really are largely historical interest only. The original programs had constraints of memory and cpu speed that no modern use case does; the set of use cases for any particular task today is very different; what users expect and will tolerate in UI has shifted; available programming languages and tooling today are much better than the pragmatic options of decades past. If you were trying to build a Unix clone today there is no way you would want to start with the historical release of sixth edition. Even xv6 is only "inspired by" it, and gets away with that because of its teaching focus. Similarly if you wanted to build some kind of "streamlined lightweight photoshop-alike" then starting from scratch would be more sensible than starting with somebody else's legacy codebase.

2) In this specific case the licence agreement explicitly forbids basically any kind of "running with it" -- you cannot distribute any derivative work. So it's not surprising that nobody has done that.

I think Doom and similar old games are one of the few counterexamples, where people find value in being able to run the specific artefact on new platforms.

you literally said:

> When will we get the linux port of Photoshop 1.0?

What would you expect to happen? Photoshop 1.0 is an almost unusably basic image editor by modern standards. It doesn't even have layers (they were introduced with Photoshop 3.0 4 years later). Even if the code was licensed in a manner that allowed distribution of derivative works (which it isn't), it's written in Apple's Pascal dialect from the mid-80s and uses a UI framework that's also from the mid-80s and only supports classic Mac OS. CHM didn't even release the code in a state that could be usable out of the box if you happen to have a 40 year old Macintosh sitting around. Here's a blog post showing how much work it took someone to compile it: http://basalgangster.macgui.com/RetroMacComputing/The_Long_V...

I think Adobe decided to release the code because they knew it was only valuable from a historical standpoint and wouldn't let anyone actually compete with Photoshop. If you wanted to start a new image editor project from an existing codebase, it would be much easier to build off of something like Pinta: https://www.pinta-project.com/

The appropriate word is "mistaken". It was explained that the licensing restrictions do not allow for a port, literal or otherwise. And "the linux port of Photoshop 1.0" is not something anyone wants when Linux already has far more capable photo editing software, and when much of this code is devoted to solving problems--e.g., interfacing with ancient hardware--that no longer exist.

Your disappointment seems to be a form of FOMO, but there isn't actually anything that you're MO here.

It would be trivial to distribute a patch and a link to the original source. The patch can be distributed under whatever license the author wants. The resulting binary then becomes an unlicensed derivative work, the person who compiled it can use it however they want but are not allowed to legally distribute it.

My personal thoughts are: open-source software is great, probably the ideal condition, but I wish the general software distribution environment was not effectively all or nothing. open-source or compiled binary. I wish that protected-source software was considered a more valid distribution model. where you can compile, inspect fix and run the software but are not allowed to distribute it. Because trying to diagnose a problem when all you have is a compilation artifact is a huge pain. You see some enterprise software like this but for the most part it either open-source or no-source.

I am a bit surprised that there is no third party patch to get photoshop 1.0 to run under modern linux or windows, not for any real utility(at this point MS paint probably has better functionality), but for the fun of it. "This is what it feels like to drive photoshop 1"

The source is now readable but it’s not open source at all.

It is open source but not free software.

It's "source available" [1], not open source [2].

Words have meaning and all that.

1: https://en.wikipedia.org/wiki/Source-available_software

2: https://en.wikipedia.org/wiki/Open_source

cant blame him. We're in a bit of a bananas situation where open source isnt the antonym of closed source

This isn't that uncommon:

* If a country doesn't have "closed borders" then many foreigners can visit if they follow certain rules around visas, purpose, and length of stay. If instead anyone can enter and live there with minimal restrictions we say it has "open borders".

* If a journal isn't "closed access" it is free to read. If you additionally have permissions to redistribute, reuse, etc then it's "open access".

* If an organization doesn't practice "closed meetings" then outsiders can attend meetings to observe. If it additionally provides advance notice, allows public attendance without permission, and records or publishes minutes, then it has “open meetings.”

* A club that doesn't have "closed membership" is open to admitting members. Anyone can join provided they meet relevant criteria (if any) then it's "open membership".

EDIT: expanded this into a post: https://www.jefftk.com/p/open-source-is-a-normal-term

* A set that isn't open isn't (necessarily) closed.

* A set that is open can also be closed.

Who says it isn't? "closed source" doesn't have a formal definition, but can be arbitrarily defined as the antonym of open source, and when people use the term that's usually what they mean.

And that has nothing to do with whether someone can be "blamed" for ignoring the actual meaning of a term with a formal definition.

> Words have meaning and all that.

Ironic put down when “open source” consists of two words which have meaning, but somehow doesn’t mean that when combined into one phrase.

Same with free software, in a way.

Programmers really are terrible at naming things.

Even without a specific definition for "open source", I wouldn't consider source code with a restrictive license that doesn't allow you to do much with it to be "open".

What exactly does "open" mean when used as a qualifier for "source"?

The fact is that your claim "“open source” consists of two words which have meaning, but somehow doesn’t mean ==>that<== when combined into one phrase" is simply false, as there is no "that".

> Same with free software, in a way.

This is a much more supportable argument, but note the change in wording: "free software" is not the same as "free source". The latter suggests that one doesn't have to pay for the source, but says nothing about what one can do with the source or one's rights to software built from that source.

As for "free [as in freedom] software", I think there would have been less contention if RMS/FSF had called it "freed software" or "liberated software", and it would have been more consistent with their stated goals.

> Programmers really are terrible at naming things.

This is silly sophism based on one anecdote that you didn't even get right. Naming things well is hard, and names in software have conditions that don't exist in more casual circumstances. The reality is that good programmers put a lot of effort into choosing names and generally are better at it than the population at large.

You're close: they should have called it "freedom software". Which they wanted to, but couldn't, because it was trademarked. Source: I e-mailed richard stallman to ask why they didn't, he replied.

You're welcome to think what you want, but I've had to explain to enough juniors enough times what "open" actually means, so I know what people without any preconceived notions think it means, vs what experts on HN associate with the word after decades in the industry.

People who are new to the profession entirely, think that "open" means "you can look inside." Source: my life, unfortunately.

> ... that you didn't even get right.

FYI: this style of conversation won't get anyone to listen to you. And FWIW I was referencing the quip which I'm sure your familiar with. It was tongue in cheek.

> The reality is that good programmers put a lot of effort into choosing names and generally are better at it than the population at large.

... isn't that a No True Scotsman?

> You're welcome to think what you want

How big of you.

> I've had to explain to enough juniors enough times what "open" actually means, so I know what people without any preconceived notions think it means, vs what experts on HN associate with the word after decades in the industry.

This is not relevant--it addresses a strawman and deflects from the actual claim you made and that I disputed.

> FYI: this style of conversation won't get anyone to listen to you.

Projection. I will in fact cease to respond to you.

> ... isn't that a No True Scotsman?

Obviously not. Failing to understand the difference between "real", "actual", "true" etc. which are the essence of the fallacy and valid qualifiers like "good" shows a fundamental failure to understand the point of the fallacy.

I don't think this is a case of programmers being bad at things (although I get that you said that as a joke), I think it's much worse than that: This is some kind of weird mind-over-matter "if we believe it hard enough it'll come true" thing. Sort of an "if we beat everyone who says the emperor has no clothes, we can redefine 'clothes' to include 'the emperor's birthday suit'". Note that these people who are downvoting anyone who dares to say that "open source" isn't synonymous with the OSI definition never concede an inch to the notion that the words have a common-sense meaning and the OSI didn't invent the term (provable via internet archive). Because it's not about being right it's about changing reality to match what they wish were true.

No, it’s source available but not open source. Open source requires at minimum the license to distribute modified copies. Popular open source licenses such as MIT [1] take this further:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

This makes the license transitive so that derived works are also MIT licensed.

[1] https://en.wikipedia.org/wiki/MIT_License?wprov=sfti1#Licens...

MIT is not copyleft. The copyright notice must be included for those incorporated elements, but other downstream code it remains part of can be licensed however it wants.

AGPL and GPL are, on the other hand, as you describe.

Modifications can be licensed differently but that takes extra work. If I release a project with the MIT license at the top of each file and you download my project and make a 1-line change which you then redistribute, you need to explicitly mark that line as having a different license from the rest of the file otherwise it could be interpreted as also being MIT licensed.

Not quite. You need to include the MIT license text when distributing the software*, but the software you build doesn't need to also be MIT.

*: which unfortunately most users of MIT libraries do not follow as I often have an extremely difficult time finding the OSS licenses in their software distributions

No, the original definition of open-source is source code that is visible (open) to the public.

Citation?

On the contrary: https://opensource.org/osd

I mean, I can buy opensource.co.net but that doesn't mean I can tell you how you can use the term.

Need more of a citation to understand that..?

> I mean, I can buy opensource.co.net but that doesn't mean I can tell you how you can use the term.

> Need more of a citation to understand that..?

This nonsense is not at all relevant to the claim for which I asked for a citation: "No, the original definition of open-source is source code that is visible (open) to the public."

No support for that claim has ever been offered.

It’s is “source available” but not open source.

Open Source is the same thing as Free Software, just with the different name. The term "Open Source" was coined later to emphasize the business benefits instead of the rights and freedom of the users, but the four freedoms of the Free Software Definition [1] and the ten criteria of the Open Source Definition [2] describe essentially the same thing.

[1] https://www.gnu.org/philosophy/free-sw.en.html

[2] https://opensource.org/osd

You could try having an LLM port it to Linux :) As an aside I was always (well, no longer) hoping that Photoshop gets ported to Linux because at least an IRIX port existed, so there has to be some source code with X11 or whatever library code.

https://fsck.technology/software/Silicon%20Graphics/Software...

Photoshop was ported to IRIX using Latitude, Quorum Software's implementation of Mac OS System 7. Apple later acquired the Quorum's code and it became part of Carbon.

There's System 7 for Unix 'natively', with either Executor (there's a fork under Github) or some other project: https://www.v68k.org/advanced-mac-substitute/

https://github.com/autc04/executor

https://github.com/jjuran/metamage_1/

As an experiment, I gave the source zip file to Claude and told it to make a WASM version of the app, by translating the Pascal to Go.

It nailed it, first try.

I cannot, unfortunately, share a link to the website it created because of the license.

LLM translations of historical software to modern platforms is a solved problem. Try it, you'll see.

I used https://exe.dev/ and their Shelley agent to drive Claude. Give it a try, it is jaw dropping.

Can you post a video demonstrating you using it?

https://exe.dev has a nifty private sharing feature, contact me in email and you can see it.

That's a bit of an extraordinary claim: what did Claude do about the important non-Pascal parts: the resource fork and the 68k assembly?

Look I understand it's crazy, but it took one small prompt and I came back a half hour later expecting it to have given up, but instead I saw exactly what you'd expect to see in my browser.

Here is the prompt I gave it:

"Use wasm and go and a 68000 emulator to get the Photoshop 1.0.1 software at https://d1yx3ys82bpsa0.cloudfront.net/source/photoshop-v.1.0... to run correctly. You should not require an operating system, instead implement the system calls that Photoshop makes in the context of wasm. Because Go compiles to wasm, you might try writing some kind of translator from the pascal to go and then compile for wasm. Or you might be able to find such a thing and use it."

You can give it a try yourself, or contact me for a private link to it (see the CHM license for why I can't make it public).

I've had a chance to review the code now. It used HTML/CSS/JS for the UI, and calls into the Go/wasm code where the filters are implemented.

When a filter is implemented half in Pascal (setup and loop over the rows) and half in assembly (each row) Claude did it all in Go, but the structure in Go is the same: one entry point for setup and iterating on rows, and one function (ported from the assembly) to process each row.

(As for the resource fork, it just reimplemented the UI in HTML. There's not enough info in the transcript of it's thinking to know if it read the resource file and understood it, or if it used a general understanding of what was in Photoshop, from training data, to do it.)

My mind is blown. I keep trying to find evidence that it just copied this from someplace, but I can't see how.

Wow, that makes so much sense - thank you! It sounds like it essentially "vibed up" the parts it didn't understand, which is amazing.

Just as an experiment, I fed the resource fork to GPT-5.2 to see whether it could render the windows/dialogs in the resource fork - it did a fairly okay job. I think the fundamental limit it ran against (and acknowledges) is that lot of Mac's classic look and feel was defined programmatically, literally, down to calls to RoundRect(...).

https://chatgpt.com/s/t_694dddb290308191babcb07a72367e97

Thanks for posting your experience.

If it uses Motif and IrisGL (now MESA3D) the amount of porting effort it's near NIL.

And, for purity/completeness, avoid Maxx Desktop and/or NSCDE; EMWM with XMToolbar it's close enough to SGI's Irix desktop.

https://fastestcode.org/emwm.html

I understand it was a very unique and powerful piece of software in 1990 but why would it be such a game changer to have the 1.0 running on Linux today?

What about GIMP or any of the other open source image editors?

Just supporting a modern OS's graphical API (The pre-OSX APIs are long dead and unsupported) is a major effort.

That software box on the shelf at Babbage’s is a cherished memory—a tangible oddity of software distribution prior to broadband, now just a relic in memory. Most of us assumed it would last forever. We get our software at the click of a button now, but we traded something for that.

Software felt more valuable when you forked over £60+ ( Which was worth a lot more back then ) and got a physical box, with a chunky set of instruction manuals and 5+ floppy disks.

It wasn't even broadband that destroyed that experience, when CDs came around developers realised they had space to just stick a PDF version of the manual on the CD itself and put in a slip that tells you to stick in the CD, run autorun.exe if it didn't already, and refer to the manual on the CD for the rest!

Manuals like AutoCADs have certainly felt valuable https://i.ebayimg.com/images/g/Gm8AAeSwwIZowjzn/s-l1600.jpg It's not even complete, for instance the ADS manual is missing. It's also a bit more expensive with roughly 3700 USD in 1992.

Oh yeah, when I said £60, I was thinking of even the cheapest consumer-grade software!

Whoa strong nostalgia hit from that photo. I seem to remember the R13 (the last version I used before shifting into tech) stack of manuals was even bigger.

The Office 4.3 set of manuals were large too, but didn't have the information density the AutoCAD ones did.

Also, you were far more likely to get actual documentation back in the day. You're never going to get a detailed first-party technical reference for today's Apple computers (at least not without being Big Enough and signing a mountain of NDAs); compare that to the Apple II having a full listing of the Monitor ROM, or the original IBM PC Technical Reference Manual.

The very existence of those manuals improved the software, as the technical writers were trained in a different discipline than programming, and it really showed.

Even some well-documented modern software is obviously documented by the programmers and programmer-adjacent.

There are many things I feel nostalgic for in that era, but chunky manuals for specific software are at the bottom of that list.

They weren’t like textbooks, which have knowledge that tends to be relevant for decades. You’d get a new set with every software release, making the last 5-20 lbs of manuals obsolete.

You did lose some of the readability of an actual book. Hard-copy manuals were better for that. But for most software manuals, I did more “look up how to do this thing” than reading straight through. And with a pdf on a CD you had much better search capabilities. Before that you’d have to rely on the ToC, the book index and your own notes. For many manuals, the index wasn’t great. Full text search was a definite step up.

Even the good ones, like the 1980s IBM 2-ring binder manuals, which had good indexes, were a pain to deal with and couldn’t functionally match a PDF or text file on a CD for searchability.

I think another thing we lost was the sense of a software release being a complete, immutable product - and the development rigor required of that.

You might expect now and again to get some optional updates/patches later, but that was rare - and rarer still for most people to even know about them.

These days, software is never complete. Nothing is done. It's just a point-in-time state with a laundry list of bugs and TODOs that just roll out whenever. The software is just whatever git tag we're pointing to today.

I understand how/why it has become like this - but it still makes me sad.

This code was likely written on a Macintosh Plus with a 9 in (23 cm) monochrome display that had a resolution of 512 × 342. Something to keep in mind. That's very little screen real estate (tiny!) and something that had to be respected. Writing long winded stuff had a cost in performance and maintainability. We sometimes wrote the documentation separately when needed. Sometimes that was printed out for ease of consumption. Then we have the issue that the Mac had only just been upgraded to 1MB of memory (4MB potentially) and only 800 KB floppy drive. And an 8 mhz processor.

I ran an exhibit of eight machines from my retrocomputing collection last year, including a 1986 Mac Plus with 1MB RAM running Photoshop 1.0. People really enjoyed it! It’s kind of remarkable what you can still do with it and how freeing it is to have singular focus in an app.

I learned Photoshop while working with John at ILM in the 90's. Cool!

There was something magical about white floppies, as shown in the screenshot.

you mean photo not screenshot.

I think all floppies are magical :)

Image.

Back in time, black were ordinary, and only white/grey ones were for licensed software, thus more desirable.

https://computerhistory.org/wp-content/uploads/2019/08/photo...

The same for cameras back in the 60s/70s. Silver was the norm, black was way more desirable. Funnily it's now the opposite.

As I remember, the blue ones where the most ordinary (and boring), at least for 3½-inch size. For 5¼-inch, they were mostly black, but I remember some of them in colors too (especially orange or yellow ones, they were beautiful).

E.g: https://c7.alamy.com/comp/2AA9BC4/ajaxnetphoto-2019-worthing...

White gold: https://archive.org/download/windows-3.00a/media-disk01.png

I used to demonstrate PS1 in my digital painting class. I would show that without a layer-based system it was still possible to create a composite using calculations feature. The process is incredibly simple… an alpha, a foreground and a background plus some addition and multiplication. Even art students understand it. I’m still blown away by how much functionality they managed to squeeze into an executable small encounter to email to someone.

FYI.., the version I used was registered to Apple. Apparently, the Knoll brothers demoed PS to apple and they promptly shared it amongst themselves and their buddies. Almost all illegitimate copies of it are derived from that pirated copy.

Fun fact… John knolls wife was the founding member of the Photoshop ‘Widows’ club… a home to people who have lost loved ones to software.

Interesting little read. I always find it fascinating when old code holds up really well - especially structurally. Great trip down memory lane!

>To download the code you must agree to the terms of the license, which permits only non-commercial use and does not give you the right to license it to third parties by posting copies elsewhere on the web.

Note this is a toxic license. Accepting it and/or reading of the code has potential for legal liability.

Still, applaud releasing the source code, even if encumbered. Preservation is most important, and any legal teeth will eventually expire with the copyright.

> Note this is a toxic license. Accepting it and/or reading of the code has potential for legal liability.

How would this potentially expose you to legal liability?

If anyone does leak it, you're on the list of suspects.

But how would they identify you? Agreeing to the license merely requires you to click a link. Nowhere are you asked to identify yourself. Even if they collect your IP address, that identifies an endpoint, not a computer or a particular person.

Gimp source code: https://gitlab.gnome.org/GNOME/gimp

the funny thing with GIMP is: even while its a very powerful tool, it still lacks a good texting tool until today :-)

and having the source available didnt help so far either :-))

Nothing stops you from creating a PR :-)))

I would, if I would GIMP use often enough to have the motivation - I use GIMP maybe 2 - 3 times a year.

And thats the irony covered in my post: Even that the source is available didnt motivate someone enough so far to create better version of the built

Nothing stops you from commenting these useless comments.

for the downvoters:

could you please show me a good textting tool plugin for GIMP, then?

you can check their forums & other sites: the textingtools is on top of their discussion lists?

I don't see it at the top of the discussion on the forums I checked.

So can you expand why you think the text tool, is bad?

Before release 3.0: https://discuss.pixls.us/t/gimp-3-0-will-the-text-tool-be-im...

Reddit: https://www.reddit.com/r/GIMP/comments/1fecr6u/suggestion_im...

Its just the first two results from top of Google.

Maybe the tool was improved in version 3.0, I'm running an older 2.x version. I will check it next time.

The versions were difficult in: - font size applying - random loss / reset settings - there were some issues with the preview when editting - font preview before selection etc.

Both of those are from over a year ago? For future, I wouldn't think that's "top" of any discussion.

The strange font sizes and setting reset was mostly fixed as part of the 2020 massive refactor [0]. There are still some minor inconsistencies between the two font editor panels, but they're being worked on.

Thankfully, you shouldn't have any random setting changes since about 2018 build.

[0] https://gitlab.gnome.org/GNOME/gimp/-/issues/344

Honestly, I think it was just the smiley faces. I didn't downvote.

I don't understand what you mean by texting tool. Do you mean text rendering? kerning?

Can you detail what you mean by good texting tool? What features are missing?

It's just tiny. And fiddly. And it likes to go bezerk and reset your font face/size/style settings on a whim if you so much as tickle the wrong key.

It's not intuitive. It's actually possibly my most hated widget in the entire FOSS ecosystem.

For texting I recommend using a mobile phone or desktop instant messaging program. While it's not the case with all of them, graphics editing tools tend to have texting utilities as a second-class citizen at best

haha, good one :-D ;-) ;-)

FTFY: the funny thing with GIMP is: even while its a very powerful tool, it still lacks a good image editing tool until today

And geometric shapes drawing, it is probably the only software that requires using paths for basic stuff.

I used to use GIMP as an example of OSS desktop applications having bad UX, I mean back around 2010 maybe. The UX felt plain horrible. Anything I every tried there was pain to achieve. And there was plethora of desktop applications having the same issue back then. "Geeks can't do UI".

I feel like that has changed? Even Blender felt good the last time I used it, Firefox became kinda fine, though these are probably bad examples as they are both mainstream software. But what about OSS that is used primarily by OSS enthusiasts? What about GIMP now?

This is just my personal experience, but even with the current UI, there can tend to be a learning curve with GIMP. Alot of it probably comes from figuring out where tools and functionality that are readily available upfront in other paint programs are hidden 2-3 menus deep in GIMP

A simple trick to make GIMP perfectly usable (exists since ages):

> To change GIMP to single-window mode (merging panels into one window), go to "Windows" in the top menu and select or check "Single-Window Mode"; this merges all elements like the Toolbox, Layers, and History into one unified view.

Blender feels like an outlier amongst open source software. Outside of programmers tools the great majority of open source feels mediocre. I wonder what the Blender people did differently.

unlike most FOSS, blender gets millions of dollars a year to support development

That’s what happens when you let people do other people's jobs. UI/UX design is a profession, and there is a reason for that.

Unfortunately, designers are rare among the FOSS community. You can't attract real casual or professional users if you don't recognize the value of professional UI/UX.

I've never understood the negative comments around UX for GIMP. It always feels just fine for me. Some stuff is in menus, but its a complex application with a lot of parts so I understand that

GIMP in my opinion has a very good UI when you're looking at graphics as a programmer: threshold this, clamp that, apply a kernel ("custom filter")... Everything seems to click with a mental model of someone who does graphics programming.

Whereas Photoshop and other "mainstream" software use terms and procedures non-programmers are more likely to be familiar with: heal this area with a patch, clone something with a clone stamp, scissors/lasso to cut something out (not saying GIMP doesn't have those)...

GIMP is an excellent example of the shortcomings of FOSS, considering that it first released in 1998 and almost 27 years later still does not have feature parity with Photoshop 6.0.

Those are not the shortcomings of FOSS. Rather, they are shortcomings of a lack of funding. The FOSS builds of VS Code, Chromium, and Android are good examples of high quality FOSS, all of which have Big Tech companies pouring money into them every year.

Still better than GIMP... /s (maybe)

Wow! Writing photoshop while a phd student at Michigan! Wish current students would do some code

They are good at dancing for TikTok videos, though.

Why do you think they don't?

> "Software architect Grady Booch is the Chief Scientist for Software Engineering at IBM Research Almaden and a trustee of the Computer History Museum. He offers the following observations about the Photoshop source code."

OMG. Booch?? The father of UML is still around? Given that UML is a true crime against humanity, it just goes to show there is no justice in the world. (I want a lifespan refund for the amount of time I spent learning UML and Design Patterns back in the bad old Enterprise Java days. Oof)

I completed a CS degree just a year ago, and they absolutely wrecked us with UML. I’m still recovering mentally.

UML used to be a staple of job interviews.

It was going to be the future of Software Engineering in the 2000s, Software Architects laying out boxes for Software Bricklayers to implement as dictated, code generation tools were going to make programming trivial.

For trivial CRUD apps, and maintaining modified versions of the generated code was a nightmare.

I was drawing UML before Christmas vacations, when one works at scale, drawing boxes to discuss implemenations works much better than throw away code.

It is also a great way to document existing architectures.

This AI hype cycle reminds me of that era.

On the contrary, UML is quite useful in enterprise architecture, and I am yet to find an alternative that isn't much worse.

It is like the YAML junk that gets pushed nowadays in detriment of proper schemas, and validation tools we have in XML.

Hard disagree. The code is the spec. The code is the spec. The code is the spec.

Yeah, that is why the code always meets user expectations.

User expectations are not the spec, they are what the spec aspires to.

Yeah, if only developers had bothered to validate the spec before diving straight into coding.

Reply on news.ycombinator.com