This avoids any possible strange behavior with calling Marinetti in P8 mode. It also ensures that I/O operations in P8 mode will give an error, but not terminate the connection: it will still be alive when we get back to GS/OS, unless the server has killed it due to inactivity (which is quite possible).
This can occur when control-reset is pressed in P8 mode. It’s supposed to reinitialize the AppleTalk stack. In our case, we mark connections to be reset once we're back in GS/OS, since we can't call Marinetti in P8 mode.
This only works if our init is loaded before Marinetti’s, because otherwise Marinetti’s shutdown notification procedure gets control first and shuts down the connection.
This should add support for a greater variety of servers, which may only support AFP 2.2 and up (or refuse to use older versions over TCP).
The IIgs software is designed for AFP 2.0. AFP 2.2 is close enough that things seem to work, but there could potentially be a few compatibility issues.
This could be unsafe for some forms of client code, but it looks like the AppleShare FST always actually has a large enough buffer to hold the full amount being requested, and can deal with up to 65535 bytes being returned at once. We take advantage of this to do larger reads in a single request, which provides a noticeable performance advantage.
This patch disables asynchronous SPCommand calls to work around the problem, which was causing hangs and crashes when those calls triggered. This effectively prevents the FST from automatically polling to check if the volume has been changed, but shouldn't cause other problems.
This issue arises because ASP requests and replies are limited to a “quantum size” of 4624 bytes even if the amount requested is larger, and the AppleShare FST relies on this behavior in sizing its buffers. DSI does not have this limitation, so it was returning more data than would fit in the buffer.
Also improve error checking, so an error is reported in cases where the buffer is too small.
Stephen Heumann