On Thu May 11 09:30:56 2023 +0000, Byeongsik Jeon wrote:
> Sorry about that. I analysed the test results incorrectly.
> While testing ImmNotifyIME: CPS_COMPLETE, I was not able to see
> IMN_SETOPENSTATUS in the application windproc, so I also looked at the
> default ime window and ime ui window. I made the silly mistake of
> analysing WM_IME_NOTIFY:wparam=0x11 as IMN_SETOPENSTATUS | IMN_CHANGECANDIATE.
> It looks like ImmSetOpenStatus is not called on CPS_COMPLETE,
> CPS_CANCEL. I would be grateful if you could confirm.
> I tested it on Japanese and Korean MS IME.
I think you're right, I probably got confused in my tests. I will try to write tests for these specific sequences. Anyway, I think it will be tricky to implement as XIM doesn't let us change the IME strings.
I also would like to finish moving all the IME functions to imm32, before trying to fix this. If we need some specific callbacks from imm32 to the drivers to help, that could probably be done using the same win32u interface jacek suggested to use.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2769#note_32543
This is the severalth time I've seen an attempt to hook up win32 Unix sockets to host Unix sockets. Which I think is reasonable in general, but I'm also not exactly thrilled about accepting this code without any tests whatsoever. Unfortunately, last time I tried to write tests for Unix sockets, I started triggering kernel panics in Windows. Maybe the situation has improved since then?
> Of particular note is the difficulty in handling `sun_path`. Most of the functions that allow for translating Windows paths to Unix paths are not accessible from ws2_32.
I'm not sure I understand. wine_nt_to_unix_file_name() should be accessible from either side.
Although it's not quite clear to me that ws2_32 is the right place to do that translation; we may want to do it in ntdll instead.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2786#note_32536