Introducing my first MARCHintosh project - GlobalTalk Chat 1

Posted 2026-03-01 | Back to blog index

Introducing my first MARCHintosh project - GlobalTalk Chat 1.0! The AppleTalk-native (no TCP/IP) chat system, now re-written from the ground-up as a native Mac Toolbox application in C.

You can get it NOW on “Blackbird” or “landisk” in the “BaroNet” zone on GlobalTalk.

A screenshot of a basic chat application running under System 7 A screenshot of a basic chat application running under MacOS 9

Originally released as a proof-of-concept HyperCard stack in 2024 and pushed to the limits of what HyperCard could do in 2025, I wanted a program people would actually use - one that didn't bring older Macs on their knees just sending lines of text - ideally something you left running in the background. This does that, in a program that can consume just 120 KB of RAM. (2/3)

This initial version is very basic, and indeed is even missing the popular Cairo/Talesin “emoji” feature of the HyperCard stack, but it's built with extensibility in mind, so look forward to things like user avatars and custom emoji being added in the future!

There's also the question of stability. I think the client is in really good shape now, but the server end does not even attempt to deal with memory fragmentation so my solution there will be “I'll just allocate 10 MB of RAM” (3/3)

Background:

I spent most of MARCHintosh 2025 just punishing HyperCard, and after my experience writing AIRConfig back in 2024, I just wanted nothing more than to move on to C to avoid butting heads against HyperCard's limitations (when your stack crashes HyperCard, you know you're done). (1/6)

AIRConfig was made just hacking apart one of the really early Apple code samples included with MPW. So in order to make fully-featured, MacOS 8-themable tools, I first set out to write a framework I could work in.

I know there's MacApp/PowerPlant, but

① Not in the mood to learn C++

② I wanted this to be an experience to learn how Mac Toolbox apps work from the ground up, not just learn how to plug code into an outdated framework. (2/6)

My goal was also to follow in the footsteps of the people I looked up to in the 90's who wrote those great Mac applications I grew up with and see if I could do the same, since it seemed so magical and unattainable at the time. I want to make applications with the polish that they could have been sold as shareware. (3/6)

In the months following March 2025 I created a framework for my utility apps. You can find an initial release here https://github.com/kalleboo/SimpleMacApp (uhh don't use this code I need to update it with a lot of elemental fixes I've made since then) (4/6)

After that I had lots of ideas for things I wanted to make. I started working on AppleTalk code to scan and map the whole network and on an ATP client/server library. But then I lost my job, and bought a house, and have spent the time since scrambling with short-term projects to pay the mortgage. (5/6)

So a couple weeks ago I realized the deadline was whizzing past and had to choose a project to complete, and Chat was the most interesting one, since it can be a base for a bunch of other ideas I have. (6/6)

The Making Of:

In the making of Chat, without exaggerating, I think I have rebooted my Macs over 200 times. Easily. 20 times a day. So many crashes. Accidentally send a bad pointer to AppleTalk? Hard freeze. Reboot. So many pointer dereference errors. So many C “oops didn't initialize this variable, it points into outer space”. (1/4)

Just getting the basics right with the different data structures is what took up the bulk of the time coding and debugging. All those linked lists going backwards and forwards. In comparison, throwing on new features at the end like preferences and sound/notifications was trivial. (2/4)

Some bugs just cause self-doubt about the whole project. Is this network timeout a fundamental issue with how primitive AppleTalk is or did I just mess up a loop somewhere? (it was always the latter). I've definitely learnt to appreciate modern OOP data structures where you don't have to keep re-implement the wheel for each situation. And virtual memory, where you don't have to use Handles. (3/4)

And while Inside Macintosh was great for its time, by modern standards it leaves you confused. You really need to read things cover-to-cover since just looking up functions leaves out critical details about where memory should be allocated or released. And even then it really does not help you as soon as you're coloring out of the lines of their examples.

Uhh I think I'm rambling now so I'll end this thread here. (4/4)

Adding a note on compatibility: this runs in anything with System 7 and up and only requires 384 KB RAM.

edit: starting with version 1.0.2, GlobalTalk Chat also works on systems without Color QuickDraw

We're blasting through the updates today fixing the bugs and adding some creature comforts.

Compared to 1.0, the current version 1.0.4:

• Now supports Macs without Color QuickDraw

• Adds tab complete for replying to users

• Adds nickname highlight when you have been replied to, including a different alert sound

• Fixes issues with: chat log scrolling back to the bottom, incomplete user list, no sound, timestamp display, text going under the scrollbar

1.0.5 is out:

• “Reveal Mentions" feature to see if you were mentioned while away

• More options for the chat sounds/background notifications

• Tab-complete is now case-insensitive

• Much faster connect on older devices

• Copy/Paste to/from other programs is fixed

• Message character limit is enforced

• Tweaked connect window server list width (wasn't taking scroll bar into account so it was 16 px off)

• Snazzy logo in About window

Day 1 is over!

It went beyond expectations!

After all the crashes, timeouts and corruption I constantly had during development I was expecting once it hit a wider user base to be full of major issues. But as far as I can tell, my debugging paid off, no reported crashes*, and all the timeouts were just due to MacOS typical multitasking fun

We also easily smashed the simultaneous user record of the HyperCard version pretty much off the bat, without breaking a sweat!

Cumulative counts:

A screenshot of MacOS 9.2 showing a status window ServerServer Name:kalleboo's hangoutStartStatus:Running.Users:23Sessions:70Lines:671Stop

The server was so unstable until about 2 AM last night that I was convinced it was a hardware problem with my PB G3 Wallstreet, and had pulled out a spare PowerMac G4 in preparation... But the Wallstreet was rock solid today, all the instability was purely my own fault and my last-minute code fixes solved it!

*after writing that initial post and right before bed the last used to join reported a hard freeze. I'm going to chalk that one up to aging hardware and MacOS instability 😅

Update on 2026-03-02:

Got a crash report on the Mac SE from @scj

I've seen the MacsBug crash screen many a time over my life, but at most I just looked at the name of what function crashed. For work I only ever used modern debuggers that show your variable contents inline

Now is the first time I'm decoding the registers, deducing what values were in my code at the time of the crash. I used to think "how could a register dump be of use to anyone, it's just random hex” but I'm starting to see thru the Matrix now… 💃

A photo of a black and white classic Mac screen with a Macsbug error dump. To the right is a CodeWarrior symbolics window showing C code interleaved with the assembly it generates. There are a bunch of red squiggly lines drawn between the registers in Macsbug and the variables in the C code

(still have no clue what is going on in this crash lol. a true MARCHintosh Mystery)

Update on 2026-03-05:

New version is out, with optimized scrolling! Especially noticeable on older machines, it now scrolls the chat log cleanly instead of constantly redrawing the whole window. No more annoying white flashes!

See the before and after:

Back to blog index