You know, I always love exploring
strange and obscure software. From old versions of Linux, to strange eBay
finds, it’s always one mystery after another. This time, we’re diving into Microsoft’s Windows
NT 4 Embedded, which is a special variant, which, as the name suggests, intended for use
in the creation of embedded systems. While Microsoft generally offered Windows CE
for use in these roles, Windows NT Embedded was offered as an alternative. I was somewhat
curious to see what it was like compared to more traditional offerings, so I decided
to roll up my sleeves and dive in headfirst. That led to the decision to do a livestream where
I installed NT 4 Embedded, and explored just what was in this forgotten piece of history. Over
the course of six hours, I ended up creating a few custom images, testing the provided
Target Designer and Component Designer, and just for fun, committing a few
crimes against web design along the way. Since my dive down the rabbit hole was
deep to say the least, we’re revisiting an old concept of mine, known as NCommander in
Real Time, where, with some editorial help, I recut one of my lifestreams into a video with new
commentary, and additional research. That’s also why you can see my ugly mug up in the corner. With
the backstory out of the way, let's dive right in. The first thing to note is that Windows NT
Embedded isn’t something you just pop in and install. Instead, it takes the form of multiple
applications that are loaded on a more traditional copy of Windows NT. Before the stream, I
took the liberty of installing Windows NT 4 Server with Service Pack 6 in VirtualBox,
and then popped in the NT4 Embedded disc. Due to Autoplay, we’re
immediately greeted with a pop-up, and a laundry list of requirements. Of these,
the most relevant was that I had to install Internet Explorer 4, which brought
Active Desktop along to join the party. After sorting out the prerequisites, Installation
took the form of a simple InstallShield installer, and when all was said and done, we left with two
new applications. These are “Target Designer”, and “Component Designer”, which could be
called the meat and potatoes of NT4 Embedded.To understand what these actually provide
though, we need to take a step back, and explain just what NT4 Embedded actually is. The easiest way to put things in context is to
look at the smallest possible installation of the normal retail versions of Windows NT. Microsoft's
own system requirement guides list 110 megabytes of available disk space as the absolute
minimum for NT 4 Workstation. In practice, you likely need closer to 150 to 200 megabytes,
for both applications, and the system page file. For those not familiar with embedded
systems, that might seem reasonably small, however, by embedded standards, it would
be excessively large to say the least, especially by the standards of the day.
Embedded systems, generally speaking, are designed around standardized hardware for
a single objective. This is in contrast to a consumer system, which has to be able to fulfill
any role at any time. To put this in context, the easiest way is to compare this to Linux,
where you can strip it down to the bare essentials of what you need. For example, it's
relatively easy to fit modern versions of Linux into less than 10 megabytes while still
having plenty of room for applications. This thus brings us to the heart of NT4 Embedded, which can basically be seen as an effort
to convert Windows into a modularized set of components that can be included
or excluded at will. The end result is that it's possible to create highly tailored
systems with little to no excessive bloat. However, the real question I have is, just much of
Windows is actually optional? In an effort to find out, I started creating a new Target Designer
configuration, which excluded everything but the absolute essentials. After working through all
the configuration screens, I was ready to build an image, but, annoyingly, deploying NT 4 Embedded
is not a straightforward or intuitive process. The Build & Install option in the menus
can write out a configured system, but instead of creating a disk image like one
might expect, it simply copies the necessary system files to a given directory. To actually
use NT Embedded, I had to get a bit creative. I tried a few approaches, such as
adding a new entry to boot.ini, but what ultimately worked best was adding a
second hard drive to the machine, and then copying the build files over. After doing so, I could
stop the VM, and then swap the hard drives around. This made the NT Embedded installation drive
letter C:, which immediately booted up, and presented us with a single command line
window in a low resolution 16 color mode. Given I stripped out all the optional components,
to say that there's little to see here is a bit of an understatement. Even the system font has been
replaced with a no thrills alternative. It’s only by opening the properties screen that we can see
that the core of the Win32 API is still available. However, what’s more impressive is that this
installation is only about 10 megabytes in size. That’s less than a 1/10th of a
normal Windows NT installation. Admitly, it’s still fairly large for what is
essentially a “do nothing system”. However, that cost is likely offset by the fact that
pre-existing Windows software could be easily modified to run in this type of environment.
We’ll explore this point in depth a bit later, but while setting up the minimal image, I
found myself wanting to look at something else that had caught my eye. Specifically,
this option is called the “Standard OS”. As it turns out, the Standard OS option is
pretty much exactly what it sounds like. In comparison to the minimal command line,
we now have Explorer available with all the bells and whistles attached. Since
we also had the Control Panel available, I was able to load the VirtualBox display
drivers, and switch to a high color mode. Although I didn’t test the Standard OS
configuration extensively, it’s likely that any NT compatible application would run
without modification in this type of environment. It also appears most, if not all Windows
NT components are available. For example, in Target designer, we can see various
Microsoft technologies such as IIS are listed. That being said, there is a fairly
large difference between building an example configuration, and deploying a real world
solution. While it's not exactly the best test, I decided to try my hand at making two more images,
based on hypothetical real world scenarios. The first is a minimal configuration dedicated
to running a single application. My candidate here was an unmodified version of NetHack 3.4.3,
since it only depends on a handful of libraries. In contrast, the second image would be a
more complex NAS-like device intended for hosting simple websites while simultaneously
being accessible over Windows file sharing. Since the option to deploy IIS was already
present, I decided to tackle that first. This was pretty easy in the end, since it only
required me to set some configuration options before our new embedded web and
file server was up and running. Amusingly, IIS comes with an appropriately
bare bones welcome page for NT Embedded. To properly celebrate this relic of the early web,
I used Word 97 to create a true expression of my passion for design and deployed it to NT Embedded
over SMB. This eye popping abomination will no doubt haunt the dreams of my viewers for years to
come, while simultaneously proving that Chrome and Firefox still support the marquee tag. Learning
that alone made this entire adventure worthwhile. Still, all good things must end, and with
the crimes against good taste complete, it was time for the Embedded NetHack image. This
was a bit more involved since, to do it properly, I needed to create a new Component to
incorporate the NetHack games files. This is done with Component Designer, which is an
incredibly uninitive application to say the least. It was only after a lot of trial and error that
I was able to create a NetHack component, and then build it into add it in Target Designer. The
“best”, and, I use that term lightly, comparison I can make is that this is very similar to
creating a Windows Installer package and I won’t be surprised at all if MSI files were in fact
influenced or influenced by Component Designer. At this point, it was time to deploy
the image and cross my fingers. If I did everything correctly, we’d boot right
into NT Embedded, and into a new game of NetHack. Obviously, it wasn’t that simple. My first
attempted boot just led to an error that WINMM.DLL is missing, which is part of the Windows
multimedia system. There isn’t an easy way to just include just one file, so I ultimately
just copied it manually. After a reboot, I was suddenly an archeologist on my quest for
the Amulet of Yendor. Mission accomplished. Admitly, in a real world scenario, I’d would likely just modify NetHack
to drop the WINMM dependency. However, it goes to show how much is actually offered
even in the so-called minimal configuration. Now, I could close out here, but there
are a few takeaways I want to talk about. While NT Embedded can build
impressive real world solutions, it's also incredibly rough around the edges. One
of the largest problems I ran into is that adding new drivers to Target Designer appears
to be an incredibly daunting task. Under normal circumstances, a Windows NT
driver is a set of binary objects with an INF that includes the necessary
metadata for installation. One would expect that one could just slipstream
new drivers in if you had the INF file, right? Unfortunately, it doesn’t appear to be the case.
From the example components provided on the CD, Windows NT Embedded drivers appear to
directly edit and influence internal data structures in the registry.
Microsoft did provide the sysdiff utility which at least makes it possible
to know what entries to add, but honestly? Adding a third party driver seems like
it would be literal days of effort. This isn’t helped by the fact that NT
Embedded also has a fairly bizarre workflow. It almost seems like you’re intended to just
deploy an NT Embedded image on a second hard drive, pull it out of your development PC, and
then put it in the target hardware to test it. The best way I can describe the
experience is as “less than ideal”. It seems like, at a minimum, one would need to
use third party utilities like Norton Ghost, or the then-new VMware, to actually get something
done without an excessive amount of frustration. The documentation does allude to the possibility
of creating a bootable CD, but even then, it doesn’t document the required steps to do so.
I can only assume that, on the whole, many of these rough edges were sanded down a few years
later with the release of Windows XP Embedded. Perhaps we’ll take a look
into that on a later date. It’s on that note that if you enjoyed this video,
please give a like, and consider subscribing. If you really enjoyed this video, consider hitting
that bell or becoming a Patreon. With that said, as always, you can follow my adventures in
realtime on Twitter, or come hang out on Discord. Until next time, this is your host NCommander,
signing out, and wishing you all a pleasant day.
