Help! Can't install VCRUN2015 under 64-bit prefix on CentOS 7.9 (updated)

[MintArvask]

Hello, you can call me Mint. The following description would be a little bit long, yet i've arranged the format so i hope you could read more easily. I still recommend you to first get yourself a cup of coffee before reading my issue, and if you are so kind to help me, I would be so much thankful!!!

First of all i'm quite a blank paper to any linux system before, so you could suggest any noob issues that might happen to my dumb brain and typing hands, as soon as they might result in my case described below:

I need to run a code on a centos7.9 server, the code is based on windows c++ and is 64-bit (i suppose). The main target is to make it run on this server, I don't actually specify "how", but as all my efforts failed, i still have to ask you guys.

Basically i use Xshell to connect to the server, and use Xmanager to receive windows. I installed wine (yum installed epel and then wine), x server stuffs(yum), winetricks(wget and chmod +x). I tried:

wine64 ProcessCaller.exe (where the latter is executable name)

It returns the lack of 4 dlls:

1. MSVCP140D.dll ;
2. VCRUNTIME140D.dll ;
3. VCRUNTIME140_1D.dll ;
4. ucrtbased.dll .

I googled and then tried: sh winetricks vcrun2015

As i suppose all the 4 dlls are in this library. However, the winecfg window popped out. After closing the window, the windows goes out again, and after the second closing, nothing just happen. If I would try:

wine64 ProcessCaller.exe

It just says the same 4 dlls are missing, which infers the library is not installed. I really wonder what happened, there must be something wrong. So i tried the gui version of winetricks:

sh winetricks

And selected to install vcrun2015. Unfortunately, the double popping of winecfg window still remains, and it also returned another fault:

wine: BAD EXE format for Y:\vcrun2015\vc_redist.x86.exe

Alright i understand you just can't open 32-bit exe with 64-bit wine, so i created a new 32-bit wineprefix and tried to install this library again. The same "BAD EXE format" info remains which is weird, however when i opened the winetricks gui again, it seems the library is successfully installed into that prefix.

But i'm going to run a 64-bit exe though! I couldn't run this under a 32-bit prefix right? Why can't i just install the library under the default 64-bit wineprefix? And after all, what's the two winecfg windows doing? I literally don't see any reason i should change a single setting.

Or if this is something that couldn't be solved, any other routes to solve the lack of dll problem? Maybe i could just download these dlls and register them seperately, but it that possible, and if it is, how?

Seems you've read all the question stuffs, and if you're still wondering what happens just as i do, just reply to ask more. I'll give support, whatever i can give, as this issue really matters for me.

Have you drunk up your coffee? If possible I would also be glad to buy you a coffee (you know there're sites), you kind and accommodating people.

[Chiitoo]

Greetings, Mint!

I'm not entirely sure what is going on, but I do have a comment or few to share.

Usually the default Wine prefix is a "WOW64" prefix, which means both, 32-bit and 64-bit applications work, and that is what most users will want, because for example installers for Windows applications often are 32-bit still, even if the application itself is 64-bit (fun!).

Either that, or a 64-bit only prefix, though it should not matter if the application really is 64-bit only.

I tried 'winetricks -q vcrun2015' in a 64-bit only prefix, and it seemed to do its thing, though I have nothing to really test it with.

I have no idea why you would see the 'winecfg' windows open. Running the 'vcrun2015' verb does execute 'winecfg' to set the Windows version, but you should not actually see it outside of logging.

Actually, maybe I do have an idea. The "Xshell to connect to the server, and use Xmanager to receive windows" part. I don't know how that works, but perhaps it somehow handles the script so that you actually get the 'winecfg' window opening... but I'm not sure.

As for the 'BAD EXE format', I wonder if that OS install has 64-bit support only currently, and as such, the Wine build is 64-bit only as well... in which case yeah, it would not be able to run 32-bit installers for example (regardless of the Wine prefix (well actually it can nowadays, in an "experimental wow64 mode", but it's very experimental indeed, and I doubt you can get it from many distribution repositories out-of-the-box)).

Winetricks does run a 'vc_redist.x64.exe' here as well though, but I'm unsure if it bails out after trying the 32-bit one and ends up like that.

Seeing the full terminal output would probably spark some more ideas.

Also, do check the Winetricks and Wine versions you are running with. Many a place carry versions from ages past.

Having green tea here. :]

[MintArvask]

Greetings, Mint!

I'm not entirely sure what is going on, but I do have a comment or few to share.

Usually the default Wine prefix is a "WOW64" prefix, which means both, 32-bit and 64-bit applications work, and that is what most users will want, because for example installers for Windows applications often are 32-bit still, even if the application itself is 64-bit (fun!).

Either that, or a 64-bit only prefix, though it should not matter if the application really is 64-bit only.

I tried 'winetricks -q vcrun2015' in a 64-bit only prefix, and it seemed to do its thing, though I have nothing to really test it with.

I have no idea why you would see the 'winecfg' windows open. Running the 'vcrun2015' verb does execute 'winecfg' to set the Windows version, but you should not actually see it outside of logging.

Actually, maybe I do have an idea. The "Xshell to connect to the server, and use Xmanager to receive windows" part. I don't know how that works, but perhaps it somehow handles the script so that you actually get the 'winecfg' window opening... but I'm not sure.

As for the 'BAD EXE format', I wonder if that OS install has 64-bit support only currently, and as such, the Wine build is 64-bit only as well... in which case yeah, it would not be able to run 32-bit installers for example (regardless of the Wine prefix (well actually it can nowadays, in an "experimental wow64 mode", but it's very experimental indeed, and I doubt you can get it from many distribution repositories out-of-the-box)).

Winetricks does run a 'vc_redist.x64.exe' here as well though, but I'm unsure if it bails out after trying the 32-bit one and ends up like that.

Seeing the full terminal output would probably spark some more ideas.

Also, do check the Winetricks and Wine versions you are running with. Many a place carry versions from ages past.

Having green tea here. :]

Thx for replying!

I doubt that CentOS 7 really does only have the 64-bit version of wine. Still the vcrun2015 is not a grandpa library, so it should supports 64-bit, and as you've said, winetricks should run a vc_redist.x64.exe. There goes the weird part.

After cd into the winetricks directory in ~/.cache/winetricks , i found that under the vcrun2015 folder, there is only vc_redist.x32.exe. No 64-bit version. Wondering if i've set any setting wrong but couldn't found a setting for this. It looks like the winetricks just downloaded a wrong version, but it always warns me that i'm in a 64-bit prefix, why i wouldn't just download the 64-bit version then?

As for the winecfg window part maybe we just dismiss for now, they don't seem important.

And after all i'm glad you've enjoyed your green tea =)

[MintArvask]

Well another problem comes here. I manually downloaded vc_redist.x64.exe, uploaded it onto the server, then wine64 vc_redist.x64.exe. Surprisingly it still reported "BAD EXE format".

More: I surfed the net and found that even the Microsoft installer for MFC is 32-bit...? Even though they're "x64" installers? So i suppose, is it possible that all installers winetricks may download or one download on Microsoft website for vcrun2015 or vcrun2022 and so, are all 32-bit, whilst in a damn it CentOS wine you could ONLY start 64-bit only exe?!

I've gotta find other ideas how to install these dlls cuz i really want it to run on my server. How could it be so frustrating, sadly =( Just a simple C++ code after all.

New: is it that just epel doesn't have an 32-bit wine version, but CentOS does have a 32 bit ver? I'm gonna have a try.

Newer: I downloaded a 32-bit version and successfully installed it. Now i face some other problem like: could not find dependent assembly Microsoft.Windows.Common-Controls still can't install the library though. I'll continue updating till the library's installed.

[MintArvask]

Well, things got more and more "interesting" ( not really funny cuz i'm needing my exe to run as soon as possible, f words):

When i use default prefix or in a 64-bit prefix, when i try to install vcrun2015, it returns: 0009:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 0009:fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub 0009:fixme:heap:RtlSetHeapInformation (nil) 1 (nil) 0 stub 0009:fixme:ntdll:NtQueryInformationToken QueryInformationToken( ..., TokenElevation, ...) semi-stub 0009:err:ole:CoGetClassObject class {f6d90f11-9c73-11d3-b32e-00c04f990bb4} not registered 0009:err:ole:CoGetClassObject no class object {f6d90f11-9c73-11d3-b32e-00c04f990bb4} could be created for context 0x1

And when i set up a 32-bit prefix and do the same thing, it did installed!!! But missed a dll.

Must be some issue there. This definitely means my 32-bit wine is working, but it couldn't install a lib under 64-bit prefix. Trying wine32 vc_redist.x64.exe fails and return the same 6-line quote above.

This doesn't mean my problem's fixed, as my exe is 64-bit and installation in any 64-bit prefix still fails.

[MintArvask]

New: Noticed I didn't saw this line: /home/Minttest/.wine/dosdevices/c:/windows/temp/win32/a10: WARNING; possible 16128 extra bytes at end of file. ↑ This i suppose, might be that under a 64-bit prefix, the winetricks determines to use 64-bit wine, and thus finally still couldn't install. But under 32-bit it could only use 32-bit wine so it successed...?

Seems a little bit weird. Also, when i use wine32 ProcessCaller.exe, wine ProcessCaller.exe, wine64 ProcessCaller.exe, results are all the same "require 4 dlls". However if i run winetricks, choose 32-bit prefix, open explorer and then try to open ProcessCaller.exe, it becomes "BAD EXE format" which should be the case. Which means, "wine32" or "wine" just doesn't work properly.

I yum installed wine first from epel, most probably 64-bit only, and then installed wine (32bit) by wget and rpm.

[Chiitoo]

Before trying anything else, please check your versions as I mentioned earlier.

That's:

wine --version && winetricks --version

Winetricks warns about the 64-bit prefix always because a lot of the verbs have historically required a 32-bit prefix, and simply would not work in a 64-bit one (not even WOW64). This is why it's very important to have both, Wine and Winetricks up to date.

[MintArvask]

Before trying anything else, please check your versions as I mentioned earlier.

That's:

wine --version && winetricks --version

Winetricks warns about the 64-bit prefix always because a lot of the verbs have historically required a 32-bit prefix, and simply would not work in a 64-bit one (not even WOW64). This is why it's very important to have both, Wine and Winetricks up to date.

Yes, you're right. Here's the versions and how i installed them:

I have wine version as: **wine-4.0.4** and winetricks version as: **20230212-next** - sha256sum: be4196ba3358be7c68cb58e7a7cbe9b37418e12e92beb88876e119998f438532

You may also want to know how I installed these stuffs, so these are by time sequence:

1. rpm installed epel-release-noarch 6-8 (which is not the suitable version for this OS);
2. found couldn't install wine, then noticed the wrong epel version, so yum uninstalled and installed epel-release-noarch 7-11, which i suppose should be the newest version for CentOS7;
3. yum installed wine from epel 7-11;
4. wget https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks, and then chmod +x, to install winetricks. This shall be the newest version, is it?
5. found there seems to be no 32-bit wine installed, and got a solution on winehq as: yum -y install https://harbottle.gitlab.io/wine32/7/i386/wine32-release.rpm yum -yum -y install wine.i686 I checked the yum list installed, and found this 32-bit wine has same version 4.0.4-1.el7 as the wine installed before.

It's notable that i was browsing for solutions yesterday, and found most ubuntu, debian and fedora users have no such problem (and you too have no problem). I wonder if the problem arised as i installed the 64-bit and 32-bit wine seperately, though they have a same version.

[MintArvask]

Is there a chance that i could install dlls without using winetricks? I've tried putting those dlls in: ~/.wine/drive_c/windows/system32 and set them native, but doesn't work. Wheareas in this case the output of wine ProcessCaller.exe does change a little bit:

[Minttest@sh5gsitolap3 tools]$ wine ProcessCaller.exe
0027:err:module:import_dll Library VCRUNTIME140D.dll (which is needed by L"D:\\tools\\MSVCP140D.dll") not found
0027:err:module:import_dll Library VCRUNTIME140D.dll (which is needed by L"D:\\tools\\VCRUNTIME140_1D.dll") not found
0027:err:module:import_dll Library VCRUNTIME140_1D.dll (which is needed by L"D:\\tools\\MSVCP140D.dll") not found
0027:err:module:import_dll Library MSVCP140D.dll (which is needed by L"D:\\tools\\ProcessCaller.exe") not found
0027:err:module:import_dll Library VCRUNTIME140D.dll (which is needed by L"D:\\tools\\ProcessCaller.exe") not found
0027:err:module:import_dll Library VCRUNTIME140D.dll (which is needed by L"D:\\tools\\VCRUNTIME140_1D.dll") not found
0027:err:module:import_dll Library VCRUNTIME140_1D.dll (which is needed by L"D:\\tools\\ProcessCaller.exe") not found
0027:err:module:attach_dlls Importing dlls for L"D:\\tools\\ProcessCaller.exe" failed, status c0000135''

originally, it is:

[Minttest@sh5gsitolap3 tools]$ wine ProcessCaller.exe
0027:err:module:import_dll Library MSVCP140D.dll (which is needed by L"D:\\tools\\ProcessCaller.exe") not found
0027:err:module:import_dll Library VCRUNTIME140D.dll (which is needed by L"D:\\tools\\ProcessCaller.exe") not found
0027:err:module:import_dll Library VCRUNTIME140_1D.dll (which is needed by L"D:\\tools\\ProcessCaller.exe") not found
0027:err:module:import_dll Library ucrtbased.dll (which is needed by L"D:\\tools\\ProcessCaller.exe") not found
0027:err:module:attach_dlls Importing dlls for L"D:\\tools\\ProcessCaller.exe" failed, status c0000135

The dlls may require each other, but how can wine says "one dll require another dll" and at the meantime, says "dll not found"?

[austin987]

I have wine version as: **wine-4.0.4**

That's incredibly old and no longer supported.

4. **wget** https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks, and then chmod +x, to install winetricks. This shall be the newest version, is it?

Correct.

5. found there seems to be no 32-bit wine installed, and got **a solution on winehq** as:
   yum -y install https://harbottle.gitlab.io/wine32/7/i386/wine32-release.rpm
   yum -yum -y install wine.i686
   I checked the yum list installed, and found this 32-bit wine has same version 4.0.4-1.el7 as the wine installed before.

It's notable that i was browsing for solutions yesterday, and found most ubuntu, debian and fedora users have no such problem (and you too have no problem). I wonder if the problem arised as i installed the 64-bit and 32-bit wine seperately, though they have a same version.

That's definitely possible, mixing packages like that is a recipe for problems.

[MintArvask]

I have wine version as: **wine-4.0.4**

That's incredibly old and no longer supported.

4. **wget** https://raw.githubusercontent.com/Winetricks/winetricks/master/src/winetricks, and then chmod +x, to install winetricks. This shall be the newest version, is it?

Correct.

5. found there seems to be no 32-bit wine installed, and got **a solution on winehq** as:
   yum -y install https://harbottle.gitlab.io/wine32/7/i386/wine32-release.rpm
   yum -yum -y install wine.i686
   I checked the yum list installed, and found this 32-bit wine has same version 4.0.4-1.el7 as the wine installed before.

It's notable that i was browsing for solutions yesterday, and found most ubuntu, debian and fedora users have no such problem (and you too have no problem). I wonder if the problem arised as i installed the 64-bit and 32-bit wine seperately, though they have a same version.

That's definitely possible, mixing packages like that is a recipe for problems.

I use EPEL for downloading wine, and the latest EPEL only have wine4.0.4. I couldn't tell if later version still support centos7, at least i haven't found one yet.

This link: https://wiki.winehq.org/CentOS/RHEL#Notes_on_EPEL_7 that i've just read clearly shows that EPEL for centos7 has never included a 32-bit ver. Which means my mixing packages, even the same ver, could be a very probable reason.

But installing WoW64 wine doesn't seem easy... Anyone have a link or could tell me?

[scroll44]

Good evening,

I read on the internet that vc_redist.x86.exe (vcrun family) requires wine32 to run.

I tried to install wine, wine32 and wine64 which were not installed on my computer. Wine and Wine64 are in conflict.

So I installed wine and wine32.

Well, vcrun2019 installed without any problem.

A solution for you, I think ...

[austin987]

A 64-bit only wine won't work; not a winetricks issue.