I'm trying to hide some values in the registry (such as serial numbers) with C++/windows
so I've been looking at this article http://www.codeproject.com/KB/system/NtRegistry.aspx
which says:
How is this possible? The answer is
that a name which is a counted as a
Unicode string can explicitly include
NULL characters (0) as part of the
name. For example, "Key\0". To include
the NULL at the end, the length of the
Unicode string is specified as 4.
There is absolutely no way to specify
this name using the Win32 API since if
"Key\0" is passed as a name, the API
will determine that the name is "Key"
(3 characters in length) because the
"\0" indicates the end of the name.
When a key (or any other object with a
name such as a named Event, Semaphore,
or Mutex) is created with such a name,
any application using the Win32 API
will be unable to open the name, even
though they might seem to see it.
so I tried doing something similar:
HKEY keyHandle;
PHKEY key;
unsigned long status = 0;
wchar_t *wKeyName = new wchar_t[m_keyLength];
MultiByteToWideChar(CP_ACP, 0, m_keyName, m_keyLength, wKeyName, m_keyLength);
wKeyName[18] = '\0';
long result = RegCreateKeyExW(HKEY_LOCAL_MACHINE,
wKeyName,
0,
NULL,
0,
KEY_ALL_ACCESS,
NULL,
&keyHandle,
&status);
where m_keyName is the ASCII text and wKeyName is the wide char text, but in regedit I see that it is treated the same and the key is just cut where I put the '\0'.
what is wrong with it?
The problem is that you are using the Win32 API and not the NT Native API. There is a table about 1/2 way through the article that you referenced that contains the list of Native APIs. For example, you would use NtCreateKey or ZwCreateKey instead of RegCreateKeyExW. The Win32 API assumes that alls strings are terminated by a NUL character whereas the Native API counterparts use a UNICODE_STRING structure for the name.
I'll take a stab in the dark, as I have never tried to do this.
It appears that you are using the wrong function to create your registry key. You should be using the NtCreateKey method because RegCreateKeyEx[AW] will notice your '\0' and chop off past it.
Why not use the class provided in the example? It provides a method called CreateHiddenKey. To use it, simply call SetKey before it. It would be much cleaner.
Related
I am trying to mimic the behavior of CString::LoadString(HINSTANCE hInst, DWORD id, WORD langID) without introducing a dependency on MFC into my app. So I walked through the source. The first thing it does is to immediately call AtlGetStringResourceImage(hInst, id, langID), and then this in turn contains the following line of code:
hResource = ::FindResourceExW(hInst, (LPWSTR)RT_STRING, MAKEINTRESOURCEW((id>>4)+1), langID);
(It's not verbatim like this, but I trimmed out some unimportant stuff).
What is the meaning of shifting the ID by 4 and adding 1? According to the documentation of FindResourceEx, you should pass in MAKEINTRESOURCE(id), and I can't find any example code that is manipulating the id before passing it to MAKEINTRESOURCE. At the same time, if I make my code call MAKEINTRESOURCE(id) then it doesn't work and FindResourceEx returns null, whereas if I use the above shift + add, then it does work.
Can anyone explain this?
From the STRINGTABLE resource documentation:
RC allocates 16 strings per section and uses the identifier value to determine which section is to contain the string. Strings whose identifiers differ only in the bottom 4 bits are placed in the same section.
The code you are curious about locates the section a given string identifier is stored in by ignoring the low 4 bits.
I'm writing a small program with QT creator under windows 7 (32 bit). My goal is to create a windows key.
I'm using
QSettings settings("HKEY_CURRENT_USER\\Software\\Company", QSettings::NativeFormat);
settings.setValue("C:\\path\\prog.exe", "Value");
but in the windows registry the generated key has the value C:/path/prog.exe
I've tryed to convert it with
qDebug() << QDir::toNativeSeparators("C:\\path\\prog.exe");
the output of qDebug() is right c:\path\prog.exe
but doing
settings.setValue(QDir::toNativeSeparators("C:\\path\\prog.exe"), "Value");
results again in a path with a wrong slash.
do there is a way to write correctly the path in the windows registry without using the windows API?
Thanks
Francesco
You can't do it even with WinAPI. Because you are specifying an invalid key. You should understand that QSettings class use platform-specific backend, so it is useful to read documentation, if something does not work as expected. Start here.
QSettings class performs custom transformation to keys and values, so you may store any QVariant values there. Even arrays. Invalid values for each platform will be escaped. You may look at exact transformation rules in Qt sources.
Note: values transformation depends on type of settings storage. For example^ for .ini files.
ok, I managed to achieve my goal by using
RegSetValueEx(hkey, TEXT("C:\\path\\prog.exe"), 0, REG_SZ, (LPBYTE)TEXT("WIN98"), 6 * sizeof(WCHAR));
for a constant string.
in case the program path is strored in a char * (like in my case), it works with
char* exe_name = /*something*/
wchar_t* wString=new wchar_t[4096];
MultiByteToWideChar(CP_ACP, 0, exe_name, -1, wString, 4096);
RegCreateKeyEx( .......... )
RegSetValueEx(hkey, (LPCWSTR) wString, 0, REG_SZ, (LPBYTE)TEXT("WIN98"), 6 * sizeof(WCHAR));
Francesco
I'm reading a book called "Introduction to 3D Game Programming with DirectX 9.0c: A Shader Approach" and I was following the codes there but the application used Multi-Byte Character Set and I read from somewhere that it's not a good practice to use that and im having error when creating a window. here is the code that im having error.
mhMainWnd = CreateWindow(L"D3DWndClassName", mMainWndCaption.c_str(), WS_OVERLAPPEDWINDOW,
GetSystemMetrics(SM_CXSCREEN)/2 - width/2,
GetSystemMetrics(SM_CYSCREEN)/2 - height/2,
R.right, R.bottom, 0, 0, mhAppInst, 0);
then the eror is:
error C2664: 'CreateWindowExW' : cannot convert parameter 2 from 'const char [16]' to 'LPCWSTR'
hope someone can help me
What you heard about the preferability of Unicode over the ANSI/MBCS is entirely correct. All new Windows code should be written to work with Unicode. In order to make this happen, you have to ensure two things:
Both the UNICODE and _UNICODE symbols need to be defined globally to ensure that the Unicode versions of the API functions are called, even if you forget the W suffix.
You can either do this at the top of your precompiled header
#define UNICODE
#define _UNICODE
or in your project's Properties window within Visual Studio. Simply add both of the values to the list.
All of your strings (both literals and otherwise) need to be Unicode strings.
With literals, you accomplish this by prefixing them with L, just as you've done in the example: L"D3DWndClassName"
With strings that are allocated at runtime, you need to use the wchar_t type. Since you're using C++, you should obviously be using a string class rather than raw character arrays like you would in C. So you need to use a string class that treats the characters in the string as wchar_t. This would either be std::wstring or MFC/ATL/WTL's CStringW class.
It looks like you've got most of this down already. The culprit is mMainWndCaption.c_str(). You are using std::string (which returns a nul-terminated array of chars) instead of std::wstring (which returns a nul-terminated array of wchar_ts).
Either change your project to ANSI or MBCS rather than UNICODE, then change
L"D3DWndClassName"
to
"D3DWndClassName"
or, leave your project properties as UNICODE but use a UNICODE string of your window caption - so
CString szCaption(mMainWndCaption.c_str()); // CString is actually CStringW in UNICODE build
mhMainWnd = CreateWindow(L"D3DWndClassName", szCaption, WS_OVERLAPPEDWINDOW,
GetSystemMetrics(SM_CXSCREEN)/2 - width/2,
GetSystemMetrics(SM_CYSCREEN)/2 - height/2,
R.right, R.bottom, 0, 0, mhAppInst, 0);
I have some existing Visual C++ code where I need to add the conversion of wide character strings to upper or lower case.
I know there are pitfalls to this (such as the Turkish "I"), but most of these can be ironed-out if you know the language. Fortunately in this area of code I know the LCID value (locale ID) which I guess is the same as knowing the language.
As LCID is a Windows type, is there a Windows function that will convert wide strings to upper or lower case?
The C runtime function _towupper_l() sounds like it would be ideal but it takes a _locale_t parameter instead of LCID, so I guess it's unsuitable unless there is a completely reliable way of converting an LCID to a _locale_t.
The function you're searching for is called LCMapString and it is part of the Windows NLS APIs. The LCMAP_UPPERCASE flag maps characters to uppercase, while the LCMAP_LOWERCASE maps characters to lowercase.
For applications targeting Windows Vista and later, there is an Ex variant that works on locale names instead of identifiers, which are what Microsoft now says you should prefer to use.
In fact, in the CRT implementation provided with VS 2010 (and presumably other versions as well), functions such as _towupper_l ultimately end up calling LCMapString after they extract the locale ID (LCID) from the specified _locale_t.
If you're like me, and less familiar with the i8n APIs than you should be, you probably already know about the CharUpper, CharLower, CharUpperBuff, and CharLowerBuff family of functions. These have been the old standbys from the early days of Windows for altering the case of chars/strings, but as their documentation warns:
Note that CharXxx always maps uppercase I to lowercase I ("i"), even when the current language is Turkish or Azeri. If you need a function that is linguistically sensitive in this respect, call LCMapString.
What it neglects to mention is filled in by a couple of posts on Michael Kaplan's wonderful blog on internationalization issues: What does "linguistic casing" mean?, How best to alter case. The executive summary is that you achieve the same results as the CharXxx family of functions by calling LCMapString and not specifying the LCMAP_LINGUISTIC_CASING flag, whereas you can be linguistically sensitive by ensuring that you do specify the LCMAP_LINGUISTIC_CASING flag.
Sample code:
std::wstring test("Does my code pass the Turkey test?");
if (!LCMapStringW(lcid, /* your LCID, defined elsewhere */
LCMAP_UPPERCASE | LCMAP_LINGUISTIC_CASING,
test.c_str(), /* input string */
test.length(), /* length of input string */
&test[0], /* output buffer (can reuse input) */
test.length())) /* length of output buffer (same as input) */
{
// Uh-oh! Something went wrong in the call to LCMapString, so you need to
// handle the error somehow here.
// A good start is calling GetLastError to determine the error code.
}
I have to convert the encoding of a string output of a VB6 application to a specific encoding.
The problem is, I don't know the encoding of the string, because of that:
According to the VB6 documentation when accessing certain API functions the internal Unicode strings are converted to ANSI strings using the default codepage of Windows.
Because of that, the encoding of the string output can be different on different systems, but I have to know it to perform the conversion.
How can I read the default codepage using the Win32 API or - if there's no other way - by reading the registry?
It could be even more succinct by using GetACP - the Win32 API call for returning the default code page! (Default code page is often called "ANSI")
int nCodePage = GetACP();
Also many API calls (such as MultiByteToWideChar) accept the constant value CP_ACP (zero) which always means "use the system code page". So you may not actually need to know the current code page, depending on what you want to do with it.
GetSystemDefaultLCID() gives you the system locale.
If the LCID is not enough and you truly need the codepage, use this code:
TCHAR szCodePage[10];
int cch= GetLocaleInfo(
GetSystemDefaultLCID(), // or any LCID you may be interested in
LOCALE_IDEFAULTANSICODEPAGE,
szCodePage,
countof(szCodePage));
nCodePage= cch>0 ? _ttoi(szCodePage) : 0;
That worked for me, thanks, but can be written more succinctly as:
UINT nCodePage = CP_ACP;
const int cch = ::GetLocaleInfo(LOCALE_SYSTEM_DEFAULT,
LOCALE_RETURN_NUMBER|LOCALE_IDEFAULTANSICODEPAGE,
(LPTSTR)&nCodePage, sizeof(nCodePage) / sizeof(_TCHAR) );