May 2025 - Wine-Devel - list.winehq.org

Re: How to add multiple versions of the same DLL (with the same base name) in apisetschema.spec?

by Fabian Maurer

Hello, For calculating the hash the last digit is intentionally ignored, so you will always get a hash collision. Although I didn't find any official documentation, the last digit seems to be the minor version, and I'd assume that means it remains backwards compatible. Unless you get someone more experienced to answer, I'd probably submit that as PR and see what Alexandre says. Regards, Fabian Maurer

May 17, 2025

How to add multiple versions of the same DLL (with the same base name) in apisetschema.spec?

by zhengxianwei

Hello, I'm planning to add the following line to apisetschema.spec: *api-ms-win-power-setting-l1-1-1 = powrprof.dll* However, this causes a hash conflict with the existing line: *apiset api-ms-win-power-setting-l1-1-0 = powrprof.dll* May I ask how you usually resolve such conflicts? I'm concerned that removing version 1-0 might cause some older applications to stop working. Would it be possible to delete the router for 1-0 and instead add a new line like this? *ln -s powrprof.dll api-ms-win-power-setting-l1-1-0*

May 17, 2025

irc.libera.chat ?

by zhengxianwei

May I ask, what's the difference between asking questions on irc.libera.chat and asking here? Will this place gradually be phased out, with activity gradually shifting over there?

May 17, 2025

Pre-commit

by robert lippmann

Hi all, I was looking in the docs, and came across this (https://gitlab.winehq.org/wine/wine/-/wikis/Git-Wine-Tutorial#removing-trai…) "It fixes whitespace on all the commits that you've made. I think it's pretty good about merge conflicts due to whitespace as well. I don't know of a way of doing this at commit time though.” Well, actually there is. Pre-commit (https://pre-commit.com/) Actually fixing whitespace is a built in rule, I believe. And there are various others tailored to different languages. It’s used pretty extensively in Python development, but doesn’t need Python. Since it runs in node, there’s a VSCode extension for it. So, I was wondering if there was any interest in perhaps adding the yaml configurations to the wine source tree, and figuring out what rules might be useful to implement. Thanks, Rob

May 16, 2025

Re: Gitlab workflow question

by robert lippmann

Yes, I have done all of that. I’ve been rebasing for a few weeks. I was just wondering that since changes were requested if there is something else I need to do to tell Gitlab “ok, I’m done” to put it back as available for merge? I’ve marked all threads as resolved, but want to make sure there’s nothing else I need to do. — Rob > On May 16, 2025, at 7:18 AM, Gerald Pfeifer <gerald(a)pfeifer.com> wrote: > > On Thu, 15 May 2025, robert lippmann wrote: >> I submitted a patch, and needed to make changes. I made the changes, >> but am not sure how to submit it for re-review. > > Are you aware of https://gitlab.winehq.org/wine/wine/-/wikis/Git-Wine-Tutorial ? > >> Is there something I need to do to get it so it’s mergeable again? >> I’ve been rebasing for weeks. Should I just close the MR, and submit a >> new one? > > https://gitlab.winehq.org/wine/wine/-/wikis/Git-Wine-Tutorial#updating-a-me… > specifically looks like it may be addressing your question? > > I have successfully used these instructions myself a few times. > > Hope this helps, > Gerald

May 16, 2025

Re: Gitlab workflow question

by Gerald Pfeifer

On Thu, 15 May 2025, robert lippmann wrote: > I submitted a patch, and needed to make changes. I made the changes, > but am not sure how to submit it for re-review. Are you aware of https://gitlab.winehq.org/wine/wine/-/wikis/Git-Wine-Tutorial ? > Is there something I need to do to get it so it’s mergeable again? > I’ve been rebasing for weeks. Should I just close the MR, and submit a > new one? https://gitlab.winehq.org/wine/wine/-/wikis/Git-Wine-Tutorial#updating-a-me… specifically looks like it may be addressing your question? I have successfully used these instructions myself a few times. Hope this helps, Gerald

May 16, 2025

Gitlab workflow question

by robert lippmann

Hi all, I submitted a patch, and needed to make changes. I made the changes, but am not sure how to submit it for re-review. I’m used to GitHub, and less formal development practices where it just automatically pops up as open again. Is there something I need to do to get it so it’s mergeable again? I’ve been rebasing for weeks. Should I just close the MR, and submit a new one? Thanks, Rob

May 16, 2025

[RFC] Running Wine under AddressSanitizer

by Yuxuan Shui

Hi all, I've been working on this for a while and the list of changes are getting long. So I think this is a good time as ever to announce it, and get some feedback to make sure I haven't gone too far off the rails. This email is a bit long. What is this about? =================== AddressSanitizer (ASan for short) is one of a class of tools that help with discovering common coding mistakes. ASan specifically detects memory problems, like buffer overflows, use after frees, memory leaks, etc. It has been extremely successful in the past decade, and the list of bugs it helped discover is very very long. It has even already seen successes in the wine project as well. @bernhardu was able to get the PE side of wine to work with ASan (with some exceptions) using llvm-mingw, after he fixed [1] a handful of incompatibility problems in llvm compiler-rt. And with that many bugs [2] were then discovered and fixed. And my plan is to take this a step further. [1]: https://github.com/llvm/llvm-project/pulls?q=is%3Apr+is%3Aclosed+author%3Ab… [2]: https://gitlab.winehq.org/bernhardu/wine/-/blob/asan-pe_2025-04-26_wine-10.… Goals ===== I want this to be a quick and easy to use tool, the first thing one would reach for when seeing something that might be a memory related problem. e.g. I spend 5 minutes reproducing the bug with an ASan-enabled wine build, if it catches it, then I am done; otherwise I move on with my usual debugging routine, without having wasted too much time. I also want it to be a first line of defence, which runs in CI to catch occasional bugs that slip through reviews. In my mind, this means 1) it must be easy to set up, ideally just a flag passed to `configure`, no fuss. 2) it should cover as much of wine as possible, both PE and unix, and ideally all PE DLLs. Current status ============== Wine builds and runs. A majority of test cases pass, but some failures seem to be ASan related, which I still need to investigate. Both stack and heap problems are detected and reported. Stack traces are captured, but only on the PE side, and are not symbolized yet - I need to pipe the numbers into llvm-symbolizer. Stack traces aren't being saved for heap allocations and frees, so for use-after-frees the reports aren't very useful yet. Fiber support is TODO. Leak detection is TODO as well. Works done so far ================ You can find my branch here: [3]. To build it, you need either clang, or a slightly patched [4] gcc, and you just run configure with `--enable-sanitize`. I tried to put into the commit messages as comprehensive a list of what I did as possible, but I'll also provide an overview here. It's very abbreviated to not make this email even longer. If you need to know of how ASan works, there is a quick explanation here [5]. Since no existing ASan runtimes can support the unix and the PE side at the same time, I chose to write my own ASan runtime. The runtime is made part of ntdll, since that's the first DLL that loads. A non-standard shadow offset was chosen, so in the new WoW64 mode the 32-bit and the 64-bit side can share a common shadow. Shadow memory is mapped very early inside `virtual_init` to make sure we can enable ASan for as much code as possible (though doing it inside the loader is also an option). Some care needed to be taken to make sure no false positives show up after stack manipulations (e.g. unwinding). Redzoning and quarantining is added to ntdll's heap allocator, though I don't like that. [3]: https://gitlab.winehq.org/yshui/wine/-/commits/address-sanitizer-presentable [4]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119926 [5]: https://github.com/google/sanitizers/wiki/AddressSanitizerAlgorithm Request for help ================ I intend to continue working on this, and I don't really see any technical challenges that would make this fundamentally undoable. But I do worry that certain things I had/will have to do might make this not upstreamable. So, I think I need some guidance. (I will open a draft MR on winehq gitlab shortly, if you prefer commenting there). Bad things I did to get it working ---------------------------------- There are certain things I did that didn't feel good when I did them, so I am listing them here to see if anyone has a better way to do them. - ASan runtime as part of ntdll. I can't think of a better place to put it, since the runtime needs to be available before PE code runs. This also means all these functions are exported from ntdll, and I have yet to find a way to not export them when ASan is disabled. - dinput/tests and ntoskrnl.exe/tests need to be linked with ntdll, since they need to get their ASan runtime from ntdll. - Things I added to winecrt0. ASan uses some global variables for information such as where the shadow was mapped, and dynamically linked libraries need this information too. On the unix side the dynamic linker will nicely find them for you, but the same doesn't work with PE. So ASan duplicates these variables for each DLLs. In the vanilla ASan runtime, this comes from linking with a "dynamic runtime thunk"; in wine, I felt winecrt0 is the best place for them? These variables also need to be initialized, which means calling an ASan interface function which is exported from ntdll, from `DllMainCRTStartup`. This meant I had to add `-Wl,--{start,end}-group` for starters, because now libntdll.a and libwinecrt0.a have circular dependencies. Additionally though this works for other DLLs, it becomes a problem when winecrt0 is linked into ntdll, which creates a importing-from-self situation. I added a `DllMainCRTStartup` to ntdll, so the one from libwinecrt0.a is not pulled in, thus breaking the cycle. But it definitely feels wrong. (Vanilla ASan does this initialization by putting functions into the `.CRT$XIB` section, which the CRT will call on DLL load. I was told wine CRT doesn't implement this). - `__WINE_FRAME`. I don't fully understand this, but IIUC this is a hacky exception/unwinding mechanism, for when the compiler doesn't support native __try/__except? These are put on the stack which later the unwinder will look for to find the correct exception handler. This doesn't work since ASan uses fake stack frames, so the unwinder can't find these `__WINE_FRAME`s and thus fails. I get this somewhat working by translating between fake and real stack addresses, ew. I don't know much about SEH, is it really not possible to use it for these __try/__excepts as well? Things I need advices on ----------------------- - Heap. I added ASan redzoning directly to the ntdll heap allocator, which I don't like since it added a lot of complexity to it, and it's not available on the unix side. I want to write an ASan specific allocator, since performance and memory efficiency aren't major concerns here, this allocator can be made simple. But I am not 100% sure if this is a good idea. - Stack trace. What's the best way of capturing stack traces from PE _and_ unix, if we are in a syscall/unix call for example? - Shadow offset. This is a bit complicated. clang supports dynamic shadow offset but mingw-gcc doesn't (it doesn't officially have ASan support), so for max compatibility we want a fixed shadow offset. If we want a single shadow to be shared between 32 and 64 bit in the case of new WoW64, the shadow offset needs to be below 4G, which basically precludes non-relocatable 64-bit PE from being loaded (the shadow takes 16 TiB); or we choose a high shadow offset for 64-bit to avoid conflicts, but that means we need to mirror this shadow into the lower 4G of the address space for 32-bit, which complicates the initialization phase. (If you made it to the end, thank you!) -- Regards Yuxuan Shui

May 15, 2025

Re: How to use AddressSanitizer with Wine?

by Yuxuan Shui

Hi, On Tue, May 6, 2025 at 1:31 PM Bernhard Übelacker <bernhardu(a)mailbox.org> wrote: > > Am 28.04.25 um 11:55 schrieb Yuxuan Shui: > > Hi, > > > > I heard you were talking about ASan :) > > > > Just want to say that I happen to be working on ASan as well. Bernhard did > > amazing work getting llvm's ASan runtime to work with Wine, however I am doing > > a different approach. I want to be able to intrument the entirity of Wine, not > > just PE. This has some challenges, created by e.g. the PE/Unix split, WoW64, > > etc. I don't think any ASan runtimes can handle this yet, so I am working on > > a special runtime for Wine. This is a lot of work, but on the flip side, this > > should make running Wine under ASan much smoother, and rid us of the dependency > > on compiler-rt. > > > > Ask me anything if this sounds interesting. Hopefully this idea doesn't sound > > completely crazy to you ^^; > > > > Best, > > Yuxuan > > > Hello Yuxuan, > this sounds interesting :-) Thanks! BTW, I just got heap poisoning to work with wine's heap allocator (though I am still not sure if that's the best way to do it), and with that I was able to replicate some of your findings! It's such a relief to know I can indeed create a working, independent ASan runtime. > > I wondered if it would be possible to use PE and unix side with ASan enabled, > and guessed this might need some changes in synchronising both to access > a single Shadow memory, but never tried something into this direction. Yes, but more importantly, I wanted to cover as much of wine as possible. This includes some of the dlls I think you had to exempt from ASan, such as ntdll.dll itself. Since ntdll is the first dll to ever load, and in fact the code to load dlls is part of ntdll, there is no choice but to link an ASan runtime into ntdll, otherwise we can't initialize the ASan runtime early enough for ntdll to use. The biggest hurdle of doing that would be the fact that the existing libasan is written in C++, so I doubt we can ship its source with wine. Plus, writing an ASan runtime dedicated to wine also gives me more control and allows me to adapt to wine's needs. (e.g. I had to adjust shadow offset for WoW64 mode since that has mixed 32-bit and 64-bit code). Oh, and I want to try and see if I can get LeakSan to work as well. ASan on Windows doesn't have that because they are missing `ptrace`. wine doesn't have this limitation :) > > Kind regards, > Bernhard -- Regards Yuxuan Shui

May 15, 2025

Re: How do I determine which functions are unimplemented?

by zhengxianwei

Nice, It seems to work On Wed, May 7, 2025 at 1:48 AM Elizabeth Figura <zfigura(a)codeweavers.com> wrote: > On Tuesday, 6 May 2025 10:02:19 CDT Hin-Tak Leung wrote: > > wine-dump can look at the import table. You can compare that with the > export table from wine to see which routine is missing. > > One non-wine solution is a piece of software called dependency walker. > It looks at what a software requires at the api / dll level. > > That won't help. If an application calls a missing function that it links > to directly, Wine should still name the function, in the terminal if > nothing else. > > [BTW, please avoid top-posting on public lists.] > > > On Tuesday 6 May 2025 at 13:11:48 BST, zhengxianwei < > baikaishiuc(a)gmail.com> wrote: > > > > When a function is commented out and the application calls it, the > application crash silently . I dont know which function caused this. Is > there any way to quickly determine which functions are unimplemented ? > > If the application is retrieving a function via GetProcAddress() and it's > missing, you can try WINEDEBUG=warn+module. This will print a warning for > every function that was not found. Be warned that it will include many > false positives, though. > > > > >

May 15, 2025