#1843 Opening zipped image files does not work correctly

[NLS]

Dragging-n-dropping a zip file in SDL2 version, externally extracts the contents and auto-attaches it properly (tapes as tapes etc.).

In GTK3 version, which seemingly handles zips internally, auto-attaches at least zipped T64 (and possibly everything else too, like CRT), as D64, which of course doesn't work.

[gpz]

Please tell exactly how to reproduce this... it'd be very odd if GTK and SDL ports behave differently in this aspect, are you sure its not a settings issue?

[gpz]

I just zipped a .t64 file and dropped it into the GTK window and it started just fine

Try resetting the settings and then do it again. If that still doesnt make it work, please attach your config and the logfile

[NLS]

I just deleted my ini.
I opened x64sc, it was immediately noticable that settings were reset.
I dropped the zip I attach here, that contains a T64, on emulator window.
It just started the auto-start from D64 sequence, instead of the tape one.
In appdata, an "autostart-C64SC.d64" was created.

[NLS]

Also, I attach the log.

[gpz]

It just works for me shrug - could it be that you have (un)zip.exe in the SDL bin directory, but not in the GTK version?

[gpz]

OK so i can reproduce it on Windows - but it also does NOT work in the SDL version (i downloaded fresh builds from github)

[NLS]

But auto-attach zipped D64 works in GTK... if (un)zip didn't work, then any auto-attach would not work.

Note that I use the same folder for both versions (as I noticed the overlaps are common files anyway).
So my SDL vice is directly in VICE folder, while GTK binaries are in VICE/bin folder.
Also I always (when I drop a new build) extract SDL first with "keep newer" and then GTK also with "keep newer" (which probably skips most files).

This was never an issue - probably still is not (probably unrelated to the issue here).

Also more info:
- Windows 11, latest updates in.
- Tested with latest builds.
- Q: is a mapped drive from my UNRAID server.
- Both VICE folders and the zips themselves (from TOSEC in the example attached) are in the server.

[gpz]

You have added a lot of variables to the mix - please try with a fresh download on a local drive

However, dropping a zipped d64 into the VICE window fails for me as well.

Do you have some kind of "zip" or "unzip" in your global path perhaps?

[NLS]

No zip, unzip in global paths.
I will try from fresh, but still the bug remains even with those variables, as except if there is a conflict when dropping gtk over sdl where an executable (not the emulator itself) or library is same name BUT different content. I doubt this is the case.

Network on mapped drive, shouldn't be an issue (and worked like that for years).

Will get back with two fresh local folders.

[NLS]

...and I have some VERY interesting results...

1) The zipped T64 itself, no matter if its local or on mapped drive. Same behavior.

2) The SDL and the GTK on two separate local folders... VERY insteresting. It is EVEN WORSE. :D
I now have the confusion of zipped T64 as D64 in BOTH versions.

[gpz]

Yeah, both behaving the same is what i'd expect (the code for this is really the same in both)

Could you check in your regular setup what svn revision the SDL and the GTK version show in the ABOUT dialog (or in the log)?

[gpz]

Oh and also, could you try both the 32- and 64 bit versions? Something odd is going on, thats for sure :)

[NLS]

In my regular setup:
3.7.1 r43409
GTK3 3.23.37, GLib 2.74.6, Cairo 1.17.8, Pango 1.50.11
SDL2 version doesn't report version in "about", but SDL2.dll is 2.26.3.0.

In my local version (that I just extracted from download - same download as my regular setup though), everything is the same version EXCEPT GTK3 (wtf? how?) 3.24.37.

Seems there is no correlation between SDL/GTK versions and the bug.

32 bit versions local react the same (buggy) as x64 local versions.

[NLS]

Also note that in the only one working properly (my SDL2 version on my mapped drive), I can visibly see a DOS window popping in and out a few times. It is ugly but seems it tries to run the zip extract command (and succeeds).
In ALL other cases I don't see the DOS window popping up.
If this means anything.

In my mapped drive version I have WAY more files (esp. dll files) from older versions in the SDL2 root folder. Possibly one of these SOLVES the issue? (and if missing, like any fresh install, then an internally compiled unzip routine takes over?)

[Querino]

i'm using unzip.exe in the 'bin' folder, and it works just fine for me.

Windows 7, GTK3 version

[gpz]

If i interpret the code correctly, the "internal" use of zlib will only handle files compressed with gzip, and only certain extensions related to it. Files with .zip extensions require an external unzip (which we should perhaps put into the package).
That said i couldnt make it work by just copying the unzip.exe from msys (plus two .dll files required by it) into the bin dir shrug

[Querino]

internally only .gz files are handled by vice, this has been like this since forever in windows.

for .zip files we always had to use external unzip.exe.

[compyx]

iirc the unzip.exe etc binaries need to be in %PATH%, so for example in c:\windows\system32

[gpz]

Now when i "cd" into the directory that contains both x64sc and unzip and run x64sc from there, i can see it lists the archive contents in the log. However it still does NOT work (testing with a zipped d64 now)

[Querino]

as said, for me it works. i placed the unzip.exein the vice bin folder, and both smart attach and also drag&drop works.

maybe it depends on the unzip version? mine is ancient though.....

/edit:
UnZip 5.52 of 28 February 2005, by Info-ZIP. Maintained by C. Spieler.

[compyx]

yeah, you need an ancient version, pkunzip.exe(?) or unzip.exe from winzip won't work.

[gpz]

I dont think "you need an ancient version" is true - because i dont have that in linux either. In fact, msys has pretty much the same thing (unzip from "infozip" package) and it does NOT work right :)

[NLS]

Irrelevant of what happens, the program's handling of the situation is bad.
In other words, if it can't uncompress something, it should NOT just consider it a D64 (it even drops some D64 in appdata - I didn't see what it supposedly contains) and "run" it.
It should just report that it cannot do it.

Also, if some extra executable or library is needed, it either needs to be in the package or in the requirements somewhere (is it?).

[gpz]

i can see in windows that it lists the archive contents fine - and then fails to detect the contained file as valid.... poking around in the related code now

if it can't uncompress something, it should NOT just consider it a D64

It doesnt. Any file that is not recognized is considered a .prg file - and that is what we want.

[gpz]

NLS: just a shoot in the dark, please wait for r43412 to finish building on github, and test that one, using -no-redirect-streams on the cmdline