NLS

OK I have an update. It works! But there is still an issue. It takes maybe 30 seconds to actually reach the point where it starts to load. For this duration, the emulator is frozen. Seeing task manager, It calls unzip, first with parameter "-l", where it probably tries to see what is in the zip. Then calls unzip with "-p" parameter. To extract the t64 from the zip. BUT Then it calls unzip AGAIN with -l and then AGAIN with -p! The command line between "attempts" are the same. Only then it manages...

I cannot make further tests until tomorrow (or in two days), way to busy at work. Will revert.

Used this unzip: https://sourceforge.net/projects/gnuwin32/ ...dropped in both SDL and GTK executables home path. They both freeze when dropping the infamous zip file.

1) Well weirdly enough mine worked (the SDL version) WITHOUT unzip.exe in the path. :D I cannot verify any more though since I deleted the old install. 2) Without unzip.exe, if user tries to auto-attach a zip, it should just ask to provide unzip or pop an error. This is the "proper" intuitive behavior. Not fail unexpectedly by rendering the zip into a trash PRG within a (broken - see below) D64. 3) In my case in DirMaster, the D64 is trashed. Shows some control chars (not a proper dir) and as I said...

Just tested 43417. No go. Exactly same behaviour both SDL and GTK3. Does not detect Demons of Topaz T64 within zip file and instead tries to load a dummy D64 that it creates in appdata. Note that the dummy d64 doesn't have a proper directory list (DirMaster reports no proper directory and LOAD"$",8 loads forever), but DOES load something with "",8,1 (which reverts to READY.) Note, I cleaned my existing install and extracted the fresh one. So: - Does not detect that it is a T64. - Does not report...

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?).

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...

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.