Re: [hatari-devel] Statistician app NULL pointer crash with GEMDOS HD emu?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On tiistai 26 elokuu 2014, Thomas Huth wrote:
> schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> > So fixing this would require enabling BIOS interception whenever
> > GEMDOS HD emulation is enabled, just to be able to reply something
> > meaningful to this call:
> > 	http://toshyp.atari.org/en/About_the_BIOS.html#Getbpb
> > 
> > and faking most of the requested data:
> > 	http://toshyp.atari.org/en/00300b.html#BPB
> > 
> > Looking at the rest of BIOS calls, this is only one that
> > is related to HD drives and not already fixed in other ways
> > (like drive map is).
> 
> There is also Rwabs:
> http://toshyp.atari.org/en/About_the_BIOS.html#Rwabs
> 
> ... but emulating this one would make even less sense than GetBPB, I
> think.

I don't think there's anything that could be emulated meaningfully.
There's no way to map host directory hiearchy contents into a direct
device reads & writes.


> > Any comments on whether supporting this is worth the trouble,
> > and are you going to look into that?
> 
> Implementation is not that straight forward since you've got to provide
> a piece of memory in the ST memory range where you can put the BPB data
> into. It might be possible by using a block in the cartridge memory...

Ouch, I didn't even notice that it returns a pointer to info instead
of app providing address where the info should be written.  This makes
it really bothersome.


> but since this is clearly a bug in the program, and providing a BPB for
> a non-block drive like our GEMDOS drive does not make too much sense,

I think the information could be mapped meaningfully to host info.
Most of info is same as for Dfree(), FAT & first free sector locations
could be derived from disk free info (or hard-coded), and root directory
length calculated from how many items GEMDOS HD root directory has.
It's not very useful though.


> I don't think it is worth the effort for just this buggy little
> program. The program will likely also crash for other non-FAT-drives
> (like network drives), so this is really just a bug in the program.
> 
> I'd suggest that we make an entry for this program in the compatibility
> list, saying that it uses GetBPB without checking for a valid return
> value -- and if we ever hit another program with this problem, we could
> reconsider intercepting GetBPB again.

Sounds reasonable, I added note.


	- Eero