Deimos-like binding to libopensc (reduced extend required by external modules [driver/SM])
|Copyright||Copyright © 2017, Carsten Blüggel|
|Registered by||Carsten Blüggel|
To use this package, put the following dependency into your project's dependencies section:
D language: Deimos-like binding to headers of libopensc.so/opensc.dll, supporting current OpenSC version 0.16.0, released June 2016, and the previous release 0.15.0.
category: Development Library | D language binding | Deimos header only binding (dub configuration "deimos")
category: Development Library | Development support library (with the difference to "deimos", that it must be compiled to make use of some additional code; dub configuration "toString")
The OpenSC framework allows for providing e.g. a smart card driver (or Secure Messaging module) as external shared object/DLL, if opensc.conf is configured accordingly.
This binding allows to implement in the D programming language.
Not all OpenSC header content is covered, but what is required/usefull for external modules (smart card driver/SM).
(There is a small, undisturbing deviation concerning cards.h/cards.d: SCCARDTYPE_ACOS5... where the driver, I'm implementing, is involved.)
There are multiple reasons why code using this binding has to tell at compile time, whether it's going to be linked to and call libopensc binary version 0.15.0, or the latest version 0.16.0. Others are not supported. The version issue is managed by a version identifier that has to be adjusted manually if not linking against the latest libopensc.so/.dll.
More about this and other version identifiers in info/options.
If used as dependency for driver 'acos5_64', it's highhly recommended to use the latest available libopensc.so/opensc.dll only. Maybe, this an option: https://launchpad.net/~gertvdijk/+archive/ubuntu/opensc-backports
The operating system support is limited to those I have and can test (64 bit CPU: Linux and Windows(10)), but may work for others too.
Another limiting factor is what get's exported from OpenSC's library binary libopensc.so/opensc.dll and it turned out that this is different (as expected for version differences, but also) for Linux and Windows: The best experience (in order to use this package for driver development) is with Linux and the latest libopensc.so, other binaries lack essential functionality.
The static import libraries supplied in folder lib/windows-x86-dmd (opensc.lib and libeay32.lib) are for the DMD-compiler's Windows default build (-m32 resulting in a 32 bit DLL; generated object code is in OMF) and are generated from version 0.16.0 opensc.dll and the system's libeay32.dll by e.g.
implib /s opensc.lib opensc.dll
http://www.digitalmars.com/ctg/implib.html. If other import libraries are required, dub.json expects them (depending on the -m switch either in folder lib/windows-x86-dmd or lib/windows-x86_64.
The OpenSC framework, when loading an external module, will query the driver module for it's version and unload it immediately, if that version reported doesn't match the one of OpenSC. This is a precaution to make shure, the developper is aware of possible API changes and took care for them before updating the driver module's version to match again. The downside is, it's more complicated to support severall libobensc binary versions and typically distros are months if not even years behind the latest software version available but some users will be up-to-date with the latest version.