I have found some scripts where comparisons that use floats and OLECOLOR directly fail. For example:
```
If Light005.State Then
' State is a float V_R4
End If
If Light005.Colorfull Then
' Colorfull is an OLECOLOR VT_UI4
End If
```
This is because `stack_pop_bool` does not handle `VT_R4` and `VT_UI4` and returns `E_NOTIMPL`.
This adds additional types to `stack_pop_bool` similar to `VARIANT_Coerce`.
Fixes https://bugs.winehq.org/show_bug.cgi?id=54731
--
v4: vbscript: Coerce to VT_BOOL when evaluating jump conditions.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2507
Here's a list of usages of `base.outer_window` that may be impacted by the change and my analysis/fixes. Note that I specifically did not look for `document->outer_window` since that one was already holding it forever, so it's out of scope for this MR (whether it's correct or not, the behavior is the same after this MR).
I also didn't consider some cases that already **did not check** for it being NULL or not, because they would have crashed earlier before anyway (they'd still crash now if outer window gets killed, but it's out of scope of the MR as I said). For those that says "Handled" it means I've added checks so that the behavior is same as before, i.e. detached inner windows behave as if outer window is NULL.
* `htmldoc.c/HTMLDocument_get_mimeType`: Changed so it doesn't rely on outer window.
* `htmldoc.c/HTMLDocument7_get_defaultView`: This is actually fixed by these patches.
* `htmlform.c/HTMLFormElement_submit`: Handled.
* `htmlstorage.c/send_storage_event`: Fixed in a separate patch with tests, since it follows the outer window.
* `htmlwindow.c/check_target_origin`: This (along with many other methods) can't have it NULL anymore or detached, since the caller must hold a ref to the outer window, and they're not called from our objects holding ref to inner window only.
* `htmlwindow.c/HTMLWindowSP_QueryService`: This uses the outer window to obtain the browser and the doc obj, so it's fine.
* `mutation.c/set_document_mode`: Handled.
* `navigate.c/BindCallbackRedirect_Redirect`: Handled.
* `navigate.c/nsAsyncVerifyRedirectCallback_OnRedirectVerifyCallback`: Handled.
* `navigate.c/nsChannelBSC_init_bindinfo`: Uses the outer window to obtain the browser and doc obj to set a flag, so it's harmless and probably correct this way.
* `navigate.c/handle_navigation_error`: Handled.
* `navigate.c/handle_extern_mime_navigation`: Handled.
* `omnavigator.c/OmHistory_get_length`: This is actually fixed by these patches.
* `script.c/ActiveScriptSite_GetItemInfo`: Handled.
* `script.c/ActiveScriptSiteWindow_GetWindow`: Handled.
--
v6: mshtml/tests: Fix XHR leak in test_window_refs.
mshtml: Get rid of outer_window member in HTMLDocumentNode.
mshtml: Remove the inner window ref from the doc only when it is actually
mshtml: Don't check for NULL outer_window from within HTMLWindow* methods.
mshtml: Don't attempt to send storage events after outer window is detached.
mshtml/tests: Improve the iframe navigation test.
mshtml: Don't rely on the outer_window in document.mimeType.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4380
The offending font is NotoColorEmoji.ttf which is present in, e. g., google-noto-emoji-color-fonts or noto-fonts-emoji packages available in various distribution. Attempting to load this font on Windows 10 (with AddFontResourceA() or open it with default font viewer) fails while currently succeeds on Windows. fontforge also refuses to open this font. That is because the font is bitmap only but missing bitmap table.
Some apps (Glyph launcher is an example) try to GetOutlineTextMetrics() on this font and do not expect that to have an error return (as we currenly do), which leads to crash on unhandled division by zero exception.
I am attaching a bitmap-only ttf test font (with only one bitmap) which I created with fontforge to make sure that such font can still be loaded in Wine. This font also loads on Windows (both with AddFontResourceA() and with default font viewer).
There are other font types which can be legitimately missing EBDT table, but FT_Load_Sfnt_Table() returns a different error for those and my patch doesn't reject those fonts.
[test.ttf](/uploads/b41472180b80c2c53f9dcc06055990f0/test.ttf)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/411
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55075
Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de>
--
v4: apisetschema: Add api-ms-win-core-com-l2-1-1
ole32: Move convert functions back from coml2
coml2: Remove temporary exports
ole32: Remove storage32.h
coml2: Move StgSetTimes from ole32
coml2: Move StgOpenStorageOnILockBytes from ole32
coml2: Move StgCreateDocfileOnILockBytes from ole32
coml2: Move StgOpenStorageEx from ole32
coml2: Move StgOpenStorage from ole32
coml2: Move storage interfaces from ole32
coml2: Move filelockbytes from ole32
coml2: Move IPropertyStorage implementation from ole32
ole32: Prepare for moving IPropertyStorage implementation
coml2: Move stream and block logic from ole32
coml2: Move stg_stream.c from ole32
coml2: Move IEnumSTATSTG from ole32
ole32: Refactor IEnumSTATSTGImpl_Construct to prepare for movement to coml2
coml2: Move StgCreatePropSetStg from ole32
coml2: Move StgIsStorageILockBytes from ole32
coml2: Move WriteClassStg from ole32
coml2: Move ReadClassStg from ole32
coml2: Move StgIsStorageFile from ole32
coml2: Move WriteClassStm from ole32
coml2: Move ReadClassStm from ole32
coml2: Move GetConvertStg from ole32
coml2: Add dll and move code from ole32/memlockbytes.c
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3106
If explicit_handle is defined in the *.idl file, c/s are uses explicit handles,
then an explicit handle must be passed in to the server-side interface
Add a test for explicit_handle.
v3.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4467
push_dc_driver() places drivers based on their priorities, so the newly created driver is not
necessary on top. Thus in windrv_CreateDC(), find_dc_driver() should be used to find the dib
driver instead of assuming the dib driver is the top driver, which could be the path driver because
it has a higher priority.
--
v3: win32u: Find the correct DIB driver in windrv_CreateDC().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4374