How do I tell if my DLL's are up to date?

[ToddAndMargo2]

Hi All,

When updating from 1.6.1 to 1.7.30, how can I tell if my DLL's are from the later version? Is there a utility to run that will force the issue?

Many thanks,
-T

[dimesio]

When you run make install for the new version it should overwrite all the old files. You can verify this just by checking the dates of the files.

This is just for Wine's dlls; it will not change any native dlls you may have installed.

[ToddAndMargo2]

When you run make install for the new version it should overwrite all the old files. You can verify this just by checking the dates of the files.

This is just for Wine's dlls; it will not change any native dlls you may have installed.

Hi Dimesio,

Does wine know it is the first time a new version is run, even when a preexisting WINEPREPIX is found?

Is there a utility I can run that will insure all the DLL's came from the new install?

Can I open a new WINEPREFIX, rename the old WINEPREFIX's system32 directory, and copy the new one's into the old install?

Many thanks,
-T

[dimesio]

Does wine know it is the first time a new version is run, even when a preexisting WINEPREPIX is found?

Yes. You should get a popup message saying that the wine configuration in the wineprefix is being updated the first time you run something under the new version.

Is this the first time you are actually using Wine? Because you should have seen that before after every upgrade.

Is there a utility I can run that will insure all the DLL's came from the new install?

No, and I really don't understand this obsession with the DLLs. Is there a particular reason you imagine this is going to be a problem?

Can I open a new WINEPREFIX, rename the old WINEPREFIX's system32 directory, and copy the new one's into the old install?

Why on earth would you want to do that? You do realize that the dlls in the wineprefix are fake, don't you? The exception are any native dlls you put there, which Wine won't touch when it updates the wineprefix. Copying native dlls over to another wineprefix will work for ones that don't need to be registered, but you would have to manually register any that do need to be registered.

[ToddAndMargo2]

Is this the first time you are actually using Wine? Because you should have seen that before after every upgrade.

I see it all the time. I had no idea tthat was what it was doing.

And the fake DLLs explains a lot. I was thinking that each WINEPREFIX got its own collection of DLLs. Now that I know they are all using the same ones, that is another story.

No, and I really don't understand this obsession with the DLLs. Is there a particular reason you imagine this is going to be a problem?

My "obsession" with DLL's is trying to figure out why a fresh WINEPREFIX will work when the original will not. I am trying to narrow down what if different between the two are. I am now kind of thinking it is something in the registry.

Question: are the DLLs Winetricks installs also fake DLLs? Or do they go into individual WINEPREFIXs?

Thank you for the explanation.

-T

[dimesio]

They are all using the same builtin dlls. Native dlls you've installed are limited to that wineprefix.

Winetricks installs native dlls, to the wineprefix you specify with the WINEPREFIX variable.

[ToddAndMargo2]

They are all using the same builtin dlls. Native dlls you've installed are limited to that wineprefix.

Winetricks installs native dlls, to the wineprefix you specify with the WINEPREFIX variable.

I understand now. Thank you!