osdir.com
mailing list archive

Subject: re: mcard plugin win32 building for DRM application - msg#00061

List: lib.muscle

Date: Prev Next Index Thread: Prev Next Index

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?
Yes No
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!
Sign up for updates to this mailing list. email:
Loading Comments...
Home | News | Patents | Sitemap | FAQ | advertise

Advertising by