Getting back into C programming for CP/M

I also like RunCPM, which can also run on some microcontroller boards, for a very tiny CP/M 2.2 system: https://github.com/MockbaTheBorg/RunCPM

The README links to the author's CP/M software library as well.

This was totally me ~15 years ago in a Scrum place with an open floor plan, doing most of my work after everyone left in the evening or on holidays because it was quiet and I could finally get some stuff done. I wrote big pieces of the product by myself.

My first C compiler was on a VAX. I did have some C compiler for my ZX Spectrum at some much later point but I don't remember doing much with it. Then a series of compilers for PCs. One random memory is some sort of REPL C, maybe Interactive-C or something? But pretty quickly it was Microsoft and Borland.

EDIT: On a more serious note re: meetings and such. Part of the difference is that working in much larger teams and projects becomes less efficient and requires more communication. Mature projects also require less of the builder thing and more of the maintainer thing. Software lasts a long time and inevitably maintenance becomes the work most people end up doing.

Computing was a smaller world back then, the company was founded by Robert Swartz (father of Aaron Swartz) and named after his father William Mark Swartz.

[0] https://en.wikipedia.org/wiki/Mark_Williams_Company

Think about early video game development at large companies: One person (maybe two), six months. The company gave them room to practice their art, and the result sold a million copies.

These days everyone wants to cosplay Big Tech and worship abstraction layers, so you can't get all of the "stakeholders" in the same meeting in six months.

It's the only practical approach when offices are designed to be distracting and productivity-killing, meetings are incessant, and groupware delivers a constant stream of interrupts which one is expected to monitor and respond to quickly - especially while working remotely.

That would have been "Mark Williams C", also marketed as "Let's C" for MDSOS.

And you're absolutely right about all the agile bull...

They really didn't have any choice if they wanted to actually accomplish something.

The 8-bit machines of the day, CP/M running 1-2MHz 8080s, 2-4MHz Z80, with no memory, and glacial disk drives (with not a lot of capacity).

Go ahead and fire up a CP/M simulator that lets you change the clock rate, and dial it down to heritage levels (and even then it's not quite the same, the I/O is still too fast). Watching the clock tick by as you load the editor, load the file, make your changes, quit the editor, load the compiler, load the linker, test the program, then back to the editor. There is friction here, the process just drrraaagggsss.

Turbo Pascal was usable for small programs. In memory editor, compiling to memory, running from memory. Ziinng! Start writing things to disk, and you were back to square one. The best thing Turbo did was eliminate the linking step (at the cost of having to INCLUDE and recompile things every time).

It was a different time.

As someone who lived through that, we simply didn't know any better. Each generation got incrementally faster. There were few leaps in orders of magnitude.

But going back, whoo boy. Amazing anything got accomplished.

That's not true.

You could use lowercase file names.

Just fire up MS-BASIC, and save your file as "test.bas". You now have a lower case file name.

The problem is that all of the CCP utilities implicitly upshifted everything from the command line. So, with the stock set, you were out of luck.

You can go back into BASIC and KILL the file, so all was not lost.

But, the file system was perfectly capable of coping with lower case file names, just nothing else was.

Sure it did. Just start Microsoft BASIC on CP/M, type a program and save it as "hello". It will appear in the directory as "hello.BAS". Of course the CCP, the console command processor, will convert all file names to upper case, so you can neither type nor copy nor erase the file, but still it exists. You can even load it from MBASIC using LOAD.

You can have any characters you like in your CP/M file names. Sometimes I ended up with file names consisting of all blanks. I usually used a disk editor to deal with those, but there were lots of more convenient tools for the job.

What I develop I always make sure I test on NetBSD and OpenBSD. That keeps me honest and those systems will find issues that Linux does not care about. I found many issues by testing on those systems.

Also, ignoring malloc() returns is dangerous if you want to port your application to a UNIX like AIX.

Is it old version of setrlimit()? Couldn't locate it in any of the man.*bsd.org.

Or if memory overcommit is disabled or an 'unreasonable' amount of memory was requested. So, no, malloc() doesn't always succeed.

I get it though, if what you’re selling is “best practices” you’re obviously going to over complicate things. You’re likely also going to be very successful in marketing it to a profession where things are just… bad. I mean, in how many other branches of engineering is it considered natural that things just flat out fail as often as they do in IT? So it’s easy to sell “best practices”. Of course after three decades of peddling various principles and strategies and so on, our business is in even worse state than it was before.

In my country we’ve spent a literal metric fuck ton of money trying to replace some of the COBOL systems powering a lot of our most critical financial systems. From the core or our tax agency to banking. So far no one have been capable of doing it, despite various major contractors applying all sorts of “modern” strategies and tools.

Within Perl 1.0, part of the Configure script, you can see the list of machines it could build on here: https://github.com/kaworu/perl1/blob/ba165bbde4eef698ff9cc69...

  attrlist="mc68000 sun gcos unix ibm gimpel interdata tss os mert pyr"
  attrlist="$attrlist vax pdp11 i8086 z8000 u3b2 u3b5 u3b20 u3b200"
  attrlist="$attrlist ns32000 ns16000 iAPX286 mc300 mc500 mc700 sparc"

C worked ok on a pdp-11/45, but that had 256K of memory and 10s of MB of fixed disk. That level of hardware didn't appear for micro systems until the 68k generation, or I suppose IBM PC, but I don't remember the PC being too important in C coding circles until the 386, much later.

A contemporary source is the opinionated "DTACK-Grounded" newsletter from 1981-1985. http://www.easy68k.com/paulrsm/dg/ Hal Hardenbergh raved about the fast 68000 chip and it's wonderfully easy assembly, but lamented that everyone switched to "portable" Pascal and C to write 16-bit programs so they seemed even slower than 8-bit ones. His favorite example was a direct comparison: Lotus 1-2-3, written in 8088 assembly, vs Context MBA with the same features but written in Pascal for portability. 1-2-3 was MUCH faster than Context on the PC, and no one remembers Context today. Or the $16,000 Unix-based AT&T workstation whose floating-point benchmarks are beaten by a $69 VIC-20. (Obviously due to the C-written runtime, which even followed the C standard of promoting all single precision calculations to double so single was no faster!)

His opinion of C was "slightly-disguised PDP/11 assembly". Not too bad for the 68000, but a terrible fit for the 8088 or Z80.

F83 is a top drawer Forth system. It implements the Forth 83 standard, and it’s in the public domain.

It runs on CP/M and MS-DOS.

It has the editor, a single step debugger, virtual memory, multi tasking, an assembler, full source code, and it is self hosting (on top of its host OS) via its meta-compiler. But you could readily port it to a system with no real OS, needing little more than console I/O and some kind of block device.

It’s a hybrid block file based system. Historically you would just hand entire block volumes that would then be managed by Forth directly. Here, you create pre-allocated files that are then used in a customary Forth block style. It did not use text files for source code. It also has shadow screens for documentation. Shadow screens are where you divide the block volume in two, and the first half is source code, and the second is documentation. So if you have a 200 block volume, then screen 4 is code and screen 104 is documentation.

If you want to see the source code of a word, just type VIEW <word> and it will show you the screen that defines the word. The compiler embeds the source screen in each definition. A simple command will bring up the shadow screen to show the documentation.

It also has a word decompiler, and a threaded dictionary for better search performance. It has hundreds of words.

The real trick is imagining the work that went into this system. The bootstrapping process that converted this from a likely hand keyed, assembly based FIG Forth to what became F83. Starting with a pure, block screen based system to one that works with a file system, shifting code around on disk with little more than offsets and a copy routine that’s little more than a block move.

On a slow, 2 floppy 8080, where resetting the system was the routine way to get back to a known state. Using a powerful, yet very dangerous language, rife with traps. It’s like doing self surgery with a mirror.

The holes they must have blasted in the floor trying to avoid shooting themselves in the foot. Repeatedly. I’ve spent hundreds of hours studying this system, it’s really an amazing effort.