Public Software Projects

Public Software Projects

The public JWC software repositories form a growing cross-platform development ecosystem spanning native C and C++, modern .NET, windowing, graphics, image processing, mathematical utilities, process execution, and reusable software infrastructure.

Each repository has a distinct responsibility. Together, they provide a layered environment in which foundational utilities, operating-system services, managed libraries, rendering systems, and external tools can cooperate without being forced into one monolithic framework.

The projects are designed primarily for Linux and Windows development and reflect a consistent philosophy: acknowledge platform differences, isolate them deliberately, expose stable interoperability boundaries, and build reusable infrastructure from capabilities proven in real work.

A Layered Software Ecosystem

“`

These repositories are related, but they are not interchangeable. Each addresses a different level of the software stack. 

JWCEssentials
Foundational native utilities
Shared structures and build conventions
Workspace configuration and staging
         |
+--------+-----------------+
|                          |
v                          v
```

CrystalCatalystLibrary    JWCCommandSpawn
Windows and events        Processes and shells
Pixels and graphics       Pipes and external tools
Clipboard and input       Command integration
|                          |
+------------+-------------+
|
v
NewLib
Collections and execution structures
Mathematics and geometry
Typed image buffers
Skia interoperability
OpenGL rendering

“`

JWCEssentials establishes the common ground. CrystalCatalystLibrary and JWCCommandSpawn build two complementary forms of operating-system integration upon it. NewLib supplies the broader managed vocabulary through which higher-level applications, renderers, tools, and experiments can be constructed.

“`

JWCEssentials

“`

JWCEssentials is the foundational repository in the public ecosystem. It contains native C and C++ utilities, .NET support, public headers, reusable CMake definitions, and Bash tooling for configuring and staging a modular development workspace.

Its responsibilities include path conversion, transferable UTF-8 and array structures, terminal facilities, hashing, random-number generation, thread-local storage, build context, and predictable artifact placement.

More importantly, JWCEssentials establishes a common architectural vocabulary. It defines where public headers are exposed, how native and managed products are staged, how Linux and Windows implementations remain separated, and how independently maintained repositories can participate in one coordinated workspace.

Read the complete JWCEssentials overview

“`

CrystalCatalystLibrary

“`

CrystalCatalystLibrary provides the application-facing native surface of the ecosystem.

Its C++ layer owns platform-specific window behavior, while an exported ABI and managed .NET wrapper make that behavior available to higher-level applications. The library supports window creation, lifecycle management, keyboard and mouse events, focus, resizing, custom cursors, icons, direct pixel presentation, configurable OpenGL contexts, clipboard operations, and drag-and-drop.

A shared PixData structure acts as a common image currency between managed memory, native presentation, SkiaSharp, and OpenGL-oriented systems.

CrystalCatalystLibrary is intentionally a substrate rather than a complete widget framework. It provides somewhere to draw, somewhere to receive events, and somewhere for managed and native code to meet, while leaving higher-level interface design open.

Read the complete CrystalCatalystLibrary overview

“`

JWCCommandSpawn

“`

JWCCommandSpawn provides a reusable process-execution boundary for native and managed applications.

It supports launching external commands, selecting shells, configuring command-line escapement, connecting standard input, standard output, and standard error, reading and writing process streams, waiting for completion, and retrieving exit status.

Its shell-aware design recognizes that Bash, direct Windows command lines, cmd.exe, PowerShell, Python, and raw execution do not share one universal quoting or invocation model.

The managed layer also supports persistent command pipes. A Bash process, for example, can remain active while multiple logical commands are sent through it, allowing the session to retain its working directory, variables, functions, and other shell state.

Read the complete JWCCommandSpawn overview

“`

NewLib

“`

NewLib is the broad managed library and integration layer of the public ecosystem.

It is organized as a dependency ladder rather than one oversized assembly: 

Lightning.V1
 |
```

NewLib
|
NewLib_Crystal
|
GLInterop

“`

Lightning.V1 provides cursor-oriented collections, stacks, circular buffers, mutable execution through the Tape system, threading and batch tools, stream abstractions, dynamic dispatch, Fourier transforms, filters, splines, and general utilities.

The central NewLib assembly adds mathematical points and vectors, transformation matrices, cameras, frustums, generated pixel types, colors, palettes, paths, interpolation, typed Eisel image buffers, data utilities, and source-generation helpers.

NewLib_Crystal connects Eisel buffers with CrystalCatalyst PixData and SkiaSharp, allowing managed image memory to be temporarily exposed as a native pixel view, an SKBitmap, or a drawable SKCanvas.

GLInterop completes the current chain with a Silk.NET-based OpenGL layer containing textures, buffers, vertex arrays, shaders, programs, samplers, models, framebuffers, render-to-texture support, and screen-space rendering tools.

Read the complete NewLib overview

“`

Native and Managed Systems Working Together

“`

A defining characteristic of these projects is the deliberate cooperation between native and managed code.

Native libraries are used where direct operating-system access, process creation, window ownership, graphics contexts, or stable C-compatible boundaries are valuable. Managed libraries provide higher-level composition, mathematical types, rendering helpers, image abstractions, generated bindings, and application-facing APIs.

The boundary between them is treated as part of the design rather than as an implementation detail.

Strings, arrays, native handles, pixel buffers, callbacks, memory ownership, and resource lifetime all require explicit contracts. Structures such as utf8_string_struct, PixData, Eisel pixel leases, and exported procedural APIs make those contracts visible.

“`

Cross-Platform Without Ignoring the Platform

“`

The repositories primarily target Linux and Windows, but their portability model does not depend on pretending that the two systems are identical.

Platform-specific implementations are kept behind shared public capabilities. Linux and Windows may use different process APIs, window systems, graphics initialization paths, cursor mechanisms, path conventions, or data-transfer protocols. Those differences are isolated in designated platform layers rather than leaking unpredictably through the rest of the codebase.

This approach preserves access to meaningful native behavior while giving higher-level code a stable surface.

Portability does not require erasing platform differences. It requires giving those differences an intentional place.

“`

Selective Composition

“`

The ecosystem is modular by design.

A native utility can use JWCEssentials without adopting the managed graphics stack. A .NET process tool can use JWCCommandSpawn without creating a window. A mathematical application can use Lightning and NewLib without referencing SkiaSharp. A graphics application can add CrystalCatalyst and GLInterop when it needs native windows and GPU rendering.

Dependencies appear where their responsibilities begin.

This keeps the projects useful independently while allowing stronger capabilities to emerge when they are combined.

“`

Infrastructure Grown From Practical Work

“`

These repositories were not created as disconnected demonstrations.

Their components emerged from continuing work in graphics, symbolic processing, native interoperability, build automation, image systems, mathematical software, development tooling, and cross-platform applications.

A staging script became shared workspace infrastructure. A path conversion became a public native type. A pixel buffer became a bridge between managed arrays, Skia, OpenGL, and operating-system windows. A cursor-driven linked list became the basis for mutable execution. A command wrapper grew into a reusable shell and process layer.

This history matters because reusable infrastructure becomes most trustworthy when it has been pressured by real requirements.

“`

Development Principles

“`

Explicit Boundaries

Native and managed systems, operating systems, graphics APIs, process streams, and memory owners should meet through visible contracts.

Modular Responsibility

Foundational utilities, application surfaces, process execution, mathematics, image buffers, and rendering layers should remain separable even when they cooperate closely.

Platform Consciousness

Shared interfaces should simplify cross-platform development without concealing important operating-system realities.

Predictable Builds

Headers, native libraries, managed assemblies, executables, configurations, target frameworks, and platform lanes should be staged into known locations.

Selective Dependencies

Projects should not be forced to take graphics, native, or platform dependencies unless they use the capabilities those dependencies provide.

Generated Consistency

Repetitive interoperability declarations and strongly typed source families should be generated where generation improves consistency without weakening the public type system.

Infrastructure as Investment

A reusable solution to a recurring low-level problem can become more valuable than the original feature that caused it to be written.

“`

Current Scope and Continuing Development

“`

The public repositories contain a mixture of stable foundations, actively developed systems, and experimental extension points.

Some areas, such as core mathematical types, established collection structures, native workspace conventions, and principal interoperability seams, are already mature. Other areas—including newer OpenGL helpers, broader platform support, selected utilities, and experimental rendering patterns—continue to evolve.

The individual project pages describe these distinctions in more detail so that users can understand both what is currently dependable and where active development is taking place.

“`

Explore the Projects

“`

Each repository now has its own detailed page covering its architecture, major types, design decisions, current capabilities, and place within the wider ecosystem.

“`

Open Source

“`

JWCEssentials, CrystalCatalystLibrary, JWCCommandSpawn, and NewLib are publicly available for inspection, experimentation, and development.

Their publication marks an important step in making the architecture, tools, and accumulated infrastructure behind the wider body of work easier to discover and understand.

Individually, the repositories solve focused classes of problems. Together, they describe a cross-platform software environment built around explicit boundaries, reusable foundations, and the belief that well-designed infrastructure should remain useful beyond the project that first required it.

“`