On 22/05/2015 05:00, David Griffith wrote:
> The "FROTZ" that appears in the crash message is from the
> filename of the executable. If I rename
> it to FOO.EXE, the crash message will contain "FOO".
Yes, that's because the 'system halt' message prints out the MCB when
MCB corruption happens (w
On 21/05/2015 21:43, Ralf Quint wrote:> Is there a way to save the game
progress, so someone else could try it
> on different hardware?
Hi Ralf,
No need for a save state - the game crashes within a minut or so after
starting playing, so the crash is rather easy to reproduce :)
Mateusz
-
On Thu, 21 May 2015, Ralf Quint wrote:
> On 5/21/2015 1:04 AM, David Griffith wrote:
>> I guess my next step is to bring one of my older machines home, clean
>> it up, install FreeDOS, and get to work with Turbo C++'s debugger. Can
>> anyone offer any explanation why a program would run fine in DO
On 5/21/2015 1:04 AM, David Griffith wrote:
> I guess my next step is to bring one of my older machines home, clean
> it up, install FreeDOS, and get to work with Turbo C++'s debugger. Can
> anyone offer any explanation why a program would run fine in DOSbox
> and crash on real hardware?
DOSBox
Hi,
On Thu, May 21, 2015 at 4:18 AM, David Griffith wrote:
> On Wed, 20 May 2015, Rugxulo wrote:
>
>> At risk of asking the obvious, what major DOS version / vendor is the
>> OP (David) developing on? Is it MS-DOS or FreeDOS? Does this mean it
>> works for him in MS-DOS but not in FreeDOS?
>
> I'
Hi,
On Thu, May 21, 2015 at 4:04 AM, David Griffith wrote:
> On Wed, 20 May 2015, Mateusz Viste wrote:
>
>> My guess is that you have a fishy memory usage in newer versions of
>> frotz - following an invalid pointer, or writing to non-allocated
>> memory, or so...
Presumably yes. A very quick te
On 05/21/2015 10:18 AM, David Griffith wrote:
> I guess I won't know
> just where the crash occurs until I can get real hardware running or if I
> can get a crash in a VirtualBox environment.
You could also try pin-pointing the problem the good old way - ie. lots
of printf() outputs at every bigg
On 05/21/2015 10:04 AM, David Griffith wrote:
> I guess my next step is to bring one of my older machines home, clean it
> up, install FreeDOS, and get to work with Turbo C++'s debugger.
You could also try running it on Linux through valgrind, it's usually
pretty decent when it comes to finding b
On Wed, 20 May 2015, Rugxulo wrote:
> Hi,
>
> On Wed, May 20, 2015 at 1:38 PM, Mateusz Viste wrote:
>>
>> Here the result with Frotz v2.43. Same computer, same game:
>>
>> http://s11.postimg.org/y8fknk0rn/frotz_v2_43_lost_pig.jpg
>
> At risk of asking the obvious, what major DOS version / vendor
On Wed, 20 May 2015, Mateusz Viste wrote:
> Good news is that Frotz v2.32 works fine. I played the "Lost Pig" game
> for about 20 minutes and I didn't experienced any crash.
>
> My guess is that you have a fishy memory usage in newer versions of
> frotz - following an invalid pointer, or writing t
10 matches
Mail list logo
