This page is a wiki. Please login or create an account to begin editing.


69 posts / 0 new
Last post
RogerWilco's picture
Offline
Joined: 2018 Nov 19
Trying to Get into Mac OS Programming

Hello! I'm very new to the forum (I only created my account a few minutes ago) and I have some questions regarding Mac OS application programming.

So, some backstory: I was thinking about programming for the Macintosh (Mac OS 9 specifically, although X would also be awesome) and I thought it would be neat to program a war-dialer that took advantage of the built-in modem of the Power Mac G4 systems.

So, I'm working on learning C++ and C with the help of some introductory guides on Macintosh programming. Next would be to learn how to interface with the modem and audio system. Does anyone have any suggestions as to what to look at for reference? Any other tips on Macintosh Programming or C/C++ in general would be greatly appreciated.

Thanks! Smile

EDIT: I am using Xcode 2.5 on Tiger and Metrowerks' Codewarrior Pro 6 on OS 9.

Comments

Duality's picture
Offline
Joined: 2014 Mar 1

Mac OS X is relatively easy to get into. All the documentation you need is on the DVD for Tiger and Leopard, and the Xcode SDKs had updates to that as well. OS X's underpinnings are pretty close to BSD Unix too so there's no weird networking libraries to learn like MacTCP or Open Transport.

The entire "Welcome to Xcode 3.1" screen that greets you takes you directly to Apple's docs. But for an easier intro, Aaron Hillegass' "Cocoa Programming for Mac OS X" series is fantastic, third edition covers Tiger and Leopard; https://www.amazon.com/Cocoa-Programming-Mac-OS-3rd/dp/0321503619

Aaron started as the developer documentation writer for NeXTSTEP, so he is good!

Then there's the follow up from Mark Dalrymple, Advanced Mac OS X Programming, which gets into signals and sockets and DTrace and other fun things for 10.4, 10.5 and 10.6; https://www.amazon.com/Advanced-Mac-OS-Programming-Guides/dp/0321706250/...

Mac OS 9 and earlier is... where things get far more tricky.

Inside Macintosh and the Apple developer library aren't nearly as easy to get ahold of or as easy to read, and the classic Mac Toolbox is filled with dated Pascal and C-isms. Only the printed versions have particularly easy to read graphs, and the documentation was already infamous for being hard to understand, especially in its earliest forms.

There is a CD-ROM version of Inside Macintosh on the Garden, coupled with the PDF books on the CodeWarrior Pro CDs that try to offer an easier intro to classic Mac programming. That's probably the best way forward with what's out there and easy to get.

For most people who want to do something with the classic Mac though, they might be better off with HyperCard, Director 3.1.3, or Director 6.5, depending on how fancy of a Multimedia thing they want to do and what Macs they want it to run on.

Hope that helps?

Idéfix's picture
Offline
Joined: 2018 Oct 14

"For most people who want to do something with the classic Mac though, they might be better off with HyperCard, Director 3.1.3, or Director 6.5, depending on how fancy of a Multimedia thing they want to do and what Macs they want it to run on."

Why not programming in Python 2.3, available here on the Garden? Easy to learn, with lot of free legit documentation elsewhere on the web. At need, I may help to find these ones.

http://macintoshgarden.org/apps/macpython-233

And for programming books on Classic Mac OS, VintageApple.org is probably the best source:

http://vintageapple.org/macprogramming/

Duality's picture
Offline
Joined: 2014 Mar 1

There are definitely many other alternative environments (Oberon! Dylan! Smalltalk/V!) although many of them, including Python, get further away from using the Toolbox directly. I assume that people wanting to write software on the Mac want to use the Toolbox (tricky), or do a flashy multimedia thing like most early to late 90s developers did (easier).

Mac OS didn't even ship with a standard C or C++ library or even a terminal-like window, those were provided by compiler vendors like THINK and Metrowerks to make the lives of programmers easier. I think SJ was deeply against shipping a command line interface with the Mac in its early, early years, which made the lives of early Mac developers like Infocom who were used to command lines.. not super fun.

For the stated purpose of modem dialing, and avoiding MacTCP, Python 2.3 might just do the trick~! The online docs are still fully intact; https://docs.python.org/release/2.3/

There's also a very recent Lua port referenced on Bolkonskij's site, www.macostoday.com . I remember Lua was faster and it seems to be one of Adobe's present day languages of choice. There's a presentation on how it was chosen to build Adobe Lightroom, which I linked to in the Lightroom 2 entry. One caveat I know of, Lua's documentation wasn't as great as Python's, and that's probably still the case.

adespoton's picture
Offline
Joined: 2015 Feb 15

(Partial dupe)

adespoton's picture
Offline
Joined: 2015 Feb 15

I can second the Python 2.3 idea, as I helped debug the Mac port of that. I wrote an entire Internet BBS using Python 2.3, complete with file transfers, chat and a bulletin board system. It also had a plugin architecture for BBS door games and the best part — it compiled itself in real-time so you could make live changes to it and anyone new who logged in would inherit the changes.

The server could run anywhere that supported asynchronous sockets on Python 2.3.

RogerWilco's picture
Offline
Joined: 2018 Nov 19

Thanks for the information on OS X programming! Smile

There is a CD-ROM version of Inside Macintosh on the Garden...

Would you mind directing me to the correct link? I did a search for "Inside Macintosh" and that came up with nothing as you describe. Smile

Duality's picture
Offline
Joined: 2014 Mar 1

http://macintoshgarden.org/apps/inside-macintosh-cd-rom and the "see also" has links to other official Mac media in CDR and PDF format.

I just tried searching for it with and without quotes and it seemed to come up in the first three hits.

RogerWilco's picture
Offline
Joined: 2018 Nov 19

Ok, thank you! Smile

Offline
Joined: 2015 Aug 25

Inside Macintosh and the Apple developer library aren't nearly as easy to get ahold of or as easy to read, and the classic Mac Toolbox is filled with dated Pascal and C-isms. Only the printed versions have particularly easy to read graphs, and the documentation was already infamous for being hard to understand, especially in its earliest forms.

At one time I had the Addison-Wesley printed versions of Inside Macintosh volumes 1-4. I don't recall them being difficult to understand. In fact, I remember thinking they were very well written and did a good job of explaining what were new at the time concepts related to GUI programming.

The difficulty with classic Mac programming was in the complexity behind even a simple "hello world" application. This is why every major language shipped with its own framework or set of libraries which wrapped Toolbox and took care of mundane stuff like the event loop.

Another wrinkle is that Toolbox relied heavily on pointers, handles (pointer to a pointer), and callbacks by function address. You had to think about memory and resource management. You worked at a lower level than you do with modern, high level languages. And the consequences were more severe (you could easily crash the OS).

Still, I wouldn't want to scare anyone away from "real" classic Mac OS development. Just beware that it's a distinct OS with its own solutions and design patterns for common problems. Some of those patterns will seem very foreign today because the Toolbox API started life on a machine with an 8 MHz processor and only 128K of RAM.

Duality's picture
Offline
Joined: 2014 Mar 1

I’ve wondered if I did make a bit much about the difficulty of early Mac OS. A problem I’ve observed is that someone will try to take the bull by the horns and do Carbon + 68k compatibility before they realize that drawing text to a window is much harder than on iOS or OS X.

Still, you’ve done a great job of outlining its thorns and not so bad bits. Subtly, I wanted to add that the DOCMaker Inside Macintosh documentation on the official CD-ROM has terrible illustrations, generated from FrameMaker sources with too much compression. The PDF versions from Apple do not have this problem, but not every volume of Inside Macintosh has an easy to find, officially produced PDF. It’s mainly the OS 8+ vintage docs.

WhosIt.There's picture
Offline
Joined: 2014 Aug 23

I can't say I ever had any problems doing Mac programming in the System 7 and MacOS 8 and 9 days using Think Pascal. Before that I was programming was using Apple II and Commodore computers, and started with real BASIC (as against REALBasic). Smile

Duality's picture
Offline
Joined: 2014 Mar 1

Tangent: Somewhat after the fact, I was wondering why nobody has tried wrapping Toolbox constructs with C++ smart pointers, to avoid the biggest overhead with managing _handles_.

Like how Win32 programming evolved to be more friendly to various flavors of smart pointers ( sort of akin to https://www.codeproject.com/Articles/1458/A-COM-Smart-Pointer ), and Mac OS X 10.6 rolled out "automatic reference counting" where every Objective-C pointer is a smart pointer, removing the need to explicitly send "Retain" and "Release" messages to objects.

Maybe it was an idea that was fashionable after OS 9 passed on from current software development. Or maybe it wasn't trivial overhead around the time when low and high memory regions were critical to understanding early 68k programming.

There's... lots of little cavernous curiosities to consider, before drawing something to a window with QuickDraw calls. Smile

Offline
Joined: 2011 Jul 21

>I was wondering why nobody has tried wrapping Toolbox constructs with C++ smart pointers, to avoid the biggest overhead with managing _handles_.

They did. It was called MacAPP. It was written at Apple and adopted by Adobe. But Adobe engineers soon began to (wisely) distrust the Apple development of MacAPP and took the source to create their own version. The integrated Adobe GUI used by many of the Classic versions of their products were built using their MacAPP version and their common set of libraries.

Gary

Duality's picture
Offline
Joined: 2014 Mar 1

Interesting! I never looked closely at MacApp. By the time I looked through it in the early 2000s, it seemed like something that would take more effort to learn and build with CodeWarrior Pro than it was worth. Although I did like what I heard of its earlier, Object Pascal based variants, the C++ version didn't seem to be that widely adopted outside of Adobe.

The WikiWikiWeb mentions that MacApp (C++) was maintained by volunteers at "Club MacApp" through the Carbon years but that website and version of MacApp seems to be gone. Internet Archive has a few things; https://web.archive.org/web/20060615183257/http://www.clubmacapp.com:80/

Metrowerks PowerPlant became the dominant higher level application framework, used by Macromedia, Bungie, and too many others to name.

It looks like some folks built their own smart pointers for PowerPlant like with "HSharableResource" at http://www.hsoi.com/hsoishop/powerplant/hsharableresource.html

Duality's picture
Offline
Joined: 2014 Mar 1

...digging just a bit further, it looks like HSharableResource's author leveraged PowerPlant's much simpler LSharable and TSharablePtr interfaces to build it.

He explains the usage of smart pointers in PowerPlant quite well in a blog comparing it to... Swift, in 2015. Still super-relevant to classic Mac best practice patterns. https://hsoienterprises.com/2015/11/02/on-custom-operators/

It's a little different from standard C++11 smart pointers (shared_ptr, weak_ptr, unique_ptr) but by no means completely foreign to the concepts.

Bolkonskij's picture
Offline
Joined: 2009 Aug 3

Roger, I salute you for your efforts! Really happy to see a growing interest in coding for MacOS(9). Exactly for that reason I've started www.macostoday.com a few weels ago, to supply the interested newcomet with code snippets and helpful tutorials.

Unfortunately I've been awful busy the last two weeks but I'm planning on updating the content this weekend. (more snippets, maybe another tutorial). Threads like that really motivate Smile

and btw, always remember there's a toolbox call for (almost) everything Smile

RogerWilco's picture
Offline
Joined: 2018 Nov 19

Thank you! I have bookmarked your site and will look at it for new updates daily. Smile

I see you have a page on C and C++, which should help me a lot! I also see you have a Jabber server set up, which I'll try out later today.

and btw, always remember there's a toolbox call for (almost) everything

Does that mean I can use a toolbox call to send commands to the modem? Smile

Offline
Joined: 2015 Aug 25

Does that mean I can use a toolbox call to send commands to the modem?

If memory serves: you will use Toolbox calls to open a serial port, then read data from and write data to the serial port. Toolbox doesn't know what you've connected to the serial port and does not help you form or parse the serial port data itself. But modems implemented a common command set (AT command set, otherwise known as Hayes command set). So you can control any modem from that period using AT commands over the serial port.

RogerWilco's picture
Offline
Joined: 2018 Nov 19

Ok, thank you! My main machine is a Power Mac G4, so it doesn't have serial ports. Would there be any differences or is it still considered a serial port by the Mac OS? Smile

Offline
Joined: 2015 Aug 25

Modem access is likely still presented as if it was via a serial port for backwards compatibility.

RogerWilco's picture
Offline
Joined: 2018 Nov 19

Ok, that is good to know. Thanks! Smile

RogerWilco's picture
Offline
Joined: 2018 Nov 19

Thanks everyone! Smile

I guess my next question is this: what language would be most supportive of interfacing with hardware like the modem.

Duality's picture
Offline
Joined: 2014 Mar 1

68k or PPC ASM, Pascal, C.

The OSes were largely written in those languages; System 6 and before in 68k assembly, System 7 in Pascal, Mac OS 8+ in C/C++. It makes sense that driver interfaces would expect you to be writing in those languages. Just like Mac OS X and Objective-C or Windows 95/NT and C++.

Like MacOS Today in http://www.macostoday.com/c.php , I think C is probably the smarter choice. By the time of Codewarrior and PowerPC, C and C++ ruled the land.

Down the road, there will be some need to convert to and from Pascal strings that don't match up perfectly with their C/C++ string types, but every Mac compiler and the Mac Toolbox itself have nice C macros to handle the conversions.

RogerWilco's picture
Offline
Joined: 2018 Nov 19

Ok, thank you! I'm learning C/C++ currently, so that will be very beneficial. Smile

nil0bject's picture
Offline
Joined: 2012 Nov 14

Your app idea is perfect for REALBasic.
All the libraries you need and documentation are built into the IDE.
I learnt the AT codes very quickly because of the speed of development.
Older versions of realbasic can compile for 68k/ppc and carbon. Newer version do cocoa.
http://www.xdevmag.com/browse/3.3/3310/

nil0bject's picture
Offline
Joined: 2012 Nov 14

also, existing Mac war dialers:
http://www.hackcanada.com/whacked/filelists/war.html

RogerWilco's picture
Offline
Joined: 2018 Nov 19

Ok, thank you! I'll look into it. Smile

nil0bject's picture
Offline
Joined: 2012 Nov 14

forgot to mention realbasic can use cocoa/carbon declares. meaning you can write supporting libraries in whatever language you choose, as long as it compiles.
eg. http://www.jo-tools.ch/realbasic/lioncocoadeclares/
and toolbox calls:
https://www.apeth.net/matt/downloads/clipbSource.sit.hqx

Declare Function MySpeakString lib "SpeechLib" Alias "SpeakString" (SpeakString as pstring) as Integer

RogerWilco's picture
Offline
Joined: 2018 Nov 19

Ok, thanks for the information! Smile

WhosIt.There's picture
Offline
Joined: 2014 Aug 23

The problem with REALBasic is that it creates over-bloated apps because it always puts in the massive standard library file of routines, including all you haven't used. Same happens with programming applications such as HyperCard, SuperCard, FileMaker Pro, etc. when compiled into standalone apps. Such systems may be good for simple use or those who don't care about app size, but they're very inefficient as "serious" programming tools ... but that hasn't stopped some apps being written in them being sold as shareware or even commercially though.

A simple "Hello World" app written in Think Pascal or C will be a few kilobytes in size, but the same app in REALBasic and the others will be megabytes in size.

The single bonus with REALBasic (and a few others) is that it can also create Windows versions of the app quite easily on the Mac. FileMaker Pro can create a Windows version, but for some silly reason it has to be created on a Windows computer (but the actual data file containing the programming scripts can still be edited on the Mac afterwards).

nil0bject's picture
Offline
Joined: 2012 Nov 14

I get what you're saying, it's an old argument. Maybe it applied when the only removable media we had were floppies, but I don't see it as an issue any more. I don't know anyone who bought a classic mac to run a hello world app.
But I think we can all agree that all programming tools have pros and cons, Think Pascal and C included.

WhosIt.There's picture
Offline
Joined: 2014 Aug 23

The only con I ever came across with Think Pascal was when the fools at Symantec took it over and then pretty much just left it to die. That's usually what happens when these big companies take over someone else's products - same happened when Adobe took over PageMaker. Sad

Think Pascal is still THE best programming environment I've ever used.

RogerWilco's picture
Offline
Joined: 2018 Nov 19

The problem with REALBasic is that it creates over-bloated apps because it always puts in the massive standard library file of routines ... A simple "Hello World" app written in Think Pascal or C will be a few kilobytes in size, but the same app in REALBasic and the others will be megabytes in size.

That's good to know. Thanks for bringing that to light. Smile

Offline
Joined: 2015 Aug 25

The problem with REALBasic is that it creates over-bloated apps because it always puts in the massive standard library file of routines, including all you haven't used.

This is false. RB always had a linker which stripped unused libraries. It's ability to strip unused code wasn't as fine grained as with better C/C++ linkers, but it was certainly there.

It also always had a real compiler and produced native 68K, PPC, and x86 binaries. HyperCard, SuperCard, and FileMaker Pro were interpreted systems.

A simple "Hello World" app written in Think Pascal or C will be a few kilobytes in size, but the same app in REALBasic and the others will be megabytes in size.

This is also false. RB 3.5.2 was the last version (I believe) to support 68K apps. Smallest size for a GUI application was 348K. Smallest PPC size (same version) was 1.2 MB. This was comparable to contemporary tools in 2001 when it was released.

Think Pascal and C were not contemporaries to RB. They were earlier, lower level, with fewer features in their own libraries. Which is understandable since they trace their lineage to literally the first compact Macintosh systems.

If you want to write an app for early model 68k Macs, Think Pascal and C are good choices. For late model 68k Macs, and PPC Macs, both RB and CodeWarrior become viable options.

Whether I would choose CodeWarrior (C/C++) or RB would depend on the task at hand. I can say that a war dialer would be trivial to write in RB 3.5.2 using their Serial Control. Compiled for 68k you would probably be looking at a 400-600K binary that required Mac OS 7.6.1 or higher. Not sure if it would also require a 68020 or higher, or if it would run on the 68000.

nil0bject's picture
Offline
Joined: 2012 Nov 14

http://www.think-pascal.org
Guide to Think Pascal, written by Ingemar Ragnemalm(creator of the sprite animation toolkit)!!!
@WhosIt.There : Have you tried the Lightweight IDE? What are your thoughts?
http://www.ragnemalm.se/lightweight/

RogerWilco's picture
Offline
Joined: 2018 Nov 19

Thanks for the resource. Smile

WhosIt.There's picture
Offline
Joined: 2014 Aug 23

I haven't seen that one before. From a quick skim though the pages, it looks like it might be okay-ish ... eventually. It does look a bit amateurish and under-featured compared to Think Pascal of course, but then it is only version 1.0 and obviously doesn't have anywhere near the same amount of money, people, and time behind it, so it also means it's very unlikely to ever topple Think Pascal from being my favourite programming environment.

Think Pascal was simply a dream to use. No mucking about with separate editors and compilers, no need to waste time compiling and recompiling simply to test run something (you just run it within the programming environment), etc.

Jatoba's picture
Offline
Joined: 2018 Apr 16

Just wanted to chime in and say that I, too, have been very interested in Mac OS 9 development. I meant to make something last year, but somehow didn't organize myself properly to make any of it happen. Hopefully I'll at least do _something_ this year. Bolkonskij said these posts inspire him to build that website for Mac OS 9 development & guiding, so here I am, voicing it! In fact, people even willing to help like that inspires _me_ to develop something!

C seems like the "best" bet for OS 9 development, but I'm keeping an eye at Java (almost out of morbid curiosity) and, especially, PowerPC assembly. The latest, free and open version of Power Fantasm is my Mac OS 9 IDE of biggest interest. They also provided a VERY awesome and well-put PowerPC assembly guide.

I'll see if I can find the links later today.

Also, I was wondering: is there any version of XCode that can target OS 9, carbonized or not? Or even a version of Project Builder IDE within Rhapsody / Mac OS X Server 1.0~1.2v3 to target it?
68k support would be cool, as well, but I doubt any version of either Projet Builder and XCode had it as a target.

Also, about Think Pascal, which was so praised, what about Think C? Isn't it about as good, but for C instead?

Duality's picture
Offline
Joined: 2014 Mar 1

Very early versions of Xcode could build PEF binaries that OS 9 could read, instead of Mach-O. I know Xcode 1.x and 2.x could do it under Panther and Tiger respectively with the Xcode Legacy package, although there was no official support for that. Most used CodeWarrior for Carbon even after Metrowerks/Freescale stopped making new Mac versions after Mac OS X 10.3, in part because CodeWarrior came with fantastic documentation and goodies.

For that reason, I'm not sure that Xcode's the sharpest tool in the shed to attempt PEF built, OS 9-compatible Carbon. The old Mac OS X 10.0 through 10.2 SDK's PBX (aka "ProjectBuilder with a space") could build Carbon apps too, but that was generally considered inferior to CodeWarrior. CodeWarrior was the PPC compiler package for anything before Mac OS X 10.4.

I don't know about starting new app development in Carbon, it's a bit of a weird compatibility platform that imitates a fraction of the Toolbox with less strict handle usage. Back then, large companies would send their engineers to Apple to work together in "Carbon Development Kitchens" to figure out how to port to Carbon and not have bad performance while smaller teams did new projects in Cocoa. It might be best to start simple, target 8.6+ first, and think about Carbon after a milestone.

Yes, Think C (previously Lightspeed C) is still considered very good for 68k Mac development. The only thing that slows it down compared to Think Pascal is that it needs to have a C preprocessor. C is two languages in one, Pascal kept things simple. C is more commonly used today. Use the best tool for the job!

Jatoba's picture
Offline
Joined: 2018 Apr 16

Thanks for sharing the wisdom. I'll keep mainly CodeWarrior in mind whenever I consider Carbon apps. But it seems Carbon is one thing I'll want to avoid in general, and only consider porting things to it as opposed to starting something fresh straight with it, considering my OS 9 focus.

It's a bit sad to know Think C requires a preprocessor, though. At best, I guess that means slightly longer compile times, but it bothers me we can't see what is effectively compiled in the end because of it. Though I assume it shouldn't be a major issue.
I simply wanted to consider Think C over Think Pascal because, if for nothing else, I really never laid a finger on Pascal! Maybe that will change someday.

Now it just occurred to me: I'm not sure what program exactly even I'd even want to build for OS 9. So I was thinking, is there a list somewhere that tells what programs System 7 ~ Mac OS 9 users would like to have, but don't? If not, maybe a "feature requests" topic could be made. I think it'd give people like me a greater sense of purpose in getting started and involved.

Duality's picture
Offline
Joined: 2014 Mar 1

For clarification, my bit about the tradeoffs of using C on the Mac was about issues with programming languages. Not an issue with THINK C. "[...] it needs to have a C preprocessor" was referring to the C programming language writ large.

C always needs a preprocessor because that's part of the language spec and definition. If THINK C didn't have a C compiler and a C preprocessor, then it would be supporting a mutant language that isn't really C. The presence of a preprocessor doesn't prevent you from seeing the generated assembly.

Borland's Turbo Pascal on the PC also benefitted from fast compile times for the same reasons. Pascal is a simpler language than C and especially C++.

No list that I'm aware of, regarding apps people want to have written. Perhaps that's a good feature request? Smile

Jatoba's picture
Offline
Joined: 2018 Apr 16

Oh man, what an embarassing mistake I made. Facepalm I assumed "prepreprocessor" to be something like how C# and VB.NET are "pre-compiled" into MSIL. https://en.wikipedia.org/wiki/Common_Intermediate_Language
So I assumed C was being "pre-processed" into some other intermediate language (i.e. Pascal) before being even turned into assembly, and that seeing the resulting "intermediate" language would be inconvenient! Since I hadn't heard of the terminology before, in my mind I never separated the C preprocessor from the rest of the language itself.

Hopefully my stupid mistake will be educational to future visitors! Doh!

As for a feature request list, then perhaps getting one up would be cool. Smile

BryMD's picture
Offline
Joined: 2018 Jul 1

First of all, it's wonderful to see how many of you are contemplating developing for Classic Mac OS Smile

Secondly, I feel I have to forcefully step on the break here a bit before this thread turns into a 'my programming language is better than your programming language'-thread. I know I'm exaggerating this quite a bit right now, but I'm a litte wary that this benign exchange of well-meaning personal preferences might stand in the way of ACTUAL PRODUCTIVE Classic Mac OS application development.

As such, here are my two cents as an ACTIVE Classic Mac OS developer:

1. If you already kind of know a programming language, USE IT! Starting from scratch trying to read up on a language you don't already know will, more often than not, transition from 'that better programming language' to 'that final nail in the coffin' even before ACTUALLY starting to create your awesome new application.

2. Develop something YOU YOURSELF have the need for. Developing an application ALWAYS takes more time and effort than you think it will, and the motivating cheers from us fellow Classic Mac OS users are fewer and further between than when developing for Mac OS X (at least in my own experience as a developer of half a dozen freeware Mac OS X applications). So, if you yourself don't have anything to gain from all the time and effort you're putting into it, chances are that your motivation will rund dry before your awesome new application sees the light of day.

3. Try to find other fellow Classic Mac OS users who either have a better understanding of the chosen programming language than you, or have the time and motivation to help you beta your awesome new application. There will be times where your knowledge, your programming book and the historic internet won't be of any help. And when that time comes, being able to throw ball with someone with a better understanding than you or getting someone to help you beta in a different environment that yours will be worth its weight in gold.

4. Be painfully aware that the difference between success and failure is ONLY defined by your capacity to see things through. As such, treasure the TRUTH that, by following through with the development of your awesome new application, you are one of a precious few who are keeping Classic Mac OS flowering and actively preventing Classic Mac OS from fading into obscurity.

So I say: GO FOR IT! CREATE THAT AWESOME NEW APPLICATION! AND KEEP OUR BELOVED PLATFORM BLOOMING! Laughing out loud

Jatoba's picture
Offline
Joined: 2018 Apr 16

2. Develop something YOU YOURSELF have the need for. Developing an application ALWAYS takes more time and effort than you think it will, and the motivating cheers from us fellow Classic Mac OS users are fewer and further between than when developing for Mac OS X (at least in my own experience as a developer of half a dozen freeware Mac OS X applications). So, if you yourself don't have anything to gain from all the time and effort you're putting into it, chances are that your motivation will rund dry before your awesome new application sees the light of day.

Rolling on bed last night, I came to realize this might be a very good approach. I still wouldn't at all mind making what others would like to see, as well, however. Smile That in itself is also very motivational for me, even if there's no praise sent back to me for it, as long as the resulting program can be useful.

Also, props to you for making Functional Keys! http://macintoshgarden.org/apps/functional-keys/
Very useful and necessary little program. Smile Love it.

BryMD's picture
Offline
Joined: 2018 Jul 1

Damn, Jatoba! You just made me look like a complete self-centered douche with that reply, hehe Laughing out loud +1 for that one Wink *taking a deep breath and getting ready to justify my choice of words* Tongue

Misunderstand me correctly. When I say 'motivating cheers', I'm talking about any palpable sign that your application ACTUALLY is being downloaded and put to good use by anyone. The Garden is devoid of anything reminiscent of a download counter (for obvious reasons Wink ), and, as such, there is no objective gauge to know if your brand spanking new application is being used by 2000 people or 2 people. On the Mac OS X-side of things I have apps downloaded 75,000 times and apps downloaded 500 times, and this helps guide me where to focus my attention. I don't have similar measurements on the Classic Mac OS-side of things, and that's why the 'motivating cheers' is of such immense value when trying to obtain a gut feeling on whether or not your time and efforts are falling on deaf ears.

On a similar note, I sincerely appreciate your kind words on Functional Keys. That's a +1 on my imaginary download counter - see how that one works Wink

Anyways, props on showing passion for Classic Mac OS application development! I hope you succeed with whatever crazily awesome application you decide to develop in the end Laughing out loud

BryMD's picture
Offline
Joined: 2018 Jul 1

And since you where requesting suggestions for potential applications that people would want, I have one for you Smile

The last piece in my own Classic Mac OS puzzle once Functional Keys hits versions 2.0 is a screen saver playing a sequence of QuickTime movies in full screen which starts after a certain idle time and stops upon keyboard press/mouse input.

To put this in context: I have a near complete collection of in-store demo loops of Macs from the 20th Anniversary Macintosh up to the G4 Quicksilver (only missing iBook Rev. A I believe) that would make for the most awesome screensaver EVER Laughing out loud

I already have a proof-of-concept application up running turning Seagull Video Player 2.0 into exactly this, but it has an unholy amount of dependencies that cannot be avoided until a valid serial number for Seagull 2.5 surfaces (which probably is never).

A screen saver built from the ground up with this purpose would circumvent all these dependencies and Seagull all together, but creating something like this is way above my coding proficiency.

Another option would be to code a proper Fader for Setting Sun with this function. There already exists a Fader with this function (QT Float), but that one is so inefficiently coded that it completely breaks my fully spec-ed iMac G4.

No worries if this isn't your cup of tea, though Wink

And on a side note: If the in-store demo loop collection is of interest for others here at the Garden, give me a hint, and I'll upload it Smile

Edit: Missing iMac Rev A. loop (iBook Rev. A loop I have), but don't even know if Apple ever made one. Never seen it in the wild, at least.

nil0bject's picture
Offline
Joined: 2012 Nov 14

couldn't 'functional keys' provide the screensaver functionality?
maybe it won't activate after a certain amount of time, but manually via the function keys?
maybe a "Play content..." function that let's you choose a folder of media to play?

BryMD's picture
Offline
Joined: 2018 Jul 1

Functional Keys could easily provide screensaver functionality, but it either would still have a crap-ton of dependencies, or would have to run as a background only application with a keyhook and repeat-timer which would break compatibility with earlier OSes - I'm primarily doing scripting/resource fork work, remember Wink

As such, either my own 'Seagull AutoPlay' application or a self-contained screen saver by someone else would still be the way to go.

And to paint the picture of why such a function is so valuable to me:
Imagine the feeling of the first time you set foot inside an Apple Store in the early 2000s... seeing all the freshly released Macs... secretly dreaming of bringing every single color... every single size... every single shape... home with you... regardless of cost... or table space... or mental sanity... all of them synchronously playing these gorgeous full screen demo loops...

...Yeah, THAT feeling Wink

Idéfix's picture
Offline
Joined: 2018 Oct 14

Speaking of visual gadgets, an abstract animated sequence running in background on the desktop instead of a plain wallpaper would be the utmost coolness. Somethig like the OpenGL scrensavers available on the Net for eons.

http://s.sudre.free.fr/Software.html

Since you seem to be a Mac user for a long time, I assume that you are probably also old enough to have seen the UFO Series from Gerry Anderson. Remember the psychedelic "painting" in Stryker's office?

Beginning at 37:00:
https://www.youtube.com/watch?v=mcFcRvyyZZw&index=20&list=PLCrrUDXZPa_nJ...

nil0bject's picture
Offline
Joined: 2012 Nov 14

woah, is that where siri came from. ha