> Well yes, of course they check for the object type compatibility, but in the end they should still preserve their "function identity" instead of being looked up from the object everytime, even if it's completely detached from it.
I don't know what you mean by that, a pair like (dispid, iid) uniquely defines a function identity. There is nothing special about dispid except that we already need its lookup implemented, so that seems convenient.
See https://gitlab.winehq.org/jacek/wine/-/commits/func-call for a draft of what I mean. It implements `call` only for legacy functions, but I think it would scale to proper prototypes. It implements bc02a4fe3be595448, but doesn't need unpleasant things like `get_dispex_from_this` and uses the new interface instead (so committing something like that would also be a good opportunity to upstream "boring" parts of 81800d9dfa59f4fd8).
Extending it with accessors support should be straightforward. For prototypes, we could just have entries for those functions both in the instance and prototype objects. In instances, they would be not searched when doing lookups by name, so the only way to use it would be through `IJSDispatchHost`. For prototypes, they would be looked up, but an attempt to call it would fail because prototypes don't actually implement the required interface (so the result of the lookup would be useful only for instances). It should also allow skipping 1ffeaa446613 with all its consequences. What do you think?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5444#note_72509
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56698
--
v6: quartz: Allow concurrent calls to AVI decoder qc_Notify and Receive.
msvfw32/tests: Test that Cinepak rejects unsupported output types.
iccvid: Reject unsupported output types.
quartz/tests: Add Cinepak test to avi splitter.
winegstreamer: Use end of previous frame if the current frame doesn't have a timestamp.
winegstreamer: Implement AM_MEDIA_TYPE to wg_format converter for Cinepak video.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5744
This is an early draft of an implementation of key auto-repeat in wineserver to get some feedback. Some open questions:
1. queue_keyboard_message requires a `current` thread, but we don't get one in timeout callbacks. At the moment I am manually setting `current` to the foreground thread, but I am wondering if that's acceptable or we should explore other ways forward (also see TODO in code).
2. This draft introduces a new server request to configure auto-repeat (`enable/delay/period`). I am thinking that for more straightforward integration with the keyboard repeat SPI parameters, the request should only support the `enable` flag and the server should query the SPI registry values to get `delay` and `period` when needed. I am wondering if there any caveats here since I don't see other code in the server querying registry values (well, except to implement the registry requests themselves).
Also, I would hope that opening and caching the `HKCU\Control Panel\Keyboard` hkey would remove most of the cost of performing this operation (if that's even a concern at all).
--
v3: win32u: Implement keyboard auto-repeat using new server request.
server: Implement key auto-repeat request.
server: Check message target process for raw keyboard device flags.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5741
On Wed Jun 5 13:11:29 2024 +0000, cqwrteur wrote:
> Of course, there is. The problem is that ucrt can be statically linked
> from Microsoft UCRT static ucrt can be put back to FILE* in dynamic
> linking. And fast_io library is using that.
gitlab is not showing the context very well. I was asking about `stdout == stdin+1` test. Does the library depend on that?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5752#note_72456
On Wed Jun 5 13:02:30 2024 +0000, cqwrteur wrote:
> It is not. The problem is that ucrt can be statically linked from
> Microsoft UCRT static ucrt can be put back to FILE* in dynamic linking.
> And fast_io library is exploiting that to gain huge performance.
The `ok(ptrold + cntold == file->_ptr + file->_cnt, ...);` test is redundant. You're testing `ptrold` and `cntold` values in earlier tests.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/5752#note_72454
This is an early draft of an implementation of key auto-repeat in wineserver to get some feedback. Some open questions:
1. queue_keyboard_message requires a `current` thread, but we don't get one in timeout callbacks. At the moment I am manually setting `current` to the foreground thread, but I am wondering if that's acceptable or we should explore other ways forward (also see TODO in code).
2. This draft introduces a new server request to configure auto-repeat (`enable/delay/period`). I am thinking that for more straightforward integration with the keyboard repeat SPI parameters, the request should only support the `enable` flag and the server should query the SPI registry values to get `delay` and `period` when needed. I am wondering if there any caveats here since I don't see other code in the server querying registry values (well, except to implement the registry requests themselves).
Also, I would hope that opening and caching the `HKCU\Control Panel\Keyboard` hkey would remove most of the cost of performing this operation (if that's even a concern at all).
--
v2: win32u: Remove auto-repeat functionality.
server: Implement key auto-repeat.
server: Check message target process for raw keyboard device flags.
user32: Add tests for cross-process raw keyboard events.
server: Pass desktop to get_first_global_hook.
https://gitlab.winehq.org/wine/wine/-/merge_requests/5741