Developing software tools needed to develop Apps and Plugs-Ins

[Naiw]

The nanokernel only exists on powerpc Mac OS 7-9, it's purpose was to abstract away the hardware (read powerpc) from the rest of the system.
However later on Daystar etc extended it to add support for threading native threads (required to utilitise multiprocessor machines such as Daystar Gensis MP that had two or four 604 cpus)
Apple eventually added similar support with the updated nanokernel in 8.6+ (along with additional features) that was not greatly utilitised or documented.
Mac OS itself does not depend upon or relay on the nanokernel at all, I just want to empathize on the fact the nanokernel was not a part of Mac OS but a underlying requirement of running Mac OS on on 68k systems- Mac OS always was and always been a 68k system and to retain compatibility with all software that could not change at any point. So Mac OS as an OS didn't really have much of a kernel.

Mac OS X however has a kernel, Originally with Rhapsody and Mac OS X Server 1.0-1.2 it used Mach 2.5 and starting with Mac OS X 10.0 and later it's been Xnu (Which at core is Mach 3.0 and the BSD server running in the same address space; Which also means Xnu is not a microkernel as Mach 3.0 but still uses lots of microkernel mechanics; message passing that is, so it's generally refered to as a hybridkernel.)

All these script languages such as Ruby, Python Lua etc was not popular and in some cases not existing by the time classic Mac OS was prime time. Perl was probably the biggest script language at the time and there was a mac version of it.
But in general I think it's not worth bothering with script languages on OS 9 or earlier, even if you find an old build of some language its most likely extremely dated and if you intend to port something yourself, be prepared to encounter about every technical problem you can imagine. Mac OS 9 was by modern standards really messed up at the core.

Stick with the established languages at the time if you intend to get something done.

If you really really consider command line stuff or similar consider looking at http://www.macrelix.org/ or https://en.wikipedia.org/wiki/MachTen (The latter is commercial and dated though- and more of running another system on top of mac os, for good and bad)

[nanopico]

MPW isn't a IDE, it's a shell (and a cumbersome one as well) but it filled a purpose in particular if you had build servers and wanted to automate stuff.

What qualifies as an IDE then? MPW is definitely an IDE.

[Jubadub]

All these script languages such as Ruby, Python Lua etc was not popular and in some cases not existing by the time classic Mac OS was prime time. Perl was probably the biggest script language at the time and there was a mac version of it.
But in general I think it's not worth bothering with script languages on OS 9 or earlier, even if you find an old build of some language its most likely extremely dated and if you intend to port something yourself, be prepared to encounter about every technical problem you can imagine. Mac OS 9 was by modern standards really messed up at the core.

Stick with the established languages at the time if you intend to get something done.

Yes, you're right, but there is a reason I brought these up, although I think I wasn't clear about it until now: I wanted to highlight all sorts of development paths, because I know some people out there other than myself will also be seeing this, and some of them are more likely to get their feet wet with general PowerPC (or even 68k) Mac development through one specific language or toolchain than another, provided they have a motive like I do. Some friends I have, for instance, are familiar with these, so the more I get uncovered, the better. I also am not strictly interested in only pre-OS-X development, although it is true Mac OS 9.2.2 is my biggest interest, so I find scripting languages that got popular only past the time of OS 9's prime are still important. I don't intend to port any of them myself, either, though. (Except maybe IBM's Node.js, but that is not a priority right now.)

Indeed, as for myself, for the sake of "getting things done", I'm actually already set on C, C++ and PPC assembly, using probably CodeWarrior Pro 9, Xcode 3.1.4, MPW and/or Fantasm/LIDE (Fantasm being an interesting program I saw you mentioning on another thread. I'll make a more detailed post on that later when I can), whichever I find suits best my needs. But I think I haven't looked at every nook and cranny yet, so I'm still after as much info on tools & everything else as possible. For my and others' sakes.


Speaking of which, those paragraphs on the kernel and those two link recommendations are being all of great help. I heard much about some of these kernel details from the good folk of this forum in other threads, and from random places online, but much of it I was completely unaware about. Thanks!

[Naiw]

MPW isn't a IDE, it's a shell (and a cumbersome one as well) but it filled a purpose in particular if you had build servers and wanted to automate stuff.

What qualifies as an IDE then? MPW is definitely an IDE.

Ok correction, MPW is not an IDE by my definition as an IDE typically is made to accelerate the development process by providing by the very least automatic project management and build automation.

But yeah okay, if MPW qualify as an IDE, then I guess Terminal.app, command.com etc are IDEs too. Or rather what would define something not to be an IDE then?

[macStuff]

https://en.wikipedia.org/wiki/CodeWarrior
read the definition of codeWarrior

lets all just 'nip this one in the bud' as they say
and just move on to the more important stuff ?? ya?



https://en.wikipedia.org/wiki/Macintosh_Programmer%27s_Workshop
the entry for MPW says that its a software development environment..
SDE vs IDE ..
close enough??

Macintosh Programmer's Workshop or MPW, is a software development environment for the Classic Mac OS operating system, written by Apple Computer. For Macintosh developers, it was one of the primary tools for building applications for System 7.x and Mac OS 8.x and 9.x. Initially MPW was available for purchase as part of Apple's professional developers program, but Apple made it a free download after it was superseded by CodeWarrior. On Mac OS X it was replaced by the Project Builder IDE, which eventually became Xcode.

MPW > ProjectBuilder > Xcode!!!
interesting to be told the history..

https://www.macintoshrepository.org/1360-macintosh-programmer-s-workshop-mpw-3-0-to-3-5

[Naiw]

I agree, it’s highly irrelevant what it is or not is.

So is the preference order of various tools as well.

It can just be established the majority of the developers after the introduction of PowerPC Mac OS tend to use Code Warrior, primary because it was the first compiler with PPC Pef support but I would also think the main reason was powerplant.

[teroyk]

The MacOS NanoKernel has some undocumented system calls to set the MSR[LE] bit. This was to accelerate VirtualPC's x86 emulation.

Wow, is this true for all PPC versions of the MacOS kernel? (Or at least from 9~10.5.)

Apparently other mechanisms been discovered as well.

https://groups.google.com/forum/m/#!topic/comp.sys.mac.programmer.help/3NK-jAdmOqg

That link is amazing, I had never thought too hard until now about user mode x supervisor mode in PowerPC MacOS. This was quite a fascinating read... Really looking forward to fiddling with this...


Also, since we are discussing all sorts of development tools and knowledge, I guess one more thing to take a look at is the availability of Ruby programming language compilers, and its most popular framework, Ruby on Rails. From quick glances online, it seems both are available for at least PPC Mac OS X 10.5 Leopard.

I also took notice that, according to the Wikipedia entry at https://en.wikipedia.org/wiki/Xcode and Apple's official documentation, the following Xcode versions exist for OS X:
- Mac OS X 10.3 Panther: Xcode v1.0 ~ 1.5;
- Mac OS X 10.4 Tiger    : Xcode v2.0 ~ 2.5;
- Mac OS X 10.5 Leopard: Xcode v2.5 ~ 3.1.4 (Wikipedia made it sound like v3.1.3 and 3.1.4 could only be installed on 10.5.7+ or that 10.5.7+ could only have those two versions of Xcode, but the official Apple documentation did not seem to indicate any such distinction amongst all the Leopard versions).
They can be obtained for free with any Apple developer account, to which, AFAIK, anyone can subscribe to. The download pages to get Xcode directly from Apple for free is here: https://developer.apple.com/download/more/
For convenience, I used a publicly-shared, pre-existing account for logging in there, found at http://bugmenot.com/view/developer.apple.com (P.S.: After pasting the password, some trailing spaces have to be removed first). Also, I think that login link should be fine, but if somehow the Mac OS 9 Lives staff finds it "risky" or anything, feel free to remove it from my post: we all can still use our own Apple IDs (or create one) to access their downloads page, anyway.

Somebody might interesting about this:
https://stackoverflow.com/questions/5333490/how-can-we-restore-ppc-ppc64-as-well-as-full-10-4-10-5-sdk-support-to-xcode-4
But how you can use XCode for making programs for Mac OS 9???

[Naiw]

That is simple to answer.

You can’t. Mac OS 9 requires PEF or XCOFF binaries, the toolchain included with Xcode only does MACH-O and that won’t work with Mac OS 9.

[teroyk]

That is simple to answer.

You can’t. Mac OS 9 requires PEF or XCOFF binaries, the toolchain included with Xcode only does MACH-O and that won’t work with Mac OS 9.

Yes I know that..but then I found interesting thing:
CodeBuilder for Classic Mac OS version 1.1
More information:
https://www.tenon.com/products/codebuilder/description/
Has anybody test this?

[Naiw]

That is simple to answer.

You can’t. Mac OS 9 requires PEF or XCOFF binaries, the toolchain included with Xcode only does MACH-O and that won’t work with Mac OS 9.

Yes I know that..but then I found interesting thing:
CodeBuilder for Classic Mac OS version 1.1
More information:
https://www.tenon.com/products/codebuilder/description/
Has anybody test this?

Yes, I have it... somewhere. It was the first tenon product I bought, never really used it to develop MacOS software, mostly just used it to play around with objective-c, to be honest it wasn't all that great. I don't remember if code builder used gcc or egcs by default- either way both was way behind MrC or CW when it came to code quality so I never found any reason to bother with the at best cumbersome process of making MacOS software with it.


Codebuilder was essentially MachTen minus networking support and a lot (really like 50 MB) or so example code and frameworks/ports of apps that MachTen didn't ship with, for example the GNUStep code base is not present in MachTen.

Either way, my recommendation is don't bother. MachTen has it's uses, Codebuilder essentially don't as the main benefit with command line based development is collaboration, and it's kind of hard to do that when there's no network support.

Said it before, CodeWarrior does it all and it's/was really good.

[Astroman]

my favourite environment has always been Open Interface by Neuron Data.
They made an expert system toolkit on Mac in the early 90s and after successfully introducing it to the market, they faced the usual 'cross-platform' dilemma.
But different than most they really nailed it by a common graphic base and GUI toolkit that kept the look and feel of the respective OS while program functionality was retained.
You could even switch the look at runtime instantly from (say) Mac to Motif or Win-3.
While developed for inhouse use originally, it became a product named Open Interface, later versions called Interface Elements (dunno those).

Have a peek in this Discovery Channe feature, lots of classic Macs on the scene...
https://www.youtube.com/watch?v=tSjPNXwcGjA
the interesting part is the 2nd half from about min 5.00 on

The company went through multiple merges and aquisitions and most traces practically vanished from the web.
Found this browsable copy of the original manual:
https://archive.org/stream/TNM_Neuron_Data_Open_Interface_technical_overview_20171017_0142#page/n1/mode/1up

Tbh it's the most well thought out oo-programming approach without having to deal with an oo-language syntax.
It's plain ansi-C and basically all needed doc is right in the header file comments - short, precise, clear.

[Custos]

Where the hell is syntho in this discussion? Wasn't it him that developes his own plugs or am I thinking of another member? I would be highly interested in messing about with some type of SDK for PT be it for LE or TDM doesn't matter.

[Protools5LEGuy]

Those are  closed platform.

Best chances to do a VST plug and "port" it with reFuse.

IIO and other users talk about MAX software&protocol. Apple and Oranges AFAIK

[Protools5LEGuy]

Maybe there is a way to do a Pluggo Plugin in Max/MsP for Protools to use it.

Easy way IMHO is "develop" VST "carbon" plugs and use a DAW as a standalone for that plug alone, and keep the Protools machine doing its tasks.

P.D. Last time I installed Pluggo on a Win Machine I regretted once I saw the list of plugs it includes. IT IS SO LONG THAT YOU CANT FIND YOUR FAVORITES ONES BACK. I warn you.

[IIO]

jupp, pluggo works with PT.

[Custos]

Is plugo win blows only? I wouldn't mind working on stuff on my laptop then porting it. Would be nice to have everything on the mac side as well. Jumping back and forth seems counterproductive.

[Protools5LEGuy]

http://macos9lives.com/smforum/index.php/topic,3158.msg20266.html#msg20266

[IIO]

like most good stuff it was mac only at first.

OS9 should be our main focus here, but you wont have any issues with windows.

you just should be aware of one minor difference, which is that the first windows version of max is newer than the latest for mac os 9.

so it has a few more vanilla objects which are not available for OS9.

you should know that list when you want to code on win but use the result on mac.

there is also a minor issue with font size. when i do somethign on windows, i usually rewrite the code later on the mac (because i am very anal when it comes to code layout).

[Custos]

Idk why but I was thinking Pluggo was an SDK. I missed the part where you mentioned PT is a closed development. I'll check it out none the less. looks pretty cool. I actually would rather use os9 but PT doesn't support VST.

[IIO]

not an "SDK" at all. you are supposed to make a "normal" max patch which includes a few pluggo-specific binaries, all of them are part of vanilla max.

i will be glad to guide you through it when you´re ready.

[IIO]

ah, about PT.

pluggo is a max runtime itself. in OS itr is installed parallel to the max programming enviroment.

this runtime works with RTAS, MAS and VST (and AU in OSX).  the pluggo plug-ins will work with all of them and you dont have to care about RTAS licensing at all - or for VST2 for that matter - because you would have a legal problem here as well since 12 months.

[Custos]

rtas would be my main goal. Where is a good starting place. complete noob I have a basic understanding of programming though.

[IIO]

for mac, PM me.

for win, search for max/msp 4.6.x and download from some moron on teh interwebz while running antivirus protection.

if you are registered for later versions, ask cycling support for a v.4 auth. they have to do it manually, but it still works.


this is how a delay effect with GUI and automation will look like. the rest is provided by the "pluggo runtime"

of course, if you want to do real stuff, it can easily get as complicated as in C++or even more - but the entry level is low.

[Custos]

I only use windows for FL studio and web surfing/file transfers. I effing hate windows. I grew up on os7/os8. Can you PM me a Links to everything I need. I bookmarked this page and download the Tuts.

[IIO]

like i once called it, the "VST" is already there, you can concentrate on the "plug-in".

[IIO]

ok will do that tomorrow. that pdf is a very nice resource for beginners indeed. others dont exist.

[Custos]

Thanks for the help 110. Will it let you do custom graphics? I just got a replacement wacom. Been needing an excuse to bust it out. 

[IIO]

more or less. you have 7 or 8 graphics objects where you can use picture files, you have pseudo-quickdraw, and if you are completly mad you could also use video and GL stuff.

shameless selfpromotion: look my GUIs here, done 20 years ago in OS9.
https://arstechnica.com/gadgets/2016/09/an-os-9-odyssey-why-do-some-mac-users-still-rely-on-16-year-old-software/3/

[IIO]

if you have a wacom... you can also use this as a midi controller in pluggo

[Protools5LEGuy]

https://forums.macrumors.com/threads/developing-for-tiger-and-leopard-powerpc-a-devlog.2383838/?post=32036127#post-32036127

User cellularmitosis

The Apple Developer Connection Reference Library​

Apple produced a monumental amount of developer documentation, but resurrecting it from internet bitrot takes a bit of effort.

I've taken a copy of the reference library from the last ADC DVD set before the library was re-oriented towards Snow Leopard, put it up on github (with all of the sample code .zip files expanded for online browsing) and made it browseable via plain HTTP at http://leopard-adc.pepas.com/

I've also corrected all of the "Featured Article" links (which are all long-since defunct links to developer.apple.com) to point to copies from the Internet Archive via the Wayback machine.

There, in legacy documents,
http://leopard-adc.pepas.com/referencelibrary/LegacyTechnologies/index-date0.html
 if you browse bottom you can find some docs that I think are missing today on Apple Developer link


Like this http://leopard-adc.pepas.com/technotes/pt/pt_12.html#//apple_ref/doc/uid/DTS10002666 Technical Note PT12
C++ Pitfalls in MPW

Important: This document is part of the Legacy section of the ADC Reference Library. This information should not be used for new development.

Current information on this Reference Library topic can be found here:

    Reference Library > Tools

Technical Note PT12
C++ Pitfalls in MPW
CONTENTS

Introduction

Class Protection and Inheritance

Type Casting

General Class Issues

Operator Overload Issues

Inlining Issues

Memory Leakage

Tricks to Help You Find Memory Leaks

Virtual Functions

Compiler Issues

Testing/Debugging

References

Downloadables
   

This Technical Note covers most of the common and serious subtle problems that a MPW C++ user might encounter. For more information consult the current C++ literature. This Note will be updated periodically to reflect changes in the language and the compiler. Always read the release notes included with the MPW C++ to find out the latest status for known bugs and restrictions.