Hi,
Yes, it does work in effect, at the end of the day to avoid breaking binary
compatibility you either need to rebuild a new version of pcsclite with the
correct DWORD, or else fool somebody. Both Sun/Solaris and Apple/MacOSX have
explicitly changed their type from "DWORD" to a different type, at times
"unsigned long" and at others "uint32_t". Remember this is code used when
building a client app using existing 64bit binaries, not the code building
PCSClite itself.
I enclose an example from my code as follows, the macro
"HAVE_WINSCARD_UNSIGNED_LONG" is enabled by a "configure" test.
/************************************************************************/
#ifdef HAVE_WINSCARD_UNSIGNED_LONG
typedef unsigned long WINSCARD_DWORD;
typedef long WINSCARD_LONG;
#else
typedef DWORD WINSCARD_DWORD;
typedef LONG WINSCARD_LONG;
#endif
#if !defined(_WIN32) && !defined(__APPLE__)
# define DWORD WINSCARD_DWORD
# define LONG WINSCARD_LONG
# define LPDWORD WINSCARD_DWORD *
#endif
#ifdef HAVE_WINSCARD_H
# include <winscard.h>
#else
# ifdef HAVE_PCSC_WINSCARD_H
# include <PCSC/winscard.h>
# define HAVE_WINSCARD_H
# endif
#endif
#if !defined(_WIN32) && !defined(__APPLE__)
# undef DWORD
# undef LONG
# undef LPDWORD
#endif
/************************************************************************/
Then client coding is as follows:
/************************************************************************/
WINSCARD_DWORD cchGroups=0;
hr=SCardListReaderGroups(self->device->ctx,NULL,&cchGroups);
/************************************************************************/
Ironically I implemented part of this fix originally to support Jaguar because
I was using DWORD derived from unsigned int, and it wanted to use a type
derived from unsigned long. Both 32bits at the time but caused compilation
warnings.
Regarding the headers, there is a simpler fix compliant with
configure/config.h, for example Solaris does not put winscard.h in a PCSC
subdirectory. I suggest:
#ifdef HAVE_PCSC_WINSCARD_H
# include <PCSC/winscard.h>
#else
# include <winscard.h>
#endif
Regards,
Roger
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Ludovic Rousseau
Sent: Tuesday, 27 July 2010 8:00 p.m.
To: MUSCLE
Subject: Re: [Muscle] 64bit portability and header tidy up
2010/7/25 Roger Brown <[email protected]>:
> Hello, I am new to the list and my interests are using PCSClite on a wide
> variety of hardware.
Welcome on board.
> The two issues I would like to raise are:
>
> (a) Use of DWORD/LONG data types on 64bit systems. The DWORD type originates
> way before 16bit windows, and was even used in Intel's PLM language to define
> a 32 bit quantity, Windows maintained this, and even though they limited the
> size of "long" on 64bit systems to 32bit, the definition of DWORD is 32bits,
> not the size of an unsigned long. For comparison go back to the OLE32
> implementation on the DEC Alpha and you will find DWORD being defined in
> "cooldefs.h" as a 32 bit quantity. Both MacOSX and Solaris have now updated
> their headers to make pcsclite.h and winscard.h use uint32_t or equivalents.
For historical reasons DWORD was defined as:
typedef unsigned long DWORD;
The same definition is/was used by Windows itself. But Windows is
LLP64 and Unix is LP64 so a long is 32-bits for Windows on 64-bits
architectures [1].
> My intermediate solution has been to
>
> a. Disable PCSC/wintypes.h by definining __wintypes_h__ before-hand.
> b. #define DWORD to a different type before the inclusion of
> winscard.h then #undef DWORD afterwards.
>
> This does not break binary compatibility, but requires special types when
> using calling SCard* APIs. If the intent is to mimic windows types in
> wintypes.h then it should maintain size compatibility, else types like GUID
> which contain a DWORD break.
I think your change will break the binary compatibility.
libpcsclite will use DWORD as 64-bits integer. But your application
will use DWORD as 32-bits integer.
Have you tried with a real code?
> (b) Use of #include <pcsclite.h> within "PCSC/winscard.h" should be changed
> to #include <PCSC/pcsclite.h> otherwise /usr/include/PCSC is required as part
> of the include path.
In my codes I have this:
#ifdef __APPLE__
#include <PCSC/winscard.h>
#else
#include <winscard.h>
#endif
Your plan is to change to this:
#ifdef WIN32
#include <winscard.h>
#else
#include <PCSC/winscard.h>
#endif
Or will #include <PCSC/winscard.h> also work under Windows?
> I'm sure we can come up with a common solution that does not break existing
> 64bit binaries on Linux, (Solaris and MacOSX are already consistent).
If you have a working solution I will be happy to implement it.
Thanks,
[1] http://en.wikipedia.org/wiki/64-bit
--
Dr. Ludovic Rousseau
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
_______________________________________________
Muscle mailing list
[email protected]
http://lists.drizzle.com/mailman/listinfo/muscle
