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 XMac 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
filecommand 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 i386The
lscommand 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 i386The PCSC framework is available for both 32-bits applications (i386) and 64-bits applications (x86_64).
Microsoft WindowsMicrosoft has a
System32directory to store system files. The surprise is that on a 64-bits machine the
System32is used to store 64-bits system files and the 32-bits system files are stored in a
SysWow64directory. 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
System32for 32-bits files and
System64for 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
RedHatRedHat, 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.
DebianDebian 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
<triplet>being something like
pcsc-liteSince 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:
The package libpcsclite1_1.8.3-3_amd64.deb provides the files:
And it is possible to install the two packages at the same time (after configuring the system for multiarch).
pcscdOne complexity is that pcsc-lite has a client/server architecture. The client is
libpcsclite.so.1and the server is
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
pcscdand one (or more)
ExampleI have a amd64 Debian system.
I have installed the Debian package pcsc-tools to have the
$ 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, strippedThe 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
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_scanbut 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.
ConclusionWith 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.