# Crash BASIC 1.37.0 Release Notes

*~written by Crash-tan~*

## THE "YOUR GAME GETS ITS OWN .EXE NOW" UPDATE

Big one. Until today, "packaging" your game meant wrapping your
`.crashcart` next to a copy of the generic CrashPlayer and calling it a
day — your game launched *through* my player. Functional! But it was
never really *yours*. It had my name on the binary, my icon, my launcher
script holding your hand to the cart.

No more. As of 1.37.0, `crashplayer package` will **compile a real,
standalone executable for your game** — named after *your* game, wearing
*your* icon, opening *its* cart and nothing else, with no launcher script
in sight. And if your cart is sealed with an encryption key, the player
**bakes that key in** — so the executable and the cart are
cryptographically married. Your game can't be pried open by a stray
player, and your player won't run anyone else's cart. Tidy.

It "just works" the moment you have Rust installed. No setup, no flags,
no incantations. I notice `cargo`, I compile. You don't have one? Fine —
I quietly fall back to the old bundle-the-prebuilt-player path. No
toolchain, no problem; you just don't get the shiny custom binary.

---

## `crashplayer package`, reborn

Same command you already know:

```bash
crashplayer package mygame.crashcart "My Game" -o dist/
```

…but when Rust is on the machine, the output is different — and better:

| Before (1.36.x) | Now (1.37.0, with cargo present) |
|---|---|
| `crashplayer.exe` + your cart + a `.cmd`/`.sh` launcher | **`My Game.exe`** + its cart, run it directly |
| Generic CrashPlayer icon | **Your `icon.png`**, baked into the exe / `.app` / `.desktop` |
| Launcher script passes the cart path | The exe **knows its own cart** and opens it |
| One player, runs anything | A player built *for this game* |

The window settings you pass — `--window-size`, `--fullscreen`,
`--no-escape-exit` — get compiled *into* the player now, instead of being
shouted at it from a launcher script. The icon comes from the `icon.png`
you embedded in your cart (the IDE already puts it there); `--icon` is
still around if you want to override it.

And on Windows that icon is now **embedded in the `.exe` itself**, so
Explorer and the taskbar show your art instead of a generic gear.

---

## Locked players: one game, one key, one executable

This is the part the commercial folks have been waiting for.

Seal your cart with a 32-byte key, hand that same key to the packager,
and the compiled player **embeds it**:

```bash
crashplayer package mygame.crashcart "My Game" --key <64-hex-chars> -o dist/
```

Now:

- The player is the **only** thing that can decrypt and run that cart —
  the key never ships as a loose file, it's compiled into the binary.
- A cart sealed with a *different* key won't open in your player. A
  *different* player can't open *your* cart. Bound, both directions.
- The "Powered by Crash BASIC" splash and your license stamp still ride
  along inside the runtime where nobody can skip them. (Nice try.)

No key? Then nothing's locked — you get an ordinary compiled player for
an ordinary cart, and everything's all-zeros under the hood like always.
The key *locks*; it isn't the on-switch. **`cargo` is the only on-switch.**

---

## The launcher learned about keys

The GUI packager (the **📦 Package** tab) grew an **Encryption key**
field, because here's the thing about a locked cart: I can't even *read*
it to pull out the name and icon without the key. So now, when you drop
a sealed cart onto the Package tab and I can't crack it, I'll tell you:

> 🔒 This crashcart is encrypted — enter the key it was sealed with to read and package it.

Paste the key in, and watch the name and icon snap into place as I
decrypt it live. Then package away. Same key, two jobs — opening the cart
*and* getting baked into the player.

---

## Under the hood (for the curious / the embedders)

To make all this possible without recompiling the entire universe every
time you package a game, the whole desktop runtime — window, splash,
interpreter, renderer, the lot — got lifted out of the player binary into
a proper reusable library (`crashcore::desktop_runtime`). The generated
players don't rebuild me from scratch; they link a **prebuilt runtime
library** that's published to the CDN alongside every CrashPlayer release,
one per platform. The exe your `cargo build` spits out is a tiny shim;
the 40-megabyte brain rides along beside it.

That library has a stable little C ABI too (`crashcore-ffi`), which means
"embed CrashBASIC inside your own native app" is now a real, if
early-days, thing. More on that another day.

---

## Known issue (honesty corner)

If you leave the **launcher window** (not a game — the launcher itself)
sitting open for a *long* time on an older Intel integrated GPU, the
Intel OpenGL driver can throw a wobbly and crash (`ig9icd64.dll`, an
access violation). It's the launcher's GUI toolkit going through Intel's
crusty old GL driver, not anything in your game — games render through a
completely different path and are unaffected. Low-impact, on the list,
getting fixed in a patch. Until then: don't use my menu as a screensaver. 💤

---

*Go make something. Lock it up. Ship it. — Crash-tan*
