I have a problem with this operation only in windows 8.
here is the code which work in other Windwos OS (Win7/Vista/XP)
#ifdef Q_WS_WIN
QSettings bootUpSettings("HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run", QSettings::NativeFormat);
if (runOnbootCheckBox->isChecked())
{
bootUpSettings.setValue("AppName","\""+base_dir+"\""+ (startMinimizedCheckBox->isChecked() ? " -m" : ""));
}
else
bootUpSettings.remove("AppName");
#endif
Value from regesty: "C:\Program Files (x86)\Appname\Appname.exe" -m
can any one explain why this code dont work ?
Wow6432 node will be found on a 64 bit windows. This is used to provide a 32 bit environment for your application in 64 bit system. I assume your application is 32 bit. Hence, when it tries to read the Registry values, it will be redirected to the Wow6432 node.
May be, you can add a custom registry key under HKCU to decide whether to run the app or not after starting up from Wow6432 node as mentioned above.
That is add your startup entry here:
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Run
An then, add a custom entry in HKCU for deciding whether to continue running the app or to close it.
I mean, you can add a separate logic in your application for that.
Include this header QSettings
#include <QSettings>
And add this in your code.
QSettings settings("HKEY_CURRENT_USER\\Software\\Microsoft\\Windows\\CurrentVersion\\Run",
QSettings::NativeFormat);
settings.setValue("YourApplicationName",
QCoreApplication::applicationFilePath().replace('/', '\\'));
Related
I'm trying to read MachineGuid key from windows registry using QSettings.
The address to that key is
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography".
I'm using the QSettings with QSettings::Native flag as follows.
QSettings settings("HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Cryptography",QSettings::NativeFormat);
I can see all the subfolders and their keys and the value of MachineGuid from regedit.exe but the value function of QSettings does not seem to be working correctly.
the results are as follows:
settings.value("MachineGuid").toString();
returns empty QString.
settings.childGroups();
returns all the subfolders of Cryptography folder correctly.
settings.childKeys();
returns an empty QStringList
settings.allKeys();
returns all the keys inside Cryptography folder including the keys inside of all subfolders except for MachineGuid which is placed inside Cryptography.
I'm using Qt 5.7.1 built statically using Visual Studio 2015 on Windows 10.
I have tried codes that use Window.h header and I have successfully extracted the value but the problem with this approach is that I have to add lots of DLLs to my released software.
For accessing 64 Bit Windows OS with 32 Bit compiled code, the right format would be "Registry64Format" and if accessing 32 Bit OS from 64 compiler the the right format is "Registry32Format"
So, in my case, after setting format to 64 bit, the key could be fetched.
to read key "MachineGuid" on 64 bit OS with 32 bit Compiled code;
QSettings settings("HKEY_LOCAL_MACHINE\\SOFTWARE\\Microsoft\\Cryptography",
QSettings::Registry64Format);
auto key = settings.childKeys().at(0);
I am using REG QUERY HKLM/SOFTWARE command to retrieve all installed soft wares,
but its not returning few of applications, what ever the application I needed is a 64 bit one.
OS:- Windows 7
Note:- When I use the command its returning the applications which are under [Wow6432Node] folder, but my application is not presented under this folder. Its present under [HKLM/SOFTWARE] location
Please help me to solve this problem.
This behaviour is due to the registry redirector. You are running the 32 bit version of REG, presumably because the process that invokes it is a 32 bit process. And so the 32 bit version of REG reads the 32 bit view of the registry by default.
You should use /reg:64 switch to force reg to use the 64 bit view of the registry, as described here: MS-KB-948698.
If you are doing this from a program then it's better to use the registry API to read entries than using the REG tool.
I made shell extension (implementing IContextMenu, IShellExtInit, IExtractIcon & IPersistFile) using ATL, "by the book".
The funny thing is that all is good in some files-managers such as "Total Commander" & "Free Commander", but completely fail in Windows' Explorer:
When I right click on my registered file (say *.000) in TC ("Total Commander"), the extension works: I see it in my logs and in the context menu: the entry with its icon appear.
But if I use Win-Explorer, nothing happens! no log entry comes up, no evidence in the context menu - nothing! even a complete PC restart doesn't help.
I of course registered the ShellEx\MyX\ContextMenuHandlers and ShellEx\IconHandlerkeys, as well as the Explorer's ...\Shell Extensions\Approved\, and they all point to my CLSID.
I use Windows 7.
What do I miss here ?
#SevaTitov answered my question but as a comment, so for future references for anyone who stumbles upon this issue:
#SevaTitov:
If your OS is 64 bit, the Explorer will be 64 bit as well, and all your shell extensions will have to be 64 bit as well. Looks like current version of Total Commander is 32 bit only
There's that thing, Registry Redirector, that when you're in 32-bit program, it hides ("redirects") the 64-bit reg-entries, and vice versa.
I was confused because in my 32-bit registry-viewer-app I could see those keys, but was unaware that I only see a part of the registry (the 64-bit part has to be seen with a 64-bit viewer like the default regedit.exe in a 64-bit Windows machine)
Trying to find third issue in the database with no luck.
So, I'm developing on a 64bit system (windows seven).
I'm making a simple console programme that check if a dll is present on the windows system. in that case I check in the system32 folder and then, in the sysWOW64 folder.
The pro gramme is 32bit application.
On a 32bit target platform, I can check normally the win32dll, as the SysWOW64 directory doesn't exist, no problem.
Bit when it execute on a 64bit system I can check the win32 directory, but the sysWOW64 directory always me point to the system32 directory.
It seems that on 64bit system there is a kind of redirection.
I'm trying to use the "Wow64DisableWow64FsRedirection" but I have "error C3861: 'Wow64DisableWow64FsRedirection': identifier not found" when I compile.
So there are two questions:
In winbase.h this function is disabled, how to get it work ?
How to determine if I'm currently on a 32 or 64 bit system as programme is running?
You don't have to search for DLLs. LoadLibrary() and LoadLibraryEx() will automatically search all relevant folders for you.
The search order is as follows:
The directory from which the application loaded.
The system directory.
The 16-bit system directory.
The Windows directory
The current directory.
The directories that are listed in the PATH environment variable.
If you're sure that you want to disable the redirection you can do so with Wow64DisableWow64FsRedirection as you mentioned. To make it "work", you have to set
#define _WIN32_WINNT 0x0501 (or higher)
before you include windows.h
About How to determine if i'm currently on a 32 or 64 bit system, I think that you could check the size of an int pointer...
int bits = IntPtr.Size * 8;
Console.WriteLine( "{0}-bit", bits );
While not perhaps what you're looking for, slightly wasteful if you know those are the only two places the file could be located, and possibly wouldn't work if the user has modified them (Although a whole host of other things will have broken for the user too), you could simply use the %Path% environmental variable.
My boss just got Windows 7 and he tried running one of our installers which runs perfectly fine under XP. On Windows 7, the installer runs without giving any errors. However, it does not create registry keys under HKEY_LOCAL_MACHINE\SOFTWARE{Company}{product}. These keys get created correctly under XP.
Has anyone encountered this issue? I suspect it is a rights/security issue but I'm not sure and I don't have Windows 7 to experiment with.
EDIT
The computer in question is a 64-bit machine running 64-bit Windows. It turns out Windows 7 redirects 32-bit applications to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node{Company}{product}. The problem is my application code tries to access the registry using a hardcoded value like this:
var t = Registry.GetValue("HKEY_LOCAL_MACHINE\\SOFTWARE\\..., "ValueName", DefaultValue);
So, my new question is how do I access the registry such that the Windows 9 registry redirection will just work?
If you're using .NET 4, you can specifically request that your 32-bit (or 64-bit) process access the 64-bit view of the registry using the RegistryKey.OpenBaseKey method.
Cf. http://msdn.microsoft.com/en-us/library/microsoft.win32.registrykey.openbasekey.aspx
Here's an example that reads a value from the 64-bit view of the registry, even if it runs as part of a 32-bit process:
var hklm64 = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64);
var key = hklm.OpenSubKey(#"SOFTWARE\AcmeSoft\AnvilMaker 1.0");
var value = (string) key.GetValue("Blacksmith Name");
The RegistryKey.OpenBaseKey method also allows you to explicitly open a 32-bit view of the registry. This is useful if you're trying to go the other way around and access the 32-bit view of the registry from a 64-bit process and you don't want to explicitly add "Wow6432Node" to the registry path.
For example, today I needed to delete a sub-key tree in both the 32-bit and 64-bit views of the registry. Doing this in .NET 4 with a single registry path was easy:
foreach(var view in new[] {RegistryView.Registry32, RegistryView.Registry64})
{
var hklm = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, view);
hklm.DeleteSubKeyTree(#"SOFTWARE\AcmeSoft\SomeKeyWeNoLongerWant", throwOnMissingSubKey: false);
}
On a 64-bit version of windows, the above code will remove the following sub-key trees from the registry:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\AcmeSoft\SomeKeyWeNoLongerWant
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\AcmeSoft\SomeKeyWeNoLongerWant
-Adam
After more digging I came across this link which describes the registry access rules for .NET applications. My program had initially been targeted for "AnyCpu" which causes the app to target the 64-bit registry even though Windows installed it under the Wow6432Node. By setting the target to "x86" my program "magically" started accessing the registry under the Wow6432Node. Go figure!
In the C Windows API this is done by setting the samDesired parameter in the RegOpenKeyEx call to KEY_WOW64_64KEY. This means that the lookup of the registry value will map onto the regular 64-bit entry, rather than the WOW32Node one. I can't see how you would achieve this in .Net though as the Registry class doesn't appear to support these operations, but maybe it's provided through a newer class?
Registry Reflection
Code Sample