[ rdesktop-Bugs-2897269 ] SCARD_E_UNSUPPORTED_FEATURE has a different value
"SourceForge.net" <[email protected]>
| Newsgroups | gmane.network.rdesktop.devel |
|---|---|
| Message-ID | <[email protected]> |
Bugs item #2897269, was opened at 2009-11-13 09:44 Message generated for change (Comment added) made by sarynx 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: jared jennings (sarynx) Date: 2009-11-25 11: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 07: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 10: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