I don’t see why not - libgit2 itself is written in C89 (and I’m the guy that’s pedantic about it by building it with VC++6 for my own perverse projects), but it’s a matter of OS support stuff.
What’ll be an annoyance is implementing the classic Mac OS stuff - the path syntax, the concept of resource forks, and \r newlines. Oh, and a GUI, because the classic Mac OS has no command line.
If classic MacOS doesn’t have a command line, what kind of interface does it have for having programs interact with each other in general? Or was that simply not a thing?
Pipes are not the be-all and end-all of program communication. Our favorite Unix-loving book had this to say about the Macintosh, which doesn’t have pipes:
The Macintosh model, on the other hand, is the exact opposite. The system doesn’t deal with character streams. Data files are extremely high level, usually assuming that they are specific to an application. When was the last time you piped the output of one program to another on a Mac? (Good luck even finding the pipe symbol.) Programs are monolithic, the better to completely understand what you are doing. You don’t take MacFoo and MacBar and hook them together.
—From Life with Unix, by Libes and Ressler
Yeah, those poor Mac users. They’ve got it so rough. Because they can’t pipe streams of bytes around how are they ever going to paste artwork from their drawing program into their latest memo and have text flow around it? How are they going to transfer a spreadsheet into their memo? And how could such users expect changes to be tracked automatically? They certainly shouldn’t expect to be able to electronically mail this patched-together memo across the country and have it seamlessly read and edited at the other end, and then returned to them unscathed. We can’t imagine how they’ve been transparently using all these programs together for the last 10 years and having them all work, all without pipes.
I’m not even talking at that level! I just meant like “open a subprocess to run this image processing thing, then immediately quit”. Just bog standard glue stuff. Windows has BAT scripts and they are helpful after all.
I do understand how lots of common user stuff will just work anyways, though, just seems that without “call another program somehow” your choices for code sharing are like “just give people the source to integrate into their own app” (with all the problems that can come with that, especially pre-internet), or “write a file, ask the user to manually open this other program and do a thing, then come back”
AppleEvents are your friend. You could send and receive events from your app. This is how many classic MacOS Web Servers implemented CGI programs back in the day. The Web App would just be another “desktop” app running on the Mac exchanging AppleEvents with the Web Server.
A long time ago in the early days of Mac OS X, I got a freelance gig to write a little Apache gizmo that would allow users to keep using AppleEvent-based CGI programs. Many universities had invested a long time developing courseware and online exam systems that relied on that technology. I had a wonderful time, it was so easy to craft a little unixy-CGI that would pick the info from the request, dispatch an AppleEvent and marshal the result back to Apache. I miss those days.
MPW existed, but the fact it wasn’t common even among us developers (Think/CW were more popular IIRC) means you couldn’t rely on it as a crutch. You live and die by the GUI (and quality of it) in the classic OS.
I did almost all of my actual programming in CW back then. And the rest was Think C or Think Pascal. But MPW was still there. The source control we used for most of our projects absolutely required MPW. (The name of the tool was Apple Projector, and this is a decent discussion of it in context).
It was not the only tool we used that required MPW, but it was the one I touched most frequently.
Surprisingly, not many other than what’s in a typical C library implementation. The Windows API backend handles most of the scenarios. I also know someone is working on an AmigaOS backend too.
Even if you’re not interested in Macs or programming on old Macs, you will probably enjoy the video about Amend’s development.
https://jcs.org/2021/10/22/amend
Can git be implemented theoretically for System {6, 7}? I suppose stuff like sha256ing will be difficult for the hardware?
I don’t see why not - libgit2 itself is written in C89 (and I’m the guy that’s pedantic about it by building it with VC++6 for my own perverse projects), but it’s a matter of OS support stuff.
What’ll be an annoyance is implementing the classic Mac OS stuff - the path syntax, the concept of resource forks, and
\rnewlines. Oh, and a GUI, because the classic Mac OS has no command line.If classic MacOS doesn’t have a command line, what kind of interface does it have for having programs interact with each other in general? Or was that simply not a thing?
From our friend ugh.pdf:
I’m not even talking at that level! I just meant like “open a subprocess to run this image processing thing, then immediately quit”. Just bog standard glue stuff. Windows has
BATscripts and they are helpful after all.I do understand how lots of common user stuff will just work anyways, though, just seems that without “call another program somehow” your choices for code sharing are like “just give people the source to integrate into their own app” (with all the problems that can come with that, especially pre-internet), or “write a file, ask the user to manually open this other program and do a thing, then come back”
https://en.wikipedia.org/wiki/AppleScript
AppleEvents are your friend. You could send and receive events from your app. This is how many classic MacOS Web Servers implemented CGI programs back in the day. The Web App would just be another “desktop” app running on the Mac exchanging AppleEvents with the Web Server.
A long time ago in the early days of Mac OS X, I got a freelance gig to write a little Apache gizmo that would allow users to keep using AppleEvent-based CGI programs. Many universities had invested a long time developing courseware and online exam systems that relied on that technology. I had a wonderful time, it was so easy to craft a little unixy-CGI that would pick the info from the request, dispatch an AppleEvent and marshal the result back to Apache. I miss those days.
Applescript.
Command lines aren’t useful for making interactive programs interact anyway.
gitk / git-gui perhaps.
You could use mpw to get around this without building a GUI. There was a gcc port (among other things) that did.
MPW existed, but the fact it wasn’t common even among us developers (Think/CW were more popular IIRC) means you couldn’t rely on it as a crutch. You live and die by the GUI (and quality of it) in the classic OS.
I did almost all of my actual programming in CW back then. And the rest was Think C or Think Pascal. But MPW was still there. The source control we used for most of our projects absolutely required MPW. (The name of the tool was Apple Projector, and this is a decent discussion of it in context).
It was not the only tool we used that required MPW, but it was the one I touched most frequently.
It’s slightly wild to see Linux servers and classic Mac OS dev in the same article, but 1998 is the right timeframe…
How many Unixisms does Libgit2 take for granted?
Surprisingly, not many other than what’s in a typical C library implementation. The Windows API backend handles most of the scenarios. I also know someone is working on an AmigaOS backend too.
Hopefully, classic AmigaOS (as in not 4+)?
AmigaOS 4 already has a port AFAIK.
How far into the transition from SHA-1 to SHA-256 is the Git ecosystem?
MacRelix includes git. I don’t think it’s very complete unless things have changed lately.
This aesthetic hits me right in the childhood. I love it and I wish I could bring back that look in my 2021 macbook
In the meantime, there’s Poolsuite / FM and Macintosh.js.
This is amazing! :-O