---
name: launch_cpp_app_windows
kind: function
lang: bash
domain: infra
version: "1.1.0"
purity: impure
signature: "launch_cpp_app_windows(app_name: string, [desktop_dir: string]) -> void"
description: "Lanza un binario .exe en Windows desde WSL2. Asume que deploy_cpp_exe_to_windows ya copió el exe a Desktop/apps/<app_name>/. Usa cmd.exe /c start para desacoplar el proceso y retornar inmediatamente."
tags: [cpp, windows, launch, wsl, exe, cpp-windows]
uses_functions: []
uses_types: []
returns: []
returns_optional: false
error_type: "error_go_core"
imports: []
tested: false
tests: []
test_file_path: ""
file_path: "bash/functions/infra/launch_cpp_app_windows.sh"
params:
  - name: app_name
    desc: "Nombre de la app (ej: registry_dashboard). Localiza Desktop/apps/<app_name>/<app_name>.exe."
  - name: desktop_dir
    desc: "Override opcional del directorio escritorio Windows. Default: /mnt/c/Users/lucas/Desktop."
output: "Imprime 'OK: <app_name> launched at <ts>' en stdout si el exe existe y el comando se lanza. Errores fatales a stderr con exit 1."
---

## Ejemplo

```bash
source bash/functions/infra/launch_cpp_app_windows.sh

# Lanzar con default desktop dir
launch_cpp_app_windows "registry_dashboard"
# OK: registry_dashboard launched at 2026-05-14T10:32:01

# Override de desktop_dir (ej. otro usuario)
launch_cpp_app_windows "chart_demo" "/mnt/c/Users/otrouser/Desktop"
# OK: chart_demo launched at 2026-05-14T10:32:05
```

## Comportamiento

`cmd.exe /c start` es la clave: lanza el proceso en Windows y **retorna inmediatamente** sin esperar a que el exe termine. El proceso queda desacoplado del shell WSL2. Esta funcion **no verifica** que el exe arranco correctamente ni que sigue corriendo — esa responsabilidad recae en `is_cpp_app_running_windows` (funcion complementaria).

El `cd /d` previo al `start` es esencial: los apps C++ del registry buscan sus assets, `local_files/` y DLLs relativos al directorio de trabajo. Sin el `cd`, Windows buscaria desde `C:\Windows\System32` y el exe no encontraria nada.

## Prerequisitos

- **WSL2**: la funcion usa `wslpath -w` y `cmd.exe`, ambos solo disponibles en WSL2.
- **`/mnt/c/` montado**: el exe debe ser accesible via la ruta `/mnt/c/...`.
- **Exe ya copiado**: `deploy_cpp_exe_to_windows` debe haberse ejecutado antes. Esta funcion no compila ni copia nada.

## Notes

Mitad complementaria de `deploy_cpp_exe_to_windows_bash_infra`. El flujo completo para actualizar y relanzar una app es:

```bash
# 1. Compilar para Windows
build_cpp_windows "registry_dashboard"

# 2. Copiar al escritorio (mata proceso si corre, copia DLLs+assets)
deploy_cpp_exe_to_windows "registry_dashboard" "/home/lucas/fn_registry/apps/registry_dashboard"

# 3. Lanzar
launch_cpp_app_windows "registry_dashboard"
```

No se incluyen tests automatizados porque requieren entorno WSL2 con Windows activo y no son automatizables en CI.

## Gotchas

- Si `FN_REGISTRY_ROOT_WSL` no es tu ruta default de fn_registry (`/home/<user>/fn_registry`), setea la variable antes de invocar esta función: `FN_REGISTRY_ROOT_WSL=/ruta/custom launch_cpp_app_windows <app>`.
- El proceso hijo hereda `FN_REGISTRY_ROOT` como path Windows (backslashes) y `FN_REGISTRY_ROOT_WSL` como path Linux. En el exe C++, `py_resolve_interpreter()` usa `FN_REGISTRY_ROOT_WSL` para construir el invocation `wsl.exe -- /path/python3`.
- PowerShell escapa `$` con `\$` para evitar expansión de variables en el string del comando.

## Capability growth log

- v1.1.0 (2026-05-16) — auto-propaga `FN_REGISTRY_ROOT` (Windows path) + `FN_REGISTRY_ROOT_WSL` (Linux path) al proceso hijo para que pueda invocar WSL python via `wsl.exe`.