An extended APDU is an APDU (command) with data and/or response of more than 256 bytes and up to 65536 bytes. See ISO 7816-4 for more details.
The CCID driver supports extended APDU. But this support may be limited by the smart card reader itself.
To be able to use an extended APDU you need to have:
With a T=0 card an extended APDU is emulated using an ENVELOPE command. This should be done at the application level and has no impact on the driver or the reader.
A CCID smart card reader can work using 4 different exchange levels:
The exchange level of a reader is contained in the dwFeatures field
of the CCID descriptor. You can get this information using the
parse command included in the driver source code.
For example the GemPC Twin reader returns:
[...] dwFeatures: 0x00010230 ....10 Automatic ICC clock frequency change according to parameters ....20 Automatic baud rate change according to frequency and Fi, Di params ..02.. NAD value other than 00 accepted (T=1) 01.... TPDU level exchange [...]
so the exchange level is TPDU for this reader.
Only very few readers work using this method. I don't know if/how they support extended APDU.
With this exchange level a lot of the work is done in the driver. In particular support of extended APDU is managed by the driver and the CCID driver implements it.
These readers are easy to use at a driver point of view but are then limited to short APDU only. Support of extended APDU is then not possible.
Some readers claim they support short APDU only but can use extended APDU when used with the manufacturer Windows driver. Maybe the Windows driver switches the reader in TPDU mode or something similar. That is not a documented CCID feature and so is not used in my CCID driver. If you can get information on this from the reader manufacturer I may include support of extended APDU for the reader in my driver.
Support of extended APDU is offered by the reader.