JWCEssentials, JWCCommandSpawn, and CrystalCatalystLibrary

I have been hard at work getting several of my foundational libraries ready to share more publicly.
The work has been spread across a few different layers, but the pieces are starting to fit together
in a way that feels important.

At the utility layer, JWCEssentials continues to grow into a practical collection of
building blocks for the larger NewAge ecosystem. One of the pieces I am especially happy with is
JWCCommandSpawn, a command-spawning utility designed to make process execution,
standard input, standard output, and standard error easier to coordinate from managed code.

Command execution sounds simple until you need it to be reliable, reusable, and flexible. Once pipes,
interactive input, output capture, environment setup, and cross-platform behavior enter the picture,
it becomes clear that this is a real infrastructure problem. JWCCommandSpawn is my answer to that
problem: a cleaner way to launch and communicate with external processes without rewriting the same
process-handling logic everywhere.

CrystalCatalystLibrary

The larger milestone is CrystalCatalystLibrary. This project is becoming my
cross-platform native and managed windowing/rendering substrate. It brings together native C++,
managed .NET, pixel presentation, window control, icons, cursors, drag/drop, clipboard work, and
Skia-based rendering.

Recently, CrystalCatalystLibrary gained support for custom cursors, standard cursors, window icons,
window titles, sizing, positioning, and SVG-to-pixel rendering through Skia. The native side now has
platform-specific support on Windows and Linux/X11, while the managed side can work with rendered
pixel data through a common PixData bridge.

One of the most exciting parts is that SVG assets can now become real window assets. An SVG can be
rendered through Skia, converted into PixData, and then used as a window icon, a custom cursor, or
displayed directly in a CrystalCatalyst window.

SVG
  -> Skia renderer
  -> PixData
  -> Window image, icon, or cursor

That means the same visual language can move through the whole stack. A project icon, a cursor, and
a demo animation can all share the same rendering path. That is exactly the kind of seam I like:
one layer of intent flowing through several layers of implementation.

The Managed and Native Bridge

A major part of the design is the bridge between managed and native code. The native layer provides
the platform-specific window behavior. The managed layer gives .NET projects a cleaner surface to use.
Between them is a C-style exported API and a PixData structure for moving pixel buffers across the
boundary.

This gives CrystalCatalystLibrary a practical shape:

Native platform window
  + exported C API
  + managed .NET wrapper
  + PixData interop
  + Skia/SVG rendering
  = CrystalCatalyst surface

This is still evolving, but it is now far enough along that it feels like a real foundation rather
than just an experiment.

Why This Matters

For a long time, I relied on Cairo-style drawing contexts in older projects. Moving toward Skia gives
me a modern drawing foundation that can be shared across applications and libraries. That does create
some version lock, but it also creates consistency. If the whole ecosystem draws through the same
rendering substrate, then icons, controls, cursors, animations, and future UI pieces can all speak
the same graphical language.

JWCEssentials helps with the practical utility layer. JWCCommandSpawn helps with process control.
CrystalCatalystLibrary helps with native windowing, rendering, and presentation. Together, they are
part of the same larger direction: building reusable infrastructure for NewAge, Sigmas, and the
broader set of tools I want to keep developing.

Repositories

The repositories are available from my GitHub profile:

https://github.com/johnwaynecornell?tab=repositories

This is one of those moments where the work starts to feel less like separate pieces and more like a
foundation. The command layer, the native layer, the managed layer, and the rendering layer are all
beginning to line up.

Utilities
  -> Process control
  -> Native windowing
  -> Managed rendering
  -> Reusable application substrate

That is the kind of progress I like to see.