Coder Legion - Recent posts tagged crossplatform

Embedding a web UI into a native desktop application comes with a price

Sun, 20 Sep 2026 14:12:47 +0000

I thought embedding a web UI into a native desktop application would be the easy part.
After all... macOS has WebKit. Linux has GTK WebKit. Windows has WebView2.

One API per platform, smaller installers, native look & feel. Sounds perfect.
Then reality arrived.

macOS 🍎

Honestly, this was the easiest platform.
System WebKit is there.
It behaves consistently.
No additional runtime.
No installer surprises.
Exactly what you'd expect from a platform component.
10/10

Linux 🐧

Things became... more interesting.
GTK WebKit works, but suddenly packaging starts to matter.
An AppImage built on one distribution may refuse to start on another because some required WebKitGTK library isn't available.
Your application itself is perfectly fine.
The user's system just doesn't happen to provide exactly the version your build expects.
You quickly discover that "works on my machine" has many regional dialects.
7/10

Windows 🪟

This one surprised me the most.
Unlike macOS, the web view isn't really just "there."
Using WebView2 means depending on the Edge WebView runtime.
If the runtime isn't installed, congratulations—you now need another installer.
So your installer may install something whose purpose is to allow your application to display HTML.
Not exactly the dependency story I was hoping for.
2/10

Meeting in the middle

At some point I asked myself:
Why am I spending time debugging operating-system packaging instead of building my application?

So I tried CEF (Chromium Embedded Framework).
Yes...
The application becomes larger.
Quite a bit larger.

But in exchange:
• Same rendering engine everywhere.
• Same JavaScript engine everywhere.
• Same debugging experience.
• Same HTML/CSS behavior.
• No Linux WebKit dependency lottery.
• No separate WebView runtime installation on Windows.
• One code path across all desktop platforms.
Ironically, shipping your own browser turned out to be simpler than relying on the browser already "provided" by the operating system.
It's one of those engineering decisions that looks wasteful on paper but ends up reducing complexity everywhere else.
Sometimes carrying the extra megabytes is cheaper than carrying platform-specific surprises.

Curious what others have settled on.

Are you using native web views, CEF, or something else for cross-platform desktop applications?

ForgeZero: musl Cross-Compilation and Objective-C Support

Sat, 06 Jun 2026 09:04:12 +0000

Recent changes to ForgeZero introduce two new build targets:

musl libc cross-compilation through the Zig toolchain
Objective-C compilation support on Linux

The goal is not to add another compiler frontend, but to keep a single command-line interface while selecting the appropriate backend automatically.

musl Targets

ForgeZero can now build statically linked musl binaries for supported architectures.

Example:

fz -cc main.c -musl=riscv64 -toolchain zig

Result:

main: ELF 64-bit LSB executable, UCB RISC-V, RVC, double-float ABI, version 1 (SYSV), statically linked, with debug_info, not stripped

The implementation uses the Zig toolchain as a cross compiler while exposing a consistent ForgeZero interface.

Typical use cases include:

static deployment
container images
embedded systems
cross-compilation without a dedicated sysroot
portable binaries

No changes are required to existing build scripts besides selecting the musl target.

Objective-C Detection

ForgeZero now recognizes Objective-C source files (.m) and automatically switches to the Clang frontend and Objective-C runtime linker.

Example:

fz -cc main.m

Verbose output:

Objective-C detected!
Bypassing Zig linker to use Clang with -lobjc

Running:
clang main.o -o main -lobjc -Wl,--build-id=none

Built: main

The language detection is automatic.

There is no separate Objective-C mode or dedicated command. Source type determines the compilation pipeline.

Unified Build Interface

The same interface can now be used for multiple languages:

fz -cc hello.c
fz -cc hello.m
fz -asm boot.asm

ForgeZero selects the compiler, linker and runtime based on the source file and requested target instead of requiring the user to manage toolchain details manually.

This behavior will be extended to additional languages and targets in future releases.

Repository

GitHub: https://github.com/forgezero-cli/forgezero

Author: https://github.com/alexvoste

ForgeZero v4.2.0: 2.84x Faster Than Ninja. Zero CGO. Zero Compromise.

Wed, 27 May 2026 17:09:17 +0000

We shipped v4.1.0 with a clear mandate: eliminate heap allocations from every critical path,
harden the syscall layer, and make the build engine deterministic at hardware limits.
v4.2.0 delivers on that — and then goes further.

This release drops CGO entirely, ships a native Windows syscall driver, and pushes
the assembler hot-path through SIMD rewrites and sync.Pool recycling. The result is a
build orchestrator that runs at 637 ms mean against Ninja's 1.813 s on a 1000-module
C project. That is a 2.84x lead, sustained across 10 runs with sub-35 ms range variance.

Benchmark: ForgeZero vs Ninja, 1000 C Modules

Tool	Mean	Range	Runs
fz (ForgeZero)	637.3 ms	626.6 ms — 685.5 ms	10
ninja	1.813 s	1.800 s — 1.834 s	10

2.84x faster. Consistent. Reproducible.

Hardware: Intel i5-10310U. Cold filesystem cache. No artificial throttling.
The variance on fz is 58.9 ms peak-to-peak. On ninja it is 34 ms — but starting from
nearly three times higher. ForgeZero is not only faster, it is stable.

The previous release already showed 3.25x against make -j4 at 100 modules. This holds
as the module count scales to 1000 against a purpose-built parallel tool. That is not a
benchmark trick. That is architecture.

The Big Change: CGO is Gone

v4.1.0 still carried CGO at the entrypoint and in the C plugin loader. Every build that
touched cplugin dragged in the C toolchain, broke cross-compilation, and introduced
non-determinism in the binary ABI.

v4.2.0 removes it completely.

The mechanism is GoContext — a pure Go struct that replaces the old C-coupled parameter
passing interface in cplugin. Platform-specific loaders are now split by build tag:

//go:build linux — Unix dynamic loader via CGO (for users who opt in)
//go:build windows — Native DLL loader via syscall and golang.org/x/sys/windows,
zero CGO dependency
fallback — no-op loader for non-CGO builds, compiles clean on any target

The entrypoint (cmd/fz) no longer imports "C" at all. The binary is now fully
cross-compilable from any host to any target without a C toolchain present.

C module structs were also aligned to 64-byte cache lines to eliminate false sharing
on multi-core dispatch.

Assembler: SIMD, sync.Pool, and One Allocation Budget

The assembler hot-path in v4.1.0 was fast. In v4.2.0 it operates under a strict
zero-allocation budget on every repeated call.

Three changes made this possible:

SIMD + branchless lookups for whitespace and comment stripping.
The previous implementation used range loops with conditional branches. The rewrite
uses branchless lookup tables and SIMD-width processing to strip comments and normalize
whitespace without a single branch misprediction in the common case.

Parser recycling via sync.Pool.
Each parse call previously allocated a new parser struct. The pool holds pre-warmed
parser instances and recycles them across goroutines. Allocation churn in the assembler
is now flat under sustained parallel load.

splitArgs as a parser method with pre-allocated slice recycling.
The argument splitter was a free function that allocated a new slice on every call.
It is now a method on the pooled parser, reusing the backing array across invocations.
The slice is reset, not reallocated.

Compiler flags are parsed once via sync.Once lazy initialization. Repeated calls
to the flag parser cost a single atomic read.

FastCopy — the inner loop for instruction stream copying — was rewritten as a
branchless unrolled function using unsafe.Pointer arithmetic. No bounds checks.
No interface dispatch. Direct memory throughput.

Linker: On-Disk Symbol Cache, No nm

The linker previously invoked the nm utility to resolve symbol tables. nm is a
process fork per object file. At 1000 modules that is 1000 forks, each with exec
overhead, pipe setup, and string parsing.

v4.2.0 introduces a co-located on-disk symbol cache. Symbol data is written alongside
the object file on first build and read directly on subsequent builds. The nm binary
is never invoked in the hot path.

Object deduplication was simplified from a custom mmap-based structure to a native
Go map. The mmap routines are gone. The map is faster for the deduplication workload
and eliminates an entire category of platform-specific edge cases.

Response file generation was refactored to use bufio.Writer with f.Sync removed.
The sync was a correctness hedge that was never needed — the linker already operates
under an ordering guarantee from the task graph.

Builder and Utils: WalkDir, Zero-Copy Loops, Raw Syscalls

The builder's source discovery was rewritten around WalkDir with explicit
filepath.SkipDir support in the custom SYS_GETDENTS64 walker. Directory subtrees
that cannot contain build targets are pruned at the kernel boundary, not in userspace.

CleanDir was deduplicated — it was being called multiple times per build target in
the previous implementation. Slice allocations in the task dispatch worker were
eliminated; the dispatch loop now operates on pre-allocated task structs with
zero heap writes in the hot path.

Platform-specific file hashing:

Linux: Direct SYS_OPENAT loops with defer-based cleanup and no os.File allocation
macOS: Low-level mmap write interfaces, resource management tuned to Darwin's
unified buffer cache behavior
Windows / non-UNIX: Updated fallback stubs that compile clean and behave correctly

Unused pools were purged. Digest-to-string conversions were rewritten to use
stack-allocated byte slices instead of fmt.Sprintf.

What v4.1.0 Established

For context: v4.1.0 shipped the HADES ELF emitter with correct .symtab ordering
(local symbols before global, strict linker compliance), deterministic relocation
calculation for call and jmp offsets, and the AEGIS security layer with TOCTOU
mitigation, atomic SBOM generation, and secureVendorPath symlink validation.

The allocation regression suite and golangci-lint enforcement were introduced in
that release and remain green.

v4.2.0 builds on that foundation without breaking it.

Numbers That Matter

2.84x faster than Ninja at 1000 C modules
3.25x faster than make -j4 at 100 modules (v4.1.0, still holds)
~1.18 GB/s sustained copy throughput on i5-10310U, zero GC interference
0 allocs/op, 0 B/op in copyFileHot micro-benchmark
0 CGO dependencies in the default build path
100% golangci-lint compliance, strict config

Get It

git clone https://github.com/forgezero-cli/forgezero
cd forgezero
go build -o fz ./cmd/fz

No C toolchain required. No network calls at build time. Reproducible output on
amd64 and arm64 across Linux, Windows, and macOS.

Source, benchmarks, and the full commit log are in the repository.
If you are running large C projects and measuring build latency, the numbers are
worth verifying on your own hardware.

ForgeZero is a low-level build orchestrator written in Go. It targets deterministic,
zero-allocation execution for large-scale C and assembly projects.

I Build Apps and Trade NSE — Systems Over Noise

Tue, 23 Dec 2025 09:44:31 +0000

Project: tradeos_phoenix

tradeos_phoenix is an early-stage trading-focused mobile application built with Flutter, powered by Firebase and Supabase, designed with a clear philosophy:
start simple, build strong, then scale smart.

Right now, we’re intentionally keeping the scope tight.

Current Focus

We are starting with only 6 core instruments, split across Commodity and Crypto:

Commodities:
Gold
Silver
Copper
Crude Oil

Crypto:
Bitcoin (BTC)
Ethereum (ETH)

Instead of chasing “everything for everyone,” we’re focusing on depth, reliability, and clean execution for these segments first.

Why Not “Smart” Yet?

The app is not heavily automated or AI-driven at this stage, and that’s intentional.

Our priorities right now:
Stable architecture
Clean data flow
Low-latency performance
Scalable backend design

A foundation that won’t break when features grow

In trading (just like in tech), bad foundations destroy good ideas.
We’re building tradeos_phoenix the same way a serious trader builds a system — step by step, with risk control.

️ Tech Stack

Flutter for cross-platform performance

Firebase for auth, notifications, and real-time needs

Supabase for scalable backend, database, and APIs

The goal is a modern, lightweight, and extensible trading-tech product that can later support analytics, automation, alerts, and strategy tools without rework.

India-Centric Vision

Our focus is India-first:
Indian commodity traders
Crypto participants operating from India
Founders, developers, and traders who understand the local market reality

We’re actively open to India-based tie-ups and long-term collaborations, especially with:
Traders or trading communities
Fintech builders
Market data providers
Founders exploring commodity/crypto tech
Anyone serious about building real products, not hype demos

Let’s Build, Not Rush

tradeos_phoenix is not a “launch-and-forget” app.
It’s a long-term build where tech discipline meets trading discipline.

If you’re interested in collaborating, contributing ideas, or exploring a long-term India-based setup, let’s connect and build this the right way — calmly, correctly, and with intent.

ImagePickerKMP support extentions now and Web

Tue, 14 Oct 2025 23:03:02 +0000

ImagePickerKMP — New Extensions & Image Compression

Repository: ismoy/ImagePickerKMP

Overview

ImagePickerKMP now introduces powerful new extension functions and image compression features for more flexible image handling across Android, iOS and Web platforms.

Available Extension Functions

These new extensions allow you to easily convert captured or selected images into different formats — perfect for storage, UI display, graphics, or network use.

Function	Returns	Usage
`loadBytes()`	`ByteArray`	For file operations and storage
`loadPainter()`	`Painter`	For direct display in Compose UI
`loadImageBitmap()`	`ImageBitmap`	For Compose graphics operations
`loadBase64()`	`String`	For API calls and network transmission

Example Usage

// State variables
var showCamera by remember { mutableStateOf(false) }
var showGallery by remember { mutableStateOf(false) }
var capturedImage by remember { mutableStateOf<Painter?>(null) }
var selectedPhotos by remember { mutableStateOf<List<GalleryPhotoHandler.PhotoResult>>(emptyList()) }

// Camera with extension functions
if (showCamera) {
    ImagePickerLauncher(
        config = ImagePickerConfig(
            onPhotoCaptured = { result ->
                // Use extension functions to get different formats
                val imageBytes = result.loadBytes()        // For file operations
                val imagePainter = result.loadPainter()    // For UI display
                val imageBitmap = result.loadImageBitmap() // For graphics operations
                val imageBase64 = result.loadBase64()      // For API calls
                
                // Store the painter to display later
                capturedImage = imagePainter
                showCamera = false
            },
            onError = { showCamera = false },
            onDismiss = { showCamera = false },
            directCameraLaunch = true
        )
    )
}

// Gallery with extension functions
if (showGallery) {
    GalleryPickerLauncher(
        onPhotosSelected = { photos ->
            selectedPhotos = photos
            showGallery = false
        },
        onError = { showGallery = false },
        onDismiss = { showGallery = false },
        allowMultiple = true
    )
}

// Display captured image
capturedImage?.let { painter ->
    Image(
        painter = painter,
        contentDescription = "Captured photo",
        modifier = Modifier.size(200.dp)
    )
}

// Display selected photos
LazyColumn {
    items(selectedPhotos) { photo ->
        photo.loadPainter()?.let { painter ->
            Image(
                painter = painter,
                contentDescription = "Selected photo",
                modifier = Modifier
                    .fillMaxWidth()
                    .height(200.dp)
            )
        }
    }
}

gist: read More

Reelora Now Available on Indus Appstore – A New Era of Movie Discovery!

Mon, 29 Sep 2025 14:17:53 +0000

We’re thrilled to announce that Reelora, your ultimate destination for movie trailers and entertainment discovery, is now officially published on the Indus Appstore! This marks a new milestone in making Reelora more accessible to millions of users across India who are looking for smarter, faster, and more personalized ways to enjoy global cinema content.

What is Reelora?

Reelora is more than just a trailer app—it’s your personalized gateway to the world of movies. With a sleek interface and curated content, Reelora allows you to:

Watch Trailers Instantly: Get access to trending, popular, and upcoming movie trailers.

Discover Movies Worldwide: Explore films across languages, genres, and countries.

Smart Filters: Tailor your experience with filters for language, genre, and even adult content.

Favorites List: Bookmark up to 10 movies in your collection and expand as you go.

Location-based Content: Get recommendations that match your region and preferences.

Why Indus Appstore?

By launching on Indus Appstore, Reelora becomes part of one of India’s fastest-growing app ecosystems. This gives millions of users—many beyond the Google Play ecosystem—direct access to a unique platform built for Indian audiences.

For users, this means easier downloads, localized app discovery, and more choice. For Reelora, it means reaching wider audiences who love cinema and entertainment but want more control over how they discover and engage with movies.

Why You’ll Love Reelora

If you’re a movie lover, Reelora puts the global film industry at your fingertips. Whether you’re into Hollywood blockbusters, Bollywood hits, or indie gems from across the world, Reelora ensures you never miss out on the latest buzz.

The app’s personalization features make it stand out—you can follow your favorite genres, explore recommendations based on your tastes, and stay updated with real-time trending trailers.

Download Now

Be part of this exciting journey and experience the future of movie discovery. Download Reelora today on the Indus Appstore and unlock a world of entertainment.

Get it here: https://www.indusappstore.com/apps/entertainment/reelora/com.dk.reelora

With Reelora on Indus Appstore, movie magic is just one tap away. Stay entertained. Stay inspired. Stay Reel!