The Problem

Enterprises that need an ad‑hoc way to show a desktop or a single window to remote participants often resort to proprietary tools that require paid licences or cloud services. When the network is isolated or the budget is tight, a lightweight, self‑hosted screen‑share client is missing.

What This Does

OpenScreen is a Windows‑only desktop application that captures the screen (full desktop or a specific window) and streams the frames over HTTP as an MJPEG video. The core capture logic lives in OpenScreen.Core/Screenshot/ (Screenshot.cs, Resolution.cs, Fps.cs) and the network layer in OpenScreen.Core/Server/ (StreamingServer.cs, ServerSocketExtension.cs, ServerConfig.cs). The UI layer (OpenScreen.xaml / OpenScreen.xaml.cs) provides a simple WPF front‑end that lets the user pick a source, toggle the cursor, and adjust quality/FPS. All three projects (OpenScreen, OpenScreen.Core, OpenScreen.Installer) are wired together by the solution file OpenScreen.sln.

How It Is Wired

Execution starts when the compiled OpenScreen.exe is launched (the entry point is the App class in OpenScreen/App.xaml.cs). The App constructor loads App.config, then creates the main window defined in OpenScreen/OpenScreen.xaml. The window’s code‑behind (OpenScreen.xaml.cs) reacts to UI actions:

  1. Source selection → calls Screenshot.StartCapture(...) in OpenScreen.Core/Screenshot/Screenshot.cs.
  2. Capture loop → Screenshot emits raw bitmap frames at the configured FPS (Fps.cs).
  3. Encoding → each bitmap is fed to MjpegWriter (OpenScreen.Core/Mjpeg/MjpegWriter.cs) which builds an MJPEG multipart stream.
  4. Network → StreamingServer.Start() (OpenScreen.Core/Server/StreamingServer.cs) opens a TCP listener (configured in ServerConfig.cs) and writes the MJPEG stream to each client connection via ServerSocketExtension.

The UI does not touch the file system beyond reading the static resources in Images/ and the icon files. No database access exists. The only external side‑effect is the network socket opened by StreamingServer. The call graph is shallow: UI → Screenshot → MjpegWriter → StreamingServer. No circular dependencies were detected.

How To Use It

# Clone the upstream repository
git clone https://github.com/moses-y/OpenScreen.git
cd OpenScreen

# Build the solution (requires Visual Studio 2019 or MSBuild for .NET Framework 4.7.2)
msbuild OpenScreen.sln /p:Configuration=Release

# Run the application
./OpenScreen/bin/Release/OpenScreen.exe

The application reads its settings from OpenScreen/App.config (e.g., default port, FPS). No environment variables or secret keys are required.

Real‑World Use

A support engineer can start OpenScreen.exe on a Windows workstation, select the “Application window” mode, choose the help‑desk tool, and share the generated http://<host>:<port>/ URL with a remote colleague. The colleague opens the URL in any browser (desktop, tablet, or phone) and sees a live MJPEG feed without installing additional software.

Code Health & Issues

  • HIGH – Add a test suite – 19 source files, no test files. Without tests any change risks silent regression.
  • HIGH – Add a CI workflow – No CI configuration present. Automating the build and (future) tests prevents broken merges.
  • HIGH – Cognitive load – Deep nesting (max indentation depth 9) in OpenScreen/OpenScreen.xaml.cs, OpenScreen/Properties/AssemblyInfo.cs, and OpenScreen.Core/Screenshot/Screenshot.cs makes control flow hard to follow. Refactor with early returns or extract inner blocks.
  • MEDIUM – Duplicated code – Repeated 6‑line blocks across the four AssemblyInfo/Resources/Settings designer files. Consolidate shared logic into a helper to follow DRY principles.

No licence issues (MIT present), no Dockerfile, no committed secrets.

The Bottom Line

OpenScreen delivers a functional, self‑hosted screen‑sharing client with a clear separation between capture, encoding, and networking. The codebase is small enough to understand quickly, but it suffers from deep nesting, duplicated boilerplate, and a complete lack of automated testing or CI. It is suitable for teams that can invest a few days to add tests and a build pipeline, after which it can serve low‑risk internal demo or support scenarios.