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.
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
It was too simple for Microsoft to use
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
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.
The libraries are then stored in
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).
Since at least four years we have:
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
I have installed the Debian package pcsc-tools to have the
And the execution works:
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
The binary is a 32-bit executable.
And the execution also works. The 32-bit binary is talking to the 64-bit pcscd server.
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.
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/lsThe
/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
ls
command is available in both 32 and 64-bits.$ cd /System/Library/Frameworks/PCSC.frameworkThe PCSC framework is available for both 32-bits applications (i386) and 64-bits applications (x86_64).
$ 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
Microsoft Windows
Microsoft has aSystem32
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 islibpcsclite.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_scanThe file is a 64-bits binary.
/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
$ ldd /usr/bin/pcsc_scanAnd it is linked with the 64-bits library at
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)
/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.
ConversionConversion EmoticonEmoticon