Space bar in debugger. AppleWin 1.27.5.0 Windows 10 32bit

[MarcoVerpelli]

I think that with the last changes in the management of the keyboard an annoying bug has been inserted.

The keyboard buffer is active in the debugger so it is almost impossible for me to repeatedly press the space bar to step in to the code.

Thank you

Marco

[tomcw]

Hi Marco,

I tried with 1.27.5.0 (on Win7-64), and I experience a lag when I hold down SPACE to do repeated stepping. What happens, is when I release SPACE, then the debugger will do a few more steps before stopping. If I disable the hook filter, then the debugger keeps up with the SPACE keyboard repeat.
Is this what you experience?

Can you try disabling the hook filter:
> applewin.exe -no-hook-system-key

[MarcoVerpelli]

I tried the -no-hook-system-key switch but the debugger continues to stop ~3÷5 lines after releasing the key. I could be wrong but the delay seems to me to be proportional to the time I hold the space bar, for this reason I said "buffer"

Marco

[MarcoVerpelli]

OK, on the second try the switch works like you said.
Thank you and sorry for the trouble

Marco

[tomcw]

No trouble, and thanks for taking the time to raise this issue.

btw. I guess the first time you mis-spelt the switch - if you enable logging (-log or -l) then the log will report unsupported switches (ie. indicating a mis-spelling).

[tomcw]

My notes:

• The hook filter always makes a call to GetKeyState(), but it only needs to do this if the keycode is ESC. Doing this API call each time could be a performance hit.
• I tried with an empty hook filter (ie. just chain to next hook filter) and still got the same lag in processing all repeat SPACE's.
• I noticed there's a 10ms delay in DebuggerCursorUpdate() - called by the main message pump loop when there's no messages (and no flashing cursor that needs updating). I replaced the call to DebuggerUpdate() (from the main msg loop) with Sleep(1) and still got the same laggy behaviour.
• I completely removed the delay for g_nAppMode == MODE_DEBUG, and now there's no lag... but obviously when in MODE_DEBUG then a whole CPU core is 100% active.
  • EDIT: I can't repro this now. Now when I remove this, I still get lag (machine=VAIO laptop).

[tomcw]

NB, using 1.27.5.0:

• On my VAIO laptop (Win7-64, Intel Corei7 quad-core-HT @2.20GHz) this is reproducible.
  • But after coming out of hibernation, for the first few minutes, it's not reproducible, then it is and thereafter remains in this reproducible state.
• On my desktop PC (Win7-64, AMD Phenom II dual-core @3ghz) I can't reproduce this.

[tomcw]

I'm a bit stumped by this situation of it working on one PC, but not another. Maybe on the VAIO some other process is adding a hook filter to the chain which is causing this slowdown? If so then it's outside of the AppleWin process's control.

One option is to unhook the filter when entering MODE_DEBUG, and re-hook the filter on leaving that mode.

I did some simple timings of 10,000 calls to just UnhookWindowsHookEx()/SetWindowsHookEx() (on both VAIO and Phenom) and the time was 16ms, ie each call is ~1us. So it's a very lightweight operation to do.

[tomcw]

From MSDN: LowLevelKeyboardProc callback function

Note Debug hooks cannot track this type of low level keyboard hooks. If the application must use low level hooks, it should run the hooks on a dedicated thread that passes the work off to a worker thread and then immediately returns.

So I tried creating a dedicated HookThread, installed the hook filter from this thread and then had a 2nd simple message loop in this thread: Get()/Translate()/Dispatch().

This seems to fix the lag.

So I suspect that the time in the hook filter + time to render AppleWin's debugger display was greater than the keyboard repeat interval, so over time there'd be an increased delay (ie. lag) in processing the WM_KEYDOWN messages.

[tomcw]

Confirmed that this (97b07ea) fixes the lag issue on the VAIO, and continues to be fine on the Phenom II.
Closing.

[tomcw]

@MarcoVerpelli - can you try this build of AppleWin 1.27.6 ?
You shouldn't need the -no-hook-system-key switch anymore.

[MarcoVerpelli]

The debugger is back to work as expected.
Thank you

[tomcw]

Thanks for checking this.

FTR, I've also checked on:

• VAIO laptop Win7-64 (Intel i7)
• VAIO laptop Win7-64 (AMD)
• Lenovo laptop Win10
• Desktop PC Win7-64 (AMD Phenom)

[MarcoVerpelli]

Now I have to use the -no-hook-system-key option to be able to enter, for example, the # character. Damn nationalized keyboards # corresponds to AltGr + à, AltGr is the Alt key to the right of the space bar.

Also if I double click on a disk image, AppleWin obviously starts without the -no-hook-system-key option. and it is impossible to insert the # symbols.

[tomcw]

So how do you normally type a # character?

NB. For me (on my UK keyboard), AltGr+a gives me á. And I have a key dedicated to # (with a ~ available when I press shift and that key).

Was the previous AppleWin 1.27.5.0 OK for you when typing a # character?
In this new 1.27.6.0, I've tried to improve the AltGr support for the ClosedApple key (see #558), which may have regressed things for you.

[MarcoVerpelli]

AltGr + à is the normal way
the key is minuscule = à uppercase = ° AltGr = #

With 1.27.5.0 the only issue I had was with the debugger, absolutely no problem with the keyboard.
For habit I use 0 and . to simulate the paddle/joystick buttons, AltGr it used only for the characters like #, @, [, ]

[tomcw]

I see, thanks. And Wikipedia shows this too, here.

There isn't much demand for ClosedApple+<key>, so maybe I'll provide a GUI option for opting in to this new 1.27.6 behaviour, and revert so that the default is like 1.27.5 (and earlier).

[MarcoVerpelli]

I could bore you for hours telling about my problems in the 80s. In short: WordPerfect on PC/DOS a person had to write commercial letters in Cyrillic, a nightmare!

[tomcw]

FYI, there's a new 1.27.7 release here with the hooked ALT GR's fake LEFT CONTROL reverted.

[MarcoVerpelli]

Thanks a lot, no problem with the debugger or with the keyboard.

[tomcw]

Thanks for checking this version.