Offer the service on Win7+ by feature-detecting, not version-gating
Replaces the hardcoded "Windows 10 or newer" gate on the Service menu with a
runtime capability probe (ServiceCapability). It tries to load the .NET
service machinery (System.ServiceProcess) and offers the Service menu wherever
that succeeds -- including Windows 7 if the service layer loads there, which is
what Ed asked for ("install on Win7 or above"). If the assembly can't load on
an older/unsupported Windows, the probe catches it and the menu is simply
hidden, so such a machine can never be crashed by it.
Safety by construction: the reference to the service types lives only in the
NoInlining Probe method, so the assembly load is triggered by the CALL from
IsAvailable (inside its try/catch) and is catchable -- not during JIT of the
caller, which would be fatal. The startup path stays service-type-free via
ServiceEntry, so this probe runs only at window construction, never at launch.
Probe uses the parameterless ServiceController ctor: it forces the assembly to
load but touches no service and no SCM. (First cut read .ServiceName on a
made-up name, which actually queries the SCM and threw "service not found" --
the self-test caught that it was hiding the menu on Windows 11 too.)
New self-test "Service capability probe": available + cached + never throws on
the Win10/11 gate runner. Gate 30/30.
Note: this makes the service INSTALLABLE on Win7 wherever the layer loads; it
does not prove the service RUNS there (Session-0 capture on an unsupported
runtime) -- only a real test on the Win7 box can confirm that.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
co-authored by
Claude Opus 4.8
parent
9392cc1fcc
commit
2dad00c42f
@@ -2182,12 +2182,14 @@ public sealed class MainForm : Form
|
||||
// and the arrow keys.
|
||||
menu.Items.Add(fileMenu);
|
||||
menu.Items.Add(recordMenu);
|
||||
// The send-only Windows service is a Windows 10+ feature: it was built and tested there, and on
|
||||
// older Windows the System.ServiceProcess assembly it relies on won't even load under .NET 10. Only
|
||||
// offer the Service menu where it can actually work — on Win7/8 it simply isn't shown and no service
|
||||
// code is ever reached. (Mirrors how "capture individual apps" is gated to the versions that support
|
||||
// it.) The startup path is already load-safe via ServiceEntry; this keeps the menu load-safe too.
|
||||
if (OperatingSystem.IsWindowsVersionAtLeast(10, 0))
|
||||
// Offer the Service menu wherever the send-only service can actually run — feature-detected, not
|
||||
// gated on a Windows version, so it appears on Windows 7 too if the .NET service layer loads there
|
||||
// (Ed's ask: install on "Win7 or above" wherever it's supported). ServiceCapability probes safely:
|
||||
// if System.ServiceProcess can't load on this OS, it catches that and the menu is simply hidden, so
|
||||
// an older Windows can never be crashed by it. The startup path is already service-type-free via
|
||||
// ServiceEntry, so this probe (at window construction, never at launch) is the only place that
|
||||
// decides visibility.
|
||||
if (ServiceCapability.IsAvailable())
|
||||
menu.Items.Add(BuildServiceMenu());
|
||||
menu.Items.Add(optionsMenu);
|
||||
menu.Items.Add(helpMenu);
|
||||
|
||||
Reference in New Issue
Block a user