|
How To Getting Floppy Drive Type Information->[^]
"Every Little Smile can touch Somebody's Heart...
May we find Hundreds of Reasons to Smile Everyday... and
May WE be the Reason for someone else to smile always!" (ICAN)
"Your thoughts are the architects of your destiny."
|
|
|
|
|
VCProgrammer wrote: How can i find this??
How about something like:
bool isFloppyDevice( LPCTSTR lpszDevice )
{
TCHAR szBuffer[MAX_PATH];
bool bIsFloppy = false;
if (QueryDosDevice(lpszDevice, szBuffer, MAX_PATH) > 0)
bIsFloppy = (_tcsstr(_T("device\\floppy"), szBuffer) != NULL);
return bIsFloppy;
}A slightly longer way, although I cannot test it, might be:
bool isFloppyDevice( void )
{
bool bIsFloppy = false;
HANDLE hDevice = CreateFile(_T("\\\\.\\A:"),
0,
0,
NULL,
OPEN_EXISTING,
0,
NULL);
if (hDevice != INVALID_HANDLE_VALUE)
{
DISK_GEOMETRY dg;
DWORD dwBytesReturned;
bIsFloppy = (DeviceIoControl(hDevice,
IOCTL_DISK_GET_DRIVE_GEOMETRY,
NULL,
0,
&dg,
sizeof(dg),
&dwBytesReturned,
NULL) != FALSE);
CloseHandle(hDevice);
}
return bIsFloppy;
}
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Some people are making such thorough preparation for rainy days that they aren't enjoying today's sunshine." - William Feather
|
|
|
|
|
Hi:
I have a socket client running which has a char array of size 512 mentioned. I have a loop to receive the message from the server, when the loop exits I am getting the following error.
I also confirmed that the message I am receiving from the server is less than 200 characters in length.
Environment:
Windows 64bit.
VS 2010
Run-Time check failure #2 - Stack around the variable 'recMessage' was corrupted.
int STRLEN = 512;
char recMessage[STRLEN] = "0";
ClientSocket sockClient;
sockClient.ConnectToServer( ipAddress.c_str(), port );
sockClient.SendData("L|100=some_value;101=some_value\n");
sockClient.RecvData( recMessage, STRLEN );
int counter = 0
while(counter <= 10){
sockClient.RecvData( recMessage, STRLEN );
cout << recMessage << endl;
counter++;
}
memset(recMessage,0,sizeof(char)*STRLEN);
sockClient.CloseConnection();
</pre>
|
|
|
|
|
The code as you've posted looks okay.
It's probably something going wrong in the methods of the ClientSocket class.
|
|
|
|
|
I hope you already know this, but this:
int STRLEN = 512;
char recMessage[STRLEN] = "0";
Will not compile in C++.
This leads to the next question:
If you say the program crashes in runtime, how is the array really declared?
|
|
|
|
|
Actually it works, even though the initialization is quite probably not what it is intended to be. The string "0" is a char array of length 2, containing the 2 characters '0' and '\0' (==char(0)).
But then, the contents of this array are irrelevant as it's filled by RecvData() before it ever gets read.
I therefore suggest to just skip the initialization.
|
|
|
|
|
I'm not talking about the initialization part - I'm aware that it's quite legal.
The problem is that array declarations in C++ need constant size expressions. And this:
char recMessage[STRLEN]
is by all means an array declaration, where STRLEN is not a constant.
|
|
|
|
|
Ah, sry, I missed your point then.
I'm always a bit suspicious about forms of array initialization, so I automatically assumed that was what you're at.
Sure, the code is missing a const there, which makes me wonder if it has been compiled as C-code, rather than C++? But I wonder if it's even possible to compile the invocation of a socket object as C-code - I don't think it is...
|
|
|
|
|
It should still compile since the value of STRLEN is known at compile time.
|
|
|
|
|
Well, there's "should" and then there's the compiler itself.
int STRLEN = 512;
char recMessage[STRLEN] = "0";
1>c:\users\otoolec\documents\visual studio 2008\projects\test2\test2\test2.cpp(14) : error C2057: expected constant expression
1>c:\users\otoolec\documents\visual studio 2008\projects\test2\test2\test2.cpp(14) : error C2466: cannot allocate an array of constant size 0
Now add "const" and the following does compile:
const int STRLEN = 512;
char recMessage[STRLEN] = "0";
|
|
|
|
|
In fact it should not, as it would require the compiler to analyze the semantics of the code in order to make sure that the variable STRLEN is not being changed. Even though this could be done in an easy example like this, the syntax is just as wrong as a missed ';'. Have you ever seen a compiler insert a missing ';' for you, no matter how obvious the fix?
|
|
|
|
|
You're right. It would unnecessarily complicate things.
|
|
|
|
|
|
I'm not that familiar with the ClientSocket class but I have a few observations / questions.
1) Clearly you expect "recMessage" to be a null terminated string (you "cout" it)
2) Who puts the NULL character at the end of each message?
3) Your buffer is "STRLEN" characters long (assuming you fix the declaration), you tell RecvData to read "STRLEN" characters. Who accounts for the NULL? Either the buffer needs to be one character bigger or the RecvData should be for one character smaller.
4) there is nothing to indicate the length of the received message in that API so how do you know or verified that all messages are < 200 characters as you stated in another reply.
5) the memset at the end of the routine does nothing useful. While it looks OK, are you sure that statement is not causing the problem.
6) other folks have commented on the declaration "char recMessage[STRLEN]" where STRLEN is not a #define constant but a variable. I suspect this is not what is used in the actual compiled code.
|
|
|
|
|
|
Regarding 3) and the code you linked, you need to pass STRLEN-1 to the sub. RecvData takes a size (STRLEN in this case), passes it directly to recv() which returns in the variable i the amount of bytes read. Then buffer[i] is set to '\0'. Which means that in the second worst case you write size, so the 0-termination writes to index STRLEN, which means the buffer should be STRLEN+1 in size at least. In the worst case scenario, SOCKET_ERROR is returned from receive and you'll end up trying to write to buffer[-1]. So... please tell me that the code at the site is not what you are using... please.
|
|
|
|
|
Excellent point on the SOCKET_ERROR case and setting buffer[-1]. My 5
|
|
|
|
|
Good point, but you're addressing the wrong person. I was just assuming this is the implementation of Socket, but I haven't used Socket myself.
|
|
|
|
|
I am having a project which is for 32 bit platform.
I am adding 64 bit support also.
32 bit compilation is able to open & read registry while 64 bit compilation is not able to open registry.
I was opening HKEY_CLASSES_ROOT. I guess it might be related to permissions but I could not figure it out.
Even worse 64 bit compilation is not able to load swf while 32 compilation does it successfully.
Any guess why?
|
|
|
|
|
Is the program still running under 32 bits? It is possible then that the registry access worked, but was done on the HKEY_LOCAL_MACHINE\Software\WOW6432Node\Classes key (see MSDN[^].
For further information, check the return values from the registry function.
|
|
|
|
|
32 bit compilation works in both 32 bit & 64 bit. But I need a separate 64 bit edition so I am trying to do that. 64 bit runs but not able to open registry and swf. 64 bit compilation does not run on 32 bit
|
|
|
|
|
Could you debug through the 64 bit compilation and specifically post the return values from the registry functions, like RegCreateKeyEx (or RegOpenKeyEx) and also what the RegQueryValueEx function returns, and any other you are using in the particular piece of code that does not work.
It'd also help if you post your code. Without more information, we're flying blind here
|
|
|
|
|
Most likely the 32 bit EXE was given a local registry to play with, this is part of UAC legacy application handling.
The 64 bit EXE is not seen as a legacy application, and gets a proper slap on the fingers.
Usually it is during installation that one chooses what files should be opened with the application. Not something the application changes after installation.
|
|
|
|
|
I am confused with Imagelist_LoadBitmap. It certainly makes sense if we create an imagelist from ICON file(resource), because icon file can have multiple images.
But within Bitmap file, only one image can be contained. I wonder Imagelist_LoadBitmap always creates an imagelist initially with only one image contained?
|
|
|
|
|
When you create the image list, you specify the size of each image. LoadBitmap will divide the loaded image into appropriate sub-rectangles. The bitmap should contain properly sized images laid out horizontally.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
