(This is a guest post by Antoni Sawicki aka Tenox)
Another day another NT QEMU post. This time we have stock Windows NT 4.0 PowerPC running on QEMU, with complete emulation of the BIOS / Firmware and everything. Networking and 1280×1024 resolution.
Since I did some work on RM-200 QEMU and this system is also capable of running Windows NT MIPS in Lite Endian mode (the CPU can switch endianness) I decided to also get it working:
I have previously covered NT on MIPS QEMU Jazz emulated machine. This is not that much different and fundamentally very close. Just a different machine with different firmware and peripherals. Also much newer QEMU version.
(This is a guest post by Antoni Sawicki aka Tenox)
In the previous post I mentioned working on a large deployment of Citrix and NeoWare thin terminals. We were using Citrix ICA exclusively. But the NeoWare terminals also had this mysterious “NTRIGUE” protocol that I never had a chance to use:
Various brochures, press articles and ads about the HDS @workStation also mentioned that this thin client is for NTRIGUE with zero mention of Citrix or ICA!
Very strangely all NTRIGUE and no mention of ICA/Citrix! What is going on here?
And what exactly is this NTRIGUE?
In a nutshell: Isignia company was mainly known for SoftPC and SoftWindows – PC emulators for Mac and Unix.
Insignia NTRIGUE product was a version of Citrix WinFrame that used Xwindow / X11 protocol for the transport. X11 appears beside ICA in the WinStation protocol list.
And that would be all… if I didn’t score a red box on eBay!
Behold! After 30 years of waiting, I present you NTrigue:
The CDROM is essentially Citrix WinFrame but everything is find / replace rebranded as NTRIGUE.
Even the NTOS kernel prints NTRIGUE…
And the login screen
The real deal comes from WinStation configuration. You can create one with X11 protocol instead of ICA:
But how do you use it? Very simply! In two ways:
XDMCP Query, either from a physical Xterminal or Xnest or Xephyr:
…yes so now any plain regular Xterminal like NCD, HP, Tek, IBM, DEC, etc can connect to a Windows host!
Second way – export NTRIGUE X11 client via remote display export. Like you would with xterm -display x.x.x.x:N or export DISPLAY=..... You RSH into NTRIGUE box and request a client:
rsh <target> <client_ip> <resolution> <colors>
In practice:
It seems that the NT box runs a rsh daemon and can send you an X11 exported client via x11.dll. It looks like they ported xlib to NT:
I find it curiously odd that the NTRIGUE client “app” runs on the host and exports display via X11 protocol. This is unlike ICA or RDP where the client runs on … the client.
Citrix ultimately acquired NTrigue from Insignia. Never to be heard from again and the tech essentially being buried. Is possible that this became their X11 ICA Client, but more likely they just bought it to kill competition to ICA protocol. After Microsoft released Terminal Server Edition with RDP, the ICA protocol and app management was all that Citrix had left to offer. NTrigue offered a “client-less” alternative. That couldn’t be good for business.
Finally a gallery of various UNIX systems talking to NTRIGUE:
(This is a guest post by Antoni Sawicki aka Tenox)
Around 1998/99 or so I was involved in a large deployment of Windows NT TSE (Terminal Server Edition) with Citrix Metaframe, for a Forbes top-100 listed corporation. The general population were using plain boring Neoware thin terminals with ICA client for their daily tasks.
Unidentified generic Neoware thin client pic stolen from ParkyTowers
Managers and higher ups were using “high end” Neoware “workstations”. Actually named “@workStation Prima”. They had options for TV and AV capture cards, teleconferencing, streaming and multi screen. However no one really used these advanced features and the expensive workstations didn’t provide any extra functionality or value in practice. Just bigger, fancier and made you look more important in the corporate rat race.
For the more perceptive observer however they did have some interesting curiosities hiding inside the pizza box. Firstly they were rocking Intel i960 !
Secondly if you pressed the odd “Don’t login” button at the ICA screen, you would land at a full blown desktop with some apps, games and a terminal with local shell. The OS (named netOS) was some proprietary i960 UNIX. Because it did feature mostly GNU apps I assumed it simply must have been an embedded Linux distro and didn’t make much of it.
Fast forward almost 30 years, Rico scored a copy of Neoware netOS install media and some people even got it installed. Out of nostalgia, I also wanted to do some archeology here and play with i960 iron. Bought one of these Neoware @workstation terminals at eBay and got the OS copied to my tftp/nfs server and booted it up.
Good memories and fun with ICA and XDMCP terminal. But I wanted to see what else can be done with the weird i960 system. I started looking at the kernel and tools. Upon closer inspection of the binaries, turns out these are not Linux at all (also i960 doesn’t have MMU so it could not run it anyhow), instead it seem to be 4.4-BSD based.
AFAIK an official SDK was never publicly available. But applications like NEdit, XScreensaver and even Netscape Navigator shipped with the OS so they must have been ported to netOS internally. Fortunately with help of LLM I was able to do some reverse engineering and map out the binary format and syscall interface. GCC 2.95 did support i960 ISA and Binutils 2.11 was able to produce somewhat compatible binary format. i960-intel-nindy is the closest triplet (nindy is the i960 ROM monitor). The rest was history. An unofficial netOS SDK was born in an evening.
Aclock on i960 UNIX
For now it can compile just the simplest C apps, but I will expand it more. I want to port SimCity!
Last but not least the “premium workstation” has an IDE port and allows installation of a hard disk for local boot. This makes it lot less of a network booted terminal and more of a proper workstation. I slapped on an industrial IDE DOM, fdisk/newfs and got the OS copied to it using provided script:
Now I have a full blown i960 UNIX graphical workstation with local OS and SDK. Hopefully one day it can self host its own toolchain!
Update: now we have rshd, telnetd and even busybox !!
studio:/Users/tenox> telnet 192.168.1.11
Trying 192.168.1.11...
Connected to 192.168.1.11.
Escape character is '^]'.
netOS telnetd - exit or ^D to quit
NETOS> busybox sh
BusyBox v1.00 (2026.09.27-09:42+0000) hush - the humble shell v0.01 (testing)
Enter 'help' for a list of built-in commands.
~ # version
Server Code Version: 3.2-D (Build 560)
PLCC Boot PROM Version: 3.1.1-E (Build 12)
netOS Version: 3.2 netOS for the Enterprise with ICA
~ #
I’m sure at some point there will be some kind of merger. As always things move fast when they are interesting.
At any rate, I had nothing but incredible issues getting this to build. I should have written the steps down for the Qemu Alpha for that can run Alph64 Windows! … .however I didn’t so I kind of lost (hopefully temperarily) the recipies needed.
Instead, I’m jumping back to my mac mini, as of course macOS is just enough UNIX to be useful but mainstream enough to have real application. And part of the reason is that I wanted to build the firmware as I had a feeling that this was some important ‘lockstep’ thing I was missing.
Building cross compilers isn’t that new for me or this blog. As a matter of fact, I’ve got two at the moment from other various projects:
jsteve@Jasons-Mac-mini gcc % /usr/local/os2/bin/i386-pc-linux-gnuaout-gcc -v
Reading specs from /usr/local/os2/lib/gcc-lib/i386-pc-linux-gnuaout/2.8.1/specs
gcc version 2.8.1
jsteve@Jasons-Mac-mini gcc % /usr/local/i586-linux2/bin/i586-linux-gcc -v
Reading specs from /usr/local/i586-linux2/lib/gcc-lib/i586-linux/2.8.1/specs
gcc version 2.8.1
Since GCC 2.8.1 seems to run ‘okay’ as a macOS arm64 binary to cross compile to the i386… But that’s not for here. Since this is a ‘modern’ build, there was no need for any funny business. Things just worked. Surprisngly, I know. Obviously for people years later this won’t hold true.
Binutils
Nothing much to see or say, just used binutils 2.46.0, and it configured/built out of the box. Nice.
This is a bit weird as, the Itanium is not a dying platform, but a very dead one. Although thanks to a single user, René Rebe keeping the flame alive, I just chose to use the mentioned version, 15 to see if it still works. Spoiler, it did!
Building on macOS also means I do have homebrew installed, and that instead of building so many dependancies from hand, I could just brew the dependancies for GCC. That did make configuring it a little more involved.
There is some weird duplicate define of fdopen that throws off the build, thanks to zlib. I know wtf.
In file included from ../../gcc-15.3.0/zlib/zutil.c:10:
In file included from ../../gcc-15.3.0/zlib/gzguts.h:21:
In file included from /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/stdio.h:61:
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/_stdio.h:322:7: error:
expected ')'
322 | FILE *fdopen(int, const char *) __DARWIN_ALIAS_STARTING(__MAC_10_6, _...
| ^
../../gcc-15.3.0/zlib/zutil.h:140:33: note: expanded from
macro 'fdopen'
140 | # define fdopen(fd,mode) NULL /* No fdopen() */
The fix, of course is to comment out line 140 of zutil.h
After that, it’ll mostly build, (remember to have the binutils binary in your path! export PATH=/usr/local/ia64-linux-gnu/bin:$PATH )
It’ll complain about missing pthread as it want’s to build all the Linux stuff, but we don’t care.
In file included from ../../../gcc-15.3.0/libgcc/gthr.h:157,
from ../../../gcc-15.3.0/libgcc/libgcov-interface.c:27:
./gthr-default.h:35:10: fatal error: pthread.h: No such file or directory
35 | #include <pthread.h>
| ^~~~~~~~~~~
compilation terminated.
Since I’m on macOS, I wanted to use the coca backend, so I don’t care about GTK+ or SDL.
From there it was just a matter of running make… I did a -j6 to use six cores it tore through the source, stopped after a few minutes with some weird error, I just typed in ‘make’ again and it finished…. Not sure what it’s hangup was, and I really don’t care.
Being greeted by the firmware image, is again confirmation that we can indeed cross compile the Itanium firmware with our GCC cross compiler!
And then the CD-ROM will prompt to hit any key to boot from CD
Press any key to boot from CD-ROM…..
At this point I should mention that Qemu doesn’t scale well with high resolution monitors. But since we enabled the zoom-to-fit option, we can resize the window so we can read it, or just maximize it.
From here it’s basically a normal XP install
Unlike the RISC of old, the creation of the system partition is now handled by the install program, like all the other EFI/UEFI platforms.
Which I have to say, is a nice change.
From there just select the remainder of the disk, I format mine as NTFS (quick) and from there it’ll start copying the files. For me this completed in under 5 minutes.
A quick reboot and you’ll now be in the graphical installer.
From here it could crash or lock hard. In that case, re-create the hard disk image, and re-try the installation. It took me 5 attempts. Although I should mention that I never could complete a single install using syunn’s fork.
XGCJ6-Q6XGJ-BQ2QQ-BRWJ7-67X7W
And when asked, I just chose the default networking settings.
In prior builds this would fail and/or hard lock at various moments, with an overall success rate of 1/5. Not the best. Although I’ve only installed XP 2600 once today, and it was a 1:1 rate in 30-40 minutes, so I guess I can say that as always, things are in motion, and getting way better!
On my m4, it took about another 30 minutes, and then It’s done.
And there we go!
I’d highly suggest setting up RDP, and using a remote desktop application, as the arrow keys currently tend to repeat far too often making typing a chore. Plus it’ll fix any coca video scaling issues.
Using the same config, different ISO, yeah it installed in about 40 minutes on my m4 Mac Mini.
Windows Server build 2462
Why, even the earliest Windows Server Itanium build that’s available, 5.1.2462 installs and runs! Of course, install it prior to August 2001.
What about other operating systems?
As of now I don’t think anything else works. Monterey didn’t do much, nor HPUX, VMS etc.
Where to go from here? Compilers! and whatnot. Needless to say, since this is 1st gen Itanium, all the stuff I’d built when I had an Itanium won’t run as it was Itanium2. Don’t you love broken binary compatiblity?
This is why 80386 is just as relevant in 2026 as it was in 1987.
Of course, Apple will break it, just because they can.
In the past I did some and some more work on SimCity/Micropolis to bring it to vintage computing. This old DUX SimCity / Micropolis works remarkably well, but because of the TCL/TK and X11 UI, platform availability is quite limited. I have previously also ported Micropolis to Windows NT (RISC) as WinTown.
But thats not enough! I wanted to run SimCity on a vintage Unix without dependency on X11 and TCL/TK. The game graphics (basically a map) is quite simplistic and structured. I was wondering if text mode rendering would work. Quite a while ago I winged up a quick ncurses based map/city viewer and it was quite promising! Fast forward to today… Behold TTY City!
The game is quite usable and playable. In a modern terminal it even supports mouse with panig and simple animations. Earthquakes look pretty cool!
The monochrome terminals are little more difficult, but I’d say is playable.
Here is a picture from an actual DEC VT420! Not bad!
When perfecting the letters and characters, I had this idea… what if modern terminal amenities could be used… like Unicode Emojis perhaps? After all you can have these 🌲🌳🌴🌵 and these 🏠🏡🏢🏭 in rendered in a terminal❗
Behold Unicode Emoji Terminal SimCIty!
Available from: https://github.com/tenox7/ttycity – there are no releases or packages yet, as it’s work in progress but expect it to be available for most modern and vintage operating systems!
It worked quite good but I did not particularly like some of the Firefox/Mozilla foundation controversies and policies. Started looking for alternatives, but the situation was quite grim. Ladybird Browser is still in active development. Chrome exterminated Ad Blockers. Brave was over bloated with crapware.
TIL Brave has released “Origin” version which is minimal and void of all the garbage features, but still has a fully functional Ad Block! Normally Origin asks for a one time license purchase, however Linux version is free. Since Docker is Linux… a perfect fit for the use case! VNCBRAVE was born.
In practice is so nice that I wrote this article on HPUX 10.20 with VUE desktop:
VNCBRAVE – Brave Origin with VNC Server as Docker Container
I also added routing of Brave active tab title in to VNC “Desktop Name” so it shows in the client window if supported.
I also typically switch to compact mode to save some real estate and make some other settings like solid background color, tab suspension and aggressive ad blocking.
A collection of TightVNC ports for old OS is available here.
