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.

The Complex Geometry of Time: From Neolithic Benches to Imaginary Futures

If you map human progress on a standard, linear timeline, it is visually useless. 99.9% of the graph is an empty line of hunter-gatherers, and absolutely everything we consider “modern technology” is crammed into a microscopic sliver on the far right edge.

But, as geeks know, when you have data spanning massively different magnitudes, you switch to a logarithmic scale. If we plot the timeline where the x-axis represents log10(years ago), the picture changes entirely:

10^6 (1,000,000 years ago): Control of fire and early stone tools.
10^5 (100,000 years ago): Emergence of modern human language.
10^4 (10,000 years ago): The Agricultural Revolution and the invention of the bench.
10^3 (1,000 years ago): The printing press and the Renaissance.
10^2 (100 years ago): Harnessing electricity and flight.
10^1 (10 years ago): Cloud computing and the smartphone era.
10^0 (Today): Widespread generative AI and rapid code deployment.

The Discovery: The Future is Orthogonal

While the past is a solid, continuous line of real numbers, looking into the future on this scale requires us to take the logarithm of a negative number (negative “years ago”). This is algebraically impossible on a 1D number line, forcing us into complex numbers.

In Base-10, every future milestone exists exactly 1.36i units above the past on the complex plane. This means:

100 years in the future = 2 + 1.36i
1,000 years in the future = 3 + 1.36i

Importantly for the natural logarithm base e the constant is exactly πi

Here is the mathematical proof of this “complex number” theory using Euler’s formula ($e^{i\pi} = -1$):We can rewrite $-100$ as $100 \times -1$.Using logarithm rules, we split it: $\log_{10}(100) + \log_{10}(-1)$.We know $\log_{10}(100)$ is exactly $2$.To find $\log_{10}(-1)$, we use the natural log equivalence derived from Euler’s formula: $\ln(-1) = i\pi$.Using the change-of-base formula, $\log_{10}(-1) = \frac{i\pi}{\ln(10)}$.So, mathematically, 100 years in the future on this logarithmic timeline is exactly:$$2 + \frac{i\pi}{\ln(10)}$$

Mathematically, the future isn’t just “in front” of us; it is a parallel dimension floating 1.36 units away, running alongside the past but never touching it. Through a logarithmic lens, the milestones of human invention form a steady, evenly spaced progression, proving that our rate of innovation isn’t just fast—it is shifting our very geometry.

$$\log_{10}(-t) = \log_{10}(t) + \log_{10}(-1)$$

The $\log_{10}(t)$ part gives you the real number (the $2$ for 100 years, the $3$ for 1,000 years, the $4$ for 10,000 years).
The $\log_{10}(-1)$ part is the imaginary piece ($\frac{i\pi}{\ln(10)}$), which always evaluates to $1.364376… i$.