Previously, there were bare "return;" statements in some places, even though main() was declared as returning int. This is disallowed by C99 and later, and ORCA/C now complains about it when using full lint checks.
This could cause Marinetti to return more data than it should, starting with valid data but then including corrupt data.
The workaround I'm using is to have Marinetti return a new handle and then copy the data out of it, using the size of the handle as the true size of the data that was read. Because of details of how Marinetti works, that size is correct.
This shouldn't have a major performance impact, because Marinetti would internally read data into a new handle and then copy it anyway.
The basic approach is just to see if GS/OS can understand the disk (i.e. if a VolumeGS call succeeds), and if not switch the order. We currently start with ProDOS order, then switch to DOS order if necessary. This is only currently done for 140k images.
At the moment, the auto-detection of DOS vs. ProDOS order is just based on the size of the image (i.e. 5.25" images are DOS-order, anything else is ProDOS-order).
This applies to both directly entered URLs and redirects. At least some servers (e.g. bit.ly) will send un-percent-encoded URLs that may contain spaces in the Location header.
Spaces are now percent-encoded in the HTTP request. Other characters that should be percent-encoded still aren't, but I think many servers can accept them as-is.
I think there should still be some disk-switched logic elsewhere, based on the somewhat complicated rules for it in the documentation, but at least this provides a notification when a new disk is mounted.
The CDev connects to the network if not already connected, and it displays the arrow cursor in the "no NetDiskInit" alert from MachineCDEV.
The mounturl utility now has meaningful return values.
This avoids sending out requests that can't work, and also gives an opportunity to process packets from the old connection while it's still logged in, which may avoid some strange behavior.
Previously, we had actually been (erroneously) using the code for a generic hard drive, rather than a generic floppy as intended. The generic floppy code shows a 5.25" floppy icon, which seems less appropriate, so now we use the same code as 3.5" SuperDrives instead.
Stephen Heumann