Test batch/WSH (VBScript, JScript) lessons under Wine on Linux/macOS

[darkn3rd]

Motivation

While testing lessons/win_scripts/batch/run (a wrapper for running .cmd
lessons from git-bash/MSYS2/Cygwin), we noticed MSYS2 can hand .cmd/.bat
files straight to Windows' own CreateProcess, which auto-invokes cmd.exe
for you. That raised the question: could Wine provide the same kind of
bridge on real Linux/macOS, letting batch, wsh.vbscript, and
wsh.jscript run in CI (currently ubuntu-latest-only) and locally on
non-Windows machines, rather than being Windows-only?

Wine ships its own cmd.exe, cscript/wscript, and JScript/VBScript
engine implementations (jscript.dll/vbscript.dll) - built out because so
many real Windows installers depend on them - so this seems plausible
without heroics.

Proposed approach

1. Manual smoke test first (before any harness work): run each lesson
   category under Wine by hand:

   wine cmd /c a00.output.cmd
   wine cscript //Nologo a00.output.vbs
   wine cscript //Nologo a00.output.js

   Confirm how much of the existing lesson set actually passes as-is.
   Batch is the safer bet; WSH is the bigger unknown since scripts commonly
   reach into the broader COM object model (WScript.Shell,
   FileSystemObject, WScript.Arguments/StdIn), and Wine's coverage of
   those peripheral objects is patchier than the language engines
   themselves.

2. Harness changes (testbox/Script.rb) - native_unix? currently
   gates :cmd/:js/:vbs out entirely on real Linux/macOS (they're only
   ever expected to run under CommandShellScript/native Windows). Needs a
   real branch resolving to wine cmd/wine cscript instead of failing
   the "cannot find X on PATH" check, plus @@option/invocation_name
   adjustments since Wine changes the actual command line shape.

3. CI wiring (.github/workflows/ci.yml) - add batch, wsh.vbscript,
   wsh.jscript matrix entries on ubuntu-latest, with an "install Wine if
   missing" step matching the existing pwsh/dash/bc pattern already
   used for powershell/posix/bash.

Open questions / risks

• How complete is Wine's cmd.exe batch interpreter vs. real Windows for
  the constructs these lessons actually use (for, delayed expansion,
  goto)?
• Does Wine's WSH/COM coverage extend far enough for the d0/n0-style
  lessons that read input or enumerate environment variables?
• First-run Wine prefix initialization (Gecko/Mono prompts) needs to be
  handled non-interactively for CI.
• Performance overhead per invocation, multiplied across ~48 lessons per
  language, in a CI job.

Out of scope for now

No harness/CI changes until the manual smoke test in step 1 confirms this
is worth building.

[darkn3rd]

Implementation

1. Install Wine
   • macOS: brew install --cask wine-stable (or wine@staging for a more current build)
   • Linux (Debian/Ubuntu): sudo apt install wine (or winehq-stable from WineHQ's own repo for a newer version than the distro default)
2. First-time Setup
   Running any Wine command the first time auto-creates a default 64-bit prefix (~/.wine) and may pop up a Gecko/Mono installer prompt (needed for embedded IE/. NET support), which one can let it install, or skip it since these lessons won't need either. winecfg opens a GUI if one wants to inspect/configure the prefix manually, but it's optional for console-only testing.
3. Smoke-test batch

   cd lessons/win_scripts/batch/scripts
   wine cmd /c a00.output.cmd
   

4. Smoke-test WSH

   cd lessons/win_scripts/wsh.vbscript/scripts
   wine cscript //Nologo a00.output.vbs
   
   cd lessons/win_scripts/wsh.jscript/scripts
   wine cscript //Nologo a00.output.js

5. If it looks promising and you want it non-interactive later (e.g. for CI), WINEDEBUG=-all quiets Wine's own diagnostic noise, and pre-accepting/declining the Gecko/Mono prompt once locally avoids it ever blocking a headless run.

Once the basics are confirmed to work, running the full lesson set through the harness would mean adding a :cmd/:js/:vbs-under-Wine path to Script.rb (today native_unix? gates these out entirely on real POSIX), worth doing only after smoke tests show firsthand how much of the lesson set Wine actually handles correctly.

For ACT/GHA, the CI side is genuinely just a few lines, matching the existing "install if missing" pattern already in ci.yml for pwsh/dash/bc:

- name: Ensure Wine is available
  if: matrix.name == 'batch' || matrix.name == 'wsh.vbscript' || matrix.name == 'wsh.jscript'
  run: command -v wine || (sudo apt-get update -qq && sudo apt-get install -y wine)

The bigger piece is the harness itself, not CI config: Script.rb command method currently has native_unix? gate out :cmd/:js/:vbs entirely on real Linux/macOS (they're only ever expected to run under CommandShellScript/native Windows) — so it needs a real branch that resolves to wine cmd/wine cscript instead of failing the "cannot find X on PATH" check, plus @@option/invocation_name handling since Wine changes the actual command line shape. That's the part worth doing only after you've manually confirmed the lesson set actually passes under Wine — no point building harness plumbing around something that turns out to choke on, say, WScript.StdIn or a for /f construct.