|
|
Subject: re: mcard plugin win32 building for DRM application - msg#00061
List: lib.muscle
Question:
If I build the libmusclecard in pcsc-lite/win32 using VC compiler,
howshould I link against the cygwin-built libpcsclite?
e.g. use GNU ld(1), Use MS link?
Background:
(A) in pcsc-lite win32/, Ive managed to build most of what seems
to be a VC build environment for the musclecard library, paralleling
libmusclecard.la under the cywin/Linux build. It required downloading
a win32 pthreads .lib.
(B) It doesn't yet make a win32 DLL, as there
as yet unresolved symbols, from the winscard API, despite
linking against the winscard.lib provided by Microsoft, as implied
by the build file provided in pcsc-lite/win32.
(C) Perhaps, if linkers allow, one can complete this DLL
build by linking against libpcsclite's implementation of the
winscard API? Hence my queston, above.
Peter.
Cheer a special someone with a fun Halloween eCard from American Greetings!
Was this page helpful?
Thread at a glance:
Previous Message by Date:
click to view message preview
Re: pcsc-tools 1.3.1 (new release)
Le mercredi 29 octobre 2003 à 15:55:48, James E. Hopper a écrit:
> Hi,
>
> the link in your email:
> >[1] http://ludovic.rousseau.free.fr/softwares/pcsc-tools/
>
> denies me access because of access control list. is this the wrong
> link??
The URL is correct and works correctly. Your problem is somewhere else.
Bye,
--
Dr. Ludovic Rousseau Ludovic.Rousseau@xxxxxxx
-- Normaliser Unix c'est comme pasteuriser le camembert, L.R. --
Next Message by Date:
click to view message preview
On-line signature standards
Dear muscle user,
Here is some information related to muscle development gathered
from a poll made to the IETF-PKIX, IETF-SMIME, and the OASIS
PKI-TC lists regarding the current state of on-line signature standards
=====================================================
There are apparently no standards and nothing in the works either
with respect to signing on-line data on the web using Internet browsers.
=====================================================
Since web-signing is today [*] used by many, many, more people
and organizations than there are users of signed e-email, I remain puzzled.
Is the PKI community really just a bunch of "nerds", mostly out of
touch with the needs of the market?
And what good is a legal framework like the EU signature directive,
intended to address "legal interoperability" if there is no interoperability
in the technical solutions?
"The truth is [still] out there" to travesty a famous TV series.
However, my request spurred quite a lot of interest, so I believe that web-
signing really is a thing that finally will be standardized. The question
is more by who, as the major interest is really coming from the public
sector, not from commercial entities like banks, that rather protect their
investments in proprietary solutions. I personally plan to pusue such
a task in W3C or in OASIS in case somebody is interested.
*] Like Scandinavian banks having > 0.5M of users.
All current systems rely on entirely proprietary mechanisms.
Most of the vendors even require NDAs for getting the documentation.
Anders Rundgren
Previous Message by Thread:
click to view message preview
mcard plugin win32 building for DRM application
Folks:
How do I build the mcard plugin (1.1.3) on a native win32 platform?
Context:
(1) I've built the mcard javacard applet in a simulator, modified to
use some extra non-PKCS-11 DRM-related crypto
mechanisms, for my customer.
(2) This javacard accepts APDUs over sockets, rather than
CCID USB or 7816 line protocols. (The DRM solution
requires the IFD to be socket server, infact, for huge
scaling.)
(3) I need to rebuild the mcard plugin from source on win32, to link
a custom PC/SC static lib rather than pcsc-lite or Microsoft DLLs. The linked proxy, allows me to dynamically load real PC/SC providers, such
as the socket provider, or the standard MS PC/SC scard framework.
My Win32 build trials to date:
(a) Using cygwin, the pc-sc lite and mcard libraries both fail to build the
shared libraries, post excution of ./configure for the usual gnu build
environment. For pcsc-lite, the build attempts to build the UNIX
package options, for things like dynamic library loading.
(b) using "configure" from an MS cmd windows for the mcard
plugin package succesfully indicates tha QT is propery configured, and
Vis.Studio's nmake should be used. However, the Makefile is too
much complex for nmake, which objects strongly to the macros.
I clearly missing something very obvious. Help sought.
Peter.
Want to check if your PC is virus-infected? Get a FREE computer virus scan online from McAfee.
Next Message by Thread:
click to view message preview
re: mcard plugin win32 building for DRM application
Might want to ensure that pcsc_stringify_error() is PCSC_API
defined and declared, so its exported from the musclecard DLL,
when built in DEBUG configuration. At least one musclecard client
tries to import the declaration from the win32 DLL implementation
(debuglog.obj).
pcsc_stringify_error() indicates that PCSC-lite has deviated
from the MS winscard API, trivially, as defined in VC98's
winscard.h . There seems to be a new error code in the
protocol: 0x8010001F. Perhaps the API evolved, and PCSC-lite
is tracking.
Fretting that your Hotmail account may expire because you forgot to sign in enough? Get Hotmail Extra Storage today!
|
|