It's a 64-bit error where the decoded error code is sign extended by the shift
operation and no longer equals to the value of the corresponding define.

unsigned char << something

is an int. Casted to a long in the assignment will sign extend resulting in
0xffffffff8010000, which != 0x8010000.

One possible patch, but other alternatives is also possible. Should be decided
if these values is signed or unsigned.

It's worth noting that the same error may bite other parts of the code as well.

D32: 99_gnupg-2.0.0-64biterror.patch

The long is due to the PC/SC specs. In fact Windows 64 bit won't get into
trouble because a long is there still 32 bits. To avoid type mismatches I have
done another patch using a masking approach. Please try it.

D31: 100_apdu-patch-2.0.0.diff

With err being long there is still signedness mismatch on 32-bit platforms.

#define PCSC_E_NO_SMARTCARD 0x8010000C

is an unsigned int (constant, does not fit in int so it's an unsigned int).

then in the expression which was the culpit you have

if (err == PCSC_E_NO_SMARTCARD)

where err is an long, and PCSC_E_NO_SMARTCARD) is an unsigned int too large for
a 32-bit long..

and this is a somewhat dangerous borderline to work on wrt sign extension..

But both patches works fine here on 64-bit.

Looks like a small BTS bug showed it's ugly face there. The only possible choice
in "Assignet To" for me is "- no selection -" and is set by default, which
removed the existing assignment set by werner..

Thanks for noting the problem with assigned to.

Fixed in SVN. Will go into 2.0.1