Recall a project back in the days where the customer wanted to upgrade their workstations but also save money, so we designed a solution where they'd have a beefy NT4-based Citrix server and reusing their 486 desktop machines by running the RDP client on Windows 3.11.
To make deployment easy and smooth, it was decided to use network booting and running Windows from a RAM disk.
The machines had 8MB of memory and it was found we needed 4MB for Windows to be happy, so we had a 4MB RAM disk to squeeze everything into. A colleague spent a lot of time slimming Windows down, but got stuck on the printer drivers. They had 4-5 different HP printers which required different drivers, and including all of them took way too much space.
He came to me and asked if I had some solution, and after some back and forth we found that we could reliably detect which printer was connected by scanning for various strings in the BIOS memory area. While not hired as a programmer, I had several years experience by then, so I whipped up a tiny executable which scanned the BIOS for a given string. He then used that in the autoexec.bat file to selectively copy the correct printer driver.
Project rolled out to thousands of users across several hundred locations (one server per location) without a hitch, and worked quite well from what I recall.
And here I am, in a shop of about 3K FTE, where we are squeezed 6 persons onto a single socket Xeon which barely beats an iPhone 15 Pro rendering those 12 screen worth of data slowing down to a crawl, huge latency, crappy disk latency too (feels like were all on the same spinning Rust, but it's Windows and some VMWare middleware so who knows why this is slow).
This was also when I learned about the pitfalls of multithreading...
I had started trying to use multithreading, and had implemented it in my raytracer. It worked like a charm on my machine.
During that project they brought a 4-socket server in the lab for testing, so after hours I fired up my raytracer on it, excited to see the promised 4x speedup... only to be met by an immediate access violation.
I had of course missed a lock, but it worked fine on my computer because it only had a single CPU (core) so even if I spawned multiple threads, the chances of them tripping over each other at that point was very low. Not so when they could actually run simultaneously.
>it was decided to use network booting and running Windows from a RAM disk.
What tech did that use? I imagine a "modern" system doing this would use a small RAM disk for the base Windows installation to boot from with any critical apps inside, and a second disk image mounted via HTTP for any "bulk" data, all via a custom iPXE build.
But NT4 predates the PXE standard by a number of years, and also the concept of mounting disk images via HTTP (or other SAN protocol). Was this some Netware stuff perhaps?
While it used NT4 this was around y2k, I recall we also had to test all the 486 and BIOS combinations they had if they survived y2k transition (one failed!). Which also means my memory is hazy.
Anyway, what comes to mind is Etherboot[1]. I'm pretty sure he used BOOTP[2] with a TFTP server for the distribution part.
bootp / tftpboot were used to provision diskless systems (diskless workstations / X-terminals) even in the very early 1990s (and likely before, but I didn't interact with them until college computer labs).
On scanning my brain-based archives I can't recall how IP addresses were assigned and a brief asking of google "bootp vs dhcp" leads me to believe that with bootp there was just a static list of IP / MAC mappings for already-known diskless devices.
A bootp server app generally listens for a MAC broadcast which appears when another physically connected device sends a "bootp request" into the network, so the bootp server can compare the MAC against its whitelist and assign its corresponding designated fixed IP address on the local network. Which IP address will then be remembered by the requesting device and is used from that point forward, not much differently than an address assigned by DHCP.
Some hardware like early HP ethernet printers did not retain their assigned IP address through a power failure. So there had to be a functional bootp server app up and running before you powered up the printer or the printer's initial bootp request would go unanswered and it was no good to anybody.
I also learned some valuable lessons in project planning and execution... they had a few guys who sat for 1.5 years to plan the rollout, working with suppliers to plan deliveries of the hardware etc.
When the time came we rolled out all the several hundred locations in just over 3 months, which included assembling and basic configuration of the servers at base, shipping the servers and then migrating data onsite from the old UNIX server (mailboxes, home directories etc).
We only had two issues, one server had gotten the hard disk cables disconnected during transport, easy fix had the technician on site been Compaq certified (had to get shipped back to base and out again), and another had a weird hardware error which caused the server to freeze when scrolling large log files in Notepad (replaced the server and all was good). Beyond that it went flawless.
To make deployment easy and smooth, it was decided to use network booting and running Windows from a RAM disk.
The machines had 8MB of memory and it was found we needed 4MB for Windows to be happy, so we had a 4MB RAM disk to squeeze everything into. A colleague spent a lot of time slimming Windows down, but got stuck on the printer drivers. They had 4-5 different HP printers which required different drivers, and including all of them took way too much space.
He came to me and asked if I had some solution, and after some back and forth we found that we could reliably detect which printer was connected by scanning for various strings in the BIOS memory area. While not hired as a programmer, I had several years experience by then, so I whipped up a tiny executable which scanned the BIOS for a given string. He then used that in the autoexec.bat file to selectively copy the correct printer driver.
Project rolled out to thousands of users across several hundred locations (one server per location) without a hitch, and worked quite well from what I recall.