[ rdesktop-Bugs-2897269 ] SCARD_E_UNSUPPORTED_FEATURE has a different value

Bugs item #2897269, was opened at 2009-11-13 15:44
Message generated for change (Comment added) made by ludov
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=381347&aid=2897269&group_id=24366

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Internals
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ludovic Rousseau (ludov)
Assigned to: Nobody/Anonymous (nobody)
Summary: SCARD_E_UNSUPPORTED_FEATURE has a different value

Initial Comment:
SCARD_E_UNSUPPORTED_FEATURE has not the same value on Windows winscard and pcsc-lite

Windows has:
#define SCARD_E_UNSUPPORTED_FEATURE 0x80100022
#define SCARD_E_UNEXPECTED 0x8010001F

pcsc-lite has:
#define SCARD_E_UNSUPPORTED_FEATURE 0x8010001F
#define SCARD_E_UNEXPECTED 0x8010001F

Yes, the same value is used for two different names. This is an historic issue.

pcsc-lite never returns SCARD_E_UNEXPECTED so when 0x8010001F is returned it is in fact SCARD_E_UNSUPPORTED_FEATURE.
And this SCARD_E_UNSUPPORTED_FEATURE (0x8010001F) should be converted to a Windows SCARD_E_UNSUPPORTED_FEATURE (0x80100022) by rdekstop. Otherwise the Windows application will get a SCARD_E_UNEXPECTED (0x8010001F) when a SCARD_E_UNSUPPORTED_FEATURE is expected (0x80100022).

I have no patch to provide. My previous patch (in bug 2864500) has not yet been committed so I do not plan to work on a patch for nothing.

----------------------------------------------------------------------

>Comment By: Ludovic Rousseau (ludov)
Date: 2009-11-25 18:29

Message:
The PC/SC workgroup is a joke. They do not specify a reference
implementation at all. For example they define (in part 5) a
EstablishContext() method that is implemented as SCardEstablishContext() in
pcsc-lite and Windows. Not defining the real value of a symbol is another
joke. And I could continue.

Regarding the future, I do not plan to change the value
SCARD_E_UNSUPPORTED_FEATURE ever. That is why I ask rdekstop (and Citrix
client) to do the conversion.

I do not use rdekstop myself but I am very happy a free software like that
exists.

----------------------------------------------------------------------

Comment By: jared jennings (sarynx)
Date: 2009-11-25 17:53

Message:
> The problem is not with the API but with the ABI.

I think what you're saying is that the API says you should use the word
SCARD_E_UNSUPPORTED_FEATURE in your program, and the exact number compiled
into your program as a result is a matter of implementation. - Ah, indeed,
here's the bit from the PC/SC standard.

http://www.pcscworkgroup.com/specifications/files/pcsc5_v2.01.01.pdf -
Sec. 3.1.4: "The following table lists the defined RESPONSECODE data types.
For the purposes of defining the Resource Manager interface, these are
defined by symbol only. It is the responsibility of the implementers to
assign specific manifest constants suitable for use within their
environment."

In other words, SCARD_E_UNSUPPORTED_FEATURE (for example) means whatever
number you defined when I'm talking to pcsc-lite, and it means whatever
number Microsoft defined when I'm talking to the terminal server. You could
erase this distinction, but the number you defined is already compiled into
a bunch of applications, and the standard does not compel you to change
anything.

Fine, I'll patch rdesktop, but I don't have to like it. As the author of
pcsc-lite, it's your unique opportunity to make bold changes that break
things now in the name of better interoperability and simpler software down
the road. Distro maintainers and admins can buffer users against that
change, providing the required amount of stability. They can preserve the
past, but only you can drive the future.

And when that future finally comes, we'll add another #ifdef
PCSC_1_6_12_OR_NEWER to rdesktop, with a comment saying, "Yes, the same
value used to be used for two different names. This is an historic issue."

----------------------------------------------------------------------

Comment By: Ludovic Rousseau (ludov)
Date: 2009-11-25 13:38

Message:
The problem is not with the API but with the ABI.

The only application impacted by this ABI difference is rdesktop (and
Citrix client and clones).

If I change the definition of SCARD_E_UNSUPPORTED_FEATURE I will break the
ABI and then break many applications. For now only rdekstop (and Citrix) is
broken. If no one complained yet maybe that is not a real problem.

The bug report is just to let you and your users know it is a known bug.

----------------------------------------------------------------------

Comment By: jared jennings (sarynx)
Date: 2009-11-13 16:05

Message:
> "My previous patch has not yet been committed so I do not plan to work on
a patch for nothing."

There's no need for brinksmanship. rdesktop goes pretty slowly, especially
compared to pcsc-lite.

Why can't you change pcsc-lite? As far as you've described, it isn't
conforming to the PC/SC API definition. Why should rdesktop work around its
brokenness? I looked on your API page at the known differences with Windows
and this doesn't appear to be one of them.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=381347&aid=2897269&group_id=24366

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july