[Ohrrpgce] FreeBASIC Mac OS X build

[James Paige]

> > Could you please email me ohrrpgce-game, ohrrpgce-custom, and the .o
> > files? Hopefully I can reproduce it on Monday.
> >
> > OK, anyone else out there with a Mac willing to try: can you compile and run?
> >
> 
> You didn't say when your build crashes, but for me it crashes when I
> try to load a game, or to quit. I forgot how Game behaves.
> Unfortunately I saw a very similar crash in one of my builds too.

Sorry I forgot to mention that, yes! The file browser runs fine, but it 
crashes when I try to open a game.

> I found that (at least one crash) is due to the wrong function being
> called - the linker inserted the wrong function address. I have no
> idea why this would happen. I think it was a garbage address into the
> middle of a function. It wasn't even a "scattered" relocation.
> 
> I actually focused today on fixing the errors when creating a new
> game, including the problem that Custom couldn't delete working.tmp.
> Not at all as easy as I thought. Why on earth do we unlump twice (and
> relump once) after creating a new RPG?

:)
We do that because the new-game code is an incredibly crappy mess, 
written so long ago that I didn't even understand the lumpfile system at 
the time (Brian wrote it)

> Took me a while to realise
> (largely because of start_new_debug problems). Equally confusing, gdb
> doesn't show non-stack-aligned calls from FB to C properly, so I spent
> a couple hours convinced that some crazy stack corruption was
> occurring. It turns out that LOF leaves files positioned at the end (I
> don't know why yet), so reading from lump files when lumping them
> would result in zero-filled buffers, so when the new RPG file was
> unlumped the second time archinym.lmp contains a bunch of zeroes so
> Custom complains and inadvertently creates files named like .fnt so
> killdir couldn't delete working.tmp because findfiles is a giant hack
> and didn't find hidden files.

Ah! Interesting!

> That's mostly fixed now, but feel free to tell me about how badly I
> broke findfiles.

I'll check it out :)

A little history on findfiles. Back in the QuickBasic 4.5 days, there 
was no QB command to get any kind of directory listing. I think the 
preferred method was to:

  SHELL "DIR /B > filelist.txt"

and then to read the results, which was of course awful because of the 
huge overhead of SHELL (huge in a 640k world anyway)

So Brian decided to write a directory lister in assembly, and we would 
have liked to do something like

  findfiles results$()

but figuring out how to write the results into a QB string array's 
memory address from ASM code was too daunting, so we just dumped them to 
a file instead.

Replacing findfiles with something that populates a string array 
instead of dumping to a temp file sounds like a very nice and long 
overdue cleanup.

---
James