I suggest that you install this version of the C++ runtime libraries on your system
https://www.microsoft.com/en-us/download/details.aspx?id=30679
Give it a try in your Win8.1 x64 VirtualBox VM first, it might correct the issue there as well as on your friend's system.
That plugin was compiled / built with Microsoft Visual Studio Express 2012, and Rainmeter is built with Microsoft Visual Studio Express 2013. Rainmeter comes with the runtime libraries needed to support itself, but there may be a conflict with the 2013 libraries and the 2012 build Brian used.
Doing this will not "replace" or in any way alter any existing runtime libraries, so it is perfectly safe to install this.
I don't promise this will correct the issue, but it's about all that's left that makes any sense to me.
It is currently September 1st, 2024, 1:38 am
RunCommand
-
- Developer
- Posts: 22710
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
-
- Rainmeter Sage
- Posts: 8003
- Joined: February 27th, 2015, 2:38 pm
- Location: Terra Yincognita
Re: RunCommand 1.0
I was also wondering if this was the culprit. I'll give it a try and report back ASAP.
EDIT: It worked!!! I can't believe it was this... Many thanks, jsmorley.
P.S. You or Brian should put a warning/note on the plugin to instruct people to install the required VC++ Runtime though, since Rainmeter itself installs a different version - otherwise people will still have problems like mine was![Thumbs Up :thumbup:](./images/smilies/ay.gif)
EDIT: It worked!!! I can't believe it was this... Many thanks, jsmorley.
P.S. You or Brian should put a warning/note on the plugin to instruct people to install the required VC++ Runtime though, since Rainmeter itself installs a different version - otherwise people will still have problems like mine was
![Thumbs Up :thumbup:](./images/smilies/ay.gif)
-
- Developer
- Posts: 22710
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: RunCommand 1.0
Brian is away for a week, but he is aware that there could be an issue there, we talked about this as he was walking out the door a day or two ago.Yincognito wrote:I was also wondering if this was the culprit. I'll give it a try and report back ASAP.
EDIT: It worked!!! I can't believe it was this... Many thanks, jsmorley.
P.S. You or Brian should put a warning/note on the plugin to instruct people to install the updated VC++ Runtime though, since Rainmeter itself installs only an "older" version - otherwise people will still have problems like mine was
The problem is that RunCommand requires the runtimes for 2012, which anyone who has been running Rainmeter for any length of time on their system will have, since until recently Rainmeter used to install it as part of the Rainmeter installation. However, it is certainly possible that someone new to Rainmeter, or someone who installs on a new Win8.1 machine (which I think ships with 2013) might well run into trouble.
Rainmeter no longer "installs" anything, but actually uses stand-alone libraries in the Rainmeter program folder. Currently Visual Studio 2013, but probably soon 2015.
I think the solution is for Brian to change his build so it leverages the runtime libraries used by Rainmeter (the "parent" application), but I'm no expert on dynamic link libraries or C++ builds. He will weigh in when he gets back.
-
- Rainmeter Sage
- Posts: 8003
- Joined: February 27th, 2015, 2:38 pm
- Location: Terra Yincognita
Re: RunCommand 1.0
Yes, I think this would be a better solution than the "note" variant.
Although ... this would require users to update the plugin, which means old versions of the plugin would have similar issues in the same conditions. And since skins all over the internet are "shipped" with the plugins at the time of skin building, it would also require the skins to be "updated" as well.
That being said, I'm happy that it finally works. I should keep in mind to include this info in my "readme", just in case.
Although ... this would require users to update the plugin, which means old versions of the plugin would have similar issues in the same conditions. And since skins all over the internet are "shipped" with the plugins at the time of skin building, it would also require the skins to be "updated" as well.
That being said, I'm happy that it finally works. I should keep in mind to include this info in my "readme", just in case.
-
- Developer
- Posts: 22710
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: RunCommand 1.0
Yeah, well Brian will have to weigh in when he gets back. In looking at it, I'm not so sure there is a conflict between 2013 (Rainmeter) and 2012 (RunCommand), but rather that on a really new installation of Windows, it is possible that there are no C++ runtimes installed at all, or at least not one "recent" enough.
Over time, applications that you run will install various flavors of the C++ runtimes when they are installed. Rainmeter used to do that as well. A lot of systems will look like this:
And I did a "clean install" of Win8.1 about a year ago. All those were installed by various applications I use, when they were installed.
But on a really new machine, and with Rainmeter no longer "installing" anything, it is possible that RunCommand just ended up orphaned. Don't forget that the built-in plugins in Rainmeter already leverage the stand-alone runtimes that come with Rainmeter. This could only impact 3rd-party plugins.
Not sure, I tread perilously close to full-of-shit territory.
Over time, applications that you run will install various flavors of the C++ runtimes when they are installed. Rainmeter used to do that as well. A lot of systems will look like this:
And I did a "clean install" of Win8.1 about a year ago. All those were installed by various applications I use, when they were installed.
But on a really new machine, and with Rainmeter no longer "installing" anything, it is possible that RunCommand just ended up orphaned. Don't forget that the built-in plugins in Rainmeter already leverage the stand-alone runtimes that come with Rainmeter. This could only impact 3rd-party plugins.
Not sure, I tread perilously close to full-of-shit territory.
You do not have the required permissions to view the files attached to this post.
-
- Rainmeter Sage
- Posts: 8003
- Joined: February 27th, 2015, 2:38 pm
- Location: Terra Yincognita
Re: RunCommand 1.0
Before I installed the VC++ from your link, I checked the Win 8.1 x64 VM and it had only VC++ 2008 9.0.30729.6161 version installed. That's intriguing, since you would expect a higher version on Windows 8.1 (kind of like the .NET framework is pretty new on a newer OS).it is possible that there are no C++ runtimes installed at all, or at least not one "recent" enough.
On my "real" Windows 7 x64 machine though, I tend to be rock solid with all the "Windows enhacements" like VC++,.NET framework, Flash/Shockwave Player, DirectX Redistributable, JRE, Silverlight, etc. I always install them separately, just after the OS installation - hence the lack of "problems".
In the RunCommand matter, I never thought this would be problem (only "suspecting", after a while), as I was aware that Rainmeter already installed some VC++ runtime... I assumed that would be enough, since the plugin came from one of the developers. But yeah, I forgot I was in a VM and install some "goodies" first...
-
- Developer
- Posts: 22710
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: RunCommand 1.0
In looking at it, I'm not sure Windows itself installs "any"... What you get is one of two things. Either an application (or dll like this) are built to "statically link" to the required runtime, which in effect embeds them in the application/dll, or the application installer "installs" the version of the C++ runtimes it needs.Yincognito wrote: Before I installed the VC++ from your link, I checked the Win 8.1 x64 VM and it had only VC++ 2008 9.0.30729.6161 version installed. That's intriguing, since you would expect a higher version on Windows 8.1 (kind of like the .NET framework is pretty new on a newer OS).
On my "real" Windows 7 x64 machine though, I tend to be rock solid with all the "Windows enhacements" like VC++,.NET framework, Flash/Shockwave Player, DirectX Redistributable, JRE, Silverlight, etc. I always install them separately, just after the OS installation - hence the lack of "problems".
In the RunCommand matter, I never thought this would be problem (only "suspecting", after a while), as I was aware that Rainmeter already installed some VC++ runtime... I assumed that would be enough, since the plugin came from one of the developers. But yeah, I forgot I was in a VM and install some "goodies" first...
I don't think Brian did either. I think he built that plugin during the era when Rainmeter was installing 2012, and he was using 2012, and all was well. That will probably need to be changed.
The issue is that any program or dll built with a specific version of C++ must have the runtime libraries for THAT specific version of C++ available, one way or the other. Doesn't matter if it is 2005/2008/2010/2012/2013, it is specific. There is no concept of "backwards compatibility" in that world.
We changed the Plugin SDK about a year ago, so that "static linking" is done on any new plugin project that uses it. However, there could indeed be an older 3rd-party plugin that will require that the correct version of the C++ runtimes be installed for that plugin. Ick. It's really even hard for a "user" to know what version of C++ was used to create the plugin.
I'll have to chew on this a bit.
-
- Rainmeter Sage
- Posts: 8003
- Joined: February 27th, 2015, 2:38 pm
- Location: Terra Yincognita
Re: RunCommand 1.0
Just for information : I was also using HWiNFO plugin, MSIAfterburner plugin 2.0.0.0 and NomFerp 0.0.2.0. All these didn't have a problem in the "fresh" Win 8.1 VM. I'm not sure all these were compiled with VS 2013, so they must differ from Brian's plugin in that they work even on a system like the one in the VM (maybe some "more compatible" functions, I don't know - just guessing here).
But, what can I say... happy chewing
At least it's not a bug in the plugin - it's a somewhat "external" matter, so just a matter of "accomodation".
EDIT : I didn't see your edit, so disregard the "compatible function" phrase.
But, what can I say... happy chewing
![Cool 8-)](./images/smilies/af.gif)
EDIT : I didn't see your edit, so disregard the "compatible function" phrase.
-
- Developer
- Posts: 22710
- Joined: April 19th, 2009, 11:02 pm
- Location: Fort Hunt, Virginia, USA
Re: RunCommand 1.0
I'm pretty sure NomFerp is in C#, not C++, so that is a non-issue. HWiNFO is C++ 2013, and presumably is fine since it is statically linking / "embedding" the correct runtime in the .dll. No idea about MSIAfterburner, since I don't use it or have it, but since it worked for you, and I think it unlikely in the extreme that it is using the 2008 you had installed, we can assume it is also embedding whatever version of the runtime it needs.Yincognito wrote:Just for information : I was also using HWiNFO plugin, MSIAfterburner plugin 2.0.0.0 and NomFerp 0.0.2.0. All these didn't have a problem in the "fresh" Win 8.1 VM. I'm not sure all these were compiled with VS 2013, so they must differ from Brian's plugin in that they work even on a system like the one in the VM (maybe some "more compatible" functions, I don't know - just guessing here).
But, what can I say... happy chewingAt least it's not a bug in the plugin - it's a somewhat "external" matter, so just a matter of "accomodation".
EDIT : I didn't see your edit, so disregard the "compatible function" phrase.
At the end of the day, this never had anything to do with any "incompatibility" with the plugin, or anything to do with a "VM", other than that it was "new", which may or may not have made any difference at all anyway. It just comes down to the fact that RunCommand is making an "assumption" about what resources will be available to it, when it really can't make that assumption reliably.
-
- Rainmeter Sage
- Posts: 8003
- Joined: February 27th, 2015, 2:38 pm
- Location: Terra Yincognita
Re: RunCommand 1.0
Well, that pretty much eliminates my own incorrect "assumptions" thenI'm pretty sure NomFerp is in C#, not C++, so that is a non-issue. HWiNFO is C++ 2013, and presumably is fine since it is statically linking / "embedding" the correct runtime in the .dll. No idea about MSIAfterburner, since I don't use it or have it, but since it worked for you, and I think it unlikely in the extreme that it is using the 2008 you had installed, we can assume it is also embedding whatever version of the runtime it needs.
![Wink ;-)](./images/smilies/innuendo.gif)
And this sums up all of it.It just comes down to the fact that RunCommand is making an "assumption" about what resources will be available to it, when it really can't make that assumption reliably.
P.S. Now that I know what was all about, I can safely use RunCommand/WMI not only for the CPU cores/architecture, but also to detect the HW NICs, using a single line instead of 100 measures searching the registry. It was a long way from a once 2MB (!) skin and 2%-5% CPU to 40 KB skin and 0% CPU. Phew!
(and yeah, I also used some very sloppy code on occasions, but the new string option on the Interface/SysInfoData helped a lot)