Subj : Need help with LordMenu utility
To : Bj�rn Felten
From : Donald Tidmore
Date : Fri Jan 05 2007 11:59 pm
>> I don't have the actual EXEC.PAS file. Its something that Charlie
>> Wardick created or found somewhere. I have a TPU file for it, which I
>> use all the time.
> I understood that it is one of those gazillion of variants of performing
> 'exec' with different memory saving tricks (swap, EMS and so on). Tricks that
> are no longer needed so I always recommend removing this stuff and rather use
> the standard 'exec' function.
>> There's no error message in regards to LordMenu's usage. It creates the
>> 3rdalt.txt fine one would think from the lack of error messages. But
>> when one tries to actually use it in LORD, Lord chokes on it.
> Ahhh... I see, so it's not really the LM program that needs to be fixed, but
>the LORD itself -- you need a fix around a serious bug in LORD, yes? No source
> code for that I imagine?
> I'll see what I can do about it...
The only person legally and contractually allowed to work on the LORD programs
is Michael Preslar, who develops it for Metropolis Gameport. Lordmenu used to
work reliably with LORD until the last year of v4.07's development, in regards
to the 3rdalt.txt file. Then LORD started choking on it. I think it was
around the same time that Michael changed to Free Pascal v2.00 for LORD
programming, and it is much fussier about things than Borland Pascal is. As
far as I know, there's no problem with the RIP file that the program makes.
I've never used LORD with RIP graphics, so have no idea if that part of the
program still works or not.
If I understand what Michael told me in early 2006 about Lord's problem with
the 3rdalt.txt it was that LORD expects to see ansi string data lines that
don't exceed 128 spaces maximum per line. So when it tries to load the file
that has 1,000-space lines, it literally chokes on it. But I have no idea how
to make a program write fixed length ansi lines to a file to cover that
situation. Donald.
