¿Por qué el software no funciona sin instalación? Guía visual de cómo las aplicaciones se integran con el sistema operativo

Si usas un PC o un móvil, seguro que te has topado más de una vez con estos pequeños misterios.

• Slack y VS Code solo funcionan después de instalarlos, pero Gmail y Google Docs arrancan en cuanto abres una URL ─ ¿cuál es la diferencia?
• El mundo está lleno de comandos para «instalar» ─ pip (Python), npm (Node.js), brew (Mac), apt (Linux), winget (Windows). ¿Qué hacen realmente todos esos?
• ¿Por qué te piden la contraseña de administrador cada vez que instalas algo?
• En macOS suele bastar con arrastrar un .app a una carpeta y listo, mientras que los instaladores .exe de Windows te llevan por diálogo tras diálogo. ¿A qué se debe esa diferencia?

«Instalación» es una sola palabra que esconde muchas sensaciones distintas, y por eso resulta difícil resumirla en una frase. Pero en cuanto sigues cada caso hasta su raíz, todos comparten la misma respuesta.

Para que un software funcione, tiene que presentarse oficialmente al sistema operativo (Windows, macOS, Linux, etc.) ─ «Hola, una nueva aplicación viene a vivir aquí» ─ y darle la mano.

«Instalación» no es más que el nombre que le damos a esa ceremonia de saludo. En este artículo desgranaremos:

• Qué hay realmente dentro de un archivo ejecutable (.exe / .app / .deb)
• Por qué los programas no pueden funcionar por sí solos y siempre necesitan ayuda del sistema operativo
• Qué hace concretamente, entre bastidores, esa caja negra llamada «instalación»
• Por qué pueden existir mundos «sin instalación» (apps web, apps portables, contenedores)

Lo iremos viendo paso a paso, con diagramas y sin dar nada por sabido.

1. Qué son realmente los programas ─ los ejecutables como instrucciones para el SO y la CPU

¿Qué hay exactamente dentro de ese «paquete» .exe, .app o .deb que acabas de descargar? En cuanto lo abrimos, queda claro por qué los programas no pueden funcionar por sí solos.

1-1. Un ejecutable son solo bytes ─ pero bytes en un orden muy concreto

Si echas un vistazo a un ejecutable, lo único que ves es una larga secuencia de ceros y unos (binario). En un editor de texto resulta ilegible. Pero el orden de esos bytes sigue reglas estrictas, y cuando el sistema operativo los lee, aparece el sentido: «el cuerpo del programa empieza aquí», «esta zona es para datos», «esta sección lista las bibliotecas externas», y así sucesivamente.

A esa disposición que el SO sabe leer la llamamos formato de archivo ejecutable. Cada sistema operativo importante usa uno de tres formatos, y todo PC del mundo se rige por uno de ellos.

Por eso, cuando un .exe de Windows se niega a ejecutarse en un Mac, no es por mala fe ─ simplemente el SO no habla el mismo dialecto de instrucciones. Es como mandar una carta en japonés a alguien que solo lee francés: ve los caracteres, pero no entiende el contenido.

1-2. Las cuatro partes principales dentro de un ejecutable

Los tres formatos difieren en los detalles, pero su estructura general es similar. Si lo dividimos en cuatro «habitaciones», se ve mucho más fácil.

┌─────────────────────────────────────┐
│ Header                              │ ← portada que el SO lee primero ("ELF v1.0", "64 bits", SO destino)
├─────────────────────────────────────┤
│ Code (.text)                        │ ← las propias instrucciones de la CPU
├─────────────────────────────────────┤
│ Data (.data / .rodata)              │ ← cadenas, constantes, recursos integrados
├─────────────────────────────────────┤
│ Symbols / link info                 │ ← lista de "qué biblioteca externa y qué función quiero llamar"
└─────────────────────────────────────┘

• El encabezado es la portada. El SO lo lee primero y decide «¿es este un tipo de archivo que puedo ejecutar?»
• El código contiene las instrucciones reales de la CPU ─ add, mov, jmp, etc.
• Los datos guardan la materia prima del programa: cadenas de texto, valores numéricos por defecto, recursos gráficos.
• Símbolos / información de enlace es una «lista de la compra de piezas que faltan» ─ «aquí quiero llamar a printf, por favor enchúfamelo», le dice al SO y al cargador.

¿Captas la idea? Un ejecutable no es un producto terminado. Es una bolsa con instrucciones de montaje + materia prima + una lista de la compra. El SO lee las instrucciones, le pasa el código a la CPU y conecta las piezas que faltan (bibliotecas compartidas) para que el programa se ejecute realmente.

2. Los programas no se ejecutan solos ─ la conversación constante con el SO

Como vimos en §1, un ejecutable lleva una «lista de la compra». ¿Dónde compra? En el sistema operativo y en sus bibliotecas estándar. Cada vez que una app pinta un carácter en pantalla, abre un archivo o habla con la red, no lo está haciendo ella misma ─ está pidiéndoselo educadamente al SO.

2-1. La pila de cuatro capas: app → biblioteca estándar → kernel → hardware

A grandes rasgos, las tripas de un PC se apilan así.

┌─────────────────────────────┐   ← Slack, VS Code, las apps que has abierto
│   Aplicación                 │
├─────────────────────────────┤
│   Biblioteca estándar        │   ← biblioteca estándar de C, .NET, libc, Foundation, etc.
│   (runtime del lenguaje)     │      Capa de traducción entre app y SO
├─────────────────────────────┤
│   Kernel del SO              │   ← kernel de Windows, kernel de Linux, Darwin
│                              │      Manda en pantalla, archivos, red y memoria
├─────────────────────────────┤
│   Hardware                   │   ← CPU, RAM, SSD, GPU, tarjeta de red
└─────────────────────────────┘

Cuando una app quiere «mostrar ‘Hola’ en pantalla», no le manda señales al monitor por su cuenta. Ocurre una carrera de relevos:

1. La app llama a una función como printf("Hola")
2. La biblioteca estándar (libc en C, BCL en .NET) prepara para el SO una petición de «salida por pantalla»
3. Le entrega esa petición al kernel del SO ─ a este traspaso lo llamamos llamada al sistema (una «orden de trabajo» oficial de la app al SO)
4. El kernel pasa por el driver de pantalla y le indica al hardware qué dibujar, y aparecen las letras

Dicho de otro modo, las apps están escritas desde el principio asumiendo que el SO les echará una mano. No existe un ejecutable que funcione sin la ayuda de un SO. Esa es la razón profunda por la que el concepto «instalar una app para un SO concreto» siquiera tiene sentido.

2-2. Llamadas al sistema ─ los «formularios de pedido» oficiales al SO

Una llamada al sistema (la ventanilla específica donde las apps le dicen «haz esto, por favor» al SO) suele pedir cosas como:

Cada una es una tarea que la app no puede hacer, o no tiene permitido hacer, por sí sola, así que se la pide al SO. Sin la ayuda del SO, una app no puede dibujar ni un solo carácter en pantalla.

3. [Núcleo] Qué hace realmente «instalar» entre bastidores

A estas alturas ya sabemos que «una app no puede ejecutarse sin la ayuda del SO». Eso facilita resumir la instalación: es el término paraguas para todo el trabajo previo que media la relación entre la app y el SO. Casi cualquier instalador del mundo (.msi, .pkg, .dmg, .deb, .rpm, el arrastre del .app en macOS, el botón «Instalar» de Microsoft Store, etc.) recorre las seis fases siguientes.

3-1. Las seis fases que recorre un instalador

Cada fase tarda entre unos cientos de milisegundos y decenas de segundos, y la suma es lo que tú vives como «tiempo de espera de la instalación».

1. 1Verificación de firmaComprueba que el archivo «viene realmente de un autor legítimo» (piénsalo como una comprobación del sello). En Windows lo hace Authenticode, en Mac Gatekeeper, en Linux es la firma GPG sobre los paquetes.
2. 2ExtracciónSaca de esa única bolsa (el instalador) el binario principal, las bibliotecas de apoyo, los ficheros de configuración, la documentación, etc. Hasta aquí solo se «están sacando los materiales».
3. 3ColocaciónMueve los archivos extraídos a las ubicaciones estándar del SO. En Win es C:\Program Files\, en Mac /Applications/, en Linux /usr/lib/ y /usr/bin/.
4. 4RegistroApunta el nombre de la app en la «agenda» del SO. Windows escribe en el Registro de Windows (la libreta enorme donde el SO guarda los ajustes), Mac escribe ficheros plist, Linux deposita un fichero .desktop.
5. 5IntegraciónAñade iconos al menú Inicio / Launchpad / menú de aplicaciones, y asocia la app con las extensiones de archivo correspondientes (.txt, .psd, …).
6. 6Tareas finalesRegistra los servicios en segundo plano, construye las cachés del primer arranque, ajusta el PATH, crea accesos directos y, por último, limpia los ficheros temporales.

Regla mnemotécnica: verificar → extraer → colocar → registrar → integrar → cerrar. Cualquier instalador te lleva por estos seis pasos para pasar de «descargado» a «listo para usar».

3-2. Antes / después ─ el sistema de archivos cambia a la vista

Si las «seis fases» siguen sonando abstractas, comparar el disco antes y después de la instalación lo deja inmediato.

~/Downloads/
└── SuperApp-1.2.3.exe   ← una sola bolsa

C:\Program Files\SuperApp\
├── SuperApp.exe                ← binario principal
├── core.dll, render.dll, ...   ← piezas (bibliotecas compartidas)
└── resources\                  ← imágenes, traducciones

C:\Users\me\AppData\Roaming\SuperApp\
└── settings.json               ← ajustes del usuario

Registro HKLM\Software\SuperApp
├── InstallPath = "C:\Program Files\SuperApp"
└── Version = "1.2.3"

Menú Inicio → SuperApp (acceso directo)

Como ves, instalar es el acto combinado de «repartir un único .exe entre las carpetas correctas + avisar al SO». No es que «el doble clic no ejecute nada» ─ más bien, en los segundos o minutos posteriores al doble clic ocurre un montón de configuración a nivel de SO. Ese es el modelo mental más preciso.

4. Dependencias ─ por qué un único ejecutable no se sostiene solo

«Si solo es una app, ¿por qué hay cientos de archivos?» La respuesta vive en esta sección. La clave es el concepto de biblioteca compartida (cajas de piezas que muchas apps toman prestadas).

4-1. Qué es una biblioteca compartida

«Guarda esta imagen como JPEG» es el tipo de funcionalidad que en algún momento querrán Photoshop, las extensiones de VS Code y Slack. Si cada app llevara su propia copia:

• El disco se hincha con piezas duplicadas
• Un solo parche de seguridad obliga a re-publicar todas las apps

Para evitar ese dolor, el SO ofrece una manera de reunir las piezas comunes en un único archivo y «prestárselas» a varias apps. Eso es una biblioteca compartida (con extensión .dll en Win, .dylib en Mac, .so en Linux).

                 ┌──────────────────────────┐
                 │      tu aplicación         │
                 └──────────────────────────┘
                       │   │   │
        ┌──────────────┘   │   └──────────────┐
        ▼                  ▼                  ▼
   libjpeg.dll        libssl.dll         libcurl.dll
   (caja JPEG)        (caja criptografía) (caja HTTP)
        │                  │                  │
        └──────────────────┴──────────────────┘
                           ▼
                ┌──────────────────────┐
                │   API del SO (kernel)│
                └──────────────────────┘

Aunque la app en sí pese solo unos pocos MB, en la práctica depende de un puñado de estas «cajas de piezas», y el instalador las suelta en el disco junto con el binario principal. Por eso «una sola app» puede ocupar cientos de MB una vez instalada.

4-2. El infierno de las DLL ─ cuando las piezas compartidas pelean por las versiones

Las bibliotecas compartidas son prácticas, pero tienen un fallo célebre: si las versiones no encajan, todo se va al traste a la vez. Es el legendario el infierno de las DLL (el caos cuando dos apps exigen versiones diferentes de la misma caja de piezas y acaban rompiéndose mutuamente).

   App A  ─→ necesita libfoo v1.0
   App B  ─→ necesita libfoo v2.0
                    │
                    ▼
        Solo cabe una libfoo en el SO
        →  una de las dos se romperá seguro

Los SO modernos lo mitigan de distintas maneras:

• Windows: WinSxS (Side-by-Side) y los paquetes tipo Microsoft.UI.Xaml permiten convivir varias versiones bajo nombres distintos
• macOS: anima a que cada .app incluya su propia copia de los .dylib que necesita
• Linux: los gestores de paquetes (los veremos luego) resuelven el grafo de dependencias por ti

Aun así, cuando rescatas un programa antiguo y aparece MSVCR100.dll not found, ese error es la sombra alargada de este mismo problema.

5. Integración con el SO ─ asociaciones de archivos, entradas de menú, autoarranque

En las fases 4 y 5 de §3 (registro e integración), el instalador hace que la app se anuncie oficialmente al SO. Si vemos exactamente «qué se escribe y dónde», lado a lado entre sistemas operativos, las diferencias saltan a la vista.

5-1. Qué se registra, SO por SO

«Las apps pueden parecer iguales por fuera, pero la libreta donde realmente escriben es distinta en cada SO.» En cuanto eso te encaja, deja de sorprender que «el software iba bien en Windows pero parece otro animal en macOS».

5-2. Por qué no basta con «soltar el ejecutable en cualquier sitio»

Puedes dejar algo como notepad.exe en Descargas y hacer doble clic; técnicamente arrancará por su cuenta. Pero te perderás experiencias como:

• Lanzarlo rápido desde el menú Inicio
• Que un doble clic en un .txt lo abra automáticamente con esa app
• Desinstalar con un clic desde la pantalla de «agregar o quitar programas» del SO
• Que las actualizaciones automáticas funcionen solas
• Que el mismo icono siga ahí después de reiniciar

Todo eso es fruto de la integración con el SO. La instalación se convirtió en el combo «colocar archivos + registrarlos en el SO» precisamente para habilitar esa experiencia.

6. Permisos y seguridad ─ por qué te pide la contraseña de administrador

«¿Por qué me pide la contraseña cada vez que instalo algo?» Esa pequeña fricción es en realidad la prueba de que el cierre de seguridad del SO está funcionando. Cuando entiendes la lógica, deja de resultar molesta.

6-1. Zona del sistema vs. zona del usuario

El sistema de archivos de un SO se divide en lugares que requieren permisos de administrador para escribir y lugares que no.

┌──────────────── Permisos de administrador requeridos ───────┐
│  Windows : C:\Program Files\, C:\Windows\, HKLM\registro    │
│  macOS   : /Applications/, /Library/, /usr/local/           │
│  Linux   : /usr/, /etc/, /opt/                              │
└──────────────────────────────────────────────────────────────┘
┌──────────────── Bastan permisos de usuario ─────────────────┐
│  Windows : %USERPROFILE%\AppData, HKCU\registro             │
│  macOS   : ~/Library/, ~/Applications/                       │
│  Linux   : ~/.local/, ~/.config/                            │
└──────────────────────────────────────────────────────────────┘

Durante la fase 3 (colocación) de §3, un instalador que quiera dejar la app en la zona del sistema será detenido por el SO con un «¿estás seguro?». Eso es justo:

• El cuadro UAC de Windows («¿quieres permitir que esta aplicación realice cambios en el dispositivo?»)
• El cuadro de contraseña de macOS
• El reto de contraseña de sudo en Linux

Y el caso simétrico ─ «arrastra un .app de Mac al ~/Applications/ de tu usuario y no te pide contraseña» ─ se desprende de la misma lógica.

6-2. Verificación de firma ─ la comprobación del sello de autenticidad

Además de los permisos, el SO también comprueba previamente «¿este instalador viene realmente del autor que dice ser?». Es la verificación de firma (la comprobación del sello que confirma que el instalador es el original de un autor legítimo), y cada SO tiene su propia versión:

Avisos como «esta app viene de un desarrollador no identificado» o «no se puede abrir esta app porque no se ha podido verificar» son justo el resultado de estas comprobaciones de firma. Que algo falle la comprobación no significa automáticamente que sea malware ─ los desarrolladores independientes pequeños suelen saltarse la firma de código porque los certificados son caros ─ pero «no ejecutes nada que falle la comprobación» es la opción segura por defecto.

7. El mundo «sin instalación necesaria»

Hasta aquí hemos visto que «instalar = darle la mano al SO». Si otro hace ese saludo en tu nombre, en principio no necesitas instalar nada tú. Y, en la práctica, la informática moderna tiene varias maneras de hacer exactamente eso. Veamos rápido cómo se las apaña cada una.

7-1. Cuatro enfoques de un vistazo

7-2. Por qué cada enfoque puede permitirse el «sin instalación»

Cada uno explicado en términos sencillos, con una analogía cercana al principiante.

• App web: el programa real vive en un servidor remoto, no en tu PC. Tu PC solo está ejecutando un navegador. Como el navegador ya le ha dado la mano al SO, las apps que corren encima de él no necesitan su propio saludo (piénsalo como si pidieras prestada una mesa en un restaurante).
• App portable (piénsala como toda la app metida en un pendrive): lleva todas las piezas que necesita y evita tocar el registro / plist, así que descomprimirla basta. La contrapartida es un tamaño mayor y la falta de integración con el SO (sin entrada de menú, sin asociaciones de archivo).
• Contenedor (piénsalo como una salita aislada y portátil que guarda la app junto con los trozos de SO que necesita): no solo la app, sino también las bibliotecas y la configuración de las que depende, van metidas en la habitación y se ejecutan aisladas de tu SO anfitrión. El saludo ocurre dentro de la habitación, así que casi nada se escribe en tu PC real. Esa es justo la comodidad que convirtió a «envía todo el runtime, no solo el código» en el estándar de la era cloud.
• Gestor de paquetes (automatiza la rutina de «instalar» que harías a mano, en nombre del SO): parece «sin instalación», pero en realidad solo está ejecutando por ti las seis fases de §3 con un único comando. Es mejor verlo como «instalación, pero bien automatizada». Durante los pocos segundos de brew install nginx, el baile verificar / extraer / colocar / registrar ocurre tras el telón.

Una vez lo ves así, «¿necesito instalar o no?» se reduce a «¿quién está dándole la mano al SO en mi nombre?». En las apps web, el navegador; en los contenedores, el motor de contenedores; en los gestores de paquetes, un script de automatización. Siempre hay alguien dando la mano en algún sitio.

8. Verlo en la práctica ─ comandos que muestran lo que la instalación cambió de verdad

Ahora que la teoría está clara, abramos tu propio PC y confirmemos «sí, los archivos realmente se añaden durante la instalación». En cada SO basta una o dos líneas de comando.

8-1. Listar las apps / paquetes instalados

Primero, vamos a imprimir «qué hay instalado actualmente en este PC», según el SO.

# Windows (PowerShell)
Get-Package | Select-Object Name, Version | Sort-Object Name

# macOS (apps instaladas con Homebrew)
brew list --versions

# Linux (Debian / Ubuntu)
dpkg -l | head -20

8-2. Ver qué archivos dejó una app concreta

También puedes profundizar en un único paquete y ver exactamente qué archivos dispersó su instalador por el sistema.

# Linux (Debian / Ubuntu) ─ lista todos los archivos que colocó el paquete git
dpkg -L git | head -20

# macOS ─ inspecciona un paquete instalado desde una ruta .pkg oficial
pkgutil --pkg-info com.apple.pkg.CLTools_Executables

# Windows ─ lista las instalaciones a través de las claves Uninstall del Registro
Get-ItemProperty 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\*' | Select-Object DisplayName, DisplayVersion

Verás entradas como /usr/bin/git, /usr/share/man/man1/git.1.gz, /etc/bash_completion.d/git ─ es decir, una sola app desperdigándose por muchos rincones del SO. Cuando te das cuenta de «ese único archivo descargado se filtra hasta este punto en el SO», la instalación deja de parecer magia y empieza a sentirse real.

Recapitulación ─ cuatro líneas que lo resumen todo

Artículo largo, pero su esencia cabe en cuatro puntos.

• Una app no funciona sola. Solo funciona pidiendo prestados el SO y el hardware ─ por eso el protocolo de saludo con el SO es inevitable.
• La instalación es la ceremonia que ejecuta ese saludo ─ verificar, extraer, colocar, registrar, integrar y cerrar, las seis fases en orden.
• La contraseña de administrador es un «¿seguro que quieres escribir en la zona del sistema?». La verificación de firma es un «¿esto viene realmente de un autor legítimo?»
• Web / portable / contenedor / gestor de paquetes son todos «intermediarios» del saludo ─ el «sin instalación» solo funciona porque alguien, en algún sitio, ya le dio la mano antes.

Con esos cuatro en mente, puedes leer .exe, .app, .deb o docker run con la misma lente y entender qué está ocurriendo delante de ti.

Para la base por el lado de la red, mira nuestro anterior ¿Qué es una dirección IP?. Combínalo con el «saludo entre SO y app» de hoy y tendrás la imagen completa de cómo los datos llegan a tu dispositivo y cómo la app realmente se ejecuta sobre él. Para profundizar todavía más, Cómo elegir el tipo numérico correcto en SQL en este sitio recorre el mismo hilo de «cómo se representan los datos dentro de un programa».

Preguntas frecuentes

P1. ¿Cuál es la diferencia entre una app portable y una app instalada?

R. El binario de dentro es prácticamente el mismo; lo que cambia es si ocurre o no la integración con el SO. Una copia instalada recorre las seis fases de §3 y «le da la mano a fondo» al SO, así que obtienes entrada en el menú Inicio, asociaciones de archivos, actualizaciones automáticas, etc. Una copia portable se queda en las fases 1–2 (verificar, extraer) más la colocación de la carpeta ─ deliberadamente se salta el paso de añadir su nombre a la agenda del SO.

P2. ¿Desinstalar de verdad lo borra todo?

R. La mayor parte desaparece, pero los ajustes y los datos del usuario suelen quedarse. Windows deja la configuración bajo C:\Users\<tú>\AppData\, Mac bajo ~/Library/Application Support/<App>/, Linux bajo ~/.config/<app>/ ─ a propósito, para que una futura reinstalación recupere tus preferencias. Si quieres una limpieza total, borra esas carpetas a mano o usa un ayudante como AppCleaner (Mac) o Bulk Crap Uninstaller (Windows).

P3. ¿Por qué con los .app de macOS basta arrastrar y soltar?

R. Un .app no es realmente un «archivo» ─ es una carpeta repleta de todo lo que la app necesita (lo llamamos un bundle). El binario principal, las piezas (.dylib), los recursos y el Info.plist están todos dentro, así que apenas hace falta tocar nada externo al estilo registro. Soltar la carpeta en /Applications/ basta para que el SO la reconozca. Los .exe de Windows también pueden ejecutarse sueltos, pero la convención de Windows desperdiga sus ajustes por el Registro, así que un solo arrastre no deja una instalación limpia.

P4. ¿Ejecutar Docker cuenta como «instalar»?

R. Piénsalo en dos capas. El propio Docker (el motor que ejecuta los contenedores) sí necesita una instalación nativa única en tu PC. Una vez está ahí, cada app individual que ejecutas encima vive dentro de un contenedor («habitación privada») y nunca se escribe en tu SO real. «Las apps que parecen no necesitar instalación» no la necesitan precisamente porque el motor de Docker está dándole la mano al SO en su nombre.

P5. ¿Puedo instalar software sin permisos de administrador?

R. Sí, mientras te quedes en la zona del usuario. En Windows existen «instaladores de usuario» que dejan los archivos en %LOCALAPPDATA% (el «User Installer» de VS Code, por ejemplo); en Mac puedes arrastrar un .app a ~/Applications/; y en Linux puedes copiar binarios en ~/.local/bin/ o usar pipx install --user. Pero cualquier cosa que afecte al sistema entero (instalar drivers, servicios persistentes en segundo plano, dejar archivos en /usr/local/, etc.) requiere por naturaleza escribir en la zona del sistema, así que los permisos de administrador se vuelven inevitables.