social.noyu.me

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

.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!

this is effectively the loss32 development thread, so I may as well use this space to point out I have put an updated time estimate for the PoC's release on https://loss32.org/ now:

time to uh… figure out how to add support for the setup.ini desktop shortcuts thing in upstream WINE. this'll be fun! probably will be our first WINE contribution :)

…eating our own dogfood and doing loss32 development from within loss32 itself would probably massively improve our productivity, if we can deal with the instability. We should try that.

ahh, writing C89 code dealing with the Windows API… it's been so long since we've done serious C programming, we've really missed this. genuinely. it's like coming home…

gotta love some DWORDs and WCHARs and a SetupGetLineTextW( &context, NULL, NULL, NULL, NULL, 0, &size )

…there is a newer way to create Start Menu entries from an INF file, one that is actually documented, and it is called ProfileItems. Why did we not notice that four months ago? Well, I learn this at just the right moment, because getting setup.ini to work in WINE is tricky.

…and it is already supported by WINE, so we don't even have to patch WINE's implementation of setupapi, we can get straight to adding the shortcuts! Software development sometimes looks like wasting a lot of time on unnecessary work, missing a solution right under your nose.

Using git-worktree for the first time in our life… we're doing our WINE development on top of master, but the released versions of loss32 will be based off WINE stable, and so we'd like to avoid rebuilding everything when we switch branch. Can't believe we never used it before…

WINE is compiling, the perfect excuse for some lazy strumming… (xkcd 303, guitar girl edition)

Did you know? WINE actually comes with quite a lot of software!

(But it doesn't come with Start Menu shortcuts for that… yet. :)

@hikari I see no calc.exe, so clearly Wine is immune from hacking.

@h0m54r @hikari luckily for security enthusiasts reactos's calc.exe works

@hikari what's a setup.ini?

@esoteric_programmer A very obscure thing documented earlier in the thread.

@hikari holy shit, I went all the way to Davy Jones's locker with that one for sure. Yo, this is fascinating! maybe that's how MSAA and UIA work internally, registry entries all the way down? is that how programs discover COM objects?

@esoteric_programmer COM is a deep rabbithole but I do believe the registry has some involvement in discovering COM objects, because CLSIDs (class IDs) can be registered there

@hikari now I wonder how wine dlls which connect to native code are made and if I can, somehow, not write them in C, because knowing how those UIA things work kinda, which is definitely something few people know even exists, we could translate windows accessibility calls properly to at-spi, instead of relying on an installed nvda which can't read its own shortcuts because wine has weird ideas about global shortcuts and the like

@esoteric_programmer There's probably a way to do this with Rust if one is sufficiently determined

@hikari yeah, I tried, and last time I got hit by abstractions, like I'm compiling for x86_64-pc-windows-gnu or something, so then the unix things aren't available because of course they wouldn't on windows. That's pretty much where the blocker is now, the rest is relatively not mind-breakingly hard from what I know, but I wasn't able to progress past that point, so yeah, bummer :p

@hikari but yeah, maybe you can include a windows screenreader in your project and see how much of the issues are simply because we don't run wine with a full windows desktop like thing? for example, when I tried to run nvda with a normal wine prefix, it reads some things, but any attempt to use its keyboard shortcuts fails

Are you using a Win32 console text editor under Wine?

@nortti that is, alas, a screenshot taken outside of the loss32/WINE environment, but someone we know is working on making Linux apps work in the Win32 console in WINE, so at some point we might be able to do that

@hikari
Yeah, shipping a full-blown Win32 development (and reverse-engineering) toolchain with your desktop environment would be neat.

Encouraging casual users to pick up programming, let alone compile software from scratch, is one of those things that the "friendly GUI-centric Linux distro" scene hasn't really bothered with.

[I'm just some guy who used to write simple ZDoom mods]

@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