kcc v1.4.0 now including MacOS 14 (x86_64) and up version

Krypton 1.4.0 — Release Notes

Released: 2026-04-27

Headline

Native binaries everywhere. C is no longer the default on any platform.

kcc.sh hello.k now produces a native executable directly — ELF on Linux, PE on Windows, Mach-O on macOS. No intermediate C step in the user-visible pipeline. C output is opt-in via --c.

---

Highlights

• macOS native pipeline — new kompiler/macho.k backend lands a working Mach-O backend on macOS Tahoe (26.x).
• kcc.sh default flipped from C → native — kcc.sh foo.k now produces a binary, not a .c file.
• Bracketless jxt syntax — cleaner imports.
• 8 new ELF builtins — printErr, charCode, fromCharCode, exit, isDigit, isAlpha, abs, startsWith.
• Bug fix — jxt { k "..." } no longer hangs the compiler.

---

macOS — Native Mach-O Pipeline

What works

./kcc.sh hello.k                # produces ./hello, runs natively on macOS
./hello

The pipeline: .k → kcc --ir → kompiler/macho.k → .s → clang → Mach-O.

clang is invoked as the assembler+linker (not as a C compiler) — macho.k emits AT&T-syntax assembly, clang handles dyld scaffolding, libSystem linkage, and code signing in one step.

Why through clang on macOS but not Linux/Windows

macOS Tahoe (26.x)+ AMFI silently SIGKILLs hand-rolled static binaries even when properly code-signed. We exhausted the cheap fixes (LINKEDIT segment, valid CODE_SIGNATURE, MH_PIE, RIP-relative addressing — codesign succeeded each time, kernel still rejected). Apple effectively requires dyld-linked Mach-Os, which clang+ld64 produce automatically. The pragmatic call is to let clang handle the complexity it owns.

kompiler/elf.k (Linux) and kompiler/x64.k (Windows) continue to emit final binaries directly, no external linker — those kernels accept hand-rolled static binaries.

IR coverage in macho.k

IR op	Status
FUNC __main__ / FUNC <name>	✓ x86_64 + arm64
PARAM / LOCAL / STORE / LOAD	✓ x86_64 + arm64 (LOAD param via positive RBP offset, LOAD local via negative)
PUSH "string"	✓ x86_64 + arm64 (string interned to __cstring section)
PUSH <int>	✓ x86_64 + arm64
ADD / SUB / MUL / DIV / MOD	✓ x86_64 + arm64 (numeric only — string-concat dispatch is future work)
EQ / NEQ / LT / GT / LTE / GTE	✓ x86_64 + arm64
LABEL / JUMP / JUMPIFNOT	✓ x86_64 + arm64
BUILTIN kp 1	✓ x86_64 + arm64 (uses libSystem _puts)
CALL <name> <argc>	✓ x86_64 (with stack-alignment padding for odd argc); arm64 stubbed (TODO)
RETURN / END / POP	✓ x86_64 + arm64

Building on macOS — first time

Requires Xcode Command Line Tools:

xcode-select --install                                  # one-time setup; provides clang, as, ld, codesign, git
git clone https://github.com/t3m3d/krypton && cd krypton
./build.sh                                              # compiles kcc from kcc_seed.c via clang (~30s)
./kcc --version                                         # kcc version 1.4.0

Then any of:

./kcc.sh hello.k                                        # default: native Mach-O at ./hello
./hello

./kcc.sh hello.k -o myapp                               # explicit output name
./myapp

./verify_macho.sh                                       # runs both hardcoded + IR-driven smoke tests

Optional: install globally

./install.sh                                            # symlinks ./kcc → /usr/local/bin/kcc
kcc --version                                           # works from anywhere

Optional: ship as a prebuilt seed

After a successful ./build.sh, you can ship the resulting binary so future macOS users skip the source-compile step:

cp ./kcc bootstrap/kcc_seed_macos_x86_64                # Intel Mac
# or
cp ./kcc bootstrap/kcc_seed_macos_aarch64               # Apple Silicon
git add bootstrap/kcc_seed_macos_*
git commit -m "bootstrap: ship prebuilt macOS kcc seed"
git push

After that, fresh clones on the same arch will detect the prebuilt and cp it directly — no clang compile needed for the seed.

What's NOT yet supported on macOS

• ARM64 CALL (multi-function programs on Apple Silicon need register-based arg marshalling — currently stubbed with a TODO)
• String concatenation via ADD (numeric ADD works; string + doesn't)
• Most non-kp builtins (toStr, toInt, substring, etc.) — would each need a libSystem helper mapping
• macOS prebuilt seed in bootstrap/ — must be built and shipped from a Mac

---

kcc.sh Default Flipped: C → Native

New behavior

kcc.sh foo.k                    # native binary at ./foo (was: C source to stdout)
kcc.sh foo.k -o bar             # native binary at ./bar (unchanged)
kcc.sh --c foo.k                # C source to stdout (legacy mode, opt-in)
kcc.sh --c foo.k -o foo.c       # C source to file
kcc.sh --gcc foo.k              # native binary, but routed through C+gcc internally
kcc.sh --llvm foo.k -o foo.ll   # LLVM IR
kcc.sh --ir foo.k               # Krypton IR (.kir) to stdout

Breaking change

If you have scripts that relied on kcc.sh foo.k printing C source to stdout, add --c:

# Old (broken now):
./kcc.sh hello.k > hello.c

# New (explicit C):
./kcc.sh --c hello.k > hello.c
# or:
./kcc.sh --c hello.k -o hello.c

---

New Syntax: Bracketless jxt

Imports without braces. Each line is inc "path"; extension routes the include (.k → Krypton module, .h / .krh → C header).

jxt
inc "stdlib/result.k"
inc "stdlib/math_utils.k"

just run {
    kp(isPrime("17"))
}

The block ends at the first non-inc token (typically func, let, or just run). Old brace form is fully backwards-compatible.

---

ELF Backend — 8 New Builtins

Hand-emitted machine code, available on the Linux native pipeline:

Builtin	Bytes	Notes
printErr(s)	37	Like kp but writes to stderr (fd 2)
charCode(s)	4	First byte as integer
fromCharCode(n)	23	1-char string from byte value
exit(n)	16	SYS_exit(atoi(n)), does not return
isDigit(s)	16	1 if first byte is '0'..'9', else 0
isAlpha(s)	19	1 if first byte is A-Z or a-z
abs(n)	14	|n| via atoi + neg
startsWith(s, prefix)	27	1 if s begins with prefix

All ELF builtins as of 1.4.0

kp, printErr, toStr, toInt, length, len, split, range, arg, argCount, substring, sbNew, sbAppend, sbToString, readFile, writeFile, charCode, fromCharCode, isDigit, isAlpha, abs, exit, startsWith, plus s[i] indexing.

---

Bug Fix: jxt { k "..." } Infinite Loop

The k branch of kompiler/compile.k's jxt-block parser was missing a jxtPos += 2 advance that the c and t branches had. Any program using jxt { k "..." } would hang kcc forever — affecting --ir, the C backend, and --native.

Discovered while testing the new bracketless syntax. Fixed.

---

Verification

• All 23 ELF regression programs still pass on Linux
• verify_macho.sh (both hardcoded + IR-driven phases) PASSES on macOS Tahoe 26.3 / Darwin 25.3.0 x86_64
• Self-host clean: ./kcc kompiler/compile.k produces byte-identical C output between old and new compilers
• Tested IR-driven examples on Mac: kp("..."), let x = ..., if x > y { ... }, func square(n) { emit n * n }; emit square(7) — all produce correct Mach-O binaries that run

---

Upgrading

git pull
./build.sh         # Linux/macOS/WSL
bootstrap.bat      # Windows

If you have scripts that piped kcc.sh foo.k > foo.c, update them to kcc.sh --c foo.k > foo.c.

---

What's Next

• ARM64 CALL support in macho.k (register-based arg marshalling)
• String concat / smart-int dispatch in macho.k's ADD
• More macho.k builtins (toStr, toInt, substring, etc. via libSystem helpers)
• Prebuilt macOS seeds for bootstrap/ (built on a Mac, shipped to repo)
• Eventually retire compile.k's C emission + bootstrap/kcc_seed.c once macOS prebuilts cover all common archs

---

Krypton 1.4.0 — t3m3d/krypton — Apache 2.0

kcc v1.3.7

Krypton 1.3.7 — Self-Hosted kcc on Bootstrap Runtime

Release date: 2026-04-25

This release closes the loop on Phase 3: a Krypton-built kcc_native.exe (compiled with ./kcc.sh --native kompiler/compile.k -o kcc_native.exe) can now read source files, parse arguments, emit valid C, and round-trip correctly. The output compiles with gcc and runs as expected. kcc_native.exe can also re-compile kompiler/compile.k itself.

This is the first version where the compiler is genuinely self-hosting on top of the kernel32-only bootstrap krypton_rt.dll — no krypton_rt_legacy.dll, no C runtime dependency in the runtime DLL.

Fixed — Four bootstrap-DLL bugs that blocked self-hosting

All four lived in kompiler/x64.k:emitBootstrapHelpers, which hand-emits machine code for krypton_rt.dll.

1. kr_argcount returned 1 always

The loop body did MOV AL, [RAX] to read each char of the cmdline, which clobbers the low byte of the cmdline pointer in RAX. After one iteration RAX no longer pointed at valid memory and INC RAX walked into garbage that happened to be 0, ending the loop with ECX=0.

Fix: read into DL instead of AL so RAX stays intact. Also dropped the trailing INC ECX so the result equals the number of spaces (= number of user args), matching the argCount() == 0 convention compile.k already used.

2. kr_arg segfaulted on every call

Three independent bugs:

• MOV RSI, RCX immediately after MOV RSI, RAX overwrote the saved cmdline pointer with the index-string pointer.
• Two JMP rel8 instructions had displacements landing mid-instruction.
• The function NUL-terminated the in-place cmdline before calling __rt_strdup. On Windows the buffer returned by GetCommandLineA is sometimes read-only, so the write itself crashed.

Fix: rewrote the function to walk to the start of the requested token, find its length, allocate len+1 bytes, copy, and NUL-terminate the copy — never touches the original cmdline.

3. kr_readfile called CreateFileA with garbage args

MOV R8D, 0x80000000   ; should have been EDX (dwDesiredAccess)
XOR EDX, EDX
XOR ECX, ECX          ; clobbered the path pointer
MOV R9D, 1            ; should have been R8D (dwShareMode)
XOR R8, R8
CALL [CreateFileA]    ; RCX=0, EDX=0, R8=0, R9=1 — all wrong

Additionally, every IAT call displacement was off by 7-19 bytes (computed for an instruction layout that no longer matched the actual emitted bytes). The function landed somewhere inside the IAT or jumped into the wrong function.

Fix: rewrote with proper Win64 ABI argument setup (RCX=path, EDX=GENERIC_READ, R8D=FILE_SHARE_READ, R9=NULL, stack args at [RSP+0x20/0x28/0x30] for OPEN_EXISTING / FILE_ATTRIBUTE_NORMAL / NULL) and recomputed every disp from the actual byte offsets.

4. kr_writefile had the same broken-args pattern as kr_readfile

Rewrote with the same fix template. CreateFileA now gets a real path, GENERIC_WRITE in EDX, share=0, sa=NULL, and CREATE_ALWAYS / FILE_ATTRIBUTE_NORMAL / NULL as stack args.

Other changes

• bsHelperBlockSize bumped 5638 → 5681 to fit the rewrites (+47 bytes net).
• Verified no kryofetch regression — kryofetch still renders end-to-end with the bootstrap krypton_rt.dll.
• Verified kcc_native.exe round-trip: it compiles compile.k, the resulting C compiles with gcc, the resulting binary compiles compile.k again. Output is valid runnable C in both passes (byte-exact reproduction is not yet a goal).

Known limitations

• Stub functions still returning empty strings (rarely used in practice): kr_init_args, kr_writebytes, kr_hex, kr_environ, kr_bufsetbyte.
• The native pipeline (kcc.sh --native) still requires bash because it chains three sub-binaries. Replacing kcc.sh with a Krypton driver is blocked on adding CreateProcessA + WaitForSingleObject + GetExitCodeProcess wrappers and a run() builtin. Targeted for 1.3.8.

kcc v1.3.4

Krypton Compiler v1.3.4 Release Notes

Date: April 17, 2026

SUMMARY

v1.3.4 delivers Phase 1 of the Krypton self-hosting roadmap (raw memory
primitives) plus critical memory leak fixes in the native compiler pipeline.

NEW FEATURES

Phase 1 — Raw Memory Primitives
Nine new built-in functions added to krypton_rt.dll and exposed via
headers/memory.krh. These enable direct heap and pointer operations
from Krypton code, laying the groundwork for writing the runtime in
Krypton itself.

rawAlloc(size)              - allocate N bytes (no magic header)
rawFree(ptr)                - free a raw pointer
rawRealloc(ptr, size)       - resize a raw allocation
ptrAdd(ptr, n)              - pointer arithmetic (ptr + n)
ptrToInt(ptr)               - pointer to 64-bit integer string
rawReadByte(ptr, offset)    - read 1 byte at ptr+offset
rawReadWord(ptr, offset)    - read 2 bytes (unsigned) at ptr+offset
rawWriteWord(ptr, offset, val)  - write 2 bytes at ptr+offset
rawWriteQword(ptr, offset, val) - write 8 bytes at ptr+offset

Usage: add import "memory.krh" to your Krypton source.
All 9 functions pass full unit tests.

BUG FIXES

Memory Leak Fixes (Krypton source — compile.k and x64.k)
The native kcc pipeline previously used O(n^2) string concatenation
in hot paths, causing runaway RAM usage on larger programs (confirmed
maxing 64 GB during compilation). Fixed by converting to sbAppend:

compile.k
- irBlockIR(): replaced code = code + pairVal(sp) loop with
sbNew/sbAppend/sbToString. This is the deepest recursive path
called for every block in every function — biggest win.
- IR assembly (irMode path): replaced irOut = irOut + ... loop
over all functions with sbAppend accumulation.

x64.k
- buildImportTable(): converted all 5 ILT/IAT builder loops and
the hint table builder loop to sbAppend. These run once per
compilation but each loop grew a string O(n^2) over the full
function list.

x64_host_new.exe IAT Directory Fix
DataDirectory[12] (IAT RVA) was incorrectly set to the Import
Directory RVA instead of the actual FirstThunk array RVA. This
caused generated PE64 executables to crash on load. Fixed in
emitPEHeader() and deployed in x64_host_new.exe.

x64_host_new.exe Recovered
The working 497 KB x64_host_new.exe was accidentally overwritten
with a broken build. Recovered by bootstrapping from x64.k via
kcc_v127 (GCC mode) + patched kr_writebytes for the xNN hex format.

System Headers Default Path
kcc now defaults to C:\krypton\headers when --headers is not
specified. Programs that ship alongside a krypton install no longer
need to bundle headers or pass --headers explicitly.

KNOWN LIMITATIONS

• Linear string allocation leak still present in krypton_rt.dll
  (kr_plus and all string ops HeapAlloc without freeing). The O(n^2)
  explosion is gone but linear growth remains. Arena allocator fix
  is planned for v1.3.5.
• Native kcc (kcc_v134.exe) requires krypton_rt.dll in the current
  working directory or on PATH when run.

kcc v1.3.0

Krypton v1.3.0 — Native x64 Code Generation
Released: 2026-04-15

WHAT'S NEW

kcc is now fully native. No GCC. No MinGW. No C compiler required.

The --native pipeline compiles .k source directly to x64 PE64
executables using only the Krypton toolchain itself:

kcc.sh source.k --native -o output.exe

Pipeline: .k -> IR -> optimize_host.exe -> x64_host.exe -> .exe

The build system (build_v130.bat) is also GCC-free. kcc.exe,
optimize_host.exe, and x64_host.exe are all built natively.

NOTE: Icon (.rsrc section) support is coming in v1.3.1. The
v1.3.0 kcc.exe does not embed the application icon.

TECHNICAL FIXES IN THIS RELEASE

• hexStrIR / irStrLen: Correct \xNN hex escape handling added.
  "\x01" was stored as 0 bytes in native PE .rdata; now correctly
  stores as 1 byte, fixing replace() and lineCount() in native exes.

• Body separator: parseFunctions joins IR body lines with "\x01"
  (SOH, 0x01). "\x01" is safe as a separator because it cannot
  appear verbatim in any IR text line. "|||" was tried but failed
  because it appeared as a literal in x64.k source, causing
  replace() to corrupt PUSH instruction lines.

• compile.k: Removed all debug printErr traces (tokenize loop
  output, KCC-NATIVE markers). Version string updated to "1.3.0".

• kompiler/x64_host.exe: Rebuilt from fixed x64.k.

BUILD SYSTEM

build_v130.bat — fully native, no GCC:

[1/6] kcc.exe --ir compile.k -> IR
[2/6] optimize_host.exe -> optimized IR
[3/6] x64_host.exe -> versions/kcc_v130.exe
[4/6] copy kcc_v130.exe -> kcc.exe
[5/6] rebuild optimize_host.exe and x64_host.exe natively
[6/6] tests (native fib20, kcc.sh --native end-to-end)

SELF-HOSTING

kcc.exe compiles compile.k using --native, producing a new kcc.exe.
Full bootstrap confirmed: the compiler builds itself without any
external toolchain.

KNOWN ISSUES / COMING IN v1.3.1

• No icon in kcc.exe (.rsrc section support not yet implemented
  in the native PE builder)

kcc v1.2.5

Krypton Compiler v1.2.5 Release Notes

Date: 2026-04-08

New Features

1. ** exponentiation operator
   Binary operator for raising a number to a power. Right-associative,
   higher precedence than * / %. Compiles to kr_pow(base, exp).

   Example:
   let x = 2 ** 10 // 1024
   let y = 3 ** 3 // 27
   let z = 2 ** 2 ** 3 // 2 ** (2**3) = 256 (right-associative)

2. ++ and -- increment/decrement operators
   Post-increment (i++), post-decrement (i--), pre-increment (++i),
   and pre-decrement (--i) — both in statement and expression position.
   All forms compile to a plain assignment (Krypton has no side-effect
   expression model, so i++ and ++i both update the variable in place).

   Example:
   let i = 0
   i++ // i == 1
   ++i // i == 2
   i-- // i == 1
   --i // i == 0

   Loop idiom (replaces i += 1):
   while i < 10 {
   printErr(i)
   i++
   }

Build Notes

• Bootstrap: kcc.exe compiles kompiler/compile.k -> compile_out.c
• compile_out.c -> gcc -> versions/kcc_v125.exe -> kcc.exe
• Icon: windres assets/krypton.rc -> assets/krypton_rc.o linked into exe
• Build script: build_v125.bat (step 1 is kcc self-compiling compile.k)

kcc v1.2.4

Krypton Compiler v1.2.4 Release Notes

Date: 2026-04-08

New Features

1. loop { } until syntax
   Do-until loop construct. Executes the body at least once, then repeats
   until the condition is truthy. Compiles to C do { } while (!kr_truthy(cond)).

   Example:
   let n = toInt(start)
   loop {
   printErr("n = " + n)
   n -= 1
   } until n == 0

2. -> bool return type
   Functions declared with -> bool return "1" or "0" as a char* string.
   The compiler generates a static int inner function (krb) and a
   char* wrapper that returns _K_ONE or _K_ZERO via ternary.

   Example:
   func isPositive(n) -> bool {
   emit toInt(n) > 0
   }

3. emit in just run {} uses process exit code
   Previously, emit inside the main just run {} block was hardcoded to
   return 0. Now it calls atoi() on the emitted value and uses it as the
   actual process exit code.

   Example:
   just run {
   emit 42 // process exits with code 42
   }

kcc v1.2.3

Krypton v1.2.3 — Release Notes

Compiler — Void Return Functions (-> zero for regular funcs)

The -> zero return type annotation now works on regular Krypton functions,
completing the void implementation started in v1.2.0. Previously -> zero only
worked on jxt declarations.

func logMessage(msg) -> zero {
    printErr(msg)
}

The compiler generates a void C function internally and a char* wrapper so
existing call sites require no changes. No unsafe type casts are used.

Generated C (simplified):

static void _krv_logMessage(char* msg) { ... }
char* logMessage(char* msg) { _krv_logMessage(msg); return ""; }

Compiler — Integer Return Functions (-> int)

Functions can now declare an integer return type. The compiler generates a
true C int function internally with a char* wrapper for interop.

func addValues(a, b) -> int {
    emit toInt(a) + toInt(b)
}

just run {
    let result = addValues("10", "32")
    printErr("result: " + result)    // prints: result: 42
}

The emit statement inside a -> int function is automatically wrapped with
atoi() so Krypton string expressions convert cleanly to int. The char* wrapper
uses kr_itoa() so the return value re-enters the Krypton string world at call
sites. No changes needed at call sites.

Generated C (simplified):

static int _kri_addValues(char* a, char* b) { return atoi(...); }
char* addValues(char* a, char* b) { return kr_itoa(_kri_addValues(a, b)); }

Compiler — File-Scope Global Variables

Variables declared with let at the top level of a .k file (outside any
function or just run block) are now compiled as static C globals accessible
from all functions in the file.

let appName = "kmon"
let version = "1.0"

func getHeader() {
    emit appName + " v" + version
}

just run {
    printErr(getHeader())
}

Global variables are initialized at the start of main before any user code
runs. They behave identically to local variables — char* strings compatible
with all Krypton builtins and operations.

Previously, top-level let was silently ignored and inaccessible from functions.
This was a significant limitation that required passing state as parameters
everywhere. Global variables eliminate that pattern for file-scope constants
and shared state.

Machine Code Roadmap Progress

These three features are the foundation of the type system needed for native
code generation:

Feature          Maps to machine code concept
─────────────────────────────────────────────
-> zero          void C function → no return register used
-> int           int C function → integer return in eax/rax register
global let       static char* → .data / .bss section in the executable

The next steps toward native compilation are: typed integer variables
(let x: int), typed function parameters, and eventually a native x64 code
generator that targets these typed forms directly instead of going through C.

kcc v1.2.2

Krypton v1.2.2 — Release Notes

Compiler — Inline C Blocks (cfunc)

A new cfunc { } block allows raw C code to be embedded directly inside a
Krypton source file. The C content is passed through verbatim to the generated
C output, eliminating the need for separate .h bridge files.

Usage:

cfunc {
    #include <pcap.h>
    #include <stdint.h>

    static int myCounter = 0;

    static void myHandler(u_char* user, const struct pcap_pkthdr* hdr, const u_char* pkt) {
        myCounter++;
    }
}

cfunc blocks can appear at the top level of a .k file (replacing a .h file) or
inside a function body (for inline C statements).

How cfunc and jxt Work Together

cfunc provides the C implementation. jxt still provides the Krypton-side
function declarations so the compiler knows the function signatures. With cfunc,
the c "header.h" line inside jxt is no longer needed since the C is already
in the file:

// Before: required two files (kmon_cap.h + kmon_cap.krh)
jxt {
    c "kmon_cap.h"
    func kmonCapOpen(iface)
    func kmonCapNext()
}

// After: one .k file with cfunc + jxt
cfunc {
    // ... full C implementation here ...
}

jxt {
    func kmonCapOpen(iface)
    func kmonCapNext()
}

What cfunc Enables

• .h bridge files can be absorbed into .k files — one file instead of two
• The pcap callback handler can now live in a .k file alongside its jxt decls
• Any C construct (structs, typedefs, macros, function pointers) can be used
  without a separate header file

Why Pure Krypton Headers Cannot Replace cfunc Yet

cfunc is a bridge for things Krypton has no syntax to express yet:

C construct              Krypton would need
─────────────────────────────────────────────
uint8_t data[65536]      Fixed-size arrays + C integer types
typedef struct { }       C-layout struct definitions
static pcap_t* handle    Typed global pointer variables
hdr->caplen              Struct field access via C pointer
memcpy(...)              Raw memory operations

These require a type system. cfunc is the pragmatic solution until Krypton
gains typed variables and typed struct definitions in a future release.

Technical Notes

• cfunc blocks are processed at tokenize time, before parsing
• Newlines inside cfunc are encoded as SOH (0x01) in the token stream and
  decoded back to newlines on output — they do not affect token parsing
• C strings containing } inside a cfunc block are handled correctly (string
  depth tracking prevents premature block termination)

kcc v1.2.1

Krypton v1.2.1 — Release Notes

Compiler — Callback Functions (callback func)

Krypton functions can now be declared as C-compatible void callbacks using the
new callback func syntax. The compiler generates a proper void C function
instead of the standard char* return wrapper.

Usage:

callback func onPacket(user, header, data) {
    printErr("packet received")
}

The generated C output:

void onPacket(char* user, char* header, char* data) {
    // body
}

Any emit/return statements inside a callback func body are dropped — void
functions cannot return a value.

Compiler — Function Pointer Builtin (funcptr)

A new builtin funcptr(name) passes a Krypton callback function as a pointer
to C APIs that accept function pointer arguments.

Usage:

callback func onTimer(hwnd, msg, id, tick) {
    printErr("tick")
}

SetTimer("0", "1", "1000", funcptr(onTimer))

funcptr casts the void C function to char* for transport through the jxt
layer. The receiving C API gets the actual function pointer.

Compatibility Notes

• callback func parameters are always char* on the Krypton side. When a C API
  passes non-char* arguments (struct pointers, byte arrays), the values arrive
  as raw pointers. Accessing their contents requires C bridge functions until
  struct field access and typed parameters are added to the language.

• This means callback func fully works for APIs with simple pointer or integer
  arguments (timers, window callbacks, etc.) but the pcap callback case still
  requires a thin C adapter due to struct pcap_pkthdr and raw byte array params.

kcc v1.2.0

Krypton v1.2.0 — Release Notes

Compiler — void Return Type Support (-> zero)

jxt function declarations now support a -> zero return type annotation for
C functions that return void. The compiler generates a char* wrapper that calls
the void C function and returns an empty string, keeping the Krypton call site
clean and warning-free.

Usage in a .krh header:

jxt {
    c "somelib.h"
    func cleanup()          -> zero
    func setMode(mode)      -> zero
    func writeBytes(buf, n) -> zero
}

Calling from Krypton works the same as any other function:

cleanup()
setMode("1")

Without -> zero, a void-returning C function would be incorrectly declared as
char* in the generated C output, causing compiler warnings or undefined behavior.

headers — windows.krh Updated

ShellExecuteA added to windows.krh (with shellapi.h include), allowing programs
to open URLs or files from pure Krypton without a C bridge:

ShellExecuteA("0", "open", "http://127.0.0.1:8080", "0", "0", "1")

kmon — Reduced C Surface

The kmon network monitor project reflects the new capabilities:

• kmonHttpOpenBrowser() removed from the C bridge (kmon_http.h) — replaced
  by a direct ShellExecuteA call from Krypton in run.k
• kmon_server.h and kmon_server.krh deleted (unused)
• kmon_cap.krh trimmed — kmonCapByte, kmonCapU16, kmonCapU32 removed from
  the C bridge; these are now implemented in pure Krypton (kmon_utils.k)

Remaining C bridges (kmon_cap.h, kmon_http.h) are held at minimum viable
surface by two current compiler limitations:

• pcap_dispatch requires a C function pointer callback
• recv/send return int; jxt currently casts all returns to char*