[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-smartcardddk
Subject:    [Q] addendum to IOCTL_SMARTCARD_EJECT problem
From:       Vladimir Beker <bwz () ARX ! COM>
Date:       1999-07-19 17:35:21
[Download RAW message or body]


I think I found something that can be related to the IOCTL_SMARTCARD_EJECTED
problem I described before.
(Klaus, I think it is for you)

As I can see, my driver is aksed for reader's mechanical capabilities, but
the answer, supplied by
SmartcardDeviceControl is wrong. Definitely, this function should use the
READER_CAPABILITIES filled by me
upon SmartcardInitialize.
And here is a mystery.
In SMCLIB.H file (dated Apr 22) this structure looks as following (I
represent only the beginning, since the rest
is not relevant):
        ULONG SupportedProtocols;
        ULONG Reserved;
        ULONG ReaderType;
        ULONG MechProperties; // = 0;
        ULONG CurrentState;
so MechProperties is 4th ULONG from the beginning of structure.
In documentation, however, it looks as
        struct {
                ULONG Async;
                ULONG Sync;
        } SupportedProtocols;
        ULONG ReaderType;
        ULONG Reserved;
        ULONG MechProperties; // = 0;
        ULONG CurrentState;
so MechProperties is the 5th ULONG.

The doc and H are taken from the same DDK (April 99 Beta3) - the last one I
found on the Microsoft site.
(SMCLIB.LIB is dates as Apr 01(seems to be less important)

The Win2000 (build 2031) has SMCLIB.SYS dated Apr 26.

If The 5th field (CurrentState) is misinterpreted as MechProperties it could
explain the problem (since it is non-zero).

So the question is: whether I am right and how to go out of this circle?

Thanks
Vladimir

[prev in list] [next in list] [prev in thread] [next in thread]