When I run BasiliskII (built from kanjitalk755's code) under Windows, and press Alt-F4, an window opens in System 7 that I've never seen before:


It accepts keyboard input, and clears its contents (but remains open) when I press Alt-F4 again. But I can't imagine what it's doing. It doesn't seem connected with any extensions or control panels, because it happens when

There seems to be no way out of this except to restart BasiliskII (with Shift-Alt-F4, apparently). And the window opens with Alt-F4 even if I start with no extensions at all.

I can't reproduce this in BasiliskII for macOS, and I don't see it in older builds. I can't find anything the source code that might be involved, but probably I haven't looked hard enough.

Does anyone recognize this?

What happens if you type in "SM 0 A9F4" <return> "G 0" <return> ?

It looks a lot like the programmer's screen when you don't have a debugger installed, although not quite.

Hmm... I see that the codes you asked me to type are supposed to let you exit to the shell (or Finder?). Is that right?

When I type in those lines, after the first, a big display of hex codes appears. Then after the second line, BasiliskII quits abruptly.

Is Alt-F4 somehow acting as the programmer key? As far as I can tell, I don't have MacsBug installed anywhere. And I've never seen it before now.

And I see that I can press G and exit this input window. Now to search for the debugger in the source code and see if I can stop this from happening...

EDIT: I wonder if this has something to do with SDL2 under Windows? Some odd keyboard effect associated with switching to SDL2?

Well, I'm completely baffled by this. I can't find anything in the source code that suggests what might be going on. Next, I suppose, is to search the SDL2 code...

This is definitely the programmer key being triggered; all the behaviour you're describing and the generic window shape lines up with that.

Is this due to you using an SDL1 keycodes file with SDL2?

[and yes, SM = Set Memory, at address 0, to A9F4 which is the code for quitting the frontmost application. G = Resume processing instructions, at address 0]

If you had MacsBug installed, you'd get the full-blown debugger on your screen instead of the programmer window you saw.

I'm away from my build machine right now, but will check this later on. I know that kanjitalk755's macOS code explicitly removes the keycodes file from the resources, but I'm not sure whether this was also done under Windows. (I'll experiment with renaming the keycodes files and rebuilding.)

Here is a keycodes file that is updated to include translation of cocoa (SDL2) scancodes to Mac keycodes: http://ronaldpr.home.xs4all.nl/basiliskiiforum/keycodes

I downloaded that file, renamed it BasiliskII_keycodes so that BII would use it, and got the error message "Cannot find vendor 'windows' in keycode translation file BasiliskII_keycodes."

So I added the string "sdl windows" at the top of the each of the keyboard definition groups, and BasiliskII loaded those definitions, but the debug window still opens with Alt+F4.

Still puzzled...

I do not think that is correct. BasiliskII should choose only one of the translation sets from the keycodes file. Did the error message not appear with the old keycodes file? Was there an "sdl windows" in that file?

With "keycodes true" in the prefs file, and with the old BasiliskII_keycodes file in the same folder, I get exactly the same error message. There is no "sdl windows" definition in the file. Perhaps SDL2 requires it?

EDIT: And if I add "sdl windows" to the Windows definition, BII launches, but Alt+F4 causes the debug window to open - and then that window won't accept input, so I have to force-quit from the task manager.

My guess is that this won't be fixed until kanjitalk755 figures out what is happening. Meanwhile, the Windows version of the BII code isn't really usable.

As far as I know, the SDL2 scancodes are platform independent. Then the place to add a line "sdl windows" or possibly just "windows" is above or below the line "sdl cocoa". The correct string will be somewhere in the source code. I suppose kanjitalk755 will know.

You can check if the correct translations are used when you switch to a different keyboard layout on both host and guest, for instance to the French AZERTY keyboard. Pressing the Q and W keys on your QWERTY keyboard should then result in an A and a Z.

I tried putting "sdl windows" at the top of all the definitions, including cocoa. None worked to solve the Alt+F4 issue. The keyboard definitions were clearly being loaded, as keys like the tilde and others changed according to which definition got loaded.

Well, so it worked. But not to solve the Alt-F4 issue.

Yes, I clarified my earlier post.

I have changed to ignore Alt+F4.

https://github.com/kanjitalk755/macemu

Thank you, kanjitalk755. I hope someday we might find out the cause of this problem, in case there is some Mac software that uses Option-F4.

Under Windows, Alt+F4 generates SDL_QUIT event.
BasiliskII emulates to press power button when processing that event.
At this time, if Alt key is also pressed, the key combination is equivalent to the programmer's key on the old mac.

Applications can read the key value, so it should be no problem.