Vibecoding a clean-slate, non-POSIX operating system ecosystem from scratch (OpenWindows)
▲ 0 r/osdev+1 crossposts

Vibecoding a clean-slate, non-POSIX operating system ecosystem from scratch (OpenWindows)

Hi everyone,

I'm 13 years old. For a long time, I’ve been interested in the concept of custom "Windows distributions" (Deborah OS, Blue Hat Windows, Windows Earth) acting as modern, open-source alternatives to Linux distros.

While ReactOS exists as an open-source NT alternative, its strict focus on 100% legacy binary compatibility forces it to replicate the technical debt and design flaws of old Windows versions. To build something better, I've been using LLMs to help me write the freestanding C99 and NASM assembly code for a clean-slate, high-performance foundation that strips away that legacy baggage.

The project is called OpenWindows. It is a modern, object-oriented kernel framework with zero POSIX/Unix heritage, compiled strictly with -std=c99 -nostdlib -ffreestanding.

To completely bypass the complexities and bugs associated with UTF-16 surrogate pairs and standard Unicode normalization tables, I engineered an alternative character mapping and serialization protocol:

  • SuperUnicode (SUCS): A 31-bit character encoding address space with a built-in System Control Plane for inline rendering markers.
  • SUTF Transports: Stream serialization protocols ranging from a 1-to-6 byte variable format (SUTF-8) down to a 4-bit hexadecimal format (SUTF-4) for raw serial text debugging, and a 2-bit symbol format (SUTF-2) for thread IPC.
  • SuperUnicode Extended (ExtSUCS): An unbounded 64-bit encoding featuring fixed-width vector transports (SUTF-128/256/512) optimized for direct SSE/AVX register alignment and SIMD string operations.
  • .suf (SuperUnicode Font): A custom vector font format mapped directly to SUCS address spaces rather than legacy Unicode index tables (WIP).

The build pipeline is automated via Python scripts and CMake, and validated using a headless QEMU integration testing harness. The current repository stack includes:

  1. Modular Bootloader (MBL): A multi-stage x86 BIOS bootloader with a custom 32-bit Protected Mode to 16-bit Real Mode trampoline (_bios_tramp) to handle BIOS disk calls natively in C.
  2. OpenWindows Storage: A freestanding filesystem suite containing native drive storage (libowfs.a) and portable external media storage (libusfs.a) with ChaCha20 encryption and an explicit cryptographic key-slot shredding protocol.
  3. SuperUnicode & SUTF: The foundational C99 library implementing the Base SUCS character mapping, SUTF stream packing, and the 64-bit Extended mode casting logic.
  4. VIP (Volume Indexing Protocol): A unified volume and partition indexing engine designed to replace traditional mount maps with SUTF-8 string identifiers. The VIP architecture (including the FVIP B+ tree indexing and UniVIP external flags) is currently WIP.
  5. BANcode Registry: A kernel damage-control system mapping critical panic states directly to 15 hardware security trap handlers at 0x7FFFFFF0 using unique SUCS codepoints (WIP).

I am currently working on the basic layout for the OpenWindows Essential Drivers repository (WIP) to handle NVMe/SATA storage blocks, PS/2 scancode filtering, and VBE graphics blitting without relying on standard monolithic abstractions.

The base libraries are dual-licensed under MIT and Apache 2.0 so anyone can implement their own independent "Windows distributions/distros" (sometimes referred to as OpenWindows distros) on top of these clean-slate kernel layers.

Let me know your thoughts on managing low-level bare-metal constraints and structural memory alignment using this kind of workflow.

u/big-user — 1 day ago

[Feedback wanted] Decompiling Naric by u/staticj3ff #1

Hey guys, and welcome r/neography!

As you see, this is the script I was inspired by for my Kupograms (and Kuponic abugida). Y'all know this script, it is the Naric script (sibesda nar) for the Naric language (idorše nar), by our beloved king, u/staticj3ff!

NOTE: The Naric script is also known as the Dasen logography (besda senxai).

So, you see, in my new post series, I'll try to decompile the Naric alphabet. Since u/staticj3ff hasn't posted a key for it yet (and I hope he does) but he did post a list of Naric radicals (but it is old so I think it needs to be updated), I thought maybe people might need a key to write a phrase in his language, so I started by "decompiling" the letter "k".

Basically, I scanned his posts and did research and this is what I found about the letter "k". If there is any fault, please correct it. If you have anything to help with, you can say it in the comments!

Thank you for helping me in "decompiling" the Naric script, something u/staticj3ff will do if he comes back!

u/big-user — 12 days ago

[FEEDBACK NEEDED] A new Cartouche symbol for foreign words and names in my Kupograms!

Hey r/neography!

I’ve just added a new orthographic feature to my writing system, tālū kōpu (Kuponic script / та́лу́ ко́пу), and I’d love to get your thoughts on the execution and logic!

I’m calling this new boundary mechanism the Kartoš (Картош), inspired by the container concept in Sitelen Pona. Since kopūlogū (Kupograms) rely on a hybrid mix of logograms and abugida characters, dealing with non-native terms like foreign proper nouns, loanwords, and international brand names can get tricky without semantic roots.

It has one opening symbol and one closing symbol, like punctuation. But only the abugida (kōpu abvukjelitsā) is allowed inside the Kartoš territory. Logographs and logograms are forbidden inside it.

In the image, notice how IKEA is neatly wrapped inside the Kartoš territory using pure abugida glyphs to sound out I-K-E-A, while the rest of the sentence transitions into standard logogram/abugida structures!

What do you think of the visual contrast between the enclosed brand name and the surrounding text? Would love to hear any feedback!

u/big-user — 18 days ago

[FEEDBACK NEEDED] Some logos in Foldian (u/Willing_Squirrel_741) and Kupograms (mine)

I would like any feedback, especially from mods, u/staticj3ff or u/Willing_Squirrel_741 or any OG here in this sub. Thanks!

u/big-user — 25 days ago

RNUR Architecture Update: Resolving Plane 15 Fragmentation, BMP Volatility, and Implementing the Two-Tiered Eviction Strategy

Hey everyone,

I’m making this post to give a comprehensive, 100% transparent update on the state of the Reddit Neographical Unicode Registry (RNUR). As the sole maintainer of this project, my absolute priority is ensuring that when a script is locked into a Set 1 coordinate, it is permanently safe from text-rendering corruption, registry collisions, and layout shifts.

Over the last few days, I’ve been running a ground-up, deep-dive infrastructure audit of our entire map. We ran into some incredibly complex, system-level challenges spanning multiple registries, but the great news is that everything has been intercepted, refactored, and secured. Here is exactly what went down and how the registry architecture is evolving to protect your scripts:

1. Resolving the Plane 15 (SPUA-A) Crossfire

During the audit, I uncovered a messy, multi-registry chain reaction within the U+F2000–U+F29FF block.

Originally, the Under-ConScript Unicode Registry (UCSUR) had left a series of unconfirmed scripts sitting as placeholders in that zone. Seeing these gaps, SPUCE (Shared Private Use Character Encoding) stepped in and mapped their own active community allocations right into the spaces. To make things even more chaotic, when UCSUR later cleared out those unconfirmed scripts, the remaining mappings ended up scattered across the range in a fragmented mess.

If we had shipped RNUR with our initial draft layout, this cross-registry overlap would have completely shattered our data structure.

The Engineering Fix: Instead of running away from the collision, I manually untangled the entire block to create a clean, layered stack. I preserved the scattered UCSUR mappings exactly where they are to maintain perfect upstream legacy alignment. Then, I dragged the SPUCE scripts completely out of that conflicted hot zone and relocated them cleanly into the undisputed real estate right below them, starting at U+F2A00 onwards. Plane 15 is now beautifully sorted, synchronized, and 100% secure.

2. The Plane 0 (BMP) Volatility & The Provisional Pivot

This next issue is a massive, project-killing reality check that a brilliant member of this subreddit, u/PiotrGrochowski, flagged for me. To be completely honest, I initially operated under the assumption that because blocks like U+EE00–U+EFFF were unallocated or marked as "Reserved for Hacks" upstream, they were completely safe for us to build on.

I was wrong. Upstream registries do not have rigid stability policies for unallocated or reserved space. To them, "Reserved" just means "We haven't put anything here yet." It is not a guarantee of future safety. We saw this on August 29, 2023, when UCSUR completely fragmented its corporate/hack zones without warning to allocate the Ath script in the U+F4C0–U+F4EF range. Anyone who had built fonts in that "reserved" space was instantly bulldozed.

This risk is amplified by a million in the Basic Multilingual Plane (BMP / Plane 0) because legacy software, older text editors, and rendering engines fight for it to maintain backwards compatibility.

The Strategy Realignment: To manage this, I have officially re-classified the U+EE00 to U+EFFF block, along with all empty gaps in Plane 15, as Tier B: Provisional RNUR Territory.

  • 📌 What this means for active allocations: To the creators who already have active scripts provisionally mapped in these BMP zones (Filipe Dos Reis, u/Willing_Squirrel_741, and Julius Dalum), your scripts are NOT being deleted. Your ranges remain firmly tracked, but their status reflects a provisional lease under an active upstream vacuum.
  • 📌 What this means for collisions: If an uncoordinated upstream authority hits these provisional zones, we do not fight them at runtime. Instead, the registry triggers an Automated Eviction Clause that gracefully migrates the displaced script records down into the first available, unassigned rows at the base of the Set 2 Sandbox Layer, updating the Set 1 master map to stay perfectly in compliance with the native upstream change.

3. Hardening RNUR: The Two-Tiered Eviction Strategy

We have adapted our core validation code and specifications to turn these inherent upstream tracking risks into a structured, automated system divided into two distinct operational pipelines:

  • Tier A (Permanent Real Estate): This covers finalized permanent allocations, the permanent structural space tracking slots of Plane 16, and selected non-provisional Plane 0 gaps (U+F500–U+F6FF and U+F820–U+F87F). If an upstream project ever builds over these coordinates, the registry automatically executes a 1:1 parallel mathematical eviction straight into their exact corresponding mirror addresses in Set 2 (e.g., Set 1 U+100580 maps directly to Set 2 U+100580). The entry is flagged with an UPSTREAM_COLLISION tag, and local, compliant pre-processors deploy a software-level override to force our fonts to render perfectly over the system defaults.
  • Tier B (Provisional Real Estate): As mentioned above, the BMP U+EE00–U+EFFF block and empty Plane 15 gaps will bypass runtime software overrides entirely. They will dynamically migrate to the base of the Set 2 Sandbox Layer to clear out system font-rendering pollution and keep our master files perfectly aligned with universal standards.

A Disciplined Release Cadence: Major versions will now launch on a flexible cadence with a minimum of one full year between releases. If a flaw is ever detected in an active version, the next major release is immediately frozen and postponed until the issue is entirely resolved in a minor patch release (v1.1, etc.). Stability comes before expansion.

Moving Forward Together

Catching these collisions and tightening the foundation is exactly why open peer-reviews exist. The registry is infinitely stronger today than it was a week ago because we are building it right from the bedrock up.

I want to give a massive shoutout to u/PiotrGrochowski! You seriously saved the future of this project. I've already reached out and extended an invite to them to join RNUR as a co-maintainer.

If anyone else wants to review the newly updated specifications, look over the validator code patches, or inspect the master CSV files, the repository is completely open and updated:https://github.com/nexustribarixa-redaamakrane/rnur/

We are building this to last. Thank you all for your trust and your incredible scripts!

Massive respect,

Nexus Tribarixa

u/big-user — 2 months ago

RNUR Update: First two allocations locked in (Loopiform & Foldian) + how we're avoiding UCSUR/SPUCE conflicts

Hey everyone,

Quick update on the Reddit Neographical Unicode Registry (RNUR). We’ve officially sorted out our first two actual script allocations, moving this from a concept into a working setup.

If you’ve ever tried making a digital font for a conlang or neography, you already know how annoying Private Use Area (PUA) collisions are. You install two different custom fonts, and they accidentally overwrite each other's characters. The point of this registry is just to map things out so our fonts can actually coexist without breaking.

Here is how the layout works and what’s been allocated so far.

The Strategy: Set 1 vs. Sets 2+

We didn't just pick random hex blocks here. Set 1 is built specifically to not step on the toes of the big existing registries, UCSUR and SPUCE.

I went through and mapped out the exact codepoint gaps left completely empty by both registries. By staying strictly inside those vacant slots, Set 1 guarantees your font won't collide with standard UCSUR/SPUCE setups on the same machine.

The exact empty gaps we are using for Set 1 are:

  • Plane 0 (BMP): EE00–EFFF, F500–F7FF, F820–F87F
  • Plane 15: F2A00–F4DFF, F5100–F7FFF, F8200–FDFFF, FFE00–FFEFF
  • Plane 16: 102000–10FFEF

Sets 2+ is the opposite. They’re "total override" pools that open up the entire raw PUA ranges (E000–F8FF, etc.). These are reserved for massive, standalone world-building projects or isolated operating systems that don't care about external registries. Since everyone is prioritizing compatibility right now, Set 2 is currently completely untouched.

The New Allocations (Sector U+EExx)

We’re starting in the U+EE00 block in Plane 0, right after Benjamin Franklin’s historical 1768 phonetic alphabet reform.

  1. Loopiform (by Filipe Dos Reis / u/Muted_Neat_2236)
  • Range: U+EE10 to U+EE5F (80 slots)
  • The Setup: 72 core characters (36 basic symbols, 9 voiced variants, 12 duodecimal digits, and 15 punctuation marks/diacritics). It starts right at U+EE10 (after Franklin's alphabet ends at EE0F). The 80-slot block keeps it aligned to half-row boundaries and leaves some padding for future tweaks.
  1. Foldian (by u/Willing_Squirrel_741 / Nikita Varfalameev)
  • Range: U+EE60 to U+EE8F (48 slots)
  • The Setup: 33 characters total (32 letters and 1 multi-use diacritic). It sits right after Loopiform. The 48-slot block (3 full rows of 16) leaves 15 empty padding slots in case the author wants to add variants later.

Current Map of the PUA Sector (Set 1)

Here is how the master database looks right now. The ranges are perfectly aligned with no overlaps:

Set_Number Start_Code_Point End_Code_Point Script_Name Author Status Description
1 EE00 EE0F Benjamin Franklin's Phonetic Additions Benjamin Franklin Allocated 16-hex historical incubator for phonetic alphabet reform.
1 EE10 EE5F Loopiform Filipe Dos Reis (aka u/Muted_Neat_2236) Allocated 72-character systematic phonetic script featuring duodecimal numerals and logographic punctuation.
1 EE60 EE8F Foldian u/Willing-Squirrel_741 (aka Nikita Varfalameev) Allocated 32-character neography with 1 associated diacritic mark.
1 EE90 EFFF OPEN_SLOT NONE Waiting for submissions Available for low-count stable alphabets (Plane 0).
1 F500 F7FF OPEN_SLOT NONE Waiting for submissions Available for low-count stable alphabets (Plane 0).
1 F820 F87F OPEN_SLOT NONE Waiting for submissions Available for low-count stable alphabets (Plane 0).
1 F2A00 F4DFF OPEN_SLOT NONE Waiting for submissions Plane 15 Grand Corridor - Tier 1 high-capacity allocation.
1 F5100 F7FFF OPEN_SLOT NONE Waiting for submissions Plane 15 Grand Corridor - Tier 2 high-capacity allocation.
1 F8200 FDFFF OPEN_SLOT NONE Waiting for submissions Plane 15 Grand Corridor - Tier 3 high-capacity allocation.
1 FFE00 FFEFF OPEN_SLOT NONE Waiting for submissions Plane 15 Terminal padding allocation block.
1 102000 10FFEF OPEN_SLOT NONE Waiting for submissions Plane 16 Massive Community Syllabary and Logography Reserve.

Want to grab an allocation slot?

Anyone can submit a proposal. It doesn't matter if you have a quick 20-character alphabet or a massive logography: we have different tiers mapped out to keep your codepoints safe.

You can drop your scripts or thoughts directly in the comments below, or open an issue on the GitHub repository:

🔗github.com/nexustribarixa-redaamakrane/rnur

Just include:

  1. Script Name & Creator Alias
  2. Total Character Count (Break down letters, digits, punctuation, and diacritics so we can calculate the exact row size and padding).
  3. A quick summary or image/link showing how the characters are laid out.

Let me know if you have any questions or want to get a block locked in!

reddit.com
u/big-user — 2 months ago
▲ 10 r/neography+1 crossposts

What is RNUR? (And yes, submissions are open)

The Reddit Neographical Unicode Registry (RNUR) is a decentralized, infinite digital registry built specifically to archive and standardize original scripts, conlangs, and neographies from the r/neography community.

If you have built a writing system (whether it is a 15-letter phonetic alphabet, a massive 10,000-glyph logography, or a fictional conlang script) submissions are officially open. RNUR gives your project a permanent, standardized home in the digital world without the risk of your code points colliding with someone else's work.

Here is the exact technical blueprint of how it works under the hood.

The Core Problem: Digital Land Wars

Traditional Private Use Area (PUA) registries treat code points like physical real estate. Repositories like the UCSUR or SPUCE have finite land. If two creators build massive scripts that want the same code points, they collide. Someone has to lose, or someone has to compromise.

For those who don't know, according to the SPUCE Project's Miraheze page (not the Fandom wiki, which is deprecated), SPUCE stands for Shared Private Use Character Encoding. It operates as a community registry to coordinate and document constructed, fictional, and user-created scripts within Plane 15 and Plane 16. But because it and registries like UCSUR occupy a single, flat layer of text, space remains a luxury.

On top of that, you hit hard engineering ceilings built into modern operating systems:

  1. The Unicode Ceiling: Standard text engines hard-stop at 10FFFF.
  2. The OpenType Wall: A single font file can physically only hold 65,535 glyph tables before it crashes layout engines.

The Breakthrough: Multi-Dimensional Typography

RNUR completely abandons the flat map model used by traditional registries. It operates as an infinite stack of virtual layers running from Set 1 to Set ∞.

Characters are tracked as a coordinate pair rather than a single code point:

RNUR Mapping = Set_Number, Code_Point

Because the Set_Number can scale infinitely, digital scarcity is dead. If two scripts clash, there is no need to play judge and jury. One goes to Set 37 and the other goes to Set 38. Everybody gets their exact mapping.

Tier 1: Set 1: The Living Mirror (The Treaty Zone)

Set 1 focuses on playing nice with the rest of the conlanging world. It acts as a highly disciplined, synchronized baseline that maps strictly around active external registries (like CSUR, UCSUR, and the SPUCE Miraheze framework) to ensure zero global collisions.

The Set 1 Map:

  • BMP (Plane 0): U+EE00 to U+EFFF, U+F500 to U+F7FF, U+F820 to U+F87F (Threads the needle around legacy blocks. This holds 16-hex historical incubators like Benjamin Franklin's phonetic alphabet starting at EE00).
  • Plane 15: U+F2A00 to U+F4DFF, U+F5100 to U+F7FFF, U+F8200 to U+FDFFF, U+FFE00 to U+FFEFF (Claims large, unassigned gaps between early-plane roadmaps).
  • Plane 16: U+102000 to U+10FFEF (The Grand Corridor for massive, universally compatible community scripts).

The Live-Sync and Deportation Rule:

Because CSUR’s original founder is deeply tied up with real-world minority scripts, UCSUR has felt like a permanent fixture, even though it is technically just a staging ground. If those upstream authorities ever update, merge, or change a script's layout boundaries, Set 1 alters its boundaries instantly to stay perfectly synced with the global standard.

The Fail-Safe: If an upstream shift happens and an old layout is replaced, the original, legacy coordinate layout is not destroyed. It gets evacuated from Set 1 and deported to a sandbox layer in Sets 2+. This keeps Set 1 pristine and modern, while older documents out in the wild never break.

Tier 2: Sets 2+: The Infinite Sandboxes (The Wild West)

Sets 2+ are strictly confined to the official PUA (Private Use Area) zones of Unicode. This guarantees standard text, numbers, and system punctuation remain completely untouched. We are cloning that specific PUA space across infinite parallel layers.

The Sandbox Canvas (Per Layer):

  • BMP PUA: U+E000 to U+F8FF (6,400 slots)
  • SPUA A (Plane 15): U+F0000 to U+FFFFF (65,536 slots)
  • SPUA B (Plane 16): U+100000 to U+10FFFF (65,536 slots)

Every single sandbox layer gets 137,472 clean slots to use freely, completely insulated from the rest of the internet and completely safe from corrupting standard Unicode text.

The Engine: JIT Scaling and Anti-Fragmentation

To keep things lightning-fast and lightweight for font developers and users, the registry handles space like a modern operating system handles memory.

1. Just-In-Time (JIT) Rollout

We avoid shipping massive, empty, ghostly fonts on day one. RNUR launches strictly with Set 1 and Set 2 active. Set 3 is only generated the exact millisecond Set 2 runs out of contiguous space. Font families only compile files for sets that actually exist (e.g. Confont_Set1.ttf, Confont_Set2.ttf).

2. The Anchor Tenant Rule

If a creator submits a massive syllabary or logography that needs 8,000 continuous slots, but the active sandbox only has 2,000 tiny, fragmented gaps scattered around near its tail end, we avoid chopping their script into pieces.

The registry automatically bypasses the gaps, initializes the next Set (like Set 3) instantly, and drops that massive script right at the front gates (U+E000). The script stays perfectly contiguous, keeping complex OpenType features (ligatures, glyph substitutions) clean and easy to compile.

Why the Tech Works

By separating the registry into distinct, independent sets, each layer compiles into its own lightweight, modular font file. This completely bypasses the 65,535 OpenType glyph ceiling because no single font file ever becomes overloaded with too many scripts at once.

Modern applications and web rendering engines can handle these sets as separate font family variants. This approach ensures text rendering engines remain fast, memory consumption stays low, and software never crashes from giant, bloated font payloads.

Submissions are officially open. Drop your scripts, layouts, and character requirements below or clone the framework to get your allocations locked in. Let's build an infinite canvas for human imagination.

reddit.com
u/big-user — 2 months ago
▲ 37 r/conlangscirclejerk+1 crossposts

FINALLY! A key for the Lumeric script!

I am releasing the key for the Lumeric script for my conlang, Lumera. This project has been a long time in the making, and I appreciate the consistent interest and motivation from the community to get this finalized.

Please see the image above for the complete character key.

Romanization and IPA Reference:

  • Vowels: a /a/, ā /a:/, e /e/, ē /e:/, ə /ə/, ę /ę/, i /i/, ī /i:/, o /o/, ō /o:/, u /u/, ū /u:/, ų /ų/, y /y/
  • Consonants: b /b/, v /v/, g /g/, d /d/, ð /ð/, z /z/, zh /ʒ/, j /j/, k /k/, kh /x/, l /l/, m /m/, n /n/, ng /ŋ/, ' /ʔ/, p /p/, r /r/, s /s/, sh /ʃ/, t /t/, þ /θ/, ts /ʦ/, ch /ʧ/, dz /ʣ/, dzh /ʤ/, ks /ks/, f /f/, h /h/

Important Technical Note on Digraphs:

The three "red" digraphs shown in the image are distinct stylistic versions of the character for the letter /y/. They follow this casing structure:

  1. First: All Uppercase
  2. Second: CamelCase
  3. Third: All Lowercase
u/Willing_Squirrel_741 — 3 months ago