I am trying to set up a mailslot that i can write to and read from.
But when calling ReadFile to i get error 87. I have tried different approaces from MSDN and i still get error 87.
I have removed a lot of error handling in my code in order to shorten it a bit.
This are calls i do from main.
hMailslot= mailslotCreate("\\\\.\\mailslot\\myslot"); //works
hMailslot=mailslotConnect("\\\\.\\mailslot\\myslot"); //works
mailslotWrite(hMailslot,w, lstrlen(w)+1)*sizeof(CHAR); //works
mailslotRead(hMailslot); //Error 87 invalid parameter
mailslotClose(hMailslot); //?
Here is a shortened version of my code.
#define TIME_OUT MAILSLOT_WAIT_FOREVER
HANDLE mailslotCreate (char *name) {
HANDLE H = (HANDLE)CreateMailslot(name,0,TIME_OUT,(LPSECURITY_ATTRIBUTES) NULL);
return H;
}
HANDLE mailslotConnect (char * name) {
HANDLE H = CreateFile(name,GENERIC_READ|GENERIC_WRITE,FILE_SHARE_READ,0,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
return H;
}
int mailslotWrite(HANDLE mailSlot,void *msg,int msgSize) {
DWORD cbWritten;
WriteFile(mailSlot, msg, msgSize, &cbWritten, (LPOVERLAPPED) NULL);
return cbWritten;
}
int mailslotRead (HANDLE mailbox) {
DWORD cbMessage, cMessage, cbRead;
BOOL fResult;
LPTSTR Message;
fResult =GetMailslotInfo(mailbox,(LPDWORD) NULL,&cbMessage,&cMessage,(LPDWORD)NULL);
if (!fResult) //Works
{
printf("GetMailslotInfo failed with %d.\n", GetLastError());
}
Message = (LPTSTR) calloc(cbMessage,sizeof(char));
Message[0] = '\0';
fResult = ReadFile((HANDLE)mailbox,(LPVOID)Message,(DWORD)cbMessage,LPDWORD)&cbRead,(LPOVERLAPPED) NULL);
if (!fResult) //Error 87
{
printf("ReadFile failed with %d.\n", GetLastError());
free(Message);
return 0;
}
return cbRead;
}
int mailslotClose(HANDLE mailSlot){
return CloseHandle(mailSlot);
}
As per Microsoft, Error 87 is ERROR_INVALID_PARAMETER from ReadFile() or WriteFile()
So something is wrong with those parameters.
Also from MS: CreateMailSlot(), CreateFile() and ReadFile() definition
I've been looking at Using Mailslots and trying to compare it to what you have. About the only difference I can see is that even though they create the file with FILE_ATTRIBUTE_NORMAL, and write to it with (LPOVERLAPPED) NULL, they still supply an OVERLAPPED ov when reading the file - even though their documentation says that it is not required.
However I don't know enough to know if that is the actual issue
Related
I use this function as usual, but the debug traces (OutputDebugString) don't work from injecting dlls. And in the target application no thread is created (I look through the process hacker)
GetlastError says 0
CreateRemoteThread says tid
but WaitForSingleObject exits immediately (why if all ok!?)
... I'm confused %
OS windows 10 x64
app and dll - x86
code dll is:
#include <stdio.h>
#include <windows.h>
WINAPI DllMain(HINSTANCE h, DWORD reason, LPVOID res)
{
CHAR pszMessage[1024] = { 0 };
sprintf(pszMessage, ("L2Proj: GetCurrentProcessId() %d, hModule 0x%p, nReason %d\r\n"), GetCurrentProcessId(), h, reason);
OutputDebugString(pszMessage);
switch(reason) {
case DLL_PROCESS_ATTACH:
//MessageBoxA(NULL, "inject success", "done", MB_OK);
TerminateProcess(GetCurrentProcess(), -1);
break;
}
return TRUE;
}
PS TerminateProcess in dll doesn't work either
PPS GetExitCodeThread() after WaitForSingleObject ends is 0
What it the problem with?
ADDED
APP code is:
NOTE: This is just test code (no control over return values / wrong label name codestyle etc.), pls do not tell me about it.
I wrote step by step in the comments which functions return which values
// process of course has access
HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, entry.th32ProcessID);
// handle is valid
if(!hProcess) {
return GetLastError();
}
DWORD id;
char str[] = "G:\\workspace\\proj\\test.dll";
void *l = (void*)GetProcAddress(
GetModuleHandle("kernel32.dll"), "LoadLibraryA");
// addr is valid
if(!l) {
return 35;
}
DWORD str_size = strlen(str) + 1;
// memory addr is valid
LPVOID lp = VirtualAllocEx(hProcess, NULL, str_size, MEM_COMMIT |
MEM_RESERVE, PAGE_READWRITE);
BOOL res = WriteProcessMemory(hProcess, lp, str, str_size, NULL);
// res is true
HANDLE h = CreateRemoteThread(hProcess,
NULL,
0,
(LPTHREAD_START_ROUTINE)l,
lp,
0,
&id);
// handle is valid
// id is valid (tid remote thread)
if(!h) {
return GetLastError();
}
DWORD err = GetLastError();
CHAR pszMessage[1024] = { 0 };
sprintf(pszMessage, ("L2Proj: GetProcessId() %d\r\n"), id);
OutputDebugString(pszMessage);
// ends immediately (no waiting)
WaitForSingleObject(h, INFINITE);
GetExitCodeThread(h, &id);
//id is 0 (exit code)
sprintf(pszMessage, ("L2Proj: GetExitCodeThread() %d (GetLastError=%d)\r\n"), id, err);
OutputDebugString(pszMessage);
// the only error after this function (VirtualFreeEx)
// GetLastError gives 87 (0x57) - ERROR_INVALID_PARAMETER
VirtualFreeEx(hProcess, lp, 0, MEM_RELEASE);
CloseHandle(h);
CloseHandle(hProcess);
I forgot, i use g++ (GCC) 9.3.0 - maybe the problem is because of this?
I solved the problem, just change the compiler.
Yes, the problem was with the compiler, everything works fine on the Microsoft compiler.
Thanks for answers.
problem in you not use debugger – RbMm yesterday
and yes, I always use the debugger, thanks a lot ...
When I run this with gcc using code:blocks, it creates the registration.txt on F if it doesn't exist and writes the password and username, but when I use this in my project using Microsoft Visual Studio's compiler it does nothing.
For example if I call this function such as: Write("JohnDoe", "password123"),
in the file registration.txt should appear in a line: JohnDoe, password123.
const char *FILEPATH = "F:\\registration.txt";
int Write(char *username, char *password) {
if (username == NULL || password == NULL) {
return -1;
}
BOOL error = TRUE;
size_t lengthUsername = strlen(username);
size_t lengthPassword = strlen(password);
LPDWORD bytesUsernameWritten = 0;
char comma[2] = ",";
char newLine[3] = "\r\n";
LPDWORD bytesPasswordWritten = 0;
LPDWORD bytesWrittenComma = 0;
//if the file doesn't exist, we create it
HANDLE file = CreateFile((LPCWSTR)FILEPATH, FILE_APPEND_DATA, FILE_SHARE_READ, NULL, CREATE_NEW, FILE_ATTRIBUTE_NORMAL, NULL);
if (file == INVALID_HANDLE_VALUE) {
if (GetLastError() != ERROR_FILE_EXISTS) {
printf("0x%x", GetLastError());
CloseHandle(file);
return -1;
} //the file exist, we try to create it
file = CreateFile((LPCWSTR)FILEPATH, FILE_APPEND_DATA, FILE_SHARE_READ, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, NULL);
if (file == INVALID_HANDLE_VALUE) {
printf("Couldn't open the file. Error : 0x%x", GetLastError());
CloseHandle(file);
return -1;
}
}
//We try to write the username and the password in file, each combination on each line, in this format: username, password
error = WriteFile(file, username, (DWORD)lengthUsername, bytesUsernameWritten, NULL);
if (error == FALSE) {
printf("The username couldn't have been written. Error 0x%x\n", GetLastError());
CloseHandle(file);
return -1;
}
error = WriteFile(file, comma, 1, bytesWrittenComma, NULL);
if (error == FALSE) {
printf("The comma couldn't have been written. Error 0x%x\n", GetLastError());
CloseHandle(file);
return -1;
}
error = WriteFile(file, password, (DWORD)lengthPassword, bytesPasswordWritten, NULL);
if (error == FALSE) {
printf("The password couldn't have been written. Error 0x%x\n", GetLastError());
CloseHandle(file);
return -1;
}
error = WriteFile(file, newLine, 2, bytesPasswordWritten, NULL);
if (error == FALSE) {
printf("The endline couldn't have been written. Error 0x%x\n", GetLastError());
CloseHandle(file);
return -1;
}
CloseHandle(file);
return 0;
}
Your main problem is confusion between using Unicode and ASCII.
All windows API functions that take string parameters have two versions:
One that works with LPCSTR and one that works with LPCWSTR.
You can cast char * to LPCSTR and use the ASCII version CreateFileA, but you can not cast it to LPCWSTR and use the CreateFileW - the Unicode version of CreateFile as it expects strings in UCS-16 encoding where each character takes 2 bytes.
Which version of the function is called depends on a compiler flag. For CodeBlocks on Windows the default is to use ASCII versions, so your function works.
For VS the default is Unicode, so the file path string gets messed up and the file is not created.
Also, you have two other erros:
You are using WriteFile incorrectly.
The 4th parameter is a pointer, where WriteFile stores number of bytes written.
You are passing a NULL pointer, because you set variables such as bytesUsernameWritten to 0. But according to MS documentation, you can only use NULL there if the last parameter, lpOverlapped is not NULL.
What you should do, is declare bytesUsernameWritten to be DWORD and pass its address using & operator.
Otherwise, even if the function creates the file successfully, you will not get the number of bytes that were written.
You are trying to close INVALID_HANDLE_VALUE
This is unnecessary, but fortunately it should not crash you program.
Finally, there is no reason to try to call CreateFile twice.
Just use one call with OPEN_ALWAYS parameter.
This will open an existing file, but if the file does not exist it will create it automatically instead of failing.
Since the latest Windows 10 1809 update we can no longer open a USB HID keyboard-like device of ours using CreateFile. We reduced the problem to this minimal example:
#include <windows.h>
#include <setupapi.h>
#include <stdio.h>
#include <hidsdi.h>
void bad(const char *msg) {
DWORD w = GetLastError();
fprintf(stderr, "bad: %s, GetLastError() == 0x%08x\n", msg, (unsigned)w);
}
int main(void) {
int i;
GUID hidGuid;
HDEVINFO deviceInfoList;
const size_t DEVICE_DETAILS_SIZE = sizeof(SP_DEVICE_INTERFACE_DETAIL_DATA) + MAX_PATH;
SP_DEVICE_INTERFACE_DETAIL_DATA *deviceDetails = alloca(DEVICE_DETAILS_SIZE);
deviceDetails->cbSize = sizeof(*deviceDetails);
HidD_GetHidGuid(&hidGuid);
deviceInfoList = SetupDiGetClassDevs(&hidGuid, NULL, NULL,
DIGCF_PRESENT | DIGCF_INTERFACEDEVICE);
if(deviceInfoList == INVALID_HANDLE_VALUE) {
bad("SetupDiGetClassDevs");
return 1;
}
for (i = 0; ; ++i) {
SP_DEVICE_INTERFACE_DATA deviceInfo;
DWORD size = DEVICE_DETAILS_SIZE;
HIDD_ATTRIBUTES deviceAttributes;
HANDLE hDev = INVALID_HANDLE_VALUE;
fprintf(stderr, "Trying device %d\n", i);
deviceInfo.cbSize = sizeof(deviceInfo);
if (!SetupDiEnumDeviceInterfaces(deviceInfoList, 0, &hidGuid, i,
&deviceInfo)) {
if (GetLastError() == ERROR_NO_MORE_ITEMS) {
break;
} else {
bad("SetupDiEnumDeviceInterfaces");
continue;
}
}
if(!SetupDiGetDeviceInterfaceDetail(deviceInfoList, &deviceInfo,
deviceDetails, size, &size, NULL)) {
bad("SetupDiGetDeviceInterfaceDetail");
continue;
}
fprintf(stderr, "Opening device %s\n", deviceDetails->DevicePath);
hDev = CreateFile(deviceDetails->DevicePath, 0,
FILE_SHARE_READ | FILE_SHARE_WRITE, NULL,
OPEN_EXISTING, 0, NULL);
if(hDev == INVALID_HANDLE_VALUE) {
bad("CreateFile");
continue;
}
deviceAttributes.Size = sizeof(deviceAttributes);
if(HidD_GetAttributes(hDev, &deviceAttributes)) {
fprintf(stderr, "VID = %04x PID = %04x\n", (unsigned)deviceAttributes.VendorID, (unsigned)deviceAttributes.ProductID);
} else {
bad("HidD_GetAttributes");
}
CloseHandle(hDev);
}
SetupDiDestroyDeviceInfoList(deviceInfoList);
return 0;
}
It enumerates all HID devices, trying to obtain the vendor ID/product ID for each one using CreateFile over the path provided by SetupDiGetDeviceInterfaceDetail and then calling HidD_GetAttributes.
This code runs without problems on previous Windows versions (tested on Windows 7, Windows 10 1709 and 1803, and the original code from which this was extracted works since always from XP onwards), but with the latest update (1809) all keyboard devices (including ours) cannot be opened, as CreateFile fails with access denied (GetLastError() == 5). Running the program as administrator doesn't have any effect.
Comparing the output before and after the update, I noticed that the devices that now cannot be opened gained a trailing \kbd in the device path, i.e. what previously was
\\?\hid#vid_24d6&pid_8000&mi_00#7&294a3305&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
now is
\\?\hid#vid_24d6&pid_8000&mi_00#7&294a3305&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}\kbd
Is it a bug/new security restriction in the latest Windows 10 version? Was this code always wrong and it worked by chance before? Can this be fixed?
Update
As a desperate attempt, we tried to remove the \kbd from the returned string... and CreateFile now works! So, now we have a workaround, but it would be interesting to understand if that's a bug in SetupDiGetDeviceInterfaceDetail, if it's intentional and if this workaround is actually the correct thing to do.
I think this is a new security restriction in the latest Windows 10 version.
I looked for the string KBD (in UTF-16 format) - it exists only in two drivers in version 1809, hidclass.sys and kbdhid.sys, and doesn't exist in version 1709.
In hidclass.sys they changed the HidpRegisterDeviceInterface function. Before this release it called IoRegisterDeviceInterface with GUID_DEVINTERFACE_HID and the ReferenceString pointer set to 0. But in the new version, depending on the result of GetHidClassCollection, it passes KBD as ReferenceString pointer.
Inside kbdhid.sys they changed KbdHid_Create, and here is a check for the KBD string to return errors (access denied or sharing violation).
To understand more exactly why, more research is needed. Some disasm:
For reference, HidpRegisterDeviceInterface from 1709 build
here ReferenceString == 0 always (xor r8d,r8d), and there's no check cmp word [rbp + a],6 on class collection data
However, KbdHid_Create in 1809 contains a bug. The code is:
NTSTATUS KbdHid_Create(PDEVICE_OBJECT DeviceObject, PIRP Irp)
{
//...
PIO_STACK_LOCATION IrpSp = IoGetCurrentIrpStackLocation(Irp);
if (PFILE_OBJECT FileObject = IrpSp->FileObject)
{
PCUNICODE_STRING FileName = &FileObject->FileName;
if (FileName->Length)
{
#if ver == 1809
UNICODE_STRING KBD = RTL_CONSTANT_STRING(L"KBD"); // !! bug !!
NTSTATUS status = RtlEqualUnicodeString(FileName, &KBD, FALSE)
? STATUS_SHARING_VIOLATION : STATUS_ACCESS_DENIED;
#else
NTSTATUS status = STATUS_ACCESS_DENIED;
#endif
// log
Irp->IoStatus.Status = status;
IofCompleteRequest(Irp, IO_NO_INCREMENT);
return status;
}
}
// ...
}
What it this function trying to do here? It looks for passed PFILE_OBJECT FileObject from Irp current stack location. It no FileObject is provided or it has an empty name, allow open; otherwise, the open fails.
Before 1809 it always failed with error STATUS_ACCESS_DENIED (0xc0000022), but starting from 1809, the name is checked, and if it's equal to KBD (case sensitive) another error - STATUS_SHARING_VIOLATION is returned. However, name always begins with the \ symbol, so it will never match KBD. It can be \KBD, so, to fix this check, the following line needs to be changed to:
UNICODE_STRING KBD = RTL_CONSTANT_STRING(L"\\KBD");
and perform the comparison with this string. So, by design we should have got a STATUS_SHARING_VIOLATION error when trying to open a keyboard device via *\KBD name, but due to an implementation error we actually got STATUS_ACCESS_DENIED here
Another change was in HidpRegisterDeviceInterface - before the call to IoRegisterDeviceInterface on the device it queries the GetHidClassCollection result, and if some WORD (2 byte) field in the structure is equal to 6, adds KBD suffix (ReferenceString). I guess (but I'm not sure) that 6 can be the Usage ID for keyboard, and the rationale for this prefix is to set Exclusive access mode
Actually, we can have a FileName begin without \ if we use relative device open via OBJECT_ATTRIBUTES. So, just for test, we can do this: if the interface name ends with \KBD, first open the file without this suffix (so with empty relative device name), and this open must work ok; then, we can try relative open file with name KBD - we must get STATUS_SHARING_VIOLATION in 1809 and STATUS_ACCESS_DENIED in previous builds (but here we will be have no \KBD suffix):
void TestOpen(PWSTR pszDeviceInterface)
{
HANDLE hFile;
if (PWSTR c = wcsrchr(pszDeviceInterface, '\\'))
{
static const UNICODE_STRING KBD = RTL_CONSTANT_STRING(L"KBD");
if (!wcscmp(c + 1, KBD.Buffer))
{
*c = 0;
OBJECT_ATTRIBUTES oa = { sizeof(oa), 0, const_cast<PUNICODE_STRING>(&KBD) };
oa.RootDirectory = CreateFileW(pszDeviceInterface, 0,
FILE_SHARE_VALID_FLAGS, 0, OPEN_EXISTING, 0, 0);
if (oa.RootDirectory != INVALID_HANDLE_VALUE)
{
IO_STATUS_BLOCK iosb;
// will be STATUS_SHARING_VIOLATION (c0000043)
NTSTATUS status = NtOpenFile(&hFile, SYNCHRONIZE, &oa, &iosb,
FILE_SHARE_VALID_FLAGS, FILE_SYNCHRONOUS_IO_NONALERT);
CloseHandle(oa.RootDirectory);
if (0 <= status)
{
PrintAttr(hFile);
CloseHandle(hFile);
}
}
return ;
}
}
hFile = CreateFileW(pszDeviceInterface, 0,
FILE_SHARE_VALID_FLAGS, 0, OPEN_EXISTING, 0, 0);
if (hFile != INVALID_HANDLE_VALUE)
{
PrintAttr(hFile);
CloseHandle(hFile);
}
}
void PrintAttr(HANDLE hFile)
{
HIDD_ATTRIBUTES deviceAttributes = { sizeof(deviceAttributes) };
if(HidD_GetAttributes(hFile, &deviceAttributes)) {
printf("VID = %04x PID = %04x\r\n",
(ULONG)deviceAttributes.VendorID, (ULONG)deviceAttributes.ProductID);
} else {
bad(L"HidD_GetAttributes");
}
}
In a test on 1809 I actually got STATUS_SHARING_VIOLATION, that also shows another bug in kbdhid.KbdHid_Create - if we check FileName, we need to check RelatedFileObject - is it 0 or not.
Also, not related to bug, but as suggestion: it is more efficient to use CM_Get_Device_Interface_List instead of the SetupAPI:
volatile UCHAR guz = 0;
CONFIGRET EnumInterfaces(PGUID InterfaceClassGuid)
{
CONFIGRET err;
PVOID stack = alloca(guz);
ULONG BufferLen = 0, NeedLen = 256;
union {
PVOID buf;
PWSTR pszDeviceInterface;
};
for(;;)
{
if (BufferLen < NeedLen)
{
BufferLen = RtlPointerToOffset(buf = alloca((NeedLen - BufferLen) * sizeof(WCHAR)), stack) / sizeof(WCHAR);
}
switch (err = CM_Get_Device_Interface_ListW(InterfaceClassGuid,
0, pszDeviceInterface, BufferLen, CM_GET_DEVICE_INTERFACE_LIST_PRESENT))
{
case CR_BUFFER_SMALL:
if (err = CM_Get_Device_Interface_List_SizeW(&NeedLen, InterfaceClassGuid,
0, CM_GET_DEVICE_INTERFACE_LIST_PRESENT))
{
default:
return err;
}
continue;
case CR_SUCCESS:
while (*pszDeviceInterface)
{
TestOpen(pszDeviceInterface);
pszDeviceInterface += 1 + wcslen(pszDeviceInterface);
}
return 0;
}
}
}
EnumInterfaces(const_cast<PGUID>(&GUID_DEVINTERFACE_HID));
The fix is in this windows update released today (March 1, 2019).
https://support.microsoft.com/en-us/help/4482887/windows-10-update-kb4482887
You can find a workaround at Delphi-Praxis in German
For short: Change in the Unit JvHidControllerClass
if not HidD_GetAttributes(HidFileHandle, FAttributes) then
raise EControllerError.CreateRes(#RsEDeviceCannotBeIdentified);
to
HidD_GetAttributes(HidFileHandle, FAttributes);
and recompile the Delhi JCL and JCVL Components by running the JEDI Install EXE.
I have written a C library function, but the return value seems to be incorrect, even though it is correct in the function.
Here is relevant code:
(In dcml_private.c) The offending function:
dcml_status _dcml_get_status(struct dcml_device *dev)
{
uint64_t data;
dcml_status ret;
int len;
libusb_bulk_transfer(dev->handle,
DCML_ENDPOINT | LIBUSB_ENDPOINT_IN,
(unsigned char *) &data,
DCML_REPORT_SZ, &len, RX_TIMEOUT);
printf("data = %ld\n", data);
if (len != DCML_REPORT_SZ)
printf("DCML: LIBUSB ERROR (%s)\n", libusb_error_name(len));
return STATUS_UNKNOWN;
ret = data & ~(1>>17);
return (ret);
}
The calling function:
void _dcml_cmd(dcml_context *ctx, dcml_cmd cmd,
dcml_status quit_cond, int dur)
{
struct timeval start;
struct timeval cur;
uint32_t stat;
(void)gettimeofday(&start, NULL);
(void)gettimeofday(&cur, NULL);
_dcml_send_cmd(ctx->active, cmd);
while(difftimeval(cur, start) < dur) {
sleep(POLL_PERIOD);
stat = _dcml_get_status(ctx->active);
printf("status (%d), quit_cond (%d)", stat, quit_cond);
if (stat == quit_cond)
break;
(void)gettimeofday(&cur, NULL);
}
_dcml_send_cmd(ctx->active, CMD_NONE);
}
As you see, I have print statements in my functions. In _dcml_cmd, typical output of that print statement would be
status (65535), quit_cond (2048)
Where _dcml_get_status prints:
data = 128
What this means is that the return value is correct IMMEDIATELY before exiting _dcml_get_status,
but incorrect immediately after it is return to the calling function (and always has a value of 65535 here...)
It's probably helpful to know that "dmcl_status" is an enum. Switching the return type to uint16_t does not fix the issue. I thought it might be an overflow issue or something, but changing types, explicit casts and adding a mask line doesn't fix it.
Any thoughts?
It's because you have a bad habit of not putting { } after your if statements ALWAYS
if (len != DCML_REPORT_SZ) {
printf("DCML: LIBUSB ERROR (%s)\n", libusb_error_name(len));
return STATUS_UNKNOWN;
}
also use fprintf(stderr,... to dump out errors. Sending errors to printf is bad practice:
if (len != DCML_REPORT_SZ) {
fprintf(stderr, "DCML: LIBUSB ERROR (%s)\n", libusb_error_name(len));
return STATUS_UNKNOWN;
}
The calling function has the same issues around:
printf("status (%d), quit_cond (%d)", stat, quit_cond);
if (stat == quit_cond)
break;
Use:
fprintf(stderr, "status (%d), quit_cond (%d)", stat, quit_cond);
if (stat == quit_cond) {
break;
}
Yes it uses up an extra line but darn it at 3:00AM when you are debugging this by adding fprintfs all over the place it won't break your logic. :^)
I am studing serial communication with win32 using C now. reading from serial port is given as below.
DWORD dwEventMask;
DWORD dwSize;
if(!SetCommMask(hSerial, EV_RXCHAR)){
//Error handling
printf("Error Setting Comm Mask \n");
}
if(WaitCommEvent(hSerial, &dwEventMask, NULL))
{
unsigned char szBuf[1024];
DWORD dwIncommingReadSize;
do
{
if(ReadFile(hSerial, &szBuf, 1, &dwIncommingReadSize, NULL) != 0) {
//Handle Error Condition
}
if(dwIncommingReadSize > 0)
{
dwSize += dwIncommingReadSize;
sb.sputn(&szBuf, dwIncommingReadSize);
printf("Reading from port \n");
}
else{
//Handle Error Condition
}
printf("Reading data from port \n");
} while(dwIncommingReadSize > 0);
}
else
{
//Handle Error Condition
}
They have used DWORD dwIncommingReadSize for while condition (while(dwIncommingReadSize > 0);.
Please explain how this condition is satifisfied. No modification can be seen for that.
Again please explain following part.
if(dwIncommingReadSize > 0)
{
dwSize += dwIncommingReadSize;
sb.sputn(&szBuf, dwIncommingReadSize);
printf("Reading from port \n");
}
This line:
if(ReadFile(hSerial, &szBuf, 1, &dwIncommingReadSize, NULL)
passes the address of dwIncommingReadSize (however badly spelt it may be) to the function so it can change it to whatever it wants.
It's similar to:
void fn (int *x) { *x = 42; }
:
int xyzzy = 1;
fn (&xyzzy);
// Here, xyzzy is now 42.
In terms of your second question, it's a little hard to tell without seeing more of the code, but it looks like it's simply increasing a "total size" variable for each block of data read in (plus whatever sb.sputn is supposed to do).
This is typical where a single read may not get all the data you want - you simply store what you got and then go back for more.