Has anyone else seen this error before? When I try to run the Prime emulator, I get the error message (see figure). The emulator used to work, and I can't think of anything I've installed since I last successfully ran it. I've uninstalled and re-installed the Prime emulator software a couple of times. I've also searched the web and followed a recommendation to install the Visual C++ 2013 Redistributable package, but to no avail. Apparently this dll is a part of the VC++ package.
The odd thing is that the file is on my system. It's in the C:\Windows\System directory.
If any one has seen this problem and successfully corrected it, I'd like to hear what it took to fix it.
Thanks,
Brad
Try installing the 64 bit one and report back. I will be interested to see if that fixes it.
Tim, I've already installed the 64 bit version, but to no avail.
A further oddity is that when I uninstall the emulator, then re-install it, it seems to remember that it was previously installed. It places the short cut back in the start menu, and also doesn't tag the emulator as "New". It appears that the emulator is not completely uninstalled. Are there any files or hidden registry entries that you know of that I might need to make to get a full uninstall? I can't help feeling that a completely fresh install would set things right.
I wouldn't have expected the 64 bit to do anything as it is only a 32 bit exe. I am assuming you have the 32 ones installed?
You could try a manual uninstall, and then reinstall. One other user a bit ago reported having to copy those to the exe location, but that was on a USB drive and not a normal install.
Tim,
You're right. The 64 bit version did nothing. I incorrectly assumed that because I'm running a 64 bit OS, the 64 bit version was the one to get. Per your suggestion, I checked and the 32 bit version was not installed. After installing it everything's working now. Not sure why the emulator suddenly quit functioning.
Thanks for the help.
Brad
Sure wish I could figure out why the installer doesn't always install the c++ redist... :-(
I don't know much about Window's install routines, but I wonder if it's an issue with the uninstaller. As I said above, when I'd reinstall the emulator, Windows didn't recognize it as a new installation. Win8 usually points out new installations with a "New" tag and a highlight. That didn't happen when I reinstalled the emulator, plus it would put the shortcut back in the Start menu as if the emulator had never been uninstalled. It seems like the emulator wasn't completely uninstalled, thus at re-installation, Windows didn't tell the installer that it needed a new version of the C++ redist installed/linked to the emulator.
Have you tried putting the required dll into the programs directory (here:"C:\Program Files (x86)\Hewlett-Packard\HP Prime Virtual Calculator", I remember a similar issue and think this workaround helped.
Arno
Thanks Arno, but I've already got it working. I wanted to make sure that the emulator had access to all the files it needs in case there were other dll's required. Sounds like your solution would work as well.
My last comment was to see if maybe the root of the problem could be discovered.
FWIW... copying "system" DLLs, e.g. from the redistributable runtimes, to an application's folder is convenient and can usually make things work, but it's bad practice
From day 1, it interferes with Windows' DLL loader, unless special care was taken by the application developer. As time passes by, it leaves old, vulnerable versions behind, and opens a can of worms.
For applications which take extra care, such as recent versions of most executable installer frameworks, copying system DLLs to the application's folder has no effect; on older versions, it's arbitrary code execution.
Hardlinks and symlinks sometimes alleviate the problem of copying system files, but out of the box, Windows provides no high-level way for the user to make such links...
(03-03-2016 12:16 PM)debrouxl Wrote: [ -> ]FWIW... copying "system" DLLs, e.g. from the redistributable runtimes, to an application's folder is convenient and can usually make things work, but it's bad practice
From day 1, it interferes with Windows' DLL loader, unless special care was taken by the application developer. As time passes by, it leaves old, vulnerable versions behind, and opens a can of worms.
For applications which take extra care, such as recent versions of most executable installer frameworks, copying system DLLs to the application's folder has no effect; on older versions, it's arbitrary code execution.
Hardlinks and symlinks sometimes alleviate the problem of copying system files, but out of the box, Windows provides no high-level way for the user to make such links...
Well, clearly copying system DLL's is not the correct way to get programs running, I usually first try without tricks like this one, but if every other option fails (installing Windows from scrap is NO option, editing the registry to get a clean install and deleting all links to some unwanted piece of software is) that is what I try last before using restore to a previous installation from recovery where I go back at maximum 2 weeks to keep everything running, finally there is a monthly backup of a) everything and b) user-files.
But as a quick workaround...
Arno