Question on restoring wine environment on new systeminstalls

[eniw]

I thought it was just a matter of preserving the ~/.wine/ folder and restoring it but it seems like that's not the case? I basically want to all the wine prereqs I added saved and then restored automatically on new system builds.

Here's what I did and how I can tell something is off when I try to restore it:

On test system A, I run the following winetricks command to download the dependencies I need:

winetricks dotnet30 vcrun2008

Prior to running this command, no ~/.wine/ existed. When the command is run, the first window I see is from Wine and says: "The Wine configuration in /home/user/.wine is being updated, please wait...". Then I click through the dotnet and vcrun2008 installers and it completes. I save the ~/.wine/ folder (tar czf wine.tgz ~/.wine/). As a test I register a DLL with the command 'wine regsvr32 xxx.dll' and it returns it registered successful. Just for fun on this same system, if I blow away the .wine folder and restore it with the tgz of that folder, I get the exact same behavior when I register the DLL which is great as that's what I want to happen on new systems.

Now if I take that saved wine.tgz, copy it to a new system (test system B), extract the .wine folder to home folder (same user name as system above), then try 'wine regsvr32 xxx.dll' test, here's what happens: the initial Wine window comes up ("The Wine configuration in /home/user/.wine is being updated, please wait..."), after that I get a window titled 'rundll32.exe - .NET Framework Initialization ...' with the message "Unable to find a version of the runtime to run this application". I do get the DLL was registered successfully message though.

So my question is why didn't restoring the .wine on test system B work like it did on test system A? Is there some system specific hash code used files in the .wine folder which wine uses to determine whether the wine environment had been initialized yet, so it's not just looking for generic locations and filenames? If so, then what I'm trying to do won't work I guess.

[oiaohm]

Wine itself does nothing to prevent a prefix being transferred. Only issues you sometimes see is different versions of wine resulting in damaged prefix that normally runs nothing. Yes when you archive wine you should record what version wine the archive it was working with just in case. Please do check userid and groupid numbers that those are fine(both systems could have different user id number and group id number for the same user and group names) in not fixable by applying "chown -R correctuser.correctgroup ~/.wine" as root. That is fairly much the end of transferring wine other than transferring the menu entries as well.

Wine contains no magic initialize. Wine initialize is basic. 1 no .wine directory has to create one. 2 check wine version recorded if older apply updates(and hopefully not kill it due to being altered).

Of course Microsoft made dot-net 3.0 who knows what tricks they do. Could be something particular to .net that is being tripped up but this is not a wine issue.

[eniw]

Thanks for the suggestions. User name and group IDs are the same on each system.

For test system B, I did a compare of the extracted .wine folder before and after I registered the DLL where it gives me the .wine configuration is being updated, various files do differ after that. For example: .wine/system.reg and .wine/user.reg

So it seems like when wine accesses that saved .wine folder from another system for the first time to register the DLL, some system specific info doesn't match so it initiates that dialogue about the .wine folder. Subsequent register DLLs call do not illicit that .wine configuration is being updated window since the file were already updated with the correct info.

So it doesn't seem like I can restore those wine dependencies cleanly by copying the .wine folder.

I'll need to see if I can find some way to save all the files that winetricks command downloaded, then see if those files can be installed using the command line only since I want to script their installation on each system. The actual install of dotnet40 and vcrun2008 involved clicking through various GUI interfaces and being prompted to install dependency programs like Mono and Gecko, so I hope it's scriptable.

[oiaohm]

eniw hardware information check happens every run of wine. Its not special to when wine moves system. Like change video card information provided at applications has to be changed.

eniw I have had another thought. Maybe you have made a very hazard mistake and you have if everything is how you said did it.. Before backing up a wineprefix you should do two things.

"wineboot" command to make sure installers perform the actions they should after a reboot.
"wineserver -k" to shut wine fully down and to fully write registry to disc.

Mind you these instructions would be recommend even backing up. That might fix the .net issue. Might not either.

[eniw]

I tried 'wineserver -k' (there was no wineboot on my system) before saving the .wine folder and then restoring that on the other system but that didn't prevent the msgs. It's weird as the DLL does register despite the NET message, it would not be possible to do that if .NET really was not installed.

The terminal output of registering the DLL is below. The first time it's done, I get the windows I described that pop up which I think is reflect by the fixme messages. Once that's done, the DLL does register. If I type the same register command again, since the values got updated for the new system, I don't get the windows or fixme msgs since they were already updated.

Is there some command I can run after I restore the .wine folder from another system to update the system-specific values in it for the new system? I assume its the registry values that regsvr32 checks against that need to be updated for the wine on the new system to believe that .wine folder belongs to it.

Code: Select all

$ wine regsvr32 foo.dll 
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:process:SetProcessDEPPolicy (1): stub
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:process:SetProcessShutdownParameters (00000380, 00000000): partial stub.
err:setupapi:create_dest_file failed to create L"C:\\windows\\system32\\atl100.dll" (error=80)
err:setupapi:create_dest_file failed to create L"C:\\windows\\system32\\mscoree.dll" (error=80)
fixme:iphlpapi:NotifyAddrChange (Handle 0x127e8e0, overlapped 0x127e8ec): stub
wine: configuration in '/home/user/.wine' has been updated.
Successfully registered DLL foo.dll
$ wine regsvr32 foo.dll 
Successfully registered DLL foo.dll

[oiaohm]

wineboot should always be callable if current wine is installed correctly.

"wine wineboot" will also find it.

Code: Select all

fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:process:SetProcessDEPPolicy (1): stub
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:process:SetProcessShutdownParameters (00000380, 00000000): partial stub.
err:setupapi:create_dest_file failed to create L"C:\\windows\\system32\\atl100.dll" (error=80)
err:setupapi:create_dest_file failed to create L"C:\\windows\\system32\\mscoree.dll" (error=80)
fixme:iphlpapi:NotifyAddrChange (Handle 0x127e8e0, overlapped 0x127e8ec): stub
wine: configuration in '/home/user/.wine' has been updated.

All this looks a lot like a wineboot. Wineboot can be manually triggered it also happens when a prefix that is not in a running state becomes running. So I don't think these messages have anything todo with regsvr32.

To force a update of a prefix/reset of registry keys.
"wine wineboot -u"

Wineboot is part of current versions of wine. If you don't have wineboot by direct or by "wine wineboot" please run wine --version and if it 1.6 or later you have a broken build for sure.

[eniw]

I didn't realize wineboot was run with the wine command, I tried it out and after typing that wineboot command, I get the window popups about configuring .wine and the NET window, so it's doing the changes there rather than when I do the register. After that's done, I can do the regsvr32 without those windows popping up, I get fixme messages though in the terminal (see below). When I repeat the regsvr32 command, I get the same fixme messages as well.

For comparison as shown in my previous terminal output, when I did the first regsvr32 (without doing wineboot before it), I get all the pop ups, and it registers. If I try the same register again, it registers with no popups and no fixme messages.

Code: Select all

$ wine wineboot -u
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:process:SetProcessDEPPolicy (1): stub
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:process:SetProcessShutdownParameters (00000380, 00000000): partial stub.
err:setupapi:create_dest_file failed to create L"C:\\windows\\system32\\atl100.dll" (error=80)
err:setupapi:create_dest_file failed to create L"C:\\windows\\system32\\mscoree.dll" (error=80)
fixme:iphlpapi:NotifyAddrChange (Handle 0x330e8e0, overlapped 0x330e8ec): stub
wine: configuration in '/home/user/.wine' has been updated.
[?1h=err:setupapi:create_dest_file failed to create L"C:\\windows\\system32\\atl100.dll" (error=80)
err:setupapi:create_dest_file failed to create L"C:\\windows\\system32\\mscoree.dll" (error=80)
fixme:iphlpapi:NotifyAddrChange (Handle 0x16de8e0, overlapped 0x16de8ec): stub
wine: configuration in '/home/user/.wine' has been updated.
$ wine regsvr32 foo.dll 
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:process:SetProcessDEPPolicy (1): stub
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:process:SetProcessShutdownParameters (00000380, 00000000): partial stub.
Successfully registered DLL MSFileReader.XRawfile2.dll
$ wine regsvr32 foo.dll 
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:process:SetProcessDEPPolicy (1): stub
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:process:SetProcessShutdownParameters (00000380, 00000000): partial stub.
Successfully registered DLL MSFileReader.XRawfile2.dll

[oiaohm]

fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:process:SetProcessDEPPolicy (1): stub
fixme:heap:HeapSetInformation (nil) 1 (nil) 0
fixme:process:SetProcessShutdownParameters (00000380, 00000000): partial stub.

These will be features the dll is calling on nothing major to worry about. Fixme are stub functions normally with enough to make the application do the right thing. Note the word normally.

eniw but I was right you have some left over fragments in startup from installing MS .net. Those fragments are causing

err:setupapi:create_dest_file failed to create L"C:\\windows\\system32\\atl100.dll" (error=80)
err:setupapi:create_dest_file failed to create L"C:\\windows\\system32\\mscoree.dll" (error=80)

I guess wine mono is not good enough to run the program.


Wine command it self acts partly as a environmental wrapper. wineboot, winecfg... in most installs can be accessed directly from the command line. But in cases were they cannot you just place wine in front. So yes your system is a little odd eniw but its not unworkable odd.