Hello, cyberpals.
I have been doing some C programming on a Mac 512K
for the past month or so, and I thought I would show you what it's like.
I would have preferred some sort
of direct interface to the video here so I can do the screencast
without sticking a camera in front of my screen
because I have to look at my screen through my phone, which is pretty
annoying, but I'm working on some solution for that
so for now you'll have to deal
with this video. I apologize for the scanlines if they come across
or the moire (or whatever it is) pattern on the desktop here
but anyway, this is a Mac 512Ke that's
been upgraded to Mac Plus specs.
So it has four megabytes of memory, it runs System 6
and it has a SCSI2SD SCSI drive inside with a two Gb partition.
I am using the original Mac Plus, er, Mac 512K keyboard
and mouse which is
notable because there are no arrow keys
on this keyboard. So that makes maneuvering
around in a text editor kind of annoying and
obviously there's no, like vi or anything on here
because they don't have an Escape key or a Control key.
So that's just something to note.
Something that I should probably explain if you're not familiar
with classic Mac OS is how
the file system works.
It's running HFS and the notable thing about HFS is that
files have data forks and resource forks.
So for every file and application
on here, which is just one file, there is two
parts to the file. There's the data fork which has all the data like you
would expect and then there is a resource fork which has all
kinds of metadata and extra information.
Like for an application there would be like icons, strings,
sometimes executable code, all kinds
of things shoved in there. And the reason for that is
that you can just drag around one file and copy it
to a floppy disk or something. And everything that is needed for
that application comes with it.
This obviously breaks down when you actually have to copy this file
through a system that doesn't understand resource forks like posting
it to a, I don't know, FTP site or something like that.
And the reason that resource forks are helpful
for applications is, aside from just having them all
in one place, is that this file is 531K.
On a Mac 512K, you obviously can't load this entire
thing into memory and that's because the data fork,
the actual executable code is not 531K,
it's much smaller than that.
So you would load that code into memory. And then as you
need resources that are part of that application
it's able to load them
in like one at a time as you need them. And then when
you're done with them, you can unload
them from memory. So it's helpful for a system with 512
kilobytes of memory.
I'll just show you what kind of resources are in the Fetch program.
There are a lot. So you have like alert dialogues.
You have some icons, pictures, menu settings,
LDEF, that's a list definition so if you have a list on
the screen, each time a cell needs to be
redrawn, it loads this list
definition into memory, executes it,
and then is able to get
it out of memory. Free it from memory.
Strings, these are static strings that you can go in here and
change without changing the actual application, which is kind of
neat. I guess that would be helpful for, like internationalization
if that was even a thing back then.
Anyway, so that's how resource forks work.
And like I said, it kind of breaks down if
you have to get these files from a system or file system that doesn't
understand resource forks. So if you download applications
from a website and you want to transfer them to your Mac, you will
often lose that extra information when you copy it. So for
an application, the application probably won't even run.
For a file that you want to open with
another application, if you don't have the file creator
and info, or the
creator and the file type I think they are?
If you double click on a file,
the system won't know what application to open it with.
This metadata says that it's to be
open in MacPaint. It's a painting file.
So even if this extension weren't here, that metadata is
still there telling it how
to deal with the file.
So that's HFS very quickly. If you need
to transfer files between machines, that don't understand resource forks
that's kind of how these BinHex utilities
and MacBinary and StuffIt, that's why these things all
came about. Actually, I mean StuffIt
is more like a zip file, but it is able to retain the resource
fork information. Well let's
just get into some C development.
I'm going to launch my C IDE, which is
THINK C version 5.
THINK C was created by Symantec.
The same Symantec that's still around now.
So I'm going to create a new project and
create it in test.
And for some reason, the naming convention, even though file
extensions weren't needed, the naming
convention at the time for a project was to name it with a
Pi symbol. I don't know why.
So that's option P creates a Pi symbol.
So we'll create a project. And this is obviously
using MultiFinder. So all
the stuff still stays in the background when you launch another application.
This is the THINK C IDE. It's pretty
small and fast. I really like it. The editor
is not very featureful but that's kind of how it is.
And like I said, I'm using the original Mac 512K keyboard
so I have no arrow keys which makes it kind of annoying to
navigate in C files. But I'll
just show you what it's like. So, it's like any
C environment.
[ loud typing ]
Oh, and newlines on old Mac were the
carriage return and on Windows
they are a carriage return and a newline, and on Unix they
are a newline. So that's kind of annoying. But you don't really
have to deal with that that often because everything on the Mac that
you'd be dealing with probably has line endings of just the carriage
return. So, anyway, so that's basically,
just the C file. And if you want to
compile it, save it as something.
And then add it to your project.
So that's your project.
Then we will run it. It'll compile it.
And it should give a link error because it doesn't know how to printf.
And it did.
So you need to link the ANSI C library,
which is not hard.
You basically just go to your THINK C installation,
go into C Libraries, and then these are kind of subsets of
the ANSI C library depending on what features you need.
I'm just going to load in the entire thing.
And then I will link it again.
And it's going to compile
actually just link it. I think that is already compiled.
So that's a pretty big file.
But you usually don't need all of that functionality
and since this is Mac OS, you would
normally create your own GUI window and then draw in it
and create buttons and all that stuff. So a printf
is kind of a weird thing but THINK C has this functionality
where if you just printf without a window,
it makes a console window for you and prints what you need.
So that's really helpful for debugging and stuff.
So that's basically all you need to get started doing C.
Learning the actual Mac system toolkit
as far as like interfacing with the system ROM
to draw windows and create menus and all that stuff,
I mean there's huge books devoted to this
if you don't want to buy books now, they're all in PDF form.
So you can just find them and start reading them. But you add
like boilerplate to load in a bunch of stuff to
initialize the toolbox and
then create a window and then sit in an event loop
responding to mount clicks and keyboard events and
all that kind of stuff.
And updating your GUI as you need. So that's pretty much it
that's a very small C project in THINK C.
It's pretty easy to get started. I will load up the-
By the way, this is a utility called On Cue. It just allows you
to dynamically create your own launch menu with applications
and then you can add in lists of documents
that you want to open with those applications. It's just easier to do
all that from a drop down than having to navigate through Finder every
time. So I highly recommend it. So anyway,
the project that I've been working on for the past month is called Carl,
it is an IMAP client. It is named Carl
because the normal IMAP client
that I run every day on my laptop, my OpenBSD laptop, is
called Mutt.
And my dog, Carl, he passed away a few months ago, so this is
kind of my tribute to Carl. And if we just
run this,
this is the debugger that I
have turned on, it's a pretty decent debugger.
Anyway. If we look at the About
window, we get a sweet picture of Carl
and that is loaded out of the resource
file, that is associated with my
project. So we can open that up and see what's in there.
So not too much right now.
But there are pictures and there's
a picture of Carl that was
imported and then copied out of MacPaint,
I think, and then pasted into here.
So the basic way that resources work, so you create a resource,
this is 1008 and then when you want to use it in your code,
you would just have a define set for it, and then
when you want to load it, you just call a toolbox function.
Like GetPicture and pass it an ID. And then it loads that into memory
and you can tell it to draw
that picture and where you want it. So pretty easy.
Anyway, so this is my code so far.
I was kind of in the middle of debugging,
something so it is showing a weird interface. But if I disable
the stub code, it should actually establish
an IMAP connection. And do everything that it's supposed to.
But it might be broken. So I'll just show you
and hope for the best right now.
It compiles relatively quickly for the slow speed of
the CPU. Obviously you want
to kind of keep your files small so the whole thing doesn't need to be
recompiled for small changes. But the
other thing, I should probably mention if you don't know is that there's
no isolation of programs. Even in an interface like
MultiFinder where you have multiple programs running at the same
time, you can read and
write to any memory address in the system from any program. So if
you scribble over video memory or anything,
the whole monitor will start glitching and you'll
frequently get lock ups in the system when you are writing
weird code and you'll just have to reset
the machine. If you look on the side of these
compact Macs there's like a little, there's
two buttons on the side. One of them generates a hardware interrupt.
This brings up the hardware debugger
and that returns from it. And then the other one performs
a reset. So as you're developing a program, you will frequently
need to reset the system when it kind of goes haywire.
Right, so there's no isolation so let's
hope this works and doesn't need to be reset. So this is
establishing a
that's weird. So I guess I should explain how that works.
Yeah, I know.
So how this Mac -- oh that's sad,
is getting on the Internet is through MacTCP
and MacPPP which were available
from Apple for the Mac 512K
and up, I believe. And what it's doing
is it's talking through the modem port but I don't actually
have a dialup modem attached. I have a
WiFi232 device which emulates a modem. But when you issue
it, an AT command like ATDT and instead of giving
it a phone number, you can give it a host name. And it will establish
a telnet connection instead of dialing
into that phone number.
I don't know why that's not working, but I will show you what it looks like.
This is a terminal program that I use for calling
like connecting to BBSes and whatever and you,
issue an ATI, you can see that it's a WiFi232 and normally that
would show you like the firmware of your modem. But this is a
WiFi232 so it's connected to my WiFi network,
gets an IP address and MacPPP
is set to
"dial" an IP
address a port and on that I
[ mumbling to myself ]
And so anyway on that other machine, I have pppd hooked up
to socat. So it's listening on a TCP port and then
when the WiFi232 connects to it, it's doing
a PPP session over TCP, which is weird. But it
works, it allows the Mac to establish its own PPP
connection and then do its own TCP/IP.
So it's able to connect out to the Internet like normal but
since my mail provider doesn't support or they
don't do, like unencrypted IMAP anymore.
I have to have another socat instance on my other machine that accepts
an unencrypted IMAP connection and then acts like a proxy and then connects
to my actual mail server over
secure IMAP. So why is
this not working?
Now it works.
So, now that we're connected, we can run this again and
it should see the existing connection.
So I spent about
probably two weeks trying to figure out
why MacTCP was not working
correctly for me in THINK C and I will
get into the details of that much later.
So this is fetching all the mailboxes this is actually like talking over
the Internet now it's building a list although it's not displaying correctly
because that is something that I was working on -- it's updating the mailbox
status to find new mail, and then it is showing
a list of messages in
my inbox which I don't really want to show.
So some decent progress it's kind of a weird state right
now because I was debugging something. But that's
where I'm at right now. Most of that is in the browser,
code that's the mailbox and
mail message list and then the mail actual
e-mail body interface.
Yeah, so I'm going to keep developing this
and I guess making more videos explaining how it works,
but it's very difficult to actually work looking
through this camera. So I need to figure out
how to get like
an out of band copy of
this screen. So I can actually look at the screen again.
Back in the 80s or 90s,
there was a SCSI -- something
that would hook into the SCSI port that would allow
it to read, or a
program that you install that would that would read the
video memory and send it through the SCSI port to a
physical device that could then be hooked up to another Mac that
could read it. And so you could do like a live video
capture of your screen. So I am working on recreating
that device basically using a device called
the RaSCSI that is like a SCSI interface
that can interface with a Raspberry Pi and it's normally used
to emulate a SCSI hard
drive like the SCSI2SD device that I already have.
But since you can program it I'm going to try and
do that so I can dump
the video memory through the SCSI
port and then somehow get that to another machine
that I can then record that screen dump as
I'm working on it. So that's a much larger
project. But for now, I just thought, I'd give this a quick example of
what it's like to develop in C on
an old Mac. So if you
like this video, I guess stay tuned for whatever
I make next. Thanks.