Añadir parámetros a un ejecutable desde su acceso directo .lnk en Windows

Cuando trabajas con accesos directos en Windows, no todo es solo hacer doble clic: a menudo necesitas que el .lnk lance un ejecutable con argumentos específicos, como notepad.exe archivo.txt o conmutadores del tipo /EDev. Esto es clave para automatizar, depurar o garantizar que una app se abra con el contexto correcto.

Además de la creación manual vía interfaz, hoy existen métodos modernos para generar y gestionar accesos directos con parámetros desde PowerShell o con el motor COM de Windows Script Host (WSH). Y si vienes de entornos empaquetados (MSIX/AppX) o te topas con programas que “solo arrancan desde su acceso directo”, hay técnicas para redirigir argumentos, ajustar manifiestos y empaquetar con PSF sin romper la experiencia.

Qué significa añadir parámetros a un ejecutable desde un .lnk

Un acceso directo (.lnk) no es más que un archivo que apunta a un destino (TargetPath) y, opcionalmente, adjunta argumentos (Arguments), un directorio de trabajo (WorkingDirectory), un icono, atajos de teclado y otros metadatos. Esos argumentos son los que ves cuando, por ejemplo, ejecutas notepad.exe C:\Notas\tarea.txt o aplicas un modificador como /safe.

En escenarios empresariales, muchas aplicaciones del menú Inicio dependen de un lanzador que pasa un parámetro específico al ejecutable principal. Si ese parámetro falta, la app podría fallar o iniciar con comportamiento incorrecto. Por eso conviene detectar exactamente qué atajo y con qué argumentos se ejecuta.

Si necesitas “clonar” ese acceso directo o desplegarlo a escala, puedes hacerlo con un script que construya el .lnk en caliente. Esto evita distribuir archivos estáticos como Internet Explorer.lnk y, en su lugar, te da flexibilidad para generarlos al vuelo en cada equipo.

También es habitual querer convertir la experiencia de un .lnk en algo invocable por herramientas que solo aceptan .exe. En ese caso, la clave está en reproducir el TargetPath + Arguments + WorkingDirectory del acceso directo, o en usar un “launcher” que ejecute el .lnk por ti.

Crear un acceso directo con parámetros desde PowerShell (método moderno)

PowerShell puede usar el objeto COM de WScript.Shell para construir .lnk sin depender de archivos preexistentes. Es un método moderno, idóneo para despliegues y automatización.

Este ejemplo genera un acceso directo en el Escritorio público que ejecuta un programa con argumentos y establece icono, directorio de trabajo y estilo de ventana. Observa cómo se asignan TargetPath y Arguments:

$WshShell = New-Object -ComObject WScript.Shell
$Desktop   = [Environment]::GetFolderPath('CommonDesktopDirectory')
$LnkPath   = Join-Path $Desktop 'MiAplicacion.lnk'
$Shortcut  = $WshShell.CreateShortcut($LnkPath)

$Shortcut.TargetPath       = 'C:\\Rutas\\MiApp\\MiApp.exe'
$Shortcut.Arguments        = '/modo=admin /perfil=Default'
$Shortcut.WorkingDirectory = 'C:\\Rutas\\MiApp'
$Shortcut.IconLocation     = 'C:\\Rutas\\MiApp\\MiApp.exe,0'
$Shortcut.WindowStyle      = 1 # 1=Normal, 3=Maximizada, 7=Minimizada
$Shortcut.Hotkey           = 'CTRL+ALT+M'
$Shortcut.Save()

Si lo que quieres es replicar el comportamiento de un acceso directo existente (por ejemplo, ese Internet Explorer.lnk que copiabas en tus despliegues), puedes leer sus propiedades, y generar otro .lnk con el mismo destino y argumentos. Aunque no es estrictamente necesario para la mayoría de casos, tener claro qué valores copia un acceso directo te evitará sorpresas.

Crear un acceso directo con WSH/VBScript (modelo clásico)

Windows Script Host (WSH) permite ejecutar VBScript y JScript de forma nativa y expone un modelo de objetos con el que puedes crear accesos directos. Aunque es una vía “clásica”, sigue funcionando en Windows modernos porque WSH está integrado desde Windows 98/2000 y disponible en NT 4.0 mediante el Paquete de Opciones.

La lógica es simple: instancias WScript.Shell, apuntas a la carpeta del Escritorio y usas CreateShortcut para construir el .lnk. A partir de ahí, personalizas propiedades como TargetPath, Arguments, IconLocation, WindowStyle u Hotkey, y guardas.

Ejemplo básico con parámetros y opciones visuales inspiradas en los ejemplos del soporte de Microsoft (reexpresado en VBScript/WSH):

Set WshShell = CreateObject("WScript.Shell")
Desktop = WshShell.SpecialFolders("Desktop")
Set Lnk = WshShell.CreateShortcut(Desktop & "\\EjemploWSH.lnk")

Lnk.TargetPath = "%windir%\\notepad.exe"
Lnk.Arguments = "C:\\Temp\\demo.txt"
Lnk.WorkingDirectory = "C:\\Temp"
Lnk.IconLocation = "C:\\miicono.ico"
Lnk.WindowStyle = 3 ' 3=Maximizada, 7=Minimizada, 4=Normal
Lnk.Hotkey = "ALT+CTRL+F"
Lnk.Save

WSH también permite crear accesos directos a URL. En ese caso, el acceso directo tiene extensión .URL y el TargetPath apunta a la dirección web:

Set WshShell = CreateObject("WScript.Shell")
Desktop = WshShell.SpecialFolders("Desktop")
Set UrlLink = WshShell.CreateShortcut(Desktop & "\\SitioMicrosoft.URL")
UrlLink.TargetPath = "http://www.microsoft.com"
UrlLink.Save

Si vienes de Visual FoxPro, la idea es la misma: la automatización COM de WSH expone métodos como CreateShortcut y propiedades equivalentes, por lo que puedes trasladar el patrón a tu lenguaje preferido sin complicaciones.

“Mi macro solo lanza .exe, pero la app exige abrirse desde su .lnk”

Un caso real: algunos juegos o herramientas “validan” su arranque desde el propio acceso directo. Si tu programa de macros solo ejecuta .exe, no .lnk, tienes varias salidas prácticas.

Opción 1: reproduce el arranque del acceso directo. Abre las propiedades del .lnk y copia fielmente Destino (Target), Argumentos y Carpeta de inicio. Luego, configura tu macro para llamar a ese exe con dichos argumentos y, si es posible, empezando en el directorio de trabajo correspondiente. En la mayoría de los casos, la verificación interna de la app se satisface con los mismos parámetros.

Opción 2: usa un launcher mínimo. Puedes crear un pequeño ejecutable o script que invoque el acceso directo. Por ejemplo, con PowerShell:

Start-Process -FilePath "C:\\Ruta\\a\\MiAcceso.lnk"

O con la orden START de cmd.exe, que puede abrir accesos directos si le pasas la ruta correcta y una título vacío entre comillas:

cmd.exe /c start "" "C:\\Ruta\\a\\MiAcceso.lnk"

Si absolutamente necesitas un .exe, compila un stub (por ejemplo, en C#) que ejecute el .lnk o llame al exe con los argumentos almacenados en el acceso directo. Esta táctica “convierte” el acceso directo en un invocable compatible con la macro sin alterar la lógica de arranque.

Cómo identificar si un iniciador del menú Inicio requiere parámetros

Antes de integrar una app en tus despliegues, conviene comprobar si sus iniciadores en el menú Inicio dependen de argumentos. Un método de trabajo para detectarlo es el siguiente:

1. Instala la aplicación de Windows en un equipo de pruebas.
2. Abre el Menú Inicio y localiza el iniciador de la aplicación.
3. Ejecuta cada iniciador asociado. Si arranca sin problemas, probablemente no requiere parámetros específicos.
4. Desinstala la aplicación del equipo de pruebas.
5. Instálala ahora mediante su instalador Win32 tradicional.
6. Vuelve al Menú Inicio, busca la app y haz clic derecho.
7. Selecciona Más > Abrir ubicación del archivo.
8. En cada acceso directo encontrado, abre Propiedades.
9. En el campo Destino (Target), examina si tras la ruta del ejecutable aparecen argumentos.
10. Anota estos parámetros para reutilizarlos en tu integración o empaquetado.

Con esta información, podrás replicar exactamente el patrón de ejecución (ejecutable + argumentos + carpeta de inicio) al crear tus propios accesos directos o al construir scripts de arranque.

Apps Windows (MSIX/AppX): redirección, PSF y por qué a veces “no arranca bien”

Las apps empaquetadas redirigen recursos a C:\\Program Files\\WindowsApps. Si una aplicación intenta escribir dentro de ese contenedor aislado, se topa con errores de permisos y puede fallar en tareas como guardar configuración o crear archivos temporales.

Para solventarlo, el Package Support Framework (PSF) permite introducir un lanzador intermedio y reglas de redirección que ajustan el comportamiento sin tocar el binario original. A nivel operativo, el flujo típico pasa por cuatro etapas:

1. Almacenar provisionalmente la app (staging) en un directorio local.
2. Crear el config.json de PSF e insertar los binarios PSF pertinentes.
3. Actualizar el AppxManifest para que el lanzador sea PSFLauncher.
4. Volver a empaquetar y firmar el paquete MSIX.

Este enfoque te permite reconfigurar el iniciador, añadir argumentos a través de PSF y redirigir rutas de trabajo, todo ello sin modificar el ejecutable original de la aplicación.

Herramientas necesarias para el flujo con PSF

Para implementar PSF y reempaquetar la app necesitarás:

• Cliente de NuGet (nuget.exe).
• Package Support Framework (Microsoft.PackageSupportFramework).
• Windows 10 SDK (versión reciente) con utilidades como makeappx y signtool.
• Sysinternals Process Monitor (opcional, muy útil para diagnosticar accesos a archivos y registro).

Descarga nuget.exe y colócalo, por ejemplo, en C:\\PSF\\nuget. Después, desde PowerShell con privilegios elevados, instala PSF vía NuGet en una carpeta de trabajo:

Set-Location "C:\\PSF"
.\nuget\nuget.exe install Microsoft.PackageSupportFramework

Para Windows 10 SDK, durante la instalación marca como mínimo: herramientas de firma para apps de escritorio, SDK para apps C++ UWP y los componentes de localización del SDK. Estas piezas aportan lo necesario para empaquetar y firmar.

Staging de la app: desempaquetar MSIX

Primero define variables para la ruta del paquete, carpeta de staging, arquitectura y versión del SDK. Un ejemplo de configuración sería:

$AppPath = "C:\\PSF\\SourceApp\\PSFSampleApp.msix"        # Instalador MSIX
$StagingFolder = "C:\\PSF\\Staging\\PSFSampleApp"         # Carpeta de staging
$OSArchitecture = "x$((gcim Win32_Processor).AddressWidth)"     # x64 o x86
$Win10SDKVersion = "10.0.19041.0"                              # Versión del SDK

Con el SDK instalado, usa makeappx para desempaquetar el MSIX en el staging:

Set-Location "${env:ProgramFiles(x86)}\\Windows Kits\\10\\Bin\\$Win10SDKVersion\\$OSArchitecture"
.\makeappx.exe unpack /p "$AppPath" /d "$StagingFolder"

Tras este paso, el contenido del paquete queda en una carpeta editable. Esto te permite añadir PSFLauncher, la runtime y el archivo de configuración JSON con los argumentos necesarios.

Crear config.json de PSF e insertar binarios

En el directorio de staging, crea un archivo config.json que describa cada aplicación dentro del paquete que requiera ajustes. La base mínima incluye id, executable y arguments:

{
  "applications": [
    {
      "id": "",
      "executable": "",
      "arguments": ""
    }
  ]
}

Abre el AppxManifest.xml del paquete y localiza el nodo <Application>. Toma el valor de su atributo Executable y úsalo en el campo executable de config.json; alinea también el id con el identificador de la aplicación en el manifiesto. Si procede, añade workingdirectory apuntando a la carpeta relativa adecuada.

Un ejemplo representativo de config.json con argumentos específicos:

{
  "applications": [
    {
      "id": "PSFSample",
      "executable": "VFS/ProgramFilesX64/PS Sample App/PSFSample.exe",
      "arguments": "/bootfromsettingshortcut"
    }
  ]
}

Desde el paquete de PSF descargado por NuGet, copia a la raíz del staging los binarios de tu arquitectura (x64/x86): PSFLauncher32/64.exe, PSFRuntime32/64.dll y PSFRunDll32/64.exe. Esto equipa al paquete con el lanzador y runtime de PSF.

Actualizar AppxManifest para usar PSFLauncher

Edita AppxManifest.xml y reemplaza el atributo Executable del nodo <Application> para que apunte a PSFLauncher32.exe o PSFLauncher64.exe, según corresponda. El EntryPoint suele mantenerse como Windows.FullTrustApplication:

<Applications>
  <Application Executable="PSFLauncher32.exe" EntryPoint="Windows.FullTrustApplication">
    ...
  </Application>
</Applications>

Con esto, el arranque real de la app pasa por PSFLauncher, que leerá tu config.json, inyectará argumentos y aplicará redirecciones de archivos/carpetas cuando sea necesario.

Reempaquetar y firmar el MSIX actualizado

Define variables para empaquetar y firmar el MSIX final: ruta de salida, certificado de firma de código y contraseña. Asegúrate de tener un certificado válido para firma.

$AppPath = "C:\\PSF\\SourceApp\\PSFSampleApp_Updated.msix"
$CodeSigningCert = "C:\\PSF\\Cert\\CodeSigningCertificate.pfx"
$CodeSigningPass = "<Password>"
$StagingFolder = "C:\\PSF\\Staging\\PSFSampleApp"
$OSArchitecture = "x$((gcim Win32_Processor).AddressWidth)"
$Win10SDKVersion = "10.0.19041.0"

Empaqueta desde el staging a un nuevo MSIX:

Set-Location "${env:ProgramFiles(x86)}\\Windows Kits\\10\\Bin\\$Win10SDKVersion\\$OSArchitecture"
.\makeappx.exe pack /p "$AppPath" /d "$StagingFolder"

Y firma el paquete usando signtool.exe del SDK:

Set-Location "${env:ProgramFiles(x86)}\\Windows Kits\\10\\Bin\\$Win10SDKVersion\\$OSArchitecture"
.\signtool.exe sign /v /fd sha256 /f $CodeSigningCert /p $CodeSigningPass $AppPath

Ahora dispones de un MSIX empaquetado con PSF que ejecuta el binario correcto con los argumentos requeridos, y con redirecciones en caso de que la aplicación lo necesite.

Método manual: crear un acceso directo con parámetro desde el Explorador

Si lo prefieres hacer a mano, el proceso gráfico es sencillo: botón derecho en el Escritorio > Nuevo > Acceso directo y, en la ubicación, introduce el ejecutable seguido del parámetro, por ejemplo:

"C:\\Rutas\\MiApp\\MiApp.exe" /EDev

Tras nombrarlo, abre sus Propiedades y ajusta, si lo necesitas, la Carpeta de inicio, el icono (Pestaña Acceso directo > Cambiar icono) y el atajo de teclado. Este método es rápido para validar argumentos como /EDev sin escribir scripts.

Generar el .lnk “sobre la marcha” en despliegues: de copiar a crear

Si tu paquete antes copiaba un “Internet Explorer.lnk” y ahora quieres que el proceso sea “sin contenido” (es decir, que el .lnk no exista en el paquete y se cree dinámicamente), PowerShell es la vía preferente en entornos modernos.

Un script .ps1 de ejemplo que podrías integrar en tu herramienta de despliegue:

$Shell = New-Object -ComObject WScript.Shell
$Shortcut = $Shell.CreateShortcut("$env:Public\\Desktop\\IE.lnk")
$Shortcut.TargetPath = "$env:ProgramFiles\\Internet Explorer\\iexplore.exe"
$Shortcut.Arguments = "https://intranet.empresa.local"
$Shortcut.WorkingDirectory = "$env:ProgramFiles\\Internet Explorer"
$Shortcut.IconLocation = "$env:ProgramFiles\\Internet Explorer\\iexplore.exe,0"
$Shortcut.Save()

Este enfoque evita distribuir archivos estáticos y te permite adaptar argumentos, iconos y rutas según el equipo o la política de la organización, todo ello en tiempo de ejecución.

Buenas prácticas y consejos rápidos

• Comprueba siempre el directorio de trabajo. Muchas apps asumen rutas relativas, por lo que si no fijas WorkingDirectory al del ejecutable, puedes obtener errores o comportamientos anómalos al cargar archivos de configuración.
• Escapa rutas y argumentos con espacios usando comillas dobles. En Accessos directos, el TargetPath suele ir entre comillas; los argumentos también pueden requerirlas si incluyen espacios o caracteres especiales.
• Si el atajo usa variables de entorno (%windir%, %ProgramFiles%), respétalas al crear el .lnk. Así, el acceso directo se mantendrá portátil entre máquinas con rutas distintas (por ejemplo, x86 vs x64).
• Para diagnósticos en MSIX, apóyate en Process Monitor. Verás qué intenta abrir la app, dónde falla por permisos y qué reglas de redirección necesitas en PSF.
• Versiona tus scripts .ps1 y documenta los argumentos. Un pequeño README junto al script ahorra tiempo cuando cambias parámetros como /perfil, switches de depuración o modos especiales de arranque.

Más ejemplos prácticos de WSH (inspirados en documentación clásica)

Variación focalizada en argumentos: abrir Visual FoxPro/Visual Studio con un archivo de configuración, fijando estilo de ventana, icono y carpeta de inicio:

Set WshShell = CreateObject("WScript.Shell")
Desktop = WshShell.SpecialFolders("Desktop")
Set S = WshShell.CreateShortcut(Desktop & "\\DevConfig.lnk")
S.WindowStyle = 7 ' Minimizada (0=Maximizada, 4=Normal)
S.IconLocation = "C:\\ruta\\builder.ico"
S.TargetPath = "C:\\Program Files\\Microsoft Visual Studio\\VFP98\\vfp6.exe"
S.Arguments = "-c \"C:\\Rutas\\config.fpw\""
S.WorkingDirectory = "C:\\"
S.Save

Atajo a una URL corporativa con extensión .URL. Útil para distribuir accesos a portales internos o manuales:

Set WshShell = CreateObject("WScript.Shell")
Desktop = WshShell.SpecialFolders("Desktop")
Set U = WshShell.CreateShortcut(Desktop & "\\PortalEmpresa.URL")
U.TargetPath = "https://intranet.empresa.local"
U.Save

Cuándo elegir cada método

PowerShell: ideal para despliegues modernos, GPO, Intune, SCCM y tareas de automatización. Es el método recomendado si no quieres distribuir .lnk prehechos.

WSH/VBScript: perfecto cuando heredas scripts antiguos o si necesitas mantener compatibilidad con entornos legacy. La API COM de WScript.Shell es estable y muy directa.

PSF con MSIX/AppX: imprescindible cuando el lanzador del menú Inicio exige parámetros o cuando una app empaquetada necesita redirecciones para funcionar correctamente. Permite ajustar comportamiento sin tocar el binario original.

Método manual: útil para pruebas rápidas, crear un atajo ad-hoc con un parámetro (como /EDev) o demostrar la viabilidad antes de automatizarlo con scripts.

Tanto si buscas añadir parámetros a un ejecutable desde su acceso directo, como si necesitas generar el .lnk “sobre la marcha” con PowerShell, o incluso si te toca lidiar con paquetes MSIX que requieren PSF, aquí tienes el repertorio completo: identificar argumentos en el menú Inicio, crear accesos directos con WSH/PowerShell, sortear limitaciones de herramientas que solo lanzan .exe y reempaquetar apps con PSF para que todo arranque tal y como espera el usuario.