On Thu Sep 8 22:31:20 2022 +0000, Etaash Mathamsetty wrote:
> yeah I have had the same issue numerous times, it's really annoying, for
> the time being I would just squash the commits (that are built on top of
> upstream, not the upstream ones themselves), it usually fixes the problem
Interesting, I think julliard fixed it with the latest commits.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/810#note_8121
On Fri Sep 9 07:30:45 2022 +0000, Davide Beatrici wrote:
> This was supposed to remain `UINT32`, I got confused by the variable's name.
> `BOOL` is basically the same data type, but it should only be used for flags.
> `BOOLEAN` would be better for that though, as it's single-byte.
Fixed in !813.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/600#note_8092
Davide Beatrici (@davidebeatrici) commented about dlls/mmdevapi/unixlib.h:
> struct release_capture_buffer_params
> {
> stream_handle stream;
> - UINT32 done;
> + BOOL done;
This was supposed to remain `UINT32`, I got confused by the variable's name.
`BOOL` is basically the same data type, but it should only be used for flags.
`BOOLEAN` would be better for that though, as it's single-byte.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/600#note_8068
this gets the YSDrv service to start successfully (with the MmAllocateContiguousMemorySpecifyCache semi-stub)
this service is used by the nox android emulator
--
v8: add KeInsertQueueDpc stub
https://gitlab.winehq.org/wine/wine/-/merge_requests/778
On Thu Sep 8 22:30:41 2022 +0000, Santino Mazza wrote:
> Are the pipelines working correctly? I think it leaves some files
> modified and it fails when rebasing to the next commit.
yeah I have had the same issue numerous times, it's really annoying, for the time being I would just squash the commits (that are built on top of upstream, not the upstream ones themselves), it usually fixes the problem
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/810#note_8044
Run C++ global/static destructors during DLL_PROCESS_DETACH while other
other dllimport functions they may want to call are still viable. While
windows imposes many restrictions on what may be done in such destructors
(given that the run inside the loader lock), there are lots of legal and
useful kernel32 functions like DestroyCriticalSection, DeleteAtom, TlsFree,
etc that are both useful and legal. Currently this does not work for builtin
modules because all the Win32 structures are discarded well before
NtUnmapViewOfSection finally does the dlllose.
Even for a winelib .dll.so module, it would be preferable for destructors
to execute during process_detach (before wine tears down the MODREF
and detaches dependant dlls), rather than be left until after the last
NtUnmapViewOfSection (when we finally reach dlclose)
Therefore, winegcc now always uses the DllMainCRTStartup entry point
unless you specify your own --entry=func. Previously it did this only for
PE modules using msvcrt. Making this default consistent matches cl.exe,
which also always defaults to _DllMainCRTStartup unless overridden by /entry:foo
https://docs.microsoft.com/en-us/cpp/build/reference/entry-entry-point-symb…
The ELF version of winecrt0.a now provides a DllMainCRTStartup which,
per the Itanium ABI that is in practice what is used by gcc and clang,
performs this this destruction by calling __cxa_finalize(&__dso_handle)..
This libc function is required to be idempotent, so it's OK that dlclose
still calls it again later (there will just be no further work to do).
Multiple calls to __cxa_finalize shall not result in calling termination
function entries multiple times; the implementation may either remove
entries or mark them finished.
https://itanium-cxx-abi.github.io/cxx-abi/abi.html#dso-dtor-runtime-api
This has two main effects; it moves ELF destructors earlier (before imports
are unmapped), and it moves them inside the Nt loader lock. Being earlier
was the intended goal, and moving them inside the lock seems fine. Any Win32
API calls in destructors are just being subjected to the same lock hierarchy
rules as usual on windows (MSVC also runs destructors from DllMainCrtStartup)
https://docs.microsoft.com/en-us/cpp/build/run-time-library-behavior?view=m…
And any purely-ELF destructors that happen to also run earlier should never
call functions exported from wine (and thus don't care about ntdll's locks).
--
v3: winecrt0: run C++ object destructors during module unload.
https://gitlab.winehq.org/wine/wine/-/merge_requests/752
Follow-up to !600.
--
v2: wineoss: Switch to mmdevapi's unixlib.h.
wineoss: Adapt "get_position_params" struct to mmdevapi's.
wineoss: Adapt "get_frequency_params" struct to mmdevapi's.
wineoss: Adapt "create_stream_params" struct to mmdevapi's.
wineoss: Adapt "test_connect_params" struct to mmdevapi's.
wineoss: Drop "oss_" prefix in unixlib enum, apply it to the functions instead.
mmdevapi: Integrate wineoss's additions in unixlib.h.
https://gitlab.winehq.org/wine/wine/-/merge_requests/799
Follow-up to !600.
---
The version check logic is removed because redundant.
`SNDCTL_SYSINFO` was introduced in OSS 4.0: [oss4white.pdf](/uploads/e85c3196b611560db849cfac9e158bd2/oss4white.pdf)
The `ioctl()` call fails with OSS 3.x.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/799
This avoids an eventual stack overflow in exception-heavy applications.
Important note: when using the experimental Wow64 support on Linux, this change causes a crash during exception handling when unix_funcs->unwind_builtin_dll is called.
The call in dll/ntdll/signal_x86_64.c virtual_unwind() to unix_funcs->unwind_builtin_dll() should be commented out and replaced with 'status = STATUS_UNSUCCESSFUL;'.
This is along the same lines as needing to comment out the unix_funcs->init_builtin_dll() call for Wow64.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/802
Hopefully this patch series is easier to review than the last one.
--
v2: uiautomationcore: Implement UiaNodeFromHandle.
uiautomationcore: Add get_prop_val method to IWineUiaNode.
uiautomationcore: Implement UiaReturnRawElementProvider.
https://gitlab.winehq.org/wine/wine/-/merge_requests/801
Huw Davies (@huw) commented about programs/notepad/notepad.rc:
> MENUITEM "&Search next\tF3", CMD_SEARCH_NEXT
> MENUITEM "&Replace...\tCtrl+H", CMD_REPLACE
> }
> +POPUP "&View"
> +{
> + MENUITEM "&Status Bar", CMD_SBAR
> + }
Another trailing space after `"&View"` and a space before the `}`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/787#note_7878
Huw Davies (@huw) commented about programs/notepad/main.c:
> return dpi;
> }
>
> +VOID ToggleStatusBar(VOID)
`static` (as the function isn't used outside the file).
Also, and I know it not the case in this file, but let's use `void` rather than `VOID`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/787#note_7873
Huw Davies (@huw) commented about programs/notepad/dialog.c:
> Globals.bWrapLongLines = !Globals.bWrapLongLines;
> CheckMenuItem(GetMenu(Globals.hMainWnd), CMD_WRAP,
> MF_BYCOMMAND | (Globals.bWrapLongLines ? MF_CHECKED : MF_UNCHECKED));
> + SendMessageW(Globals.hMainWnd,WM_SIZE,0,MAKELPARAM(rc.right,rc.bottom));
This looks hacky. You probably want to move the code that you're adding to the main window's WM_SIZE handler to a helper function and call that directly from here.
Also, and this applies throughout, please leave a space after each comma.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/787#note_7872
Generally I think this MR should be split into two separate ones. That'll give us a chance to get the status bar work in before we worry about the goto dialog box.
So, just concentrating on the status bar commit, I'd start off by splitting that into two commits. First add the code that creates and displays the status bar (it doesn't need to display any text at this point). Then add a second commit that updates the status bar with line / col info.
As @besentv mentioned, the commit messages are still not quite there - we terminate the subject with a period.
I'll comment on some of the code below.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/787#note_7869
Fixes building tests in Visual Studio with msvc's own crt headers.
---
This follows patches in other places that replaced it first with _strnicmp(a, b, -1),
and later with _stricmp(a, b), because _strnicmp with size=-1 raises a runtime error.
--
v2: test.h: Don't use \e.
include/test.h: Don't use strcasecmp.
https://gitlab.winehq.org/wine/wine/-/merge_requests/796
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….
--
v3: win32u: Return DISP_CHANGE_SUCCESSFUL from nulldrv_ChangeDisplaySettingsEx.
win32u: Read current display settings from the registry if GetCurrentDisplaySettings fails.
win32u: Write current display settings to the registry in apply_display_settings.
win32u: Force update display cache after NtUserChangeDisplaySettingsEx.
win32u: Introduce a new VirtualScreenRectChanged display driver callback.
win32u: Broadcast WM_DISPLAYCHANGE message on display settings change.
win32u: Move enumeration of available modes out of graphics drivers.
https://gitlab.winehq.org/wine/wine/-/merge_requests/551
Dual source blending implies an additional shader output, which needs to
be declared. This improves WoT on high graphics settings on MoltenVK.
--
v2: wined3d: Tell vkd3d_shader about dual source blending.
https://gitlab.winehq.org/wine/wine/-/merge_requests/784
This includes some fixes for obvious mistakes as well as initial cleanup of the WM async reader, in preparation for implementing proper threading support.
I'm planning on doing some more refactoring first, ultimately implementing the async reader on top of the sync reader, and removing the need for a private interface. I've checked that it can indeed work on Windows too, and it'll make the code simpler overall.
--
v2: winegstreamer: Query IWMReaderCallbackAdvanced interface in Open.
winegstreamer: Avoid waiting for callback thread on allocation failure.
winegstreamer: Release callback and context in async_reader_close.
winegstreamer: Move open_stream / close_stream helpers around.
winegstreamer: Leave async reader callback_cs on calloc error.
winegstreamer: Leave WM reader CS on invalid output format.
winegstreamer: Avoid leaking async ops on release or multiple close.
winegstreamer: Rename async reader stream_thread to callback_thread.
https://gitlab.winehq.org/wine/wine/-/merge_requests/695
Instead of leaking "kernel" pointers.
--
v2: winevulkan: Separate PE and Unix VkCommandBuffer structs.
winevulkan: Wrap VkCommandPool on PE side.
winevulkan: Separate PE and Unix VkPhysicalDevice strucrts.
winevulkan: Separate PE and Unix VkInstance structs.
winevulkan: Separate PE and Unix VkQueue structs.
winevulkan: Separate PE and Unix VkDevice structs.
https://gitlab.winehq.org/wine/wine/-/merge_requests/788
On Wed Aug 10 18:46:02 2022 +0000, Tobias G��rgens wrote:
> All commits build now and tests run through fine.
> What do I need to do next?
> Is there still anything I should change?
Hey there, I'd really like to get this through, I just need to know what's missing/what I should do next :)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/564#note_7627
Fixes building tests in Visual Studio with msvc's own crt headers.
---
This follows patches in other places that replaced it first with _strnicmp(a, b, -1),
and later with _stricmp(a, b), because _strnicmp with size=-1 raises a runtime error.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/796
This implements sending StorageEvents to the same window/doc from where the storage change happened, which seems to be a thing on native IE. For some reason I was unable to have them actually sent to other windows, so that's not implemented since I've no idea how that even gets triggered to test it, and if it does it will probably be in a follow up MR, even though that's *supposed* to be the use of these events���
localStorage sends for `onstoragecommit` on the doc that did the change, while sessionStorage sends for `onstorage` on the window and doc that did the change, depending on compat mode. Although the event sent to the document's `onstorage` seems to be a legacy/old-style event (as tests show).
Tests are on the last patch since events have to be sent properly (else it hangs).
--
v2: mshtml/tests: Add tests for StorageEvents.
mshtml: Send StorageEvents when removing an existing item.
mshtml: Send StorageEvents when setting an item.
mshtml: Implement StorageEvent and send it when clearing the storage.
mshtml: Move the MessageEvent construction to a helper.
include: Add IDOMStorageEvent and DispDOMStorageEvent interfaces.
https://gitlab.winehq.org/wine/wine/-/merge_requests/795
This implements sending StorageEvents to the same window/doc from where the storage change happened, which seems to be a thing on native IE. For some reason I was unable to have them actually sent to other windows, so that's not implemented since I've no idea how that even gets triggered to test it, and if it does it will probably be in a follow up MR, even though that's *supposed* to be the use of these events���
localStorage sends for `onstoragecommit` on the doc that did the change, while sessionStorage sends for `onstorage` on the window and doc that did the change, depending on compat mode. Although the event sent to the document's `onstorage` seems to be a legacy/old-style event (as tests show).
Tests are on the last patch since events have to be sent properly (else it hangs).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/795
Added a status bar to track line and column number
Added a goto line dialog
--
v3: notepad: Added goto dialog function
notepad: Added status bar to track line number and column
https://gitlab.winehq.org/wine/wine/-/merge_requests/787