GL_MAP_WRITE_BIT does not mean that the buffer will be filled, unless an
INVALIDATE bit is explicitly set. The application is free to partially update
the buffer, even if it does not read from it.
Thanks to Aida Jonikienė for doing most of the debugging here.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55045
Commit b1cc87cb65 ("msi: The line control has a height of exactly 2
device units.", 2007-12-16) open-coded the body of
(msi_)dialog_add_control() inside dialog_line_control() modulo the
height override.
Except the fixed height, line controls have nothing special compared to
other controls. Thus, there is little merit in open-coding it.
Also, dialog_line_control() has bit-rotted over time; it already missed
a few changes that were done to any other controls.
Fix this by just using dialog_add_control(). Also, add a special case
logic just for line controls.
Today, CreateTextServices() sometimes triggers an assertion failure in
select_style().
When ME_MakeEditor() calls ME_MakeFirstParagraph(), the editor
(ME_TextEditor) is not in a fully initialized state. For example, the
font cache (pFontCache) is not fully initialized, which sometimes makes
select_style() believe that the cache slots are fully occupied.
Fix this by delaying the call to wrap_marked_paras_dc() until the editor
is fully initialized.
Also, delay the call to ITextHost::TxReleaseDC() until after
wrap_marked_paras_dc(), since we need the device context a bit longer.
Fixes: b70eb32c5f
Many built-in callers of ActivateActCtx() just assume that it will
always succeed. If it ever fails, then DeactivateActCtx() will notice
that the cookie is invalid and raise an exception anyway.
The main thread still waits for the worker thread, in order to keep
buffer resizing synchronized with presentation. As soon as buffer
presentation is offloaded to the worker thread too the wait can be
dropped.
In the following commits the worker thread will be used for actual
presenting and buffer resizing. In this way the worker thread can
wait on the vkd3d queue without blocking or even deadlocking the
application.
In HttpSendRequestW and HttpSendRequestExW, if the header pointer is not
null but the length parameter is 0, the header length should be derived
from the string length instead.
In HttpSendRequestA and HttpSendRequestExA, on the same scenario, the
function should fail instead.
