Measured rather than guessed: the whole repository was cross-compiled for
linux/amd64 and the gaps closed one by one. There were fewer than expected.
Flex and TCI were never Windows-specific — they carried //go:build windows by
inheritance and import nothing but net and gorilla/websocket. Untagged, no code
change. The two backends a Linux operator is most likely to own were already
portable.
Audio was 560 lines, not 2287: only devices.go and engine.go touch WASAPI, while
manager.go, recorder.go, wav.go and mp3.go were pure Go wearing the tag by
association. The whole platform surface is seven functions, now implemented a
second time on PulseAudio through github.com/jfreymuth/pulse — pure Go over the
server socket, so the no-cgo rule survives, and PipeWire answers the same
protocol. The fixed 16 kHz mono format and the server-side resampling mirror
what AUTOCONVERTPCM does on Windows, for the same reason.
OmniRig is the only real loss, and its backend still EXISTS off Windows rather
than being compiled out of app.go: a settings database is portable, so an
operator moving a profile across keeps "omnirig" saved and must be told to pick
a native backend instead of meeting a nil one.
The parts where Linux is not Windows, and where a compile-only stub would have
been a silent bug:
- data dir: still beside the binary, but ~/.local/share/OpsLog/data when that
folder belongs to the system — decided by trying the write, because /opt and
/usr/local are writable on some stations and not others.
- single instance: an flock, not a pid file. The kernel drops it however the
process dies, so a crash leaves nothing to delete by hand. This is the guard
that stops two instances fighting over the rig frequency.
- update: simpler here. Unix renames over a running binary, so the deferred
swap the Windows path needs a detached helper for is unreachable.
- tasklist/taskkill become /proc and SIGTERM; the boot log moves out of /tmp,
which is wiped exactly when the evidence is wanted.
- serial ports sorted naturally: /dev/ttyUSB10 was landing between USB1 and
USB2, the same trap COM10 fell into.
release.ps1 now cross-builds and vets for linux before it builds the exe, and
refuses the release if that fails — a port rots one unguarded x/sys/windows call
at a time.
Nothing has been executed on Linux yet: Wails needs webkit2gtk and cgo there, so
the binary must be built on Linux. scripts/linux-setup.sh checks the machine and
does it; BUILDING-LINUX.md is the manual version.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Confirmed on the machine that started this: an 'Edge blocker' utility was
in the way, and unblocking Edge fixed the launch.
Those tools work by registering a Debugger entry under Image File
Execution Options for msedge.exe and msedgewebview2.exe, so Windows
refuses to run the process. The runtime is installed and registers its
version quite happily — which is why the logs showed WebView2 present —
and then never starts. OpsLog draws its whole interface with that engine,
so the window never opened: no error, no crash, a process sitting there
doing nothing.
That entry is read at startup now and said plainly, in the log and on
screen, with the one thing that helps: unblock Edge in the tool that
blocked it. Reinstalling OpsLog cannot fix a machine in this state, and
that is where an unexplained silence sends people.
Also logs the Windows build and which Edge policies are set — value names
only, never their contents: a policy key holds URLs and account names
that are nobody's business here.
'The Evergreen installer will not install either' moves the problem out
of OpsLog's reach: the runtime is a Windows component, and on a managed,
offline or otherwise locked-down machine it may simply refuse.
Microsoft publishes the same runtime in a FIXED VERSION form — a folder
an application carries and points at, needing no installation and no
administrator. That is exactly this case, so OpsLog now looks for it
beside its own executable and uses it when it is there. The versioned
subfolder the download unpacks into is handled, because asking someone to
flatten it by hand is one more step to get wrong on a machine where
nothing starts.
No setting for it: that would be a question asked of the one operator
least able to answer it. The folder is either there or it is not.
The startup log also records the Windows build — the first thing anyone
diagnosing a runtime that will not install is going to ask for.
His log reaches 'entering wails.Run' and stops: WebView2 is installed
(120.0.2210.91) and never hands control back. A hang, not a failure —
there is no error to report, so the two remaining causes have to be
addressed rather than diagnosed.
The profile folder is now named explicitly, on the LOCAL disk. Wails
defaults it into the ROAMING profile, which on a managed account can be
redirected to a share; a WebView2 profile on a share that is slow or gone
does not fail, it hangs. Naming it also gives someone a folder they can
be told to delete, which is the fix when the profile itself is corrupt.
And a marker is written before the window is attempted, removed when it
paints. Finding it at the next launch means the last one never got there,
so that launch runs with GPU acceleration off: a WebView2 that cannot get
on with the graphics driver hangs exactly like one that cannot start, and
this is the single lever that separates them — at no cost on machines
where it was never the problem.
The data folder is created and stays empty, the process keeps running,
and no window appears. Nothing returns, so nothing is logged: WebView2
never hands control back, and a hang has no error to report.
So the ABSENCE of progress is reported. If OnStartup has not been reached
twelve seconds after wails.Run, that is written to the startup log and
shown in a message box naming the two causes — a missing WebView2 runtime
and an antivirus blocking msedgewebview2.exe — because 'OpsLog is not
responding' otherwise sends people to reinstall OpsLog, which is the one
thing that cannot help: the part that has not started is not ours.
Reported from a Windows 10 machine: the process appears, no data folder
is created, nothing starts. There was nothing to read because the only
log OpsLog has lives inside the folder that was never created.
Three exits happen before any window or log exists, and all three were
silent. Another instance already running — correct to refuse, since two
would fight over the rig, but indistinguishable from a crash. The data
folder unwritable — it is created BESIDE the executable, so a copy
dropped into Program Files is refused by Windows outright. And wails.Run
failing, which is where a missing WebView2 runtime lands; its error went
to println, which in a GUI-subsystem program goes nowhere at all.
Each now writes to %LOCALAPPDATA%\OpsLog\startup.log — a folder Windows
guarantees the user can write to, whatever OpsLog was installed into —
and shows a message box naming the fault and what to do about it.
rouggyandClaude Opus 5