Damian Walker

Personal Web Pages

Some Adventures with Personal C

Saturday, 11th June 2016

Since installing a couple of C compilers onto a CF card on my 100LX, I've been playing more with Personal C.  It creates smaller executables than Turbo C does, and its lack of graphics primitives won't affect me much since it's easy enough to write directly to CGA video memory.

But this week I came upon an annoying bug.  For its PC-specific IO, the compiler supplies a library appropriately called PCIO.  If you want to call any of the functions for setting the screen mode, or direct keyboard scanning, you need to link this library with your own object code.  The problem is that when you do this, the function fseek() stops working.

The fseek() function allows you to move the file pointer backwards and forwards in a file.  I have combined multiple images into a graphics file for my project, and was using fseek() to skip to a particular image to load into memory.  But I found that all my attempts at calling fseek() failed.  A bit of experimentation showed me that I could get it to work if I didn't link PCIO with my program, but that's not an option for a program that uses graphics and keyboard scanning.

In this current project I have a workaround.  I'm not constantly jumping backwards and forwards in the file like I would if it was a database.  I'm just reading a length word and, if I don't want to load that particular chunk of data, I'm skipping it.  Normally the code would be:

fread (&n, sizeof (n), 1, file_handle); /* read the length word */
fseek (file_handle, n, 1); /* skip n bytes */

Instead I have to do this:

fread (&n, sizeof (n), 1, file_handle); /* read the length word */
while (n--) fgetc (file_handle); /* skip n bytes */

So while it's not a show-stopper, I'm apprehensive about what other bugs I might discover as I progress.  For future projects I have Turbo C on standby, and I may have to resort to it if I meet any further roadblocks with PCC.