It is currently October 15th, 2021, 11:56 pm

4.5.1.3538

Test and provide feedback on potential changes
User avatar
jsmorley
Developer
Posts: 22364
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

4.5.1.3538

Post by jsmorley »

⬇️ https://builds.rainmeter.net/test_builds/Rainmeter-4.5.1.3538-prerelease.exe


SysInfo is now a "measure" instead of a "plugin".

Change:

Code: Select all

[SomeMeasure]
Measure=Plugin
Plugin=SysInfo
To:

Code: Select all

[SomeMeasure]
Measure=SysInfo

We consolidated a few of the network functions into a new file called NetworkUtil in the Common project. This allowed for SysInfo and the NET measures to share the same functions instead of duplicating things.

First, for interface adapter types, SysInfoData will now reference the interface index (or "ifindex") instead of the "position" of the adapter array returned from Windows. This "ifindex" is now logged when Rainmeter first starts when using Debug mode.

Second, for the interface adapter types, the default value for SysInfoData is now Best. Also, negative values will default to Best as well.
The SysInfoData values for network interfaces are indexed starting at one (1) not zero (0). Any measure that is currently set to SysInfoData=0 will automatically default to Best.

Third, all the values are now retrieved in the "Update" function, instead of some of the string values that were retrieved in "GetString". This will help with performance, however, if skins took advantage of this, they may not work they way they used to. I don't see this as a BWC issue really, but more of a performance fix.

Fourth, SysInfoType=DOMAINWORKGROUP has been changed to SysInfoType=DOMAIN_WORKGROUP for consistency. The old version is now deprecated, but still works.

New Types:
We added a few new types.
  1. INTERNET_CONNECTIVITY_V4 (Number value) - Tests specifically for IPV4 internet connectivity. 1 for connected, -1 for not connected.
    Space
  2. INTERNET_CONNECTIVITY_V6 (Number value) - Tests specifically for IPV6 internet connectivity. 1 for connected, -1 for not connected.
    Space
  3. LAN_CONNECTIVITY_V4 (Number value) - Tests specifically for IPV4 local lan connectivity. 1 for connected, -1 for not connected.
    Space
  4. LAN_CONNECTIVITY_V6 (Number value) - Tests specifically for IPV6 local lan connectivity. Not super useful...yet. 1 for connected, -1 for not connected.
    Space
  5. GATEWAY_ADDRESS_V4 (Number value) - Returns the gateway / router IPv4 IP address.
    Space
  6. GATEWAY_ADDRESS_V6 (Number value) - Returns the gateway / router IPv6 IP address.
    Space
  7. ADAPTER_STATE (Number and String values) - Gets the "media connected state" of the adapter. This works for physical and non-physical adapters. The number value will return 1 for connected, and -1 for disconnected. The string value will return Connected or Disconnected. Any other state returns 0 and Unknown.

    MS Docs: https://docs.microsoft.com/en-us/windows/win32/api/ifdef/ne-ifdef-net_if_media_connect_state
    Space
  8. ADAPTER_STATUS (Number and String values) - Gets the operational status of the adapter. This works for physical and non-physical adapters. The values returned are:
    • Number: -3 String: Not Present
    • Number: -2 String: Lower Layer Down
    • Number: -1 String: Down
    • Number: 0 String: Unknown
    • Number: 1 String: Up
    • Number: 2 String: Dormant
    • Number: 3 String: Testing
    Not a ton of use for most of these other than Up or Down.
    MS docs: https://docs.microsoft.com/en-us/windows/win32/api/ifdef/ne-ifdef-if_oper_status
    Space
  9. MAC_ADDRESS (String value) - Gets the physical MAC address of the adapter. Not all adapters will have addresses.
Please reply in this thread with any issues you find with these changes.
Last edited by Brian on September 11th, 2021, 7:32 pm, edited 2 times in total.
Reason: Edit: Removed link to prerelease
User avatar
SilverAzide
Rainmeter Sage
Posts: 1611
Joined: March 23rd, 2015, 5:26 pm

Re: 4.5.1.3535

Post by SilverAzide »

I ran into a very obtuse issue with the change of SysInfo to an internal measure, so perhaps my question is more about how Rainmeter handles plugins vs. internal measures.

In pseudo-code, I have set of measures like this:

Code: Select all

[MeasureAdapterDescription]
Measure=SysInfo
SysInfoType=ADAPTER_DESCRIPTION
SysInfoData=Best
DynamicVariables=1

[MeasureMyPluginStuff]
Measure=Plugin
Plugin=MyPlugin
Input=[MeasureAdapterDescription]
UpdateDivider=-1
(Note the UpdateDivider=-1 on the plugin measure, and particularly the fact that DynamicVariables is not set.)

In all previous versions of Rainmeter going all the way back to at least 3.x days, the plugin would receive an "Input" value that was set to <something> at the very first update. Thus the MeasureMyPluginStuff measure would fire off happily and return some exciting value.

In 4.5.1, it seems something has changed. Now I *must* use DynamicVariables=1 on my plugin measure, otherwise I seem to get nothing the very first time the plugin is invoked (and because of the UpdateDivider=-1, it stays nothing). Clearly this is trivially simple to fix, and you could argue that I always should have been using DynamicVariables anyway, but I guess my question/issue is that this is now acting differently.

Is there some subtle difference with the way plugins are handled vs. internal measures? It's almost acting as if plugins spin up one tick faster than internal measures.
Gadgets Wiki GitHub More Gadgets...
User avatar
SilverAzide
Rainmeter Sage
Posts: 1611
Joined: March 23rd, 2015, 5:26 pm

Re: 4.5.1.3535

Post by SilverAzide »

I assume that these enhancements are possible because you are now able to more easily grab data from the MIB_IFROW structures? A couple of suggestions/requests:

For the docs (if it is not already there), for anyone using SysInfoData=<ifIndex>, be aware that the ifIndex value can change if you twiddle airplane mode or enable/disable adapters. From the MS docs:
This index value may change when a network adapter is disabled and then enabled, and should not be considered persistent.
So don't assume that this value is static.

Second, if you are grabbing the MIB_IFROW data, can we have a new SysInfoType=ADAPTER_SPEED (just a suggestion for talking purposes) that returns the dwSpeed member? This value might be helpful to know (it's not always the max speed of the adapter, especially in the case of wireless) and it is kind of a freebie since you already did all the hard work to grab the adapter info.
Gadgets Wiki GitHub More Gadgets...
User avatar
Brian
Developer
Posts: 2272
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: 4.5.1.3535

Post by Brian »

SilverAzide wrote: September 10th, 2021, 12:05 am Is there some subtle difference with the way plugins are handled vs. internal measures? It's almost acting as if plugins spin up one tick faster than internal measures.
Technically the answer is: No, plugins are not handled differently in instances like these.

However, in reality, the problem lies in how the SysInfo plugin was implemented (and possibly other plugins).

This is the reason why it is different:
jsmorley wrote: September 9th, 2021, 5:15 pm Third, all the values are now retrieved in the "Update" function, instead of some of the string values that were retrieved in "GetString". This will help with performance, however, if skins took advantage of this, they may not work they way they used to. I don't see this as a BWC issue really, but more of a performance fix.

Measures and plugins are "supposed" to gather the string value inside the Update function - which is called during the update cycle. Some plugins (like SysInfo), gathered the string value in another function called "GetString" that is called whenever a skin uses a section variable, or if the About dialog is open.

Basically this means the old SysInfo plugin would still gather its string value if the measure was paused or disabled, or UpdateDivider was used. It could also gather that string value several times each update cycle - meaning the performance was really bad.


SilverAzide wrote:September 10th, 2021, 12:05 am Second, if you are grabbing the MIB_IFROW data, can we have a new SysInfoType=ADAPTER_SPEED (just a suggestion for talking purposes) that returns the dwSpeed member?
Yeah, we can look into this as well, but nothing has been discussed as of yet.

-Brian
User avatar
death.crafter
Posts: 1038
Joined: April 24th, 2021, 8:13 pm

Re: 4.5.1.3535

Post by death.crafter »

I know it's not much, but I think you should sign prerelease versions too.
Screenshot 2021-09-10 071322.png
You do not have the required permissions to view the files attached to this post.
from the Realm of Death
My Current Desktop
User avatar
SilverAzide
Rainmeter Sage
Posts: 1611
Joined: March 23rd, 2015, 5:26 pm

Re: 4.5.1.3535

Post by SilverAzide »

Brian wrote: September 10th, 2021, 1:15 am This is the reason why it is different:
Oh!!! Thanks Brian (and JSMorley)! I missed that distinction, that is the exact scenario I ran into and didn't snap to it until you pointed it out.

Another tidbit of info that would be great to gather if it is easy to do would be the "Alias" (aka, interface name), as shown here in the debug log:

Code: Select all

DBUG (20:24:55.998) :  35: Name: Intel(R) Dual Band Wireless-AC 8260
DBUG (20:24:55.998) :      Alias: Wi-Fi
DBUG (20:24:55.999) :      GUID: {0FB9DB6E-26B8-4BAD-A4AB-31B0F705E414}
DBUG (20:24:56.000) :      Type=Wireless(71), Hardware=Yes, Filter=No
DBUG (20:24:56.000) :      IfIndex=3, State=Connected, Status=Up(1)
This value is really hard to fetch efficiently, and it is not exposed by any measure anywhere in Rainmeter (that I can find). If this is a freebie too, it would be nice to have this as well.
Gadgets Wiki GitHub More Gadgets...
User avatar
Brian
Developer
Posts: 2272
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: 4.5.1.3535

Post by Brian »

death.crafter wrote: September 10th, 2021, 1:43 am I know it's not much, but I think you should sign prerelease versions too.
Hmmm, jsmorley was having issues when doing the build, I guess this explains that. Anyway, I fixed it. You can get r3535 in the first post.

-Brian
User avatar
death.crafter
Posts: 1038
Joined: April 24th, 2021, 8:13 pm

Re: 4.5.1.3535

Post by death.crafter »

Brian wrote: September 10th, 2021, 4:55 am Hmmm, jsmorley was having issues when doing the build, I guess this explains that. Anyway, I fixed it. You can get r3535 in the first post.

-Brian
It was quick...

Thanks, tho I had already installed it. I thought I should report this since people are less trusting these days.
from the Realm of Death
My Current Desktop
User avatar
SilverAzide
Rainmeter Sage
Posts: 1611
Joined: March 23rd, 2015, 5:26 pm

Re: 4.5.1.3535

Post by SilverAzide »

jsmorley wrote: September 9th, 2021, 5:15 pm Please reply in this thread with any issues you find with these changes.
Here is another variation I found: when using the old SysInfo plugin with SysInfoType=IP_ADDRESS, when no network was present the measure would return a string value of an empty string (and a number value of 0). With the new measure, when no network is present the string value is now "0" instead of "".

I assume this is another issue related to the Update change. It is easy enough to fix by adding a substitute on the measure, but I just wanted to mention it in case it was a backwards compatibility concern.
Gadgets Wiki GitHub More Gadgets...
User avatar
Brian
Developer
Posts: 2272
Joined: November 24th, 2011, 1:42 am
Location: Utah

Re: 4.5.1.3535

Post by Brian »

SilverAzide wrote: September 10th, 2021, 11:43 pm Here is another variation I found: when using the old SysInfo plugin with SysInfoType=IP_ADDRESS, when no network was present the measure would return a string value of an empty string (and a number value of 0). With the new measure, when no network is present the string value is now "0" instead of "".

I assume this is another issue related to the Update change. It is easy enough to fix by adding a substitute on the measure, but I just wanted to mention it in case it was a backwards compatibility concern.
Thanks for reporting this. This one is caused by poor plugin design. Normally "strings" are supposed return "nothing" (or null) when there is no string value. This is because of how Rainmeter "decides" whether to use the string value or number value in some cases. For some reason, the old plugin specifically returned an empty string for invalid IP_ADDRESS's, instead of a null. I guess it makes sense, but not really how other plugins or measures do it.

I couldn't see any other types do this, so hopefully this is the only one!

Anyway, I fixed it.

-Brian