This fixes "out of realized font handles" errors seen with Valve games like Half-Life 2 (which uses more than 1000 font handles).
The new limit of 5000 is roughly inspired by the Windows limit, although there are differences. On Windows 11 I can call `CreateFont()` (and then `SetMapMode()`, `SelectObject()`, `SetTextAlign()` to realize the font) exactly 5000 times before it hits the handle limit.
Under Wine, child fonts use handles as well, so the limit is usually hit before 5000 `CreateFont()` calls. But, there is caching so that `CreateFont()` calls with identical arguments do not count towards the limit. Ultimately the old limit of 256 was sufficient for almost all applications, and 5000 should be enough for all but the worst-behaved apps.
--
v2: win32u: Make font handle table dynamically growable.
win32u: Track free font handles through indices instead of pointers.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7771
Add `IOCTL_WINEBTH_RADIO_START_AUTH`, which gets used to implement `BluetoothAuthenticateDeviceEx`.
--
v3: bluetoothapis/tests: Add tests for BluetoothAuthenticateDeviceEx.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7885
Add `IOCTL_WINEBTH_RADIO_START_AUTH`, which gets used to implement `BluetoothAuthenticateDeviceEx`.
--
v2: bluetoothapis/tests: Add tests for BluetoothAuthenticateDeviceEx.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7885
WMSyncReader starts a background read thread that reads from the IStream
passed to IWMSyncReader::OpenStream. This means it could use the IStream in the
background even when no IWMSyncReader methods are being called.
For well-behaved applications, this is probably OK. However, AQUARIUM
(Steam 2515070) frees the IStream it passes to WMSyncReader _before_
it calls IWMSyncReader::Close, which stops the read thread. This causes
the read thread to access freed memory. This is improper, but not
unreasonable, as IWMSyncReader is supposed to be a synchronous
interface, so one might assume when they weren't calling into
IWMSyncReader methods, the IStream won't be used.
This commit adds a `wg_parser_dont_read` function, which can be used to
stop wg_parser from issuing read requests. This is used by IWMSyncReader
to make sure read requests are only issued when IWMSyncReader methods
are being called.
--
v6: DONT MERGE: winedebug in CI, only run qasf:asfreader
https://gitlab.winehq.org/wine/wine/-/merge_requests/7676
WMSyncReader starts a background read thread that reads from the IStream
passed to IWMSyncReader::OpenStream. This means it could use the IStream in the
background even when no IWMSyncReader methods are being called.
For well-behaved applications, this is probably OK. However, AQUARIUM
(Steam 2515070) frees the IStream it passes to WMSyncReader _before_
it calls IWMSyncReader::Close, which stops the read thread. This causes
the read thread to access freed memory. This is improper, but not
unreasonable, as IWMSyncReader is supposed to be a synchronous
interface, so one might assume when they weren't calling into
IWMSyncReader methods, the IStream won't be used.
This commit adds a `wg_parser_dont_read` function, which can be used to
stop wg_parser from issuing read requests. This is used by IWMSyncReader
to make sure read requests are only issued when IWMSyncReader methods
are being called.
--
v5: DONT MERGE: winedebug in CI
winegstreamer: Make sure WMSyncReader never reads in the background.
https://gitlab.winehq.org/wine/wine/-/merge_requests/7676