https://bugs.winehq.org/show_bug.cgi?id=54550
Bug ID: 54550 Summary: Move registry functions implementations into offreg.dll Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: advapi32 Assignee: wine-bugs@winehq.org Reporter: kolan_n@mail.ru Distribution: ---
https://learn.microsoft.com/en-us/windows/win32/devnotes/offline-registry-li...
This is a library to work with registry files. It is not shipped with Windows, but is a part of WDK, so usually apps needing it bring one with itself. But AFAIK Wine registry format is different from Windows one.
Also it'd be nice to be able to manipulate Wine registry from the apps native to the host.
So it is proposed to
1. move all the impls of the registry format into a unix library `libwineoffreg.so` 2. generate `offreg.dll.so` and `offreg.dll` using `libwineoffreg.so` 3. use it from `advapi32.dll`
https://bugs.winehq.org/show_bug.cgi?id=54550
Zeb Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |8.2 Summary|Move registry functions |Provide tools to modify |implementations into |on-disk registry files |offreg.dll |without running Wine CC| |z.figura12@gmail.com
--- Comment #1 from Zeb Figura z.figura12@gmail.com --- I gather the end goal is just to modify registry files without needing to run Wine, so I've renamed the bug accordingly.
Note that all of the registry file parsing lives in the server; it's not done directly from advapi32 (or kernelbase, or ntdll), so even if we do this I don't think we want "offreg.dll".
https://bugs.winehq.org/show_bug.cgi?id=54550
--- Comment #2 from KOLANICH kolan_n@mail.ru --- And, BTW, why are we using a text format for hives? I guess to allow easier editing and debugging... But why not to use the same format used on Windows (to get the compatibility to the software working with the files directly, and, maybe, better efficiency in reading/writing) and expose the human-friendly representation via a fuse fs?
https://bugs.winehq.org/show_bug.cgi?id=54550
KOLANICH kolan_n@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Provide tools to modify |Provide libraries to parse |on-disk registry files |& modify on-disk registry |without running Wine |files without running Wine
https://bugs.winehq.org/show_bug.cgi?id=54550
KOLANICH kolan_n@mail.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Provide libraries to parse |Provide shared libraries to |& modify on-disk registry |parse & modify on-disk |files without running Wine |registry files without | |running Wine
https://bugs.winehq.org/show_bug.cgi?id=54550
--- Comment #3 from Zeb Figura z.figura12@gmail.com --- (In reply to KOLANICH from comment #2)
And, BTW, why are we using a text format for hives? I guess to allow easier editing and debugging... But why not to use the same format used on Windows (to get the compatibility to the software working with the files directly, and, maybe, better efficiency in reading/writing) and expose the human-friendly representation via a fuse fs?
I wasn't around when those decisions were made, so take my answer with a grain of salt, but I suspect it's a matter of nobody ever needing to use those tools, plus binary formats just being generally more difficult to work with in various ways. As you say, text files are easier to edit (both by hand and in our registry writing code) and debug, and not committing to the Windows format also removes the need to research and match that format, or to implement every feature at once. (E.g. we've made multiple changes to our registry format over time.)
-
WineHQ Bugzilla