Archive

Archive for April, 2013

SCardWrappers v1.0

April 28, 2013 10 comments

Just to let everyone know that v1.0 of SCardWrappers has been released. This is a set of C++ classes to provide a complete encapsulation of the Smart Card API for Windows.

The classes provided are: SCard::CException, SCard::CContext, SCard::CContext2, SCard::CAPDURequest, SCard::CAPDUResponse, SCard::CCard, SCard::CCard2, SCard::CATR, SCard::String, SCard::StringArray, SCard::GUIDArray & SCard::ByteArray.

CException is the exception class used and can be thrown by CContext2 and CCard2 methods. If MFC integration is chosen for the classes then this class will be derived from the CException MFC class and exceptions will be thrown by pointer. If STL integration is chosen then the exception will be throw by standard reference.

CContext provides an encapsulation of a Smart Card SCARDCONTEXT handle.

CContext2 derives from CContext and provides an exception based version of it.

CAPDURequest provides a C++ encapsulation of a request which is sent to the Transmit method of CCard/CCard2. It also provides a Parse method to convert a raw BYTE buffer into a request.

CAPDUResponse provides a C++ encapsulation of a response which is received via the Transmit method of CCard/CCard2. It also provides a Parse method to convert a raw BYTE buffer into a response.

CCard provides an encapsulation of a Smart Card SCARDHANDLE handle.

CCard2 derives from CCard and provides an exception based version of it.

CATR provides an ATR parser class.

String derives from either CString if the classes are using MFC or std::string/std::wstring if using STL.

StringArray derives from either CArray<String..> if the classes are using MFC or std::vector<String> if using STL.

GUIDArray derives from either CArray<GUID..> if the classes are using MFC or std::vector<GUID> if using STL.

ByteArray derives from either CByteArray if the classes are using MFC or std::vector<BYTE> if using STL.

Categories: Web Site Updates

ShelExec v1.18

April 14, 2013 Comments off

Just to let everyone know that v1.18 of ShelExec has been released. Updates for this version include:

  • Updated copyright details.
  • Updated the code to compile cleanly on VC 2010 and later using /analyze.
  • Following a request from Thorsten Schöning, ShelExec now includes support for a new /NOSFNC command line option. If this is specified, then the program will pass the long filename down to the Win32 ShellExecute API. If this command line option is not set (which is the default), then the program will continue to pass the 8.3 short filename to the API.
Categories: Web Site Updates

CFileTreeCtrl v1.56

April 7, 2013 Comments off

Just to let everyone know that v1.56 of CFileTreeCtrl has been released. Updates for this version include:

  • Minor update to the code in DisplayNetworkComputer method.
  • Fixed a spelling mistake in EnumNetwork method.
Categories: Web Site Updates

CFileTreeCtrl v1.55

April 6, 2013 Comments off

Just to let everyone know that v1.55 of CFileTreeCtrl has been released. Updates for this version include:

  • Updated copyright details.
  • Updated the code to compile cleanly on VC 2010 and later
  • Reworked CFileTreeCtrl::AddMultipleFileNameMasks to use CString::Tokenize
  • Removed old Win9x code path from CShareEnumerator class.
  • Reworked the CSystemImageList class to remove the defunct Win9x code path.
  • Removed the static instances of CSystemImageList and CShareEnumerator. These changes along with the Win9x changes means that the code no longer supports running on Win9x.
  • Reworked the code so that calling SetRootFolder on a UNC server name now works. The issue was that a path of the form "\\MACHINENAME" is not a true file system path because only paths of the form "\\MACHINENAME\SHARE" allow file enumeration. The code now explicitly checks the path and instead enumerates the network resources below the UNC server name even when SetRootFolder has been called. Thanks to Jan Moorman for reporting this issue.
Categories: Web Site Updates