Groundhog day

*** Please report new bugs here! ***

Moderator: Dreamer

Post Reply
jonha4711
Posts: 55
Joined: Mon Feb 08, 2016 4:35 pm

Groundhog day

Post by jonha4711 » Sat Feb 09, 2019 11:51 am

A new version and once again it will not install. Windows 7-64, trying to install the 32-bit version zip version. After unzipping the error I get is once again "The application was unable to start correctly. (0xc000007b)".

This time round it turns out that *some* of the required MS runtime DLLs are included in the download ZIP but not all. It can't be that difficult to produce a zip with *all* the required DLLs, can it? Just create a VirtualBox VM with a bare-bones Windows, install your zip and check whether it actually works!?

Sigh.

EDIT: Wonder of wonders, the Linux version installed and worked w/o any problem.

anonymous_user
Posts: 15
Joined: Tue Dec 13, 2011 2:37 am

Re: Groundhog day

Post by anonymous_user » Sun Feb 10, 2019 2:01 am

I have Windows 7 64-bit and tried the zipped XnViewMP 0.93 (32-bit). I had no problem with launching the program. Do you have the same issue if you use the EXE version? Have you tried deleting the zip and downloading it again?

jonha4711
Posts: 55
Joined: Mon Feb 08, 2016 4:35 pm

Re: Groundhog day

Post by jonha4711 » Sun Feb 10, 2019 6:51 pm

The zip is fine. The problem is simply that the developer includes *some* MS runtime DLLs in the zip but not all that are required. As I have no system-wide version of the required files xnviewmp.exe simply refuses to start. If I copy the missing files (mostly a bunch of api-ms*.dll files) into the xnview directory it works.

Including only a subset of the required DLLs is quite careless and means that xnviewmp.exe will work on some systems (those where the DLLs are system-wide available, that's why your copy runs) but not on others like mine.

User avatar
xnview
Author of XnView
Posts: 31747
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Groundhog day

Post by xnview » Mon Feb 11, 2019 8:26 am

jonha4711 wrote:
Sun Feb 10, 2019 6:51 pm
The zip is fine. The problem is simply that the developer includes *some* MS runtime DLLs in the zip but not all that are required. As I have no system-wide version of the required files xnviewmp.exe simply refuses to start. If I copy the missing files (mostly a bunch of api-ms*.dll files) into the xnview directory it works.
The api-ms*.dll should be present on Win 7 x64, which dll are missing?
Pierre.

jonha4711
Posts: 55
Joined: Mon Feb 08, 2016 4:35 pm

Re: Groundhog day

Post by jonha4711 » Mon Feb 11, 2019 11:08 am

xnview wrote:
Mon Feb 11, 2019 8:26 am
The api-ms*.dll should be present on Win 7 x64, which dll are missing?
No, they aren't, that's exactly my point.

These are relatively recent VC runtime libraries and they may be available if someone has explicitly installed them system-wide. I haven't.

This is the list of the needed DLLs:

Code: Select all

api-ms-win-core-console-l1-1-0.dll
api-ms-win-core-datetime-l1-1-0.dll
api-ms-win-core-debug-l1-1-0.dll
api-ms-win-core-errorhandling-l1-1-0.dll
api-ms-win-core-file-l1-1-0.dll
api-ms-win-core-file-l1-2-0.dll
api-ms-win-core-file-l2-1-0.dll
api-ms-win-core-handle-l1-1-0.dll
api-ms-win-core-heap-l1-1-0.dll
api-ms-win-core-interlocked-l1-1-0.dll
api-ms-win-core-libraryloader-l1-1-0.dll
api-ms-win-core-localization-l1-2-0.dll
api-ms-win-core-memory-l1-1-0.dll
api-ms-win-core-namedpipe-l1-1-0.dll
api-ms-win-core-processenvironment-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-0.dll
api-ms-win-core-processthreads-l1-1-1.dll
api-ms-win-core-profile-l1-1-0.dll
api-ms-win-core-rtlsupport-l1-1-0.dll
api-ms-win-core-string-l1-1-0.dll
api-ms-win-core-synch-l1-1-0.dll
api-ms-win-core-synch-l1-2-0.dll
api-ms-win-core-sysinfo-l1-1-0.dll
api-ms-win-core-timezone-l1-1-0.dll
api-ms-win-core-util-l1-1-0.dll
api-ms-win-crt-conio-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-locale-l1-1-0.dll
api-ms-win-crt-math-l1-1-0.dll
api-ms-win-crt-multibyte-l1-1-0.dll
api-ms-win-crt-private-l1-1-0.dll
api-ms-win-crt-process-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
**msvcp140.dll
ucrtbase.dll
**vcomp140.dll
**vcruntime140.dll
You include only the three DLLs marked **. But then you include vccorlib140.dll which is not required at all. It's all a fine mess.

User avatar
xnview
Author of XnView
Posts: 31747
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Groundhog day

Post by xnview » Tue Feb 12, 2019 7:47 am

jonha4711 wrote:
Mon Feb 11, 2019 11:08 am
xnview wrote:
Mon Feb 11, 2019 8:26 am
The api-ms*.dll should be present on Win 7 x64, which dll are missing?
No, they aren't, that's exactly my point.
do you have received my PM?
Pierre.

User avatar
foxyshadis
Posts: 384
Joined: Sat Nov 18, 2006 8:57 am

Re: Groundhog day

Post by foxyshadis » Mon Apr 15, 2019 6:40 am

Microsoft does explicitly say that runtime dlls should never be distributed by the app anymore, and the generic Visual Studio runtime installer should be used instead. Otherwise you risk local security problems in the version that was installed (if you can even get it to run; the new registration requirements are hairy).

User avatar
xnview
Author of XnView
Posts: 31747
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Groundhog day

Post by xnview » Mon Apr 15, 2019 1:13 pm

foxyshadis wrote:
Mon Apr 15, 2019 6:40 am
Microsoft does explicitly say that runtime dlls should never be distributed by the app anymore, and the generic Visual Studio runtime installer should be used instead. Otherwise you risk local security problems in the version that was installed (if you can even get it to run; the new registration requirements are hairy).
There is a lot of apps that have these dlls in their folder
Pierre.

Post Reply