|Re: [hatari-devel] Statistician app NULL pointer crash with GEMDOS HD emu?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
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:
> ... but emulating this one would make even less sense than GetBPB, I
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.