I started to write a program to recursively enumerate registry keys but then thought, hmm, there may be a registry search API function? I can't seem to find one. Is anyone aware?
No, there is no registry search function available via API.
Related
I just came up with a Question thats bugging me.
I would like to create or find a Program that can observe filesystem changes and registry etc. Changes made by another Executable.
Like Starting a Program through Another and observing the windows api calls or something.
Is that possible? And how would I go about it?
Thanks in advance.
You can use this api http://msdn.microsoft.com/en-us/library/windows/desktop/aa365261(v=vs.85).aspx
This api is limited and if your task is out of scope of this api you must go in minifilter driver wonderland.
Where can I find standard guidelines for user interfaces of Windows applications? I have done a search with no luck, but there must be some sort of document on how actions should be handled.
sigh...the usual thing. After asking I found it.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa511440.aspx
Our installed is occasionally detecting the wrong version of Windows. (It detects version via built in Wise installer function to detect System Info and doesn't say HOW it does this).
So, I'm looking for another way to detect the Windows version. The Wise installer is pretty limited in it's ability to call Windows API functions so reading from the Registry or a specific file would be easier (of course then I have to map the file version to the Windows version).
I found this discussion thread:
http://www.velocityreviews.com/forums/t513244-best-way-to-get-version-from-registry.html
But it had no citations. So I'm not sure how dependable it would be.
I understand you would rather not use the API, but if you don't trust what Wise gives you, it might be the only way to be sure:
GetVersionEx() http://msdn.microsoft.com/en-us/library/ms724451(v=VS.85).aspx
There is sample code (and many comments about alternate functions that might be closer to what you actually need) on the linked to page.
If you want a registry solution you can look at the key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion and check out the values for ProductVersion, CurrentVersion, CurrentBuild.
I'm looking for some information how to replace the default email program within Windows. So far I've been able to find limited information about changing the registry keys to point to a custom coded DLL. Microsoft mentions that there is a MAPI stub which is saved as Windows\System32\MAPI32.dll and there are functions that need to be implemented but not much detail on how it must be done.
I'll be writing the main program in C# but get the feeling I'll need to write the custom MAPI DLL in unmanaged C/C++
Any links or insight would be helpful.
Thanks.
Two things I can think of
modifying default email program is not related to DLL. See KB 299853. The sample is in VB but you can easily change it to C#.
associate the mailto: protocol to your program, which is already discussed here
Thanks Peon for the info.
Part of my research brought me information about Mozilla's Thunderbird.
Thunderbird may not fully implement Simple MAPI as many people have mentioned. However it gives a great outline of the DLL stub that needs to be overridden.
Anyone looking into creating a default email client, or at least acts like a default email client should look at the Thunderbird source code ( available off Mozilla's website ).
Also, install Thunderbird. It creates all of the proper registry changes that you'll also need to make.
https://stackoverflow.com/questions/38074930/windows-application-crash-issue-with-dllmain-c
use registry to change default email client. And code from the link will help you to run your code.
Code is in c++.
Is it possible to determine whether or not a given registry key is redirected?
My problem is that I want to enumerate registry keys in both the 32-bit and 64-bit registry views in a generic manner from a 32-bit application. I could simply open each key twice, first with KEY_WOW64_64KEY and then with KEY_WOW64_32KEY. However, if the key is not redirected this gives you exactly the same key and you end up enumerating the exact same content twice; this is what I am trying to avoid.
I did find some documentation on it, but it looks like the only way is to examine the hive and do a bunch of string comparisons on the key. Another possibility I thought of is to try to open Wow6432Node on each subkey; if it exists then the key must be redirected. I.e. if I am trying to open HKCU\Software\Microsoft\Windows I would try to open the following keys:
HKCU\Wow6432Node, HKCU\Software\Wow6432Node, HKCU\Software\Microsoft\Wow6432Node, and HKCU\Software\Microsoft\Windows\Wow6432Node. Unfortunately, the documentation seems to imply that a child of a redirected key is not necessarily redirected so that route also has issues.
So, what are my options here?
Your goal is not clear. Why do you need to enumerate registry keys in both the 32-bit and 64-bit registry views in a generic manner from a 32-bit application? What do you want to do with 64-bit values in your application? What would you do if there is some different values for x64 and x86 key? It feels like strange or rather wrong idea.
Keys are redirected for important reason: to not break behavior of x86 applications. For example: CLSID is used by COM to find proper implementation for a given interface. Among other, "proper" means that it might be run by caller code i.e. should be of the same platform. That's why there should be different sets of entries for x64 and x86. Reasons for other redirected keys are similar. Generally speaking, those redirected keys has to be different for x86 and x64 applications.
As Raymond Chen wrote, "On 64-bit Windows, 32-bit programs run in an emulation layer, and if you don't like that, then don't use the emulator" and I totally agree with his advice. So my best advice if you need something like this, is to do it from x64 application. But first reconsider whether you really need it.
EDIT: There is samDesired parameter of RegOpenKeyEx that you might find useful. Also take a look at "Accessing an Alternate Registry View" MSDN article.
You're in for a fair amount of pain, it depends on the operating system version. The full list is available here.