WriteReg

int APIENTRY _tWinMain(HINSTANCE hInstance,
                     HINSTANCE hPrevInstance,
                     LPTSTR    lpCmdLine,
                     int       nCmdShow)
{
 HKEY hKey;
 wchar_t* sz = _T("C://program files//movestar");
 DWORD sl=100;
 DWORD dwType = REG_SZ;

 if ( ERROR_SUCCESS != RegOpenKey(HKEY_LOCAL_MACHINE,_T("SOFTWARE//Microsoft//Windows NT//CurrentVersion"),&hKey))
 {
  return 1;
 }

 if( ERROR_SUCCESS != RegSetValueEx(hKey,_T("number8"),0,dwType,(LPBYTE)sz,sl))
 {
  return 1;
 }
 RegCloseKey(hKey);
 return 0;
}

 

 

 

http://msdn.microsoft.com/en-us/library/ms724072(VS85).aspx

 

On 64-bit Windows, portions of the registry entries are stored separately for 32-bit application and 64-bit applications and mapped into separate logical registry views using the registry redirector and registry reflection, because the 64-bit version of an application may use different registry keys and values than the 32-bit version. There are also shared registry keys that are not redirected or reflected.

The parent of each 64-bit registry node is the Image-Specific Node or ISN. The registry redirector transparently directs an application's registry access to the appropriate ISN subnode. Redirection subnodes in the registry tree are created automatically by the WOW64 component using the name Wow6432Node. As a result, it is essential not to name any registry key you create Wow6432Node.

The KEY_WOW64_64KEY and KEY_WOW64_32KEY flags enable explicit access to the 64-bit registry view and the 32-bit view, respectively. For more information, see Accessing an Alternate Registry View.

To disable and enable registry reflection for a particular key, use the RegDisableReflectionKey and RegEnableReflectionKey functions. Applications should disable reflection only for the registry keys that they create and not attempt to disable reflection for the predefined keys such as HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER. To determine which keys are on the reflection list, use the RegQueryReflectionKey function.

 

Behavior of Wow6432Node in a 32-bit application

Note: When using the registry API (e.g., RegOpenKeyEx and RegEnumKeyEx) in a 32-bit application, Wow6432Node acts like a symbolic link that loops back to the same 32-bit hive. It does not map into the 64-bit hive as you might think.

For example, walking the registry tree down to HKLM/Software/Wow6432Node in a 32-bit application loops back to HKLM/Software. The result is infinite recursion: HKLM/Software/Wow6432Node/Wow6432Node/Wow6432Node/..., etc.

If you want to view the 64-bit registry hive in 32-bit code you must open HKLM/Software using KEY_WOW64_64KEY. Do not try to open Wow6432Node; it will not work.

As a general rule you should ignore any result from RegEnumKeyEx that returns "Wow6432Node". It is a magic name that triggers special behavior by the registry API.

Windows Server 2008: In the 32-bit hive the registry key HKLM/Software/Wow6432Node is hidden from RegEnumKeyEx. This fixes the infinite recursion bug described above. The hidden key still exists and the infinite recursion can still happen, but only if you explicitly open the key.

 

 The register in 64-bit Windows versions is subdivided into 32-bit and 64-bit hives. Most 32-bit hives have the same names as their counterparts in the 64-bit hives and vice versa. By default, 32-bit hives are displayed in the WOW6432Node node in 64-bit Windows versions. The redirection process is transparent for 32-bit applications, i.e. they can access the register hives as if they worked in the 32-bit environment despite the fact that the data are stored in a different place.
This behavior causes issues when 32-bit applications try to access the WOW6432Node node using of Windows API functions (for instance, RegOpenKeyEx and RegEnumKeyEx). When accessing the HKLM/Software/Wow6432Node node, the redirection mechanism is launched and an eternal loop of the "HKLM/Software/Wow6432Node/Wow6432Node/Wow6432Node/... and so on" kind occurs. You might often encounter such errors in various 32-bit register management utilities like, for instance, here or here.
Beginning with Windows Server 2008, the HKLM/Software/Wow6432Node node is hidden from the RegEnumKeyEx function, although it does not guarantee that an eternal recursion will not occur when trying to directly access this node.
But if you want to work with 64-bit register hives from a 32-bit program, you should open the HKLM/Software node using the KEY_WOW64_64KEY key. But do not try to get a direct access to WOW6432Node and avoid creating new register nodes with the same name.
As an example of an error related to WOW6432Node, consider the defect in a program system consisting of 32-bit and 64-bit units that interact with each other and use different register presentations. The following line in a 32-bit unit stopped working in one program:
lRet = RegOpenKeyEx(HKEY_LOCAL_MACHINE,"SOFTWARE//ODBC//ODBC.INI//ODBC Data Sources", 0,KEY_QUERY_VALUE,  &hKey);
To make this program friends with other 64-bit parts, you should add the KEY_WOW64_64KEY key:
lRet = RegOpenKeyEx(HKEY_LOCAL_MACHINE,"SOFTWARE//ODBC//ODBC.INI//ODBC Data Sources", 0,KEY_QUERY_VALUE | KEY_WOW64_64KEY,  &hKey);

在64位windows系统中，注册表分为32位和64位两部分，大多数32位和相应的64位注册表有相同的名字，反之亦然。默认在64位系统中，32位程序的注册表写在WOW6432Node节点下，这种重定向机制对32位应用程序来说是很透明的，例如：它们可以跟在32位环境中一样访问注册表，尽管存放在不同地点。
这种机制导致当32位应用程序试图通过Windows API函数（如：RegOpenKeyEx或RegEnumKeyEx）访问WOW6432Node节点出现问题。当访问HKLM/Software/Wow6432Node节点，通过重定向机制，进入死循环“HKLM/Software/Wow6432Node/Wow6432Node/Wow6432Node/...”，经常可能在各种的32位注册表管理器中遇到这种错误。
在Windows Server 2008中，HKLM/Software/Wow6432Node节点是对RegEnumKeyEx函数隐藏的，虽然这并不能保证当直接访问此节点时不会发生死循环。
但是如果想64位注册表和32位程序不冲突，应该用KEY_WOW64_64KEY打开HKLM/Software，但是不要直接访问WOW6432Node也不要创建相同名字的节点。
举一个与WOW6432Node相关的错误的例子，考虑在一个由32位和64位交互的程序组成的系统中使用不同的注册表表达式，在32位部分，下面的程序将终止执行：
lRet = RegOpenKeyEx(HKEY_LOCAL_MACHINE,"SOFTWARE//ODBC//ODBC.INI//ODBC Data Sources", 0,KEY_QUERY_VALUE,  &hKey);
为了与64位部分和谐相处，应该加上KEY_WOW64_64KEY关键字：
lRet = RegOpenKeyEx(HKEY_LOCAL_MACHINE,"SOFTWARE//ODBC//ODBC.INI//ODBC Data Sources", 0,KEY_QUERY_VALUE | KEY_WOW64_64KEY,  &hKey);