Right now, I use SetThreadUILanguages() to set a thread's language to always get the timezone in English by GetTimeZoneInformation().
Unfortunately, sometimes it will still return Time Zone Information in the system default language.
I think SetThreadUILanguages() might be too old for Windows 11, so I try to use SetThreadPreferredUILanguages(), but I'm not sure how to use this function.
Microsoft seems not to give a sample for this.
I'd like to set a program as the 'default browser', so that for example, it'll be opened when addresses like http://google.com/ are opened by another program or Windows.
At first I assumed this was the same as XP/7 (via HKCR), but I found that you need to use the Default Programs feature of win8[+]. The relevant key is stored I think, at [HKEY_CURRENT_USER\Software\Microsoft\Windows\Shell\Associations\UrlAssociations\https\UserChoice]"Hash"="/9CPwAgPN4s=" "Progid"="IE.HTTPS".
But I don't know how to generate the hash keys.
Any information about how other programs do this or just hints in the right direction is greatly appreciated.
I want to monitor when a key is changed/added/deleted to the registry whenever application is being installed or removed. I have tested the sample code from the msdn(link) and it works fine.
But the problem is that it does not tell me which key has actually been modified/added/deleted. How can i retrieve this information using c++?
There are only 3 ways, none of which is both easy and adequate:
RegNotifyChangeKeyValue:
Doesn't give you the info you need, but is very easy to use.
EVENT_TRACE_FLAG_REGISTRY which is part of Event Tracing for Windows
which is what ProcMon uses. It works well, but it's quite difficult to use.
I'm not sure exactly how to use it myself, but if I figure it out I'll post it here.
CmRegisterCallback:
Requires kernel-mode driver, which is a pain in 64-bit.
But it's the most perfect solution otherwise.
Unfortunately Event Tracing for Windows (EWT) does not allow to see full key path in the event. You get only a partial key name and a strange handle with is actually a key control block. It's not so simple to get information from this block.
Yes the process monitor uses EWT, but it does not use Windows Kernel Trace as a provider.
There seems to be two methods of setting and getting a user screensaver parameters on a Windows platform:
1: Via the SystemParametersInfo() API:
//To read
SystemParametersInfo(SPI_GETSCREENSAVEACTIVE, 0, &bScreensaverAcrtive, NULL);
SystemParametersInfo(SPI_GETSCREENSAVETIMEOUT, 0, &nScreensaverTimeout, NULL);
//No API to get the screensaver file used
//To set
SystemParametersInfo(SPI_SETSCREENSAVEACTIVE, 0, bScreensaverAcrtive, NULL);
SystemParametersInfo(SPI_SETSCREENSAVETIMEOUT, 0, nScreensaverTimeout, NULL);
//No API to change the screensaver file
2: Through the system registry keys:
HKCU\Control Panel\Desktop - "ScreenSaveActive"
HKCU\Control Panel\Desktop - "ScreenSaveTimeOut"
HKCU\Control Panel\Desktop - "SCRNSAVE.EXE"
But since there're two competing methods that seem to do the same, what is the recommended way to use?
PS. I highly favor method #2 (or writing directly into registry) due to the following reasons:
A. If you read the explanation of a bug in the SPI_GETSCREENSAVEACTIVE flag, you'll see that MS themselves recommend to use registry.
B. If you read the documentation for the SPI_SETSCREENSAVEACTIVE and SPI_SETSCREENSAVETIMEOUT flags, there's this mystical line that says, "*If the machine has entered power saving mode or system lock state, an ERROR_OPERATION_IN_PROGRESS exception occurs.*" I first ignored this situation until it actually started happening on my test installation of Windows 8. This is the most asinine error, I should tell you. There's absolutely no graceful way of interpreting what it means or do any workaround (except, writing directly into the registry.)
Use the API. Asking that is like asking if you should wait for the traffic light to turn green before crossing the road. I won't call the cops if I see you crossing at red, but if you ask me, I'll tell you you have to wait. And you are the one taking the risk of bad things happening.
The API is documented, the registry locations are not. Microsoft is in no obligation to preserve the registry locations or their functionality.
The SPI_GETSCREENSAVEACTIVE flag affects Windows 2000. If you support Windows 2000 as a target platform, I would apply the registry read to that version only (OSVERSIONINFO.dwMajor=5, .dwMinor=0)
ERROR_OPERATION_IN_PROGRESS I'd try to figure out under what circumstances this happens (e.g. screensaver already active, or system about to enter a power saving state).
Generally, I'd find it questionable if activating / deactivating the screensaver is not at least related to a user action, in which case the system should be ready to accept a change.
What are you trying to achieve? Why do you need to modify screensaver activity? Maybe there's some better method to achieve your goal
Use the API. The registry format changes often.
As for the power state changes, screen savers are really a 20th century feature. Laptops turn off the screen entirely, for obvious reasons. In that power saving state SPI_SETSCREENSAVEACTIVE obviously should fail. Not a lot of interpreting to do.
So, check for GUID_VIDEO_POWERDOWN_TIMEOUT first.
edit
I just realized that Group Policy screensavers are also unlikely to be in the registry, and certainly would override HKCU. Not a real issue for Windows 2000, of course, but today the API method would be even more advisable. Of course, do realize that this is just another reason why SPI_SETSCREENSAVEACTIVE may return an error. Still an improvement over the registry approach, which fails silently in the presence of Group Policy.
"To set" above is incorrect. It should be:
//To set
SystemParametersInfo(SPI_SETSCREENSAVEACTIVE, bScreensaverAcrtive, NULL, NULL);
SystemParametersInfo(SPI_SETSCREENSAVETIMEOUT, nScreensaverTimeout, NULL, NULL);
I know that one can call the following API to hibernate the system:
SetSuspendState(TRUE, FALSE, FALSE);
But is there any way to find out if "real" hibernation is available for the current Windows user?
Here's what I mean:
If an admin calls:
powercfg.exe /hibernate off
the API above will put system into a Sleep mode. So how do you know (from a C++ program) that this will happen instead of hibernation?
I'm not sure if there's a group policy that can prohibit a user from hibernating a computer connected to an Active Directory?
Edit I am aware of the (dated) IsPwrHibernateAllowed API. I find that it doesn't work: it still returns the same result even if powercfg.exe /hibernate off was called. Am I doing something wrong there? Can someone explain why IsPwrHibernateAllowed doesn't work for me?
Take a look at SYSTEM_POWER_CAPABILITIES structure that can be obtained with CallNtPowerInformation. Specifically, look at HiberFilePresent field.