
Your First THINK C Program - vermilingua
http://beyondloom.com/blog/thinkc.html
======
buserror
THINK C was the straight successor of Lightspeed C, and I came from there, and
before that from Turbo/TML Pascal on the IIgs.

Whatever people will say, I still miss these "one pass" compilers, they were
amazing and peaked with CodeWarrior, the best development suite, ever, in my
nearly 40 years experience.

Nowadays we see autoshit "configure" stuff and compilers like gcc (some) or
clang (oh my frigging GOD!!) trawl their way slowly and painfully thru the
most simple projects without even support for plain basic stuff like automatic
precompiled headers.

Wow look, we've NEARLY got Link Time Optimization working (took decades), in
2020 whoohoo, I'm so delighted. I could compile _hundred of thousands_ of
lines of light C++ or (better) plain C 25 years ago on a much, MUCH slower
machine, with an simple editor that used the compiler lexer output so you had
highlighting, real indexing it was 'just there' and always right, and always
blinding fast.

I'm pretty sure we are way worse than we were 20 years ago for tooling. I'm
sure some people will disagree, these people haven't seen CodeWarrior chew
thru hundreds and hundreds of files in seconds.

~~~
kohtatsu
I feel like if Terry Davis could have maintained a bit more of a grip on
reality, he would have picked up the combined torch of Wozniak and Jobs.

Rest in peace.

Edit: not that TempleOS isn't beautiful, and I'm glad it exists and believe he
achieved what he set out to do. I was just selfishly musing that if he hadn't
lost his mind the way he did, maybe he would his ideas would have been adopted
more in the mainstream. I'm also glad TempleOS exists in its incarnation, so
it's conflicting.

~~~
mhd
Have a look at Oberon or SmallTalk. Being sane doesn't really help all that
much.

------
kick
This is an amazing post for a _bunch_ of reasons (as soon as I finished
reading it a few days ago, I immediately sent it to half a dozen people), but
one that should immediately jump out for you is that the picture of the Mac
Plus is dithered using Bill Atkinson's dithering algorithm. Atkinson's done a
bunch of really awesome things, but most notably, he played probably the
biggest role in the genesis of the Macintosh.

Very few posts on the WWW have the same attention to detail and wonderful
playfulness as this one. It's an incredibly rare thing, and insanely pleasant
to read.

~~~
jdiez17
The mystical style mixed with computing subjects reminded me very much of
aphyr's excellent "technical interview" series, which I very much recommend if
you enjoyed the OP:

[https://aphyr.com/posts/340-reversing-the-technical-
intervie...](https://aphyr.com/posts/340-reversing-the-technical-interview)

[https://aphyr.com/posts/341-hexing-the-technical-
interview](https://aphyr.com/posts/341-hexing-the-technical-interview)

[https://aphyr.com/posts/342-typing-the-technical-
interview](https://aphyr.com/posts/342-typing-the-technical-interview)

~~~
kick
I love Aphyr's writing already!

------
catketch
I used to work on this product (and think Pascal, Think Reference and other
cool stuff). Fun times and a lot of great developers.

When compiling, there was a modal dialog that would show the name of each file
being compiled...they went by fast even on early macs. Michael Kahl sped it up
even more by figuring out that QuickDraw’s DrawText routine was still slow
enough to be impacting compile time. So a custom blitter was made to replace
it and a fast compiler got even faster.

~~~
macjohnmcc
I ran into that with a backup product showing the current file being backed
up. I wound up just posting the current file to a buffer that was protected by
a mutex and whatever file name happened to be in the buffer at render time was
what was drawn.

------
ken
I don't know if it's the fonts, the icons, the controls, the monochromaticity,
the blocky resolution, the tinkerability, or even just stupid nostalgia, but
there's just something so darned _cute_ about classic Mac OS.

macOS today is attractive and useful and colorful, but it feels so serious.

------
firefoxd
I am the newbie who only recently found some interest in machines from the
80s.

I'm a web programmer and I cannot wrap my head around how those machines
rendered the graphics. I draw a 512 x 342 canvas on a webpage, if I loop pixel
by pixel to draw an image using an array, the fans of my powerful computer
start to scream. I'm not a graphics programmer maybe I am doing it wrong, but
how the hell does an 8 Mhz computer with 128kb do it.?

~~~
Athas
These machines had extremely low overhead for everything you did. If the
framebuffer is just a piece of memory, and the screen is monochromatic, then a
512x342 display consists of 175104 one-bit pixels, which is just about 21KiB
of memory (which is probably even distinct from main memory). A single pixel
update could presumably be done with a single instruction. If we assume maybe
4x looping overhead, then updating the entire screen by individually poking
each pixel could be done in about 700k instructions. In practice, there will
likely be special hardware and instructions for copying entire blocks of
pixels onto the screen in a much faster way ("bit blitting", although I don't
know exactly how the Mac did it).

Modern machines have huge overheads because of the indirection,
virtualisation, and protection mechanisms we desire. On a webpage, you
obviously don't have direct access to the framebuffer, but are drawing into
some in-memory canvas. Drawing a single pixel in Javascript is going to go
through many function calls, with probably orders of magnitude more
instructions than you would have on an old Mac. There are still ways of
getting (near) direct graphics access that is screaming fast, since people do
write games and play videos and such, but there is much more ceremony to it
now.

~~~
Taniwha
Little special hardware on those old macs, memory was 16-bits, framebuffer was
part of memory (memory was expensive), no blitting hardware, no hardware
cursors (software removed the cursor, rendered to the screen, copied the data
under the cursor and restored it). Screen refresh also refreshed memory,
during horizontal blanking it fetched audio data

------
smacktoward
Why do we still need to trawl obscure Google Sites to download a valid classic
Mac ROM? Why isn’t Apple just making them available? It’s not like it would
cut into their “modern” MacOS sales at this point, and it would make
preserving classic Mac software like this so much easier...

------
news_to_me
I love this. I’ve been using Think C on an old Mac 512k I got a couple years
ago, and it’s a completely different world. I’m currently working on writing a
gif animation app!

One interesting thing is that the ANSI library is relatively large, so I try
not to use it, instead relying on ROM routines or reimplementing bits of
stdlib that I need.

------
mrpippy
Similar: I wrote a walkthrough using Basilisk to run THINK C 6, and build john
calhoun’s classic game Pararena 2 from source.

[http://bslabs.net/2016/11/13/building-
pararena/](http://bslabs.net/2016/11/13/building-pararena/)

------
yjftsjthsd-h
> If you’re specifically using an OLPC, the target should be either lx86 for
> the XO-1 or larm for any subsequent ARM-based models.

That's oddly specific. Mind, I approve; it's nice to see people trying things
on less-common platforms and documenting the way:)

~~~
RodgerTheGreat
I have an XO-4 (the unobtanium model) and I love using it for distraction-free
tinkering. A mac emulator looks especially nice in the display's black-and-
white mode when I have the chance to use it in sunlight.

~~~
avhon1
How did you get your XO-4? Were you involved in a project developing software
for it?

~~~
RodgerTheGreat
Nothing so exciting I'm afraid; I cruised ebay for a few months and had the
good fortune of stumbling upon what appeared to be a decommissioned classroom
set from a pilot program in Canada. Nabbed a pair, so I have some spare parts
if I need them.

------
ngcc_hk
Done it under macOS and it is easy. Just in case:

\- download the minivmac said linked web site.

\- you need to download also the vmac.rom and the system7.dsk.

\- you can run the "mini Vmac.app" by clicking and drag and drop first the
vmac.rom then the system7.dsk.

\- your own disk needed to be created and drag-and-drop to the mini Vmac.app.

\- follow the instruction.

\- press control (and hold it) press H and other commands under H (you need to
press control).

\- it is a Mac the original one and hence you have to press the menu all the
time :-). Forget that.

\- and within a couple of minutes you have your first think C program in Mac
7.

Not sure I will go through the whole volume of Think C. One day may be one
day.

~~~
ngcc_hk
Very nice except the magnification (control-H-M) only to one level. If it is
one more level (i.e. 4 times instead of just double) that my 27 inches may be
good for some development. Full screen is just grey others in mine.

And the alarm sound (for bug etc.) is a bit harsh as alarm sound go. Not sure
how to change this.

------
Koshkin
See also [http://jamesfriend.com.au/pce-js/pce-js-
apps/](http://jamesfriend.com.au/pce-js/pce-js-apps/).

~~~
greendave
Wow. Even persists data across reboots (like the full emulator).

------
fmajid
My first Think C program reformatted my entire drive, requiring a full
reinstall...

There are benefits to modern operating systems with memory protection.

~~~
Koshkin
Sometimes it's good to learn the hard way.

------
slobiwan
Not being an original Macintosh guy I'm having a hard time getting the
minivmac to boot directly into System7. I follow the steps but can't figure
out what "Copy the donor system folder into our new boot volume, using the
familiar drag-and-drop." means. Any clues?

~~~
mjcohen
I dragged the System7 file from the finder into the running app.

~~~
slobiwan
yeah, that works. I'm trying to figure out how to make disk1.dsk be the
default disk that the app starts up with. Is that possible?

------
NCG_Mike
Wow. Going back a long time. I was in the MPW Shell camp but did use ThinkC
With Objects and it was so much faster than the C compiler in MPW.

------
i_don_t_know
I loved Think C 5 and devoured Dave Mark’s books on programming with the Mac
toolbox in the early 90s. Good times.

------
pjmlp
Ah, a trip down memory lane.

------
ur-whale
cfg/CNFGRAPI.h:10:9: fatal error: Cocoa/Cocoa.h: No such file or directory

also:

./setup_t -t xl64 >setup.sh Unknown value for -t

attention to details indeed.

[edit]: I assume this'll only work on a Mac. Too bad, looked fun.

~~~
gryphel
The Mini vMac download page
([https://www.gryphel.com/c/minivmac/dnld_std.html](https://www.gryphel.com/c/minivmac/dnld_std.html))
includes binaries for Macintosh, Windows, Linux, and other platforms.

As recently noted in the build documentation, compiling it yourself is not
recommended for most people. (First, the result will be much less efficient
than the official binary unless you tweak things for your particular compiler.
Second, there is the chance of running into compiler bugs and bugs in Mini
vMac that show up only on some compilers - the official binaries are much
better tested.)

~~~
RodgerTheGreat
Quite reasonable. I've edited the footer section with a callout to these
recommendations and appropriate links.

