|
NtCreateFile is an undocumented API and should not be required for standard WIN32 Applications which can simply use "CreateFile" as they are the same API.
Now, if you are writing a driver the API that should be documented in the DDK header files is "ZwCreateFile". This encapsulates the overhead of creating a IRP_MJ_CREATE IRP and handling it for ease of use with your driver. Of course the down fall of using such an API is that it is not flexible and can only be used at IRQL PASSIVE.
ZwCreateFile[^]
8bc7c0ec02c0e404c0cc0680f7018827ebee
|
|
|
|
|
Suppose a program is doing some processing and the CPU shoots up to 99% (by design and not by error). How do I make it use only 50% of CPU? I have seen a program somewhere that always shows 50% in the task manager. Any idea how to achieve this behaviour? Thanks.
|
|
|
|
|
1. You can reduce the priority of your application or of specific worker threads.
The SetThreadPriority function sets the priority value for the specified thread. This value, together with the priority class of the thread's process, determines the thread's base priority level.
Why not just let the OS figure it out? Although I realize that a ill-behaved foreground application can really seem to take over your computer!
|
|
|
|
|
I want to obtain the theme colour of the border of a disabled button. I try;
GetThemeColor(hTheme, BP_PUSHBUTTON, PBS_DISABLED, TMT_BORDERCOLOR, &rgb );
but the returned color is darker than the colour produced by DrawThemeBackground call.
I've tried various other property IDs but to no avail.
Does anyone know how to obtain the correct theme colour?
|
|
|
|
|
RazorBridge wrote:
I've tried various other property IDs but to no avail.
I don't know for sure, but have you tried these in particular?
TMT_EDGELIGHTCOLOR
TMT_EDGEHIGHLIGHTCOLOR
TMT_EDGESHADOWCOLOR
TMT_EDGEDKSHADOWCOLOR
TMT_EDGEFILLCOLOR
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Yes, tried them all but no luck.
|
|
|
|
|
Target OS = WinXP/SP2
Using VC6
I'm trying to modify Tom Delascia's TaskKeyHook DLL as follows
<br />
LRESULT CALLBACK MyTaskKeyHookLL(int nCode, WPARAM wp, LPARAM lp)<br />
{<br />
KBDLLHOOKSTRUCT *pkh = (KBDLLHOOKSTRUCT *) lp;<br />
<br />
if (nCode == HC_ACTION) <br />
{<br />
BOOL bCtrlKeyDown = GetAsyncKeyState(VK_CONTROL)>>((sizeof(SHORT) * 8) - 1);<br />
BOOL bDelKeyDown = (pkh->vkCode == VK_DELETE);<br />
BOOL bAltKeyDown = (pkh->flags & LLKHF_ALTDOWN);<br />
<br />
if ( (pkh->vkCode==VK_ESCAPE && bCtrlKeyDown)
||(pkh->vkCode==VK_TAB && bAltKeyDown)
||(pkh->vkCode==VK_ESCAPE && bAltKeyDown)
||(pkh->vkCode==VK_LWIN || pkh->vkCode==VK_RWIN)
||(bCtrlKeyDown && bAltKeyDown && bDelKeyDown))
{<br />
if (g_bBeep && (wp == WM_SYSKEYDOWN || wp == WM_KEYDOWN))<br />
{<br />
MessageBeep(0);
}<br />
return 1;
}<br />
}<br />
return CallNextHookEx(g_hHookKbdLL, nCode, wp, lp);<br />
}<br />
My line of code is the addition of the last comparison in the if statement:
||(bCtrlKeyDown && bAltKeyDown && bDelKeyDown)
This does not have the desired affect of simply eating the keystroke. Why not, and how do I get to where I want to go if a global hook isn't going to work?
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
I always thought the whole point of the Ctrl-Alt-Del sequence was that it *couldn't* be interupted by application programs, but was under the sole control of the OS, so that it could be trusted. I'm sure you're not, but if you could catch this combination, what's to stop you putting up a dialog box just like a standard logon box, and stealing passwords?
|
|
|
|
|
I didn't ask why it's done, I asked how to get around it.
I'm building a "kiosk"-style app that will be put on over 100 laptops, and I don't want the users to be able to exit our app at all. The app already goes full-screen (no titlebar, menu, toolbar, or statusbar), can't be minimized, and requires a password to shut it down.
I've also disabled any way to change tasks using normal avenues (alt-tab, etc).
Now, I want to keep them from shutting down or restarting the box.
Is there a way to do this, or not?
------- sig starts
"I've heard some drivers saying, 'We're going too fast here...'. If you're not here to race, go the hell home - don't come here and grumble about going too fast. Why don't you tie a kerosene rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
I did a quick search, I remembered that the GINA dll who isresponsible for the logon process might also be used when doing a log-off.
one thing that came up was :
The purpose of a GINA DLL is to provide customizable user identification and authentication procedures. The default GINA does this by delegating SAS event monitoring to Winlogon, which receives and processes CTL+ALT+DEL secure attention sequences (SASs). A custom GINA is responsible for setting itself up to receive SAS events (other than the default CTRL+ALT+DEL SAS event), and notifying Winlogon when SAS events occur. Winlogon will evaluate its state to determine what is required to process the custom GINA's SAS. This processing usually includes calls to the GINA's SAS processing functions.
maybe this can lead you to something usefull.
Maximilien Lincourt
Your Head A Splode - Strong Bad
|
|
|
|
|
|
|
Theres 3 ways:
1. Inject into winlogon and handle the WM_HOTKEY.
2. Write a gina to handle the SAS.
3. Write a keyboard filter driver.
|
|
|
|
|
Anonymous wrote:
3. Write a keyboard filter driver.
To my knowledge, the Ctrl+Alt+Del key combination is not sent to the keyboard driver. Otherwise it would be too easy to circumvent.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Hi,
I have a char*. How to convert it to unicode big-endian in unmanagerd C++?
Thanks
|
|
|
|
|
Converting to unicode and converting to big-endian are 2 completely separate things.
To convert to unicode use mbstowcs from the C runtime library or the Windows API call MultiByteToWideChar.
Do you reall need it in big-endian? Are you sending the data over TCP or something? Anyway to convert to big-endian loop over each character in the unicode string buffer and either call htonl from the winsock library or manually swap the bytes yourself like:
wchar_t bigendchar = ((littleendwchar & 0xFF) << 8) | ((littleendwchar & 0xFF00) >> 8);
|
|
|
|
|
Actually I want to convert the string pointed by a char* to big-endian encoding, nothing deal with TCP/IP.
Like the following managed C++ code but work in unmanaged C++:
#include "stdafx.h"
#using <mscorlib.dll>
using namespace System;
using namespace System::Text;
int main()
{
String* unicodeString = S"This string contains the unicode character Pi(中)";
// Create two different encodings.
Encoding * unicode = Encoding::Unicode;
Encoding * bigendian = Encoding::BigEndianUnicode;
// Convert the string into a Byte->Item[].
Byte unicodeBytes[] = unicode -> GetBytes(unicodeString);
// Perform the conversion from one encoding to the other.
Byte bigendianBytes[] = Encoding::Convert(unicode, bigendian, unicodeBytes);
// Convert the new Byte into[] a char and[] then into a string.
// This is a slightly different approach to converting to illustrate
// the use of GetCharCount/GetChars.
Char bigendianChars[] = new Char[bigendian ->GetCharCount(bigendianBytes, 0, bigendianBytes -> Length)];
bigendian -> GetChars(bigendianBytes, 0, bigendianBytes->Length, bigendianChars, 0);
String* bigendianString = new String(bigendianChars);
// Display the strings created before and after the conversion.
Console::WriteLine(S"Original String*: {0}", unicodeString);
Console::WriteLine(S"bigendian converted String*: {0}", bigendianString);
}
|
|
|
|
|
That code isn't actually converting from char* (ANSI string) to big-endian. Rather, it's converting a String object, which internally holds a unicode string encoded as UTF-16) to another String object, which internally will hold a unicode string, again encoded as UTF-16 but this time using big-endian.
From end to end it's just swapping pairs of bytes.
The entire process it's doing is as follows:
1. Get the internal buffer of the original string as a byte array
2. Convert the byte array to big-endian (swapping each pair of bytes)
3. Copy the byte array into an array of Unicode UTF-16 chars
4. Create a new String object from the array of Unicode UTF-16 big endian chars
So, an equivalent in unmanaged C++ would be converting a wide char string to big-endian. I'm not aware of any standard C++ or Win32 API function that can be used to swap pairs of bytes, but something like the function below should work:
void ConvertToBigEndian(const wchar_t* pw, wchar_t* pwBuffer, int nBufLen)
{
int i = 0;
for( ;i < nBufLen && pw[i] != 0; i++)
{
const char* p = (const char*)&pw[i];
char* q = (char*) &pwBuffer[i];
q[0] = p[1];
q[1] = p[0];
}
if (i < nBufLen)
pwBuffer[i] = 0;
else
pwBuffer[nBufLen-1] = 0;
}
Besides that, if you really need to start from a char* (MBCS/ANSI string), first convert it to wide chars (Unicode UTF-16) using MultiByteToWideChar.
Hope that helps,
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Thanks for everybody.
I have constructed a method:
char* UnicodeCharToBigEndianConverter(char* message)
{
wchar_t input[2000];
wchar_t output[2000];
MultiByteToWideChar(
CP_ACP, // code page
MB_COMPOSITE, // character-type options
message, // string to map
-1, // number of bytes in string
input, // wide-character buffer
strlen(message)+2 // size of buffer
);
// escape character for unicode
output[0]='\xFE\xFF';
MessageBoxW(NULL,input,L"Input",0);
for(int i=1;i<=wcslen(input);i++)
{
output[i] = ((input[i-1] & 0xFF) << 8) | ((input[i-1] & 0xFF00) >> 8);
}
wcscat(output, (wchar_t*)"\x00\x00");
return (char*) output;
}
It works fine if the char* that I got from my application is a string with all unicode characters, e.g. all chinese characters. However, what if a user input a string with some chinese characters and some ASCII characters, e.g. A-Z, a-z?
Is that whole string can be converted to big-endian using:
output[i] = ((input[i-1] & 0xFF) << 8) | ((input[i-1] & 0xFF00) >> 8);
Or we need to handle those ASCII characters?
|
|
|
|
|
I hope you don't mind my comments 
scchan1984 wrote:
wchar_t input[2000];
wchar_t output[2000];
MultiByteToWideChar(
CP_ACP, // code page
MB_COMPOSITE, // character-type options
message, // string to map
-1, // number of bytes in string
input, // wide-character buffer
strlen(message)+2 // size of buffer
);
Those magic 2000 don't look well. If you are going to specify a maximum length of strings you support, you should at least check that the string you receive isn't longer than what you support.
The last parameter to MultiByteToWideChar is wrong. There you are expected to pass the size of your buffer, which in this case is 2000. strlen() returns a char count of the string (not counting the null terminator), so for example, if you receive a message of 2100 chinese characters, strlen will return 4200. When you call to MultiByteToWideChar will try to write 2100 wide chars in a buffer that can only hold 2000, based in the erroneus information you gave it (you would be telling it that your buffer has space for 4202 wide chars instead of the actual 2000). The most likely result is a crash of your application.
You should call MultiByteToWideChar first using 0 as the buffer size. That will return the required size for the buffer in wide chars. With that info, you can allocate a buffer in the heap, and then call MultiByteToWideChar again to do the conversion.
scchan1984 wrote:
// escape character for unicode
output[0]='\xFE\xFF';
You defined both buffers with the same size, but if output will hold a byte oder marker, then it should be at least one wide char bigger, or you might not have enough space.
scchan1984 wrote:
for(int i=1;i<=wcslen(input);i++)
You are calling wcslen in each iteration, making it traverse the entire string in the search for the NULL terminator. It would make more sense to call wcslen outside of the loop, store its value in a variable, and use the variable in the loop.
Then again, you don't even need to call wcslen, as the length of input is what MultiByteToWideChar returns; you'd just need to receive it in a variable.
scchan1984 wrote:
output[i] = ((input[i-1] & 0xFF) << 8) | ((input[i-1] & 0xFF00) >> 8);
This seems to be a more readable version of the byte swap I wrote in my previous post, right?
scchan1984 wrote:
wcscat(output, (wchar_t*)"\x00\x00");
Here you are again traversing the entire string just to add a terminator at the end. You already know in advance that the length of output would be exactly one wide char more (the byte order marker) than the lenght of input, which in turn was returned by MultiByteToWideChar. So you could simply write
int nInputLen = MultiByteToWideChar(...);
.
.
.
output[nInputLen+1] = 0;
scchan1984 wrote:
return (char*) output;
Why are you returning a pointer to a wide char string as if it were a char string? It doesn't make sense. The return type should be wchar_t, and you shouldn't be casting it to anything else.
Besides, you are returning a pointer to a variable allocated in the stack in the context of the function. As soon as the function returns, the variable will be destroyed!
scchan1984 wrote:
It works fine
I think you haven't done enough testing
scchan1984 wrote:
However, what if a user input a string with some chinese characters and some ASCII characters, e.g. A-Z, a-z?
That wouldn't be a problem. For example, in a MBCS string, which is what your function is supposed to receive as the char* message, an 'a' will occupy just one byte, while a Chinese character will probably use a lead byte followed by a second byte (3 bytes total, plus one additional byte for the null terminator = 4 bytes). After using MultiByteToWideChar to convert it to Unicode, you'll have a wide char (that's 2 bytes) for the 'a' and a second wide char for the chinese character (total = 2 wide chars plus a null wide char as terminator = 3 wide chars = 6 bytes). Then you would swap the bytes in each of those 3 wide chars while copying them to the output buffer, and everything would be fine.
scchan1984 wrote:
Or we need to handle those ASCII characters?
No need for special handling. Each ascii char will be represented by two bytes (one wide char), one with the original value and the other with a value of zero. Those 2 bytes will be swapped like every other wide char in the buffer.
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Really really thank you so much.
I have to improve and test my code now 
|
|
|
|
|
My improved version:
WCHAR* UnicodeCharToBigEndianConverter(char* message)
{
// get the number of WCHAR from the message
int nInputLen = MultiByteToWideChar(
CP_ACP, // code page
0, // character-type options
message, // string to map
-1, // number of bytes in string
NULL, // wide-character buffer
NULL // size of buffer
);
WCHAR* input = new WCHAR[nInputLen+1];
WCHAR* output = new WCHAR[nInputLen+1];
MultiByteToWideChar(
CP_ACP, // code page
MB_COMPOSITE, // character-type options
message, // string to map
-1, // number of bytes in string
input, // wide-character buffer
nInputLen+1 // size of buffer
);
// escape character for unicode
output[0]='\xFE\xFF';
for(int i=1;i<=nInputLen;i++)
{
output[i] = ((input[i-1] & 0xFF) << 8) | ((input[i-1] & 0xFF00) >> 8);
//output[i] = input[i-1];
}
output[nInputLen+1] = 0;
return output;
}
|
|
|
|
|
It's much better now
Note that you are allocating two buffers. You are returning one of them as the result. The other should be deleted before returning, to avoid leaking memory. Add the following line before the return:
delete[] input;
You should note that the callers of this function are responsible for deleting the result...
Besides that, it seems to be already doing what it's supposed to do. Now, if you want to do it really right, keep reading...
First I reccomend you read the following article by Joel Spolsky: The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!)
[^]
Now that you have read it (if not, go and read it, I'll wait right here), you surely understand why a name like UnicodeCharToBigEndian[...] doesn't make much sense for what this function does (i.e.: it's not receiving an Unicode string, but a multibyte string.)
A better name would be MultiByteToBigEndianWideChar...
One additional problem with your function is that it returns a buffer that must be released by the caller. This is a problematic approach because as a user of the function, I couldn't deduce that from the function signature alone.
If all I see is a function declared in a header file as
WCHAR* MultiByteToBigEndianWideChar(char* message);
I have no way to know whether I should delete the returned buffer or not, or in case I'm expected to delete it, whether I should use delete[], free, or anything else. I'd have to rely on some documentation or on having access to the implementation itself in order to find out.
To avoid this ambiguity, it's a common practice in this kind of functions to make the caller supply the buffer and its size as parameters to the function. When the buffer is supplied by the caller, the caller already knows if that buffer is allocated in the stack or in the heap, and how to release it in the latter case. That's exactly the approach followed by MultiByteToWideChar and all the API functions.
In fact, you might start with a function with exactly the same parameters as MultiByteToWideChar
int MultiByteToBigEndianWideChar(
UINT CodePage,
DWORD dwFlags,
LPCSTR lpMultiByteStr,
int cbMultiByte,
LPWSTR lpWideCharStr,
int cchWideChar
)
{
int nResult = MultiByteToWideChar(
CodePage,
dwFlags,
lpMultiByteStr,
cbMultiByte,
cchWideChar? lpWideCharStr + 1 : 0,
cchWideChar? cchWideChar-1 : 0
);
if (cchWideChar != 0)
{
lpWideCharStr[0] = 0xFEFF;
WideCharToBigEndian(lpWideCharStr, nResult+1);
}
return nResult + 1;
}
When cchWideChar is 0, it calls MultiByteToWideChar with 0, and returns its result plus 1, because this function will need to add a byte order marker (BOM) at the start of the buffer).
When cchWideChar is not 0, it calls MultiByteToWideChar to make the conversion to Unicode, leaving the first position available for the BOM, then puts the BOM at the first position, and calls WideCharToBigEndian, which simply does the byte swapping in the same buffer it receives.
void WideCharToBigEndian(LPWSTR lp, int cchWideChar)
{
for(int i = 0; i < cchWideChar; i++)
lp[i] = ((lp[i] & 0xFF) << 8) | ((lp[i] & 0xFF00) >> 8);
}
Now your function can be used exactly like MultiByteToWideChar, including the option to query a buffer size, and with the same flexibility (i.e.: all the options in code page, flags, etc.) You can refer anyone to the documentation for MultiByteToWideChar and simply state that you add a BOM and convert the unicode string to big-endian.
Now suppose you want to provide a simplified version in which some of the options are filled with default values.
int MultiByteToBigEndianWideChar(
LPCSTR lpMultiByteStr,
LPWSTR lpWideCharStr,
int cchWideChar
)
{
return MultiByteToBigEndianWideChar(
CP_ACP,
MB_COMPOSITE,
lpMultiByteStr,
-1,
lpWideCharStr,
cchWideChar
);
}
There, now you only need to compile and test. Good luck!
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
I got the answer!!!
The reason is that when I change the ASCII character to big-endian, take 'B', with unicode \x42\x00, it become \x00\x42.
And I used strlen to check the string length of (char* UnicodeCharToBigEndianConverter(char* message)), which finds the terminating character \x00, and gives me the wrong string length!!
My code in the above post should be ok.
Anyone interested in have a look in it and test it.
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
