"Attach a disk image" dialog: A console window briefly opens when selecting...
Versatile Commodore Emulator
Brought to you by:
blackystardust,
gpz
Menu
▾
▴
#1536 "Attach a disk image" dialog: A console window briefly opens when selecting a disk image with a name similar to that of a ZipCode file name
In the "Attach a disk image" dialog, whenever selecting a disk image with an exclamation mark as second character in its file name, a console window appears and quickly closes again.
This can be observed by having two disk images in a folder, one with an exclamation mark as second char in its file name, and one without, like:
s!nafu.d64 snafu.d64
Move the selection between these two files a couple of times with the cursor keys, and everytime s!nafu.d64 is selected, a console window blinks in to and out of existence.
After further inspection, i can see Viceexecuting c1541.exe whenever the file with the exclamation mark is being selected, and the short-lived console window containing the text
command 'zcreate' unrecognized. Try 'help'.
As it seems, Vice treats files such as s!nafu.d64 as ZipCode-compressed files instead of disk images (even though it doesn't really adhere to the file name pattern for ZipCode files), trying to open them with the help of c1541.exe while using an unsupported c1541 command.
If the "Attach a disk image" dialog (and by extension Vice's commandline interface) is intended to support ZipCode-compressed disks [that said, since the dialog filters by actual disk image file extensions, i am anything but certain that ZipCode support is actually intended here] , i would like to suggest the following Vice behavior:
-
If a file with an exclamation mark as 2nd character in its name is selected, check whether the first character is in the range of [1..4] (or [1..5] perhaps?).
-
If the file name matches the pattern for ZipCode-compressed disk, check whether the file extension equals one of the disk image types supported by Vice, and whether the file size is equal to the size of that disk image type.
-
If both file extension and file size indicate the file being a normal disk image, do not treat it as a ZipCode-compressed disk, and just open it like any other standard disk image. Only if both the file extension and file size do not match a disk image type, try opening it as a ZipCode-compressed disk.
-
When Vice invokes c1541.exe "under the hood", it should suppress the opening of the console window.
Oops, sorry, i forgot to mention which Vice version i am using. It's:
GTK3VICE-3.5-win64-r40584 on Windows 7 Pro x64
Last edit: elgonzo 2021-08-28
The invalid command was fixed in r40578.
As for VICE accepting 's!foo', there are archives using zipcode for a list of files instead of a sector-by-sector copy of a 35/40-track disk. These archives use 'a!foo', 'b!foo', 'c!foo' etc for the zipcoded files and have an accompanying 'x!foo' file that contains the "directory" of the archive. Each non-directory file contains max 166 blocks, so if the tool was supposed to support disks larger than a 35 track 1541 disk, 's!foo' could be correct.
c1541 however does not contain code that supports this format, only zipcoded disks with 35 or 40 tracks, so assuming 's!foo' is a zipcode archive file is incorrect in this case, and indeed a bug.
In my opinion the spawning of c1541 should be removed and either zipcode support implemented in the emulators themself, or removed altogether.
The opening of a visible temporary shell on Windows is something someone who's interested in Windows should have a look at. Perhaps there's a way to suppress that.
i dont see any reason whatsoever for why the emulator should work with zipcoded disks directly. +1 for removing :)
Ah, i first tested with r40000, and seeing the console window still popping up in r40584 made me falsely believe it would be the same there. I checked once more with r40584, and the output in the console window is indeed different . Not about unknown command anymore, but an error message about not being able to decode/unpack s!nafu.d64.
I restored an old sanity check that wasn't technically required since c1541 would fail anyway, and improved the filename check to test the first character for '1'-'5'. This should be enough to avoid spawning c1541 most of the time.
The fix is in r40594, please test once a build is available (usually about 20 minutes after the commit).
No response after nearly 4 weeks, assuming fixed.
Yes, it's fixed (i tested with GTK3VICE-3.5-win64-r40824 now).
My apologies for dropping the ball here. How time flies - i didn't realize it is/was so long ago i filed the report. Again, my apologies for not coming back earlier. :(
No worries, time does indeed fly. Good to know it's fixed :)