E
Eddie
Hello.
I encountered the following bugs the USB HID driver.
I'd be happy to see a reply from MS.
1) Reports are lost:
When there are several reports waiting in the driver's
buffer, and the application is reading them one at a time -
some reports are lost. the lost reports are usually
reports number 3,5,7 etc. (1 based).
2) COMMTIMEOUTS doesn't work.
When calling SetCommTimeouts() and then ReadFile() with no
OVERLAPPED - the ReadFile() doesn't return even after the
timeout should have elapsed (unless of-course if all the
requested data was received).
3) (Design Bug) There is no Peek() function:
The application cannot know how many bytes are available
for reading. It has to call ReadFile().
When the application calls ReadFile() and there is no data
available - ReadFile() will either block (if it has no
OVERLAPPED) or stay pending (if it does have OVERLAPPED).
There is no mode of ReadFile() that returns immediately
and Cleanly when there are no available data.
*) The result of (2)+(3) is Pending ReadFile() calls.
- This is a problem when programming in .NET because the
garbage collector moves the target array around without
updating the pointer given to the pending ReadFile(). When
data does arrive - it is written to the old location which
is now used for other data. This usually crashs the system.
*) CancelIo() stops pending calls to ReadFile() but it
takes 15 ms to complete which is too much for my
application.
*) Using 'fixed' pointers to solve that is problematic:
- My application is actually a communications class.
- The target array for A-Synchronic ReadFile() should
remain 'fixed' throughout the life of the class - from
Construction till Dispose().
- 'fixed' statements are only valid during the 'fixed'
statement block. Of-Course there's a good reason for that -
'fixed' pointers cause the Heap to be defragmented.
- My communications class can have multiple instances -
which may create more defragmentation.
Best Regards,
Eddie.
I encountered the following bugs the USB HID driver.
I'd be happy to see a reply from MS.
1) Reports are lost:
When there are several reports waiting in the driver's
buffer, and the application is reading them one at a time -
some reports are lost. the lost reports are usually
reports number 3,5,7 etc. (1 based).
2) COMMTIMEOUTS doesn't work.
When calling SetCommTimeouts() and then ReadFile() with no
OVERLAPPED - the ReadFile() doesn't return even after the
timeout should have elapsed (unless of-course if all the
requested data was received).
3) (Design Bug) There is no Peek() function:
The application cannot know how many bytes are available
for reading. It has to call ReadFile().
When the application calls ReadFile() and there is no data
available - ReadFile() will either block (if it has no
OVERLAPPED) or stay pending (if it does have OVERLAPPED).
There is no mode of ReadFile() that returns immediately
and Cleanly when there are no available data.
*) The result of (2)+(3) is Pending ReadFile() calls.
- This is a problem when programming in .NET because the
garbage collector moves the target array around without
updating the pointer given to the pending ReadFile(). When
data does arrive - it is written to the old location which
is now used for other data. This usually crashs the system.
*) CancelIo() stops pending calls to ReadFile() but it
takes 15 ms to complete which is too much for my
application.
*) Using 'fixed' pointers to solve that is problematic:
- My application is actually a communications class.
- The target array for A-Synchronic ReadFile() should
remain 'fixed' throughout the life of the class - from
Construction till Dispose().
- 'fixed' statements are only valid during the 'fixed'
statement block. Of-Course there's a good reason for that -
'fixed' pointers cause the Heap to be defragmented.
- My communications class can have multiple instances -
which may create more defragmentation.
Best Regards,
Eddie.