Done Bugs nobody cares about

[Charles Dye]

#1: %_VOLUME: Doesn't work for me in Windows 10. Was it ever updated to use
the Vista mixer model? Does anybody ever use this variable?

#2: %_ADMIN: Works for local users, not for domain users. Does anybody use
this variable? When would it ever be useful?

 

[Joe Caverly]

E:\Utils>echo %_volume
50

...which agrees with my Logitech Keyboard Volume Control;

I use it to auto-reset the volume to 50%, as I usually forget to reduce from a higher volume after playing a song or video.


I use %_ADMIN in .btm files that use commands which require Administrator Mode.

I only have a few .btm's that require Administrator Mode.

Joe

 

[rconn]

_admin calls a Windows API (NetUserGetInfo) that only works if the user has admin or group access. There is no other API that can retrieve that info.

_volume calls the Windows audio mixer APIs.

 

[Charles Dye]

_admin calls a Windows API (NetUserGetInfo) that only works if the user has admin or group access. There is no other API that can retrieve that info.

You can get the user name with GetUserNameEx(), and enumerate local admins with NetLocalGroupGetMembers(). Won't catch users in nested groups, but I don't think _ADMIN did that anyway...?

_volume calls the Windows audio mixer APIs.

The Windows XP mixer APIs, or the Vista mixer APIs? They are, of course, wildly different. I've tried _VOLUME on several different Windows 10 systems, and it usually returns wrong values.

None of which is to imply that I care particularly about any of these. I'm just posting them on the off chance you get bored and want a time-filler. I have others, all just as trivial if not more so.

 

[Charles Dye]

I use %_ADMIN in .btm files that use commands which require Administrator Mode.

I only have a few .btm's that require Administrator Mode.

I would recommend _ELEVATED for this purpose. _ELEVATED will tell you whether your batch file is currently running elevated.

 

[vefatica]

I have a couple _VOLUME variables. Mine (sysutils) agrees with Windows.

v:\> plugin /u sysutils & echo %_volume & plugin /L D:\data\tccplugins\SysUtils64.dll & echo %_volume
100
90

This may explain where I get it. I'll post more if anyone wants it.

hr = pDefaultDevice->Activate(__uuidof(IAudioEndpointVolume), CLSCTX_INPROC_SERVER, NULL, (LPVOID*) &pEndpointVolume);

 

[Charles Dye]

I have a couple _VOLUME variables. Mine (sysutils) agrees with Windows.

As do I. I just thought Rex might like to join in the fun.

 

[rconn]

The Windows XP mixer APIs, or the Vista mixer APIs? They are, of course, wildly different. I've tried _VOLUME on several different Windows 10 systems, and it usually returns wrong values.

The Windows multimedia system APIs. The Core Audio API's (what I assume you're referring to as the "Vista mixers") drag in an enormous amount of COM cruft that is of no use to TCC.

 

[Joe Caverly]

CORRECTION: Just as with @Charles Dye, _volume does not work for me on Windows 10.

It always returns 100.

It would appear that I have been using _volume from;

E:\Utils>which _volume 
_volume is a plugin variable (SYSUTILS)

The Windows 10 issue with the internal _volume is probably why I started using the SYSUTILS version.

Joe

 

[vefatica]

The Core Audio API's (what I assume you're referring to as the "Vista mixers") drag in an enormous amount of COM cruft that is of no use to TCC.

Hmmm! When I gut my volume_helper() function (the COM stuff) I save 384 bytes of text segment in the DLL. Is that a lot?

 

[vefatica]

Hmmm! When I gut my volume_helper() function (the COM stuff) I save 384 bytes of text segment in the DLL. Is that a lot?

To be fair, that function can also set the volume (which is barely any harder than getting it).