[Ohrrpgce] FreeBASIC Mac OS X build

[Ralph Versteegen]

On 12 October 2010 06:48, James Paige <Bob at hamsterrepublic.com> wrote:
>> > 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!

It turns out the problem was actually in OPEN, not LOF. OPEN calls the
function setvbuf. The Mac man page for this warns that it does crazy
things and leaves the file in an undefined state. The GNU man page
appears identical, but with that warning removed!

>> 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.

We could go back to an implementation that calls system functions to
read directory contents, if there was some benefit to doing so.

> 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.

I think I'll do that over the weekend.

> ---
> James

I should mention that I updated the Mac build (twice):
http://tmc.castleparadox.com/ohr/ohrrpgce-macosx-2010-10-13-wip.tar.bz2

See here for details:
http://www.castleparadox.com/ohr/viewtopic.php?p=83654#83654

This build is r3858 + all the Mac fixes I've committed since then.

I built both oggenc and oggenc2; that build packages oggenc, which is
much smaller. But including oggenc was accidental, it's probably a
better idea to use oggenc2 (which uses the fancy and huge
libsamplerate library)

I haven't yet looked again into why James' builds crash; I decided to
prioritise OHR work over FB work for now.