Story
NTU was the initial/code name for the project (ImMobile)
Welcome to the story behind NTU (NT Universal) — my attempt to create a true universal environment that works even on the earliest Windows builds and provides a desktop-like experience on limited, often abandoned hardware.
This project is powered by C++ and ImGui — a combination chosen for raw performance and flexibility. I want to take you through the journey — the problems I faced, the technical trenches I fell into, and the solutions I came up with, often through sheer persistence rather than perfection.
UWP has been incredibly limiting—especially on older Windows devices that were forced to use it exclusively.
Microsoft’s main direction has been pushing .NET and XAML, shifting app dependencies from OS-level libraries to frameworks. As a result, we ended up with apps that were completely incompatible with older Windows builds (14393 and below). I constantly ran into situations where even small XAML components would break entire apps, and there were no known fixes for the compatibility issues.
On C++/DirectX level most apps that designed for UWP perform general DPI calculations, which result in oversized frame rendering on weak SoCs. Porting them into a XAML-based UI made things worse. Older Windows builds had memory leaks in some components, making the app progressively heavier the longer it ran.
To make matters worse, newer XAML libraries demanded significantly more system resources.
Even more complicated was trying to port apps like WUT (Windows Universal Tool) to Windows 8.1 using C#/XAML—it was nearly impossible.
Some essential .NET libraries were simply unavailable. I couldn’t even get a basic HTTP client working. Whether that was my fault or not, I didn’t face such issues with my ImMobile project, which used C++/DirectX/ImGui.
I spent years fixing and completing UWP apps for ARM32 that were abandoned by other developers.
Some of those efforts felt like a waste of time, especially with GPL-licensed projects where some owners were skeptical, thinking I was doing it for profit.
Others, like Kodi, PPSSPP, and RetroArch, had supportive friendly owners which pushed me to contribute to the original projects.
Look—I get it. No one owns a GPL project. But amid all these struggles and working a full-time job, I just couldn’t keep up.
Some project owners didn’t seem to grasp the reality of investing precious time into legacy support. It’s a huge risk—your ideas and your work are out there in public, and we have 0% protection for even a single line of it.
That’s when I started to appreciate the MIT license. It promotes transparency and goodwill, but also encourages responsibility.
So, what now? The only real solution is to build your own thing—something based solely on what’s necessary, leaving behind the outdated environment.
Originally, I never imagined it would grow this large. My initial idea was just to create a simple grid with a click-and-show window.
But it turns out, building an environment—especially using my own complex calculation methods—was far more challenging.
Since I taught myself C/C++, I knew that any project I create should be:
-
C++-friendly and easy to use
-
Allow others to focus on logic, while NTU handles the heavy lifting: UI, system access, and touch input
That was—and still is—the vision.
This was the first screenshot debug test of NTU (ImMobile)
at this moment I got that dialog and touch-pad..etc I though all will be easy and quick lol.
I had 2 projects coding on them in the same time, the main one Windows 10 (WinRT) and NTU for Windows 8.1 / Mobile (CX)
devenv_Z2b8EYjFfN.mp4
Generally after setting the bases during the early development I put 8.1 version on hold to boost the main one
it's hard and very much time consuming.. later it took nearly 30 days to port the whole thing to 8.1 with more challenging issues.
Let me take you through the biggest pain points I encountered, the decisions I made, and the stuff that just wouldn’t work until it finally did.
Each section here is a chapter of what was happening behind the scenes.
The first major hurdle I hit? UWP file access—especially on Windows builds older than 14393.
Microsoft only allowed HANDLE from (StorageItem) starting from build 14393. Anything older than that? You're pretty much on your own.
So I had to implement two separate code paths:
- One for builds below 14393
- Another for builds 14393 and above
And the further back you go, the worse it gets. I had to come up with some really strange workarounds. Thankfully, I had prior experience from an earlier UWP storage project—that helped a lot.
Still, of course… it never goes smoothly.
In this kind of situation, you end up doing exactly what you were trying to avoid.
What does that mean?
It means you have to fall back to the basics—the old-school, legacy way of handling files. That means using things like fopen, fread, fwrite, and other file stream functions.
Most C/C++ codebases use those anyway. Some fall back to HANDLE (like libzip), but a 90% working solution is always better than something completely broken.
So I built a full emulation layer for fopen, fread, fwrite, and more, based on a fake FILE* wrapper that behaves just like the standard C API.
It was anything but easy—especially for the functions that involve formatted output. I ran into weird issues that forced me to manually parse format strings.
This part of the project was long, difficult, and time-consuming. I had to dive deep and understand how each stream function really works—the exact kind of low-level detail I always avoided every time I saw those functions in a library.
UWP apps have a "Pause/OnSuspending" behavior — meaning the app (and its threads/render loop) gets paused whenever something else steals focus. This includes file pickers, which suspends the app until the user selects a file (on desktop this may differ).
As you'd expect, this introduces some bugs. For example, the file picker might close unexpectedly during file selection, and if the app doesn’t handle it properly, it may crash. Good luck debugging that.
So instead of relying on external pickers, why not do it the better way? Pick files directly in place — and manage them too.
I started with ImFileDialog, but had to modify it to make it usable in a mobile UWP context:
-
On vertical mobile screens, the layout was nearly unusable.
-
The on-screen keyboard would pop up and cover half the interface.
-
Async file loading was necessary to prevent UI freezes.
Here's what I added:
-
File previews
-
Asynchronous loading
-
Basic file operations (copy, delete, rename)
There were many other fixes and tweaks for the environment that I cannot remember.
One particularly tricky issue was navigation. On touchscreens, I don't like tap to open files directly, user may need to scroll, select before open.
Double-tap navigation was implemented and works, but due to varying frame rates and tap speeds, it wasn’t always reliable.
The solution? I made the left-side icon act as a button that opens a context menu — much more stable and touch-friendly, in tight area with a lot of files there is no empty space for the user to show the root context, so the root folder has sub menu button at the top so you can perform few tasks.
I thought touch would be simple. One tap = one event, right?
Nope. It was one of the hardest parts.
I had to analyze touches over multiple frames. Imagine this:
- One tap = maybe scroll.
- One tap + hold = maybe context menu.
- Two fingers = maybe zoom.
Delays, offsets, visibility — everything had to be accounted for. Even the angle of your finger blocking the view mattered.
Touch rules became an entire engine of its own.
Still not perfect, but after all the headaches, I’d say it works 70% correctly.
I always believe that there is no fancy recipe that can solve everything
you must at some point calculate and emulate behavior manually
in my WUT app I had to make deep conditions for pages navigation, this sounds bad idea?
but as user experience it's much better than the regular page navigation and caching system
same goes here, I believe OS such as Android or iOS has their own deep calculations based on studies to perform the best touch behavior and it doesn't happen as auto trigger for event action.
Another example on the wide cases touch may cause.. the input pane (touch keyboard) behavior
the basic one is when you touch on input it should popup, when touching outside it should go
but there are some cases I don't want it to popup because I didn't initially touch the input it just my finger got released over it after scrolling
same goes for the bottom bar I didn't meant to touch the start menu I was just scrolling horizontally and ended a bit over the start menu
it happens quick but generally will trigger unwanted thing, specifically there are some parts of the UI has NoInput flags to avoid losing the focus when they get touched, so I usually calculate the touch point and the position of those items to detect whether they need to be clicked (simulated) this increased the problem in few cases.
the opposite exists always like in the terminal I want to copy text but keep the keyboard visible because I'm still working and typing.. so I ended up making different behavior for each case
also the menus and sub menus, in vertical case, the sub menu may appear above the main one which is right under your first touch, and because there is release delay resolver you get the sub menu clicked as well lol.
anyway this much headache if I want to explain every point, but it kind of stuff I like to solve and nearly got fine behavior.
I wanted a desktop-style experience. That meant multiple windows, taskbars, minimize/maximize behavior.
The problems?
- Handling focus across windows was tricky.
- Mobile rotation would break layouts.
- Rendering minimized windows wasted CPU.
I built a focus manager with rules for rendering, behavior, and even FPS throttling:
- 30 FPS standard
- 30 FPS with CPU sleep to reduce power draw
Yes, configs matter. I built a custom .ini system that automatically saves and restores settings. This made testing and UX so much easier later.
I integrated ImGuiColorTextEdit, but again — mobile broke it.
- Touch input caused weird selection bugs.
- Input pane would cover the editor.
- Needed to scroll the view when cursor was hidden.
I even supported multiple editor instances with their own buffers.
Zoom? Done. Syntax colors? Extended.
A huge thanks to BalazsJako — this widget saved me.
Tabs needed tap (hover, click) support — hover doesn’t exist on mobile. I made a system to switch tabs on tap (technically "hovered").
DPI scaling? The usual nightmare. Every device had its own multiplier.
So I gave users custom scale controls.
I didn’t plan on this... but I ended up with a multi-queue task engine to keep the UI smooth. It works and helps a lot with long-running operations.
Mobile top/bottom screen areas are semi-dead zones (used for notifications or gestures). Touch often fails there.
I decided not to place anything critical in those spots, there are custom calculations to increase the delay of the pointer if the touch was on those places.
Style editor? Based on ImGui's demo.
Menus? They were tricky. I had to simulate click events over multiple frames to avoid unwanted behavior.
Mixed fonts can be a RAM killer. I thought adding FontAwesome would be simple.
Boom — 160MB usage.
Turns out, fonts are loaded into memory whole. I now only load the glyphs I need.
This needs a full font engine... if I ever get the time.
Async in UWP is a mess. Half the APIs require UI thread.
No blocking, no sync alternatives. You’re stuck using await, co_await, or nothing.
Win32 doesn’t like it either.
I hacked my way through it — not proud, but it works.
NTU lets you build your own extensions. Inspired by RetroArch/Kodi, but powered by ImGui.
I made helper APIs like:
ImMobileWindowImMobileInputImMobileImage
They abstract away the hard stuff and let you focus on building something great.
I value scripting. So I embedded QuickJS.
JavaScript lets users:
- Automate tasks
- Write simple extensions
- Skip the C++ build process
It’s fast, lightweight, and far easier to use than C++ for small tweaks.
I added wallpaper image support and suddenly... camera photos were flipped.
Turns out: EXIF Orientation is a thing.
So I wrote logic to detect EXIF tags, rotate as needed, and cache the result.
I later found WinRT has APIs to handle this. Too late. 😅
But it works now. Even huge images are compressed + cached.