Porque há no Windows pastas Program Files e Program Files(x86)?

int3 says:

DLL são ficheiros compilados onde tens funções para executar. Basicamente um programa tem uma parte de memória só para ele executar. Quando o programa é muito complexo e para ser fácil de gerir é preciso dividir as coisas por livrarias dinâmicas (Dynamic Linked Library). Os programas são “linkados” durante a compilação e quando o programa é corrido e dentro da execução precisa de saltar para uma função num DLL aí o SO cria mais espaço e um endereçamento diferente. É uma questão muito técnica e não quero confundir-te porque sei que não vais entender.
.bat é um ficheiro script com comandos para a linha de comandos. .exe é um ficheiro binário executável já linkado. Os executáveis são linkados com as livrarias do sistema operativo quer estáticas (static libs) quer dinâmicas (dynamic libs ou DLL). Assim o sistema operativo pode apontar para o “start” do programa que por sua vez salta para o “main” do executável. As libs estáticas até são compiladas e juntadas no mesmo executável acho eu.
Mac e linux diferem.
No mac é possível ter várias arquiteturas destintas no mesmo “object file” (ficheiro compilado mas não linkado -> não é executável porque não existe um start).
No linux já é preciso diferir:
/lib
/lib32
/lib64

No MacOS (temos que ver isto pelo kernel. o kernel chama-se XNU, Xnu is not Unix) podemos ver que tipo de ficheiro estamos a lidar:
$ file libosxfuse.dylib
libosxfuse.dylib: Mach-O universal binary with 4 architectures: [ppc_7400: Mach-O dynamically linked shared library ppc_7400] [ppc64: Mach-O dynamically linked shared library ppc64] [i386: Mach-O dynamically linked shared library i386] [x86_64: Mach-O 64-bit dynamically linked shared library x86_64]
libosxfuse.dylib (for architecture ppc7400): Mach-O dynamically linked shared library ppc_7400
libosxfuse.dylib (for architecture ppc64): Mach-O dynamically linked shared library ppc64
libosxfuse.dylib (for architecture i386): Mach-O dynamically linked shared library i386
libosxfuse.dylib (for architecture x86_64): Mach-O 64-bit dynamically linked shared library x86_64

esta libraria dinâmica (similar ao dll no windows) tem 4 arquiteturas no mesmo ficheiro. 32 bits da intel e 64 bits da intel e powerPC de 64 bits e powerPC dos antigos que presumo que seja 32 bits.

Executáveis:
$ file Mail
Mail: Mach-O 64-bit executable x86_64
São do tipo Mach-O.

No linux:
# file /lib/security/pam_google_authenticator.so
/lib/security/pam_google_authenticator.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=9da71b105f036115dc6b5cd49bc076f606baac04, stripped

São do tipo ELF. Neste caso é uma livraria compilada para 64 bits da intel.

/bin# file echo
echo: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=9a7491319c83fdfccc9e23340320177e8d186e3d, stripped

Um exemplo de um executável no linux.

O windows NT chama-se PE (Portable executable). ELF no linux e Mach-O no XNU.

Vantagens?
Num ciclo consegues calcular números muito maiores que em vez de 32 bits.
O número máximo em 32 bits que podes manter num registo no CPU é 2^32-1. Corta a metade se for signed porque precisas de um bit para dizer se é positivo ou negativo.
Em 64 bits é o mesmo mas 2^64-1. E é um valor muito grande.

Termos práticos? 64 bits consegues mapear endereços de memória até 64 bits de tamanho. Imagina uma rua grande. Cada casa pode armazenar 1 byte de informação. O número de casa casa começa em 0 depois 1 depois 2 por aí fora. se tiveres 32 bits podes ir até 4Biliões. Ou 4 biliões de bytes. São 4 GBs. Por isso só podes ter memória endereçada e usável até 4GBs. em 64 bits o número é tão grande que deve ser na ordem dos petabytes. por isso podes ter mais casas na mesma rua 😉

Velocidade é quase igual para situações que não precisas de usar números maiores que 32 bits. se tiveres uma aplicação a 32 bits e precisar de fazer uma multiplicação de um número maior que 4 biliões então tens que fazer-lo em vários ciclos. E isso demora ocupa tempo ao CPU que poderia estar a fazer outras coisas.

Espero que tenha sido simples. Não é algo fácil de explicar porque é necessário um background na área.