social.noyu.me

let's start a thread to collect little things we learn about WINE as we tumble down the rabbithole

hoping not to also have an it's-my-own-invention WINE thread or a looking-glass-insects WINE thread

everyone who's ever used WINE has seen this little box that pops up while it's creating or updating the wineprefix. this is drawn by wineboot.exe, which makes sense.

anyway how does it do the actual prefix setup? by executing an honest-to-god .inf file!!! https://gitlab.winehq.org/wine/wine/-/blob/master/loader/wine.inf.in

on Windows 10 this INF file creates a start menu entry, but the space becomes an underscore ^^;

[version]
signature=$chicago$
[DefaultInstall]
UpdateInis=AddLink
[AddLink]
setup.ini,progman.groups,,"group1=""Test Group"""
setup.ini,group1,,"""Shortcut Name"",""%11%\notepad.exe""

ah, WINE is cheeky and most DLLs it ships with are “fake”, with it instead loading code from host binaries. what's fun is that you can't just swap out those DLLs, because WINE always assumes they are fake and won't load them. you have to set WINEDLLOVERRIDES to make that work

so I've been trying to get WINE to copy ReactOS's mspaint.exe into the wineprefix's system32. wine.inf has a wildcard that copies any exe files in /usr/lib/wine/x86_64-windows into system32, but that skips ones without a special signature in the DOS stub! so I'm using CopyFiles

@hikari no longer true i believe? since the switch to compiling builtin dlls as real PE dlls instead of native shared libraries. then the dlls make "syscalls" and the syscall implementations (which couldn't be replaced in the windows world anyway) are native libraries

@tbodt @hikari
They are real DLLs, i.e. they're identical to the builtin files that actually get loaded. However, the load order logic still applies; if there is a builtin DLL present in libdir or the build tree it'll get loaded instead of the one in the prefix.

@zfigura @hikari oh i see

@hikari i parsed that as "WINE DLL LOVER RIDES"