Can't start OpenPHT on Windows 10 - missing dlls

Dev Community Apps & Creations
1

Hi,

I have problem starting OpenPHT on fresh WIn10. It says I’m missing following dll:
msvcr100.dll
msvcp110.dll
msvcr110.dll

All those files are in system32 directory, any ideas?

2

I suppose these DLLs will be added to the next release package, but in the meantime I think you can get them installed by installing some visual C++ runtime packages which can be downloaded from Microsoft.

msvcr100.dll comes from Visual Studio 2010, and is part of the vcredist package for that version, which you can download from links on these pages:

For 32-bit VS2010 version “https://www.microsoft.com/en-US/download/details.aspx?id=8328”
For 64-bit VS2010 version “https://www.microsoft.com/en-us/download/confirmation.aspx?id=13523”

msvcp110.dll and msvcr110.dll come from Visual Studio 2012 and are part of that version’s vcredist package, which you can download through a link on this page:

For either 32 or 64 bit VS2012 version (or both):
“https://www.microsoft.com/en-us/download/details.aspx?id=30679#”

NB: Microsoft names the vcredist files for all Visual Studio versions identically, so if you don’t rename the files when downloading them you can’t easily tell them apart, and a download of a second version can and will overwrite the first version if you didn’t rename either one. To avoid such problems I always rename such files when downloading them.

For example:
When downloading the 32-bit version of the update 4 release of the vcredist package for VS2012, I rename that file from the original name “vcredist_x86.exe” (confusingly used for ALL 32-bit vcredist versions) to the unique name “vcredist_2012u4_x86.exe”. And of course I rename all vcredist downloads similarily, so I can always tell which is which. I strongly recommend that you use a similar naming convention.

I haven’t yet had time to test this in Win10 myself, so there may be further dependencies not shown until the ones you mentioned are satisfied. But hopefully the packages linked above will be sufficient.

Edit:
On second thought I realize that I may have misunderstood your final comment.
I took it to mean that the DLLs mentioned SHOULD be stored in that folder, but weren’t.
Did you mean to say that the DLLs supposed to be missing really are present in that folder already ?
If so, then I guess installing the packages I mentioned might be futile.

Please clarify if the files are there or not, as it could indicate some OS version compatibility issue.
In the meantime I’m going to try this in Win10 myself, but it will take some time for me to do that, as I haven’t got any proper Win10 installation yet. (Just the now obsolete preview version, which I never upgraded as I dislike spyware.)

Best regards: dlanor

3

Thanks @dlanor for answer. I did my fair share of googling and I have installed all those packages. Like I said I have those dll in my windows\system32 folder. Yet OpenPHT claims they are missing.

4

@Bartlomiej Baraniec said:
Thanks @dlanor for answer. I did my fair share of googling and I have installed all those packages. Like I said I have those dll in my windows\system32 folder. Yet OpenPHT claims they are missing.

OK, I see. So I did misunderstand the final comment of your previous post (I edited my post just before you made your newest one, to mention my worry about such a misunderstanding.)

I suppose this means we have a problem with Win10 OS methods as such, possibly some new way they have of preventing unauthorized access to the system folders.

As mentioned at the end of my previous post (the edited part), I will now attempt to replicate this under Win10 and see if I can fix the problem. My first guess at a fix would be to copy those DLLs from their system location into the main folder of OpenPHT. That’s one location which the program definitely can access in any OS version, and placing DLLs in the main folder of a program has solved similar problems with other applications in the past.

I’ll get back to you here later with my results on this matter.

Best regards: dlanor

5

Copying was my next step.

6

Scratch that, I’ve found solution, it wasn’t OpenPHT error. Windows can be ■■■■, ■■■■, ■■■■ OS. Please close topic.

7

I see. So it was just a problem with Win10 usage, that happened to affect OpenPHT when you tested it.
That’s good news as it means that no OpenPHT changes are needed for Win10 compatibility.

Edit: I partly rephrased the above, as the original phrasing makes less sense when the post is shown as an “Accepted Answer”, out of its original context.

In the meantime I’ve tested this mysef in Win10pro_x86 (fresh upgrade from fresh install of Win7pro_x86 under VMware), and with this system I had no problems installing or running OpenPHT 1.5.0.502.

But don’t feel bad about me having to do this, as preparing such a VM for Win10 is something I’ve been meaning to do for quite some time now, but never got around to. Your previous posts just gave me the extra motivation I needed to finally get it done… :slight_smile:

Best regards: dlanor

8

Thanks @dlanor for taking your time :slight_smile: I was playing with Win10 under VMware for quite some time and I had no issues. Migrated my main machine to Win10 yesterday and imagine not being able to watch my stuff :slight_smile: