Updated plugins not automatically downloaded.

[rawnar]

While checking the plugin for Borderlands with my friend we found out that his plugins were not updated. To be more precise his Roaming\mumble\plugins directory was completely empty. This could be due to his for gaming optimized version of windows, that lacks some functionality needed by mumble.

Me and my want to fix it all attitude went into the source of mumble to find this functionality that he could be missing. And quickly within the Plugins.cpp file I found the WinVerifyTrust() function that asks the trust provider if a file can be trusted. Probably the provider is missing on his system and function will not return a zero. Could this part be changes so it also checks the possibility that there is something wrong with the trust provider and handle appropriately?

While reading the documentation of WinVerifyTrust on MSDN I came across this note:

The return value is a LONG, not an HRESULT as previously documented. Do not use HRESULT macros such as SUCCEEDED to determine whether the function succeeded. Instead, check the return value for equality to zero.

In Mumble the return value is declared HRESULT, maybe as a precaution this has to be changed to LONG WINAPI. The return value is checked for being zero, so that is consistent with the note.

[hacst]

I doubt it makes a functional difference (iirc HRESULT is a long) but I guess we should adhere to the documentation anyway.

Want to provide a patch?

On your friends problems. In this case "Optimized for gaming" sounds more like broken ;-)

[rawnar]

There are two other instances of the WinVerifyTrust() in the source tree of Mumble. The one in the src/mumble1xx tree was already set to LONG, but the other in the src/mumble tree was not. Do you also prefer a name change as the variables are called hr, which is related to HRESULT. Maybe tStat is an option, standing for Trust Status. I am not familiar with naming conventions for coding.

update: Just found out that part of the file in the mumble1xx tree are symbolic links, :roll: so it is only one extra instances. And the one in src/mumble1xx tree was already set to LONG as I had already changed the one in the src/mumble tree. ;)

I went for the long name TrustStatus as no other variable in the hole mumble tree is named like that.

[rawnar]

According to slicer the name I picked was not following your naming guide. So I have changed the name and changed the file attached to the tracker/patch. I am willing to help more in the coding of mumble, so I was wandering were I can find some information about the naming guide you are using for the coding?

It could be a idea to add a wiki page with the guide for future reference and new coders.

[hacst]

I'm afraid - at least afaik - we do not yet have such a page.

We use a relaxed hungarian notation style for naming (does not include the scope, is not applied to local variables, mostly systems hungarian). Just take a peek at some of the code and it'll be pretty obvious.

We do not really have any hard rules for formatting afaik. Slicer regularly does runs with a format tool so anything you mess up there should be corrected by that. Basically it's again: Just take a peek at a few lines in say MainWindow.h/cpp.

I guess easiest, for now, would be asking on IRC if unsure.