On 12/09/2020 14:11, spaarder wrote:
Gabriel Ivăncescu schreef op wo 09-09-2020 om 18:30 [+0300]:
On 09/09/2020 15:25, spaarder wrote:
Hello,
I want to contribute to the wonderful Wine project, so I decided to start with a simple patch for the CreateSymbolicLinkW WINAP in kernelbase.dll .
In my patch I use the system() function, which is in the stdlib library. The linker cannot find this library because of the "-nodefautlibs" in Makefile.in . When I remove -nodefaultlibs, all compiles well, but now wineboot (and probably a _lot_ of other things) are broken, even if I undo my patch.
Why does removing -nodefaultlibs from wine/dlls/kernelbase/Makefile.in break so many things? Has it anything to do with @ cdecl system(str) MSVCRT_system?
What would be the "proper" (wine) way to solve this?
Big thanks!
Hans.
Hi Hans,
Unfortunately, CreateSymbolicLinkW is actually complicated. There are patches in wine-staging that implement it, so you can take a look there and see why that is so (because Windows also has junction points and so on). See the ntdll-Junction_Points patchset in wine-staging.
Now for your question about -nodefaultlibs: the wine dlls that have this flag are compiled as native Windows .DLL PE files. That means they can't use system (unix) functions. kernelbase is one such example: most of the functions in kernelbase are done through ntdll.
ntdll is also compiled as PE, but it has a unix library component (to be able to use unix libraries or communicate with the wine server). So in general, the procedure would be to:
Implement symbolic links via some ntdll API. Have kernelbase use the ntdll API to implement it.
You can see a 'unix' subdir in the ntdll, which is where the unix library is, and it's called through function pointers from the PE module (all files at the root of the dir).
Again, the wine-staging patchset might help you in with clues. I'm not that familiar with the details myself, so I apologize if I said something wrong.
Someone more knowledgeable might clarify it better, if they have the time.
Thank you for your answer Gabriel, it helped me a lot! I looked at the patch in staging, and I noticed it is HUGE and COMPLICATED.
Yeah, it's complicated as I said. On Windows, you have both junctions (which can only point to directories) and symbolic links (which can point to both files and directories). AFAIK, a symlink also remembers whether it points to a directory or to a file, even if the target doesn't exist (so you can't inspect the target to report whether it's a dir or file). All of these things must be implemented using some trickery (such as specially encoding the underlying unix symlink and translating it back when requested by a Windows app, giving it the information).
Another potential problem is what happens when you move the prefix. What about absolute symlinks? Clearly, on Windows you can store absolute symlinks to drives like `D:\somedir` and moving the symlink within the Windows filesystem will still point to the same place. This works on Wine if you keep absolute unix symlinks, but it creates another problem if you move the wine prefix itself, because then the symlink will be dead.
You have to take into account all of these matters. Your solution also uses a system command to do it, which should only be a last resort in extreme cases (such as when you need a setuid binary), instead of simply calling unix library functions, which is much faster and reliable.
Now, if you're interested in just making use of this functionality, is there a reason you can't just use the wine-staging patch? Is it wrong in some cases you need? You might consider bringing those issues up and/or fixing them instead in the wine-staging patchset.
Your patch is obviously wrong for the purposes of the Wine project and is what we call a "hack" since it clearly doesn't match Windows behavior. Keep in mind that just because it works for you doesn't mean there's not some obscure app somewhere that relies on Windows specific symbolic link behavior. That's why the wine-staging patch is so complicated, and it's still not ready yet for upstream.