64-bits Intel and AMD CPUs are able to run 32 and 64 bits programs at the same time. Different OS uses different strategies to use this feature.
Apple Mac OS X
Mac OS X uses what they call a
Universal Binary. This format has been designed during the transition from 680x0 to PowerPC two decades ago. The idea is to have the code for both 680x0 and PowerPC in the same executable file. So a user do not have to select any thing. The system will use the correct version transparently.
This Universal Binary concept has also been used for the PowerPC to Intel migration and now for the support of 32 and 64 bits Intel CPU.
The idea is very nice and easy to use. It works for both libraries and binaries. You can use the
file command line tool to check what is inside a binary.
$ file /bin/ls
/bin/ls: Mach-O universal binary with 2 architectures
/bin/ls (for architecture x86_64): Mach-O 64-bit executable x86_64
/bin/ls (for architecture i386): Mach-O executable i386
The
ls command is available in both 32 and 64-bits.
$ cd /System/Library/Frameworks/PCSC.framework
$ file PCSC
PCSC: Mach-O universal binary with 2 architectures
PCSC (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64
PCSC (for architecture i386): Mach-O dynamically linked shared library i386
The PCSC framework is available for both 32-bits applications (i386) and 64-bits applications (x86_64).
Microsoft Windows
Microsoft has a
System32 directory to store system files. The surprise is that on a 64-bits machine the
System32 is used to store 64-bits system files and the 32-bits system files are stored in a
SysWow64 directory. I am not a Windows expert (or even user). I got the information from friends and it is confirmed
here.
It was too simple for Microsoft to use
System32 for 32-bits files and
System64 for 64-bits files. Never underestimate Microsoft on its ability to find a complex solution to a given problem.
Another example of Microsoft complexity is the use of
UTF-16 instead of
UTF-8 for Unicode strings and then the duplication every API with A and W variants like
SCardListReadersA() and
SCardListReadersW().
RedHat
RedHat, and other GNU/Linux distributions, use
/usr/lib32/ to store 32-bits libraries and
/usr/lib64/ to store 64-bits libraries. This scheme is know as
multi lib or biarch.
This scheme is simple (more logical than the one from Microsoft :-) but it is also limited. For example it is limited to one specific architecture: Intel/AMD.
Debian
Debian is working on the problem since 2004 (see History in
Debian multi arch support). The solution is to avoid a limitation to only 2 architectures and generalize the solution to any CPU architecture.
The libraries are then stored in
/usr/lib/<triplet>/. The
<triplet> being something like
i386-linux-gnu or
x86_64-linux-gnu or
mipsel-linux-gnu.
pcsc-lite
Since version
1.8.3-1 of the
Debian pcsc-lite package the multiarch system is supported.
The package
libpcsclite1_1.8.3-3_i386.deb provides the files:
/usr/lib/i386-linux-gnu/libpcsclite.so.1
/usr/lib/i386-linux-gnu/libpcsclite.so.1.0.0
/usr/share/doc/libpcsclite1/changelog.Debian.gz
/usr/share/doc/libpcsclite1/changelog.gz
/usr/share/doc/libpcsclite1/copyright
The package
libpcsclite1_1.8.3-3_amd64.deb provides the files:
/usr/lib/x86_64-linux-gnu/libpcsclite.so.1
/usr/lib/x86_64-linux-gnu/libpcsclite.so.1.0.0
/usr/share/doc/libpcsclite1/changelog.Debian.gz
/usr/share/doc/libpcsclite1/changelog.gz
/usr/share/doc/libpcsclite1/copyright
And it is possible to install the two packages at the same time (after configuring the system for multiarch).
pcscd
One complexity is that pcsc-lite has a client/server architecture. The client is
libpcsclite.so.1 and the server is
pcscd.
Since at least four years we have:
pcsc-lite-1.4.99: Ludovic Rousseau
9 January 2008
- add support of mix 32/64 bits platforms. Thanks to Jacob Berkman for
the big patch
So a 32-bit library can talk to a 64-bit pcscd. That is nice since, even with multi-arch, it is not possible to install two pcscd (for i386 and x86_64) at the same time. You only need to install one
pcscd and one (or more)
libpcsclite.so.1.
Example
I have a amd64 Debian system.
I have installed the Debian package
pcsc-tools to have the
pcsc_scan command.
$ file /usr/bin/pcsc_scan
/usr/bin/pcsc_scan: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0x50bda59b9b9a86b312e59fd3022cd4da87b87265, stripped
The file is a 64-bits binary.
$ ldd /usr/bin/pcsc_scan
linux-vdso.so.1 => (0x00007fff7c75f000)
libpcsclite.so.1 => /usr/lib/x86_64-linux-gnu/libpcsclite.so.1 (0x00007f022ca9d000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f022c716000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f022c50d000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f022c2f1000)
/lib64/ld-linux-x86-64.so.2 (0x00007f022ccb1000)
And it is linked with the 64-bits library at
/usr/lib/x86_64-linux-gnu/libpcsclite.so.1.
And the execution works:
$ pcsc_scan
PC/SC device scanner
V 1.4.18 (c) 2001-2011, Ludovic Rousseau
Compiled with PC/SC lite version: 1.7.4
Using reader plug'n play mechanism
Scanning present readers...
Waiting for the first reader...^C
I also fetched the i386 version of the
pcsc-tools package. I can not install it since it will conflict with the amd64 version of the package (same filename
/usr/bin/pcsc_scan but different content). So I unpack the Debian package in a temporary directory.
$ mkdir foobar
$ cd foobar
$ dpkg -x ../pcsc-tools_1.4.18-1_i386.deb .
$ file usr/bin/pcsc_scan
usr/bin/pcsc_scan: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.26, BuildID[sha1]=0xcbf386965c3541f0557c913c5aead05512d4b75c, stripped
The binary is a 32-bit executable.
$ usr/bin/pcsc_scan
PC/SC device scanner
V 1.4.18 (c) 2001-2011, Ludovic Rousseau
Compiled with PC/SC lite version: 1.8.1
Using reader plug'n play mechanism
Scanning present readers...
Waiting for the first reader...^C
And the execution also works. The 32-bit binary is talking to the 64-bit pcscd server.
Conclusion
With multiarch it will/should be easy to install and execute on the same system programs for different architectures.
Maybe the new Linux
x86 architecture (taking best parts from the i386 and x86_64 worlds) will also be available as a new in architecture in the multiarch word.