Rixstep should be shortly rolling out ‘Past Masters’. Check this link for updates.
We regularly get requests for older builds of the ACP. For people using older hardware. The demographic of users who do not toss out old hardware and use other than the latest and most expensive is overlooked.
The ACP's been out for over twenty years. We followed along with Apple's updates for a long time, back when we thought they could save the world. We've kept those images - and that source code - in archive. Our registered clients have access to all those builds, dating back to at least 2002.
We thought we'd make those builds available to the public at large.
You'll get access to all our 'Past Masters' dating from OS X 10.2 and moving forward to 10.15. The idea is you'll be able to 'window-shop' - take whatever you please, and please call again.
Subscriptions?
We're saddened to see that some vendors have moved to a subscription model, exacting yearly fees for what are only desktop 'local machine' applications, previously one-time payment. We've otherwise moved in the opposite direction. We charge for our efforts once only - you buys the product, you gets the product, and there are no hidden costs, no new payments for 'upgrades', aka bug-fixes.
As this particular product - the ACP - is not a single application but instead a collection of applications, and a rather big one at that. It's not meant to cost you something more if we add new applications to the collection, and it never has.
We build software the same way we teach it. We write compact single-purpose applications that do one thing only and do it well. Like Uncle Doug wanted. We're not out to dazzle you with doodads - we're out to give you what you need so you can get the job done.
So many people over the years have asked how we can get our code so compact. Our pat response is 'how do others get their code so bloated?' We hit the global stage with a few posts to the famous RISKS Digest, and even corresponded with Dennis Ritchie over it. Totally exasperated with the obscene sloppiness in software engineering, we began to pluck apart the worst offenders. Our software reviews at 'The Very Ugly' are a sample of our work. Once we'd made our point, we let it go. We're not out to bash the idiots, but to teach good programming practices. (But oh yeah, there sure are lots of idiots out there!)
Objective-C is the perfect language for developing software that targets an environment with a graphical user interface. Things are no longer procedural. It's hard to pinpoint the entry and exit points. And functions become methods which often send messages. This is all simulated for our Von Neumann machines, of course, but if the programmer uses the same paradigm as the user, then things are working well.
C is an expressive language with a limited syntax yet an abundance of operators. This leads to there being multiple ways to express the same thing. Compilers are always different. One library function can have been written by a summer temp. You notice things as you become acquainted with your environment. Try different ways to express the same thing and compare object file sizes. You'll find what works well and what doesn't.
Shared Libraries
Do not create shared libraries (DLLs, frameworks) until you have to, but don't reinvent the wheel either. It's downright stupid to place the same snippet in multiple projects if that snippet can be put in a shared library at no loss. Once you duplicate a snippet for the first time, it's time to start considering that shared library.
Corporations can have one common shared library for all their in-house work. They can include this in projects for their clients. And projects can have a common library as well. But you don't go making libraries just because you learned how it's done and you think it's cool. Libraries have an overhead you have to keep in mind.