social.noyu.me

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

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

.inf is one of the older Windows mechanisms for installing… stuff. drivers in particular are often distributed with .inf files. seeing that WINE is eating its own dogfood here makes me happy. I love this stuff. it's like how touchHLE's UI is written in UIKit :)

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

so on Windows, file types, extensions and associations are defined in the registry in HKEY_CLASSES_ROOT, e.g.

[HKEY_CLASSES_ROOT\.bmp]
@="Paint.Picture"
[HKEY_CLASSES_ROOT\Paint.Picture]
@="Bitmap Image"
[HKEY_CLASSES_ROOT\Paint.Picture\shell\edit\command]
@="mspaint.exe \"%1\""

filetypes can have an icon, often from an exe/dll, e.g.

[HKEY_CLASSES_ROOT\txtfile\DefaultIcon]
@="notepad.exe"

but what about the exe file type… those have their own icons, are they special-cased?

[HKEY_CLASSES_ROOT\exefile\DefaultIcon]
@="%1"

nope! string interpolation! :3

microsoft windows is so cool

oh and yes, there is in fact a file association for opening exe files too. that part is also not a special case either. I think fucking up the file association for exe files is one of those classic things malware can do to really hose your system lol

jesus christ, if wine.inf specifically is any guide, there is a file association for opening folders and it uses something called "ddeexec", what were microsoft smoking in 1994 man

oh god it's real oh no what hell am i descending into

wow everything really is in the registry. there's shell extensions registered on certain filetypes, GUIDs referencing what must be some kind of COM object that can be loaded. this is really cool

why is there a ddeexec association to tell IExplore to WWW_OpenURL on every image file type. was the command that invokes iexplore.exe not enough

I tried the creating-shortcuts-with-an-INF-file trick on Windows 95!

• It brings up the “Updating Shortcuts” window we remember from the first boot after installing Windows 95!
• It creates a setup.old file, presumably renamed from setup.ini after execution!
• No underscores! :)

then I discovered that, with a fresh install of Win95, there's a setup.old file with a bizarre mess of entries, many with no target for the shortcut, only a name. I thought it might be leftover developer mess, but it turns out name-only lines remove shortcuts: upgrade cleanup!

though frankly a lot of that probably is leftover developer mess, it's just… there to clean it up? like, removing stuff that was never in a proper release version of Win95, only developer builds/betas/whatever? I'm just speculating!

@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"

@hikari oh wow neat