now comes the tricky bit

The response to the packet stuff has been great, mostly because people can now read their FAT disks. Its exciting!

I have been tweaking a few things since the big release. There was one tedious problem that was preventing NameFromLock() from working correctly, which meant that anything more than a naive file copy wasn’t doing the right thing. It turns out that NameFromLock() calls FSA_OPEN with a base handle point to a file rather than a directory like it should be in order to get a handle on the directory the file is in. This maps closely enough to ACTION_PARENT, so I’ve added code to detect that case and do the right thing. Its a hack, and really should be fixed in DOS, but it’ll do for now, and makes this possible:

After a bit of discussion on the mailing list, I’ve also implemented an autodetection method and so got rid of that stupid “type = packet” thing. Its pretty straightforward - DOS tries to open the handler as a device, and then when it fails, packet.handler has a turn at it. Its naive and has a little overhead (loading the binary twice), but it works nicely.

The next thing to do with packets is to implement the API. I thought this was going to be the easy bit its a nightmare. I’m not going to go into too much detail here - join the mailing list if you want the gory bits. Essentially if you take the required changes to their logical end, it means getting rid of the IOFS system entirely. Now I have no problem at all with this - as I’ve said before, IOFS really offers nothing compelling over packets - but I think getting rid of it is going to take quite a bit of political wrangling that I’m really not interested in.

Its tricky. The way I read the bounty requirements I really need to get the API side working, but that really can’t happen easily, and I’m worried I won’t have time for it. But I’m still waiting to see the outcome from the mailing list; hopefully someone will make a decision. I may have to force the issue - that should be entertaining :P