[Bug 50344] New: wine failed to import HKLM from command line

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50344

Bug ID: 50344
           Summary: wine failed to import HKLM from command line
           Product: Wine
           Version: 5.20
          Hardware: x86-64
                OS: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: registry
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

Hello!

I'm trying to import .reg file using linux command line: "wine regedit 123.reg"
and only HKCU keys are imported HKLM keys are ignored! I've tried multiply wine
versions and all failed (winehq-5.20, lutris etc...)

You can easy reproduce it using clean WINE prefix. Reg file:

REGEDIT4

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\GameUX\Games{BCF632EC-0AF8-4E44-9B14-50E9D3F3B114}]
"ApplicationId"="{BCF632EC-0AF8-4E44-9B14-50E9D3F3B114}"
"ConfigApplicationPath"="C:\GOG Games\The Witcher Enhanced Edition\"
"ConfigGDFBinaryPath"="C:\GOG Games\The Witcher Enhanced
Edition\goggame-1207658924.dll"
"Description"="The Witcher Enhanced Edition Director's Cut"
"Title"="The Witcher Enhanced Edition Director's Cut"

[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Layers]
"C:\GOG Games\The Witcher Enhanced Edition\launcher.exe"="DISABLEDWM
HIGHDPIAWARE RUNASADMIN WIN7RTM"
"C:\GOG Games\The Witcher Enhanced Edition\System\witcher.exe"="DISABLEDWM
HIGHDPIAWARE RUNASADMIN WIN7RTM"

[HKEY_LOCAL_MACHINE\Software\Wow6432Node\CD Projekt Red\The Witcher]
"InstallFolder"="C:\GOG Games\The Witcher Enhanced Edition\"
"IsDjinniInstalled"=dword:00000001
"Language"="3"
"RegionVersion"="WE"

[HKEY_CURRENT_USER\Software\CD Projekt RED\Witcher\Settings]
"TextLanguage"="3"
"VoiceLanguage"="3"

[Bug 50344] wine failed to import HKLM from command line

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50344

--- Comment #1 from Alexey Kuznetsov  ---
PS: same reg file imported successfully if imported using regedit Registry /
Import Registry File ...

[Bug 50344] wine failed to import HKLM from command line

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50344

--- Comment #2 from Nikolay Sivov  ---
Please attach .reg file that fails.

[Bug 50344] wine failed to import HKLM from command line

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50344

--- Comment #3 from Alexey Kuznetsov  ---
Created attachment 68931
  --> https://bugs.winehq.org/attachment.cgi?id=68931
123.reg

[Bug 50344] wine failed to import HKLM from command line

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50344

Anastasius Focht  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[e-mail]

--- Comment #4 from Anastasius Focht  ---
Hello Alexey,

you're using a 64-bit WINEPREFIX hence several registry keys are affected by
WOW64 (redirection).

https://docs.microsoft.com/en-us/windows/win32/winprog64/shared-registry-key...

Not sure how you "validated" the presence of the keys but they all should
exist.
You need to look under 'HKLM\Software\Wow6432Node' since that part is not
shared between 64-bit and 32-bit.

Please don't use 'Wow6432Node' directly in .reg snippets for keys that are
redirected. It will lead to 'Wow6432Node\Wow6432Node' sub-keys which don't
make sense.

---

Some of your registry keys don't make sense with Wine.

--- snip ---
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Layers]
...
--- snip ---

Wine doesn't implement Microsoft Windows Application Compatibility
Infrastructure/Framework (​application shims).

Regards

[Bug 50344] wine failed to import HKLM from command line

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50344

--- Comment #5 from Alexey Kuznetsov  ---
Created attachment 68932
  --> https://bugs.winehq.org/attachment.cgi?id=68932
AppCompatFlags.reg

Ok. Maybe wine ignore unsupported registry keys. I simplified 123.reg to only
have AppCompatFlags and run "wine regedit AppCompatFlags.reg".

No keys are added. I've check keys presence using "wine regedit".

Same reg file using regedit "Import Registry File" keys appeared!

Not sure it is a intended behavior. Or just those keys are not imported on my
machine?

Adding HKCU keys to the same AppCompatFlags.reg gives me same issue: HKLM
ignore and HKCU imported... What a heck!

[Bug 50344] wine failed to import HKLM from command line

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50344

--- Comment #6 from Hans Leidekker  ---
(In reply to Alexey Kuznetsov from comment #5)
> Created attachment 68932 [details]
> AppCompatFlags.reg
>
> Ok. Maybe wine ignore unsupported registry keys. I simplified 123.reg to
> only have AppCompatFlags and run "wine regedit AppCompatFlags.reg".
>
> No keys are added. I've check keys presence using "wine regedit".
>
> Same reg file using regedit "Import Registry File" keys appeared!
>
> Not sure it is a intended behavior. Or just those keys are not imported on
> my machine?

regedit doesn't restart as 64-bit when there's a command line to process. Try
running 'wine64 regedit 123.reg'

[Bug 50344] wine failed to import HKLM from command line

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50344

--- Comment #7 from Alexey Kuznetsov  ---
Thanks! "wine64 regedit 123.reg" does import keys!

But how [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Layers] key is relevant to the 64-bit wine?

Is it bug or should I close the issue?

[Bug 50344] wine failed to import HKLM from command line

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50344

--- Comment #8 from Anastasius Focht  ---
Hello Alexey,

--- quote ---
No keys are added. I've check keys presence using "wine regedit".
--- quote ---

You need to get familiar with the concept of registry reflection.

When you start regedit with graphic user interface you have to look under the
reflected key when looking for 32-bit view.
Otherwise you see the 64-bit view (default).

'wine regedit foobar.reg' (= 32-bit regedit) will get the keys imported in the
32-bit view since the parent key is redirected for 32-bit.

Easy to check with 'grep':

--- snip ---
# 32-bit regedit
$ wine regedit 123.reg

$ grep -i -B 2 DISABLEDWM ~/.wine/system.reg

[Software\Wow6432Node\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Layers] 1608205913
#time=1d6d46b036b709a
"C:\GOG Games\The Witcher Enhanced Edition\launcher.exe"="DISABLEDWM
HIGHDPIAWARE RUNASADMIN WIN7RTM"
"C:\GOG Games\The Witcher Enhanced Edition\System\witcher.exe"="DISABLEDWM
HIGHDPIAWARE RUNASADMIN WIN7RTM"
--- snip ---

The keys are present, under 'Wow6432Node'.

Now with 64-bit view:

--- snip ---
# 64-bit regedit
$ wine64 regedit 123.reg

$ grep -i -B 2 DISABLEDWM ~/.wine/system.reg

[Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers]
1608206262
#time=1d6d46bd38c26a2
"C:\GOG Games\The Witcher Enhanced Edition\launcher.exe"="DISABLEDWM
HIGHDPIAWARE RUNASADMIN WIN7RTM"
"C:\GOG Games\The Witcher Enhanced Edition\System\witcher.exe"="DISABLEDWM
HIGHDPIAWARE RUNASADMIN WIN7RTM"
--- snip ---

--- quote ---
But how [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
NT\CurrentVersion\AppCompatFlags\Layers] key is relevant to the 64-bit wine?
--- quote ---

As I wrote earlier: Wine doesn't implement app shims hence any sub-keys/values
are meaningless = ignored by Wine.

If the game installer creates sub-keys there then let it be.
But you don't need these keys if you have some hand-crafted .reg file.

Regards

[Bug 50344] wine failed to import HKLM from command line

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50344

--- Comment #9 from Hans Leidekker  ---
I think the confusion stems from the fact that if you run 'wine regedit
123.reg' the 32-bit view will be updated, but if you run 'wine regedit' and
then import the same file through the menu, the 64-bit view is updated. This is
because the former doesn't restart regedit as 64-bit.

[Bug 50344] Wine builtin 'regedit' should always restart as 64-bit process under WoW64 regardless if command line arguments have been supplied or not

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50344

Anastasius Focht  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |source
             Status|UNCONFIRMED                 |NEW
            Summary|wine failed to import HKLM  |Wine builtin 'regedit'
                   |from command line           |should always restart as
                   |                            |64-bit process under WoW64
                   |                            |regardless if command line
                   |                            |arguments have been
                   |                            |supplied or not
          Component|registry                    |programs
     Ever confirmed|0                           |1

--- Comment #10 from Anastasius Focht  ---
Hello folks,

I think the general consensus was to always use 64-bit regedit in 64-bit
WINEPREFIX to avoid user confusion w.r.t. Wine configuration settings
(overrides etc.). The current restart behaviour is indeed inconsistent.

Let's make this bug report useful and adapt builtin regedit restart behaviour
accordingly.

https://source.winehq.org/git/wine.git/blob/ef876fc54e207344b5809f40a59e3d5d...

--- snip ---
 139 int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR
lpCmdLine, int nCmdShow)
 140 {
 141     MSG msg;
 142     HACCEL hAccel;
 143     BOOL is_wow64;
 144 
 145     if (ProcessCmdLine(GetCommandLineW())) {
 146         return 0;
 147     }
 148 
 149     if (IsWow64Process( GetCurrentProcess(), &is_wow64 ) && is_wow64)
 150     {
 151         STARTUPINFOW si;
 152         PROCESS_INFORMATION pi;
 153         WCHAR filename[MAX_PATH];
 154         void *redir;
 155         DWORD exit_code;
 156 
 157         memset( &si, 0, sizeof(si) );
 158         si.cb = sizeof(si);
 159         GetModuleFileNameW( 0, filename, MAX_PATH );
 160 
 161         Wow64DisableWow64FsRedirection( &redir );
 162         if (CreateProcessW( filename, GetCommandLineW(), NULL, NULL,
FALSE, 0, NULL, NULL, &si, &pi ))
 163         {
 164             WINE_TRACE( "restarting %s\n", wine_dbgstr_w(filename) );
 165             WaitForSingleObject( pi.hProcess, INFINITE );
 166             GetExitCodeProcess( pi.hProcess, &exit_code );
 167             ExitProcess( exit_code );
 168         }
 169         else WINE_ERR( "failed to restart 64-bit %s, err %d\n",
wine_dbgstr_w(filename), GetLastError() );
 170         Wow64RevertWow64FsRedirection( redir );
 171     }
...
--- snip ---

For an automated import 'reg.exe' should be preferred because that's how most
app/games/installers import registry snippets.

There is bug 44755 which aims support to switch between both views using
'/reg:32' and '/reg:64' command line parameters.

There is also "fun" bug 50308 ("Starting certain Wine builtin apps with
explicit SysWOW64 path in 64-bit WINEPREFIX causes infinite process restart
loop (wineboot, winecfg, ...)") ;-)

Regards

[Bug 50344] Wine builtin 'regedit' should always restart as 64-bit process under WoW64 regardless if command line arguments have been supplied or not

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=50344

--- Comment #11 from Alexandre Julliard  ---
(In reply to Anastasius Focht from comment #10)
> For an automated import 'reg.exe' should be preferred because that's how
> most app/games/installers import registry snippets.

Most, but not all. I don't think we can be incompatible here.

If we truly want to be consistent, the only way is to remove the restart as
64-bit behavior in GUI mode.