I haven't seen any software that uses this, but some older software out there might use it, so it's good idea to export it.
--
v3: ntoskrnl.exe: add KeNumberProcessors export.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1139
I haven't seen any software that uses this, but some older software out there might use it, so it's good idea to export it.
--
v2: ntoskrnl.exe: add KeNumberProcessors export.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1139
This should move all of the remaining interfaces out of basedoc, except for IDispatchEx (and some fields will still remain); those will be for next MR.
Because all of the remaining interfaces are in the `htmldoc.c` file, and they typically tend to just forward to the HTMLDocumentNode, I'm using some macros inspired by the HTMLWINDOW7_ONEVENT_PROPERTY_\* in `htmlwindow.c` to reduce duplication. The ones that are exceptions are implemented normally without macros.
The first commit converts all of the non-IHTMLDocument\* interfaces because most of the methods are FIXMEs/unimplemented, so splitting it up isn't worth it.
--
v2: mshtml: Move the IHTMLDocument7 interface out of basedoc.
mshtml: Move the IHTMLDocument6 interface out of basedoc.
mshtml: Move the IHTMLDocument5 interface out of basedoc.
mshtml: Move the IHTMLDocument4 interface out of basedoc.
mshtml: Move the IHTMLDocument3 interface out of basedoc.
mshtml: Move the IHTMLDocument2 interface out of basedoc.
mshtml: Move the remaining non-IHTMLDocument* interfaces out of basedoc.
mshtml: Move HTMLDocumentObj implementation to oleobj.c.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1125
As far as my testing goes, the message box is never shown on Windows when abort() is called with retail runtime is used, regardless of error mode and abort behaviour. That is not the case with _assert which still can show a dialog even in release mode.
It happens rather often that an app meets the error condition during the process exit and that goes silent on Windows while we display the abort dialog on app's exit.
The test program below shows that (and the same behaviour is, e. g., with ucrtbase vs ucrtbased).
```
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
void CDECL _set_app_type(int app_type);
#define D(name) static typeof(name) *p_##name
#define L(name) p_##name = (void *)GetProcAddress(hdll, #name); if (!p_##name) printf("NULL %s.\n", #name)
D(abort);
D(_set_app_type);
D(_set_abort_behavior);
D(_set_error_mode);
int main(int argc, char *argv[])
{
HMODULE hdll = LoadLibraryA("msvcrt.dll");
printf("hdll %p.\n", hdll);
L(_set_app_type);
if (!p__set_app_type)
if (!(p__set_app_type = (void *)GetProcAddress(hdll, "__set_app_type")))
printf("NULL p__set_app_type.\n");
L(abort);
L(_set_abort_behavior);
L(_set_error_mode);
p__set_app_type(2);
if (p__set_abort_behavior)
p__set_abort_behavior(_WRITE_ABORT_MSG, _WRITE_ABORT_MSG);
p__set_error_mode(_OUT_TO_MSGBOX);
p_abort();
}
```
--
v2: msvcrt: Display message box in abort() for specific CRT versions only.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1128
With this series it's now possible to run and pass `user32:monitor` and `user32:sysparams` tests with nulldrv, and so most `user32` tests (except for a few desktop cursor position tests). This still requires some prefix configuration to enable the nulldrv driver, or a change like https://gitlab.winehq.org/rbernon/wine/-/commit/753368ad0ec52f03f8d6e78ca79… to enable it when `DISPLAY` environment variable is unset.
This then shows that some of the user32 tests are failing with winex11 but passing with nulldrv, as in https://gitlab.winehq.org/rbernon/wine/-/commit/6d5f4109a514a0dc266899fcacf….
--
v11: win32u: Read mode from the registry if GetCurrentDisplaySettings fails.
win32u: Write display settings to the registry in apply_display_settings.
win32u: Lock display devices while applying display settings.
winemac.drv: Avoid calling back to win32u to find the primary adapter.
winex11.drv: Avoid calling back to win32u to find the primary adapter.
win32u: Add an is_primary parameter to ChangeDisplaySettings.
win32u: Force update display cache after NtUserChangeDisplaySettingsEx.
win32u: Add a BOOL force parameter to update_display_cache.
https://gitlab.winehq.org/wine/wine/-/merge_requests/551
Currently, unwinding the unix libraries (or full ELF builds) requires having libunwind available.
When starting up a wine environment, an exception of type `RPC_S_SERVER_UNAVAILABLE` gets thrown - and if libunwind isn't available, this breaks the startup. Thus, currently on ARM/ARM64, libunwind is essentially mandatory.
Additionally, at least on ARM, libunwind seems brittle (commits in latest git master breaks the unwinding use cases in Wine, see e.g. https://github.com/libunwind/libunwind/pull/203#issuecomment-984126066.
This MR tries to resolve all of this, by including the preexisting DWARF parser from x86_64 in the aarch64 version too. This bit was mostly quite straightforward.
For ARM, libunwind has currently relied on DWARF debug info in the `.debug_frame` section, since Linux on ARM doesn't use DWARF for runtime unwinding. This MR adds ARM EHABI unwind opcodes where necessary, and adds a local reimplementation of an ARM EHABI/EXIDX/EXTBL unwinder, similar to the DWARF one.
With these changes, unwinding on both ARM and ARM64 seems to work fine, even without libunwind.
See the individual commit messages for more commentary on the decisions taken so far (I've tried to write up all relevant considerations there - it's a fair amount of commentery).
A couple open questions:
- So far, the shared DWARF code was put in a header, `dwarf.h`. Do you want to make this a proper standalone `.c` file too?
- I wrote the ARM EHABI unwind code mostly with `stdint.h` types like `uint32_t`(as it's in the ntdll/unix directory anyway), but I can rewrite it with `DWORD` or similar if that's preferred.
- The ARM EHABI opcodes are enabled for `defined(__arm__) && defined(__ELF__) && defined(__GNUC__) && !defined(__SEH__) && !defined(__ARM_DWARF_EH__)` - there's no define to check for for knowing it's used and enabled, but it has to be implicitly assumed if no other other unwind mechanism is signaled.
- The `dl_iterate_phdr` function, used for finding the EXIDX section for locating ARM EHABI unwind info, is used within `#ifdef linux`. It might be available on other OSes too (like FreeBSD etc). Or should I go ahead and add a configure check for it?
CC @julliard @rbernon @AndreRH
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1134
As far as my testing goes, the message box is never shown on Windows when abort() is called with retail runtime is used, regardless of error mode and abort behaviour. That is not the case with _assert which still can show a dialog even in release mode.
It happens rather often that an app meets the error condition during the process exit and that goes silent on Windows while we display the abort dialog on app's exit.
The test program below shows that (and the same behaviour is, e. g., with ucrtbase vs ucrtbased).
```
#include <windows.h>
#include <stdio.h>
#include <stdlib.h>
void CDECL _set_app_type(int app_type);
#define D(name) static typeof(name) *p_##name
#define L(name) p_##name = (void *)GetProcAddress(hdll, #name); if (!p_##name) printf("NULL %s.\n", #name)
D(abort);
D(_set_app_type);
D(_set_abort_behavior);
D(_set_error_mode);
int main(int argc, char *argv[])
{
HMODULE hdll = LoadLibraryA("msvcrt.dll");
printf("hdll %p.\n", hdll);
L(_set_app_type);
if (!p__set_app_type)
if (!(p__set_app_type = (void *)GetProcAddress(hdll, "__set_app_type")))
printf("NULL p__set_app_type.\n");
L(abort);
L(_set_abort_behavior);
L(_set_error_mode);
p__set_app_type(2);
if (p__set_abort_behavior)
p__set_abort_behavior(_WRITE_ABORT_MSG, _WRITE_ABORT_MSG);
p__set_error_mode(_OUT_TO_MSGBOX);
p_abort();
}
```
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1128
On Fri Oct 21 09:44:38 2022 +0000, Rémi Bernon wrote:
> I suggested to do that so we can use these tokens in the macros, which
> need to stringify their value for the `.cfi_escape` strings.
Oh, I see - thanks, that makes sense.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_11683
On Fri Oct 21 09:29:30 2022 +0000, Martin Storsjö wrote:
> Out of curiosity - was there any specific reason for changing these
> enums into defines (or was this maybe an artifact from how this patch
> evolved from earlier forms)?
I suggested to do that so we can use these tokens in the macros, which need to stringify their value for the `.cfi_escape` strings.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1065#note_11674
Jan Sikorski (@jsikorski) commented about dlls/dbghelp/dwarf.c:
> }
>
> /* Dwarf tends to keep the structure of the C/C++ program, and emits DW_TAG_lexical_block
> - * for every block in source program.
> + * for every block the in source program.
in the ;)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1126#note_11664