Slimming Down Windows 3.1/3.11 (2002)
geocities.ws
geocities.ws
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.
Somehow snappyness is completely eradicated.
Barely inadequate engineering by design.
Actually that's a difficult target to hit accurately and there's a fine line between it and barely adequate engineering leadership.
And even if it's adequate, is barely adequate what you wanted anyway?
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.
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?
Anyway, what comes to mind is Etherboot[1]. I'm pretty sure he used BOOTP[2] with a TFTP server for the distribution part.
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.
Old network cards could have a boot rom in them; this https://www.vogons.org/viewtopic.php?t=86741 discusses the magic and a couple of the non-pxe protocols.
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.
Edit: yes, wikipedia seems to confirm my recollection
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.
He'd either boot to it to 'hobble' his own laptop and remove all other distractions while writing, or boot to it from other peoples PCs to a set up he was used to and happy to work from when away from home. (Mike was one of the first technomads - or at least one of the first to post about it a lot.)
I had a similar set up for a while which I used with my home laptop or work PC at lunch time, but I never really got into writing as much as I'd hoped I would, so it wasn't that useful for me.
Interestingly W95 could be trimmed down to about 35mb, and carefully adding Word & Excel from Office97 was about another 65mb, so it ended up fitting if you had one of the huge 128mb USB sticks.
That's about the smallest I can figure you can get a 32-bit Windows office machine which would be "fully compatible" with the latest Windows & Office versions, as long as you were carefully storing your office files on a FAT32 partition and limiting your expectations (like file size and number of XL rows) to those addressed by W95 which was as functional an office machine as millions of people need today.
For those of you who did manage to run W95 at its full 2GHz maximum over 10 years later on much higher speed motherboards than there were in the 1990's, you know what I'm talking about when I say the most noticeable thing is zero latency in almost all human-computer interactions.
You could be doing all kinds of office work, with lots of other things to "boot".
Just got a couple more of the "small" 128GB SATA SSD that are finally cheap enough for bootable OS's to use like "game cartridges" now. Not much different "application", just faster booting and operation than most USB.
Two partitions on each SSD, one for an OS only, one for ALL related storage.
Still have some massive multibooting going on, but with these lttle SSDs the most up-to-date are going to be W11, W10x86, W10x64, Debian, Mint & Fedora.
Fortunately I got a few of the pre-NUC cheap ASUS miniPC that has a simple hatch on top and came with a full size SATA Desktop HDD right there. Gets even better ventilation and has no exposed electronics when the cover is off all the time, remove the HDD (for good now) and just slip in whichever SSD you feel like booting to at the time.
Looks like about 128GB will do what 128mb would do back in the day.
That's because DOS-based Windows could use the BIOS for disk access, and BIOS presented USB drives as hard drives. I believe you can even do the same with an NVMe SSD that has a suitable boot ROM.
W98 would install and run from USB too, as long as USB device drivers did not get installed. That way once booted if you plugged something into a USB socket on the MB, it was "unknown" and remained inaccessible. But if you booted when the second USB device was plugged in beforehand, W9x (or DOS) assigned an alphabetic drive letter and you could access the files.
Sometimes I still use a small FAT32 partition with simple DOS on a Syslinux'ed volume to boot distros from the NT5 bootloader. That way you can edit the Linux multiboot menu in Windows, or even DOS which sure boots a lot faster today.
Now they have USB enclosures for M.2 drives, usually not both NVMe & SATA flexibility though.
There was a SCSI drive for data storage in 1995, but it required special Data discs instead of standard audio ones: https://www.minidisc.wiki/equipment/sony/misc/mdh-10 (disclaimer, I run this site)
They finally did allow mass storage usage with Hi-MD as the format was dying out, but too little too late.
There's now a FUSE driver PoC for standard MD devices that have USB ports (NetMD) thanks to reverse engineering.
Lots of OS support live USB images. It’s only Windows and macOS that don’t (though I’m sure Windows could with a little effort).
> Sony really should have brought the minidisc to the pc as a floppy and cd/dvd rom replacement.
Sony did. But there were already removable writable formats that had larger capacity than a CD back when the minidisk was a thing and they didn’t become mainstream either.
Frankly I think MiniDisk is one of those technologies that people remember as being better than they actually were.
Mac OS can boot from external volumes too. It's not a traditional live image, the volume is usually writable and it's a real copy of Mac OS. We're probably talking actual HDD or SSD portable hard drives here, not flash drives, Mac OS isn't that small. You need a Mac to run one of these of course. No idea if this works across computers on Apple Silicon. The new Macs store a lot of the encryption and boot policy stuff in the SE, so I have no idea if booting an unrecognized system would actually work.
It's "Windows-to-Go", introduced in Windows 8.0 which had the full Windows functionality contained on the USB stick, if the bootable stick met the high-performance requirements and had firmware indicating to Windows that the USB stick was not a "Removable Device".
This was gradually deprecated for the most part:
https://learn.microsoft.com/en-us/previous-versions/windows/...
"Hiren’s BootCD PE (Preinstallation Environment) is a restored edition of Hiren’s BootCD based on Windows 11 PE x64. Given the absence of official updates after November 2012, the PE version is currently under development by the fans of Hiren’s BootCD. It features a curated selection of the best free tools while being tailored for new-age computers, supporting UEFI booting and requiring a minimum of 4 GB RAM."
As MiniDisc and Zipdrive are obsolete I'd like to have a minicd or businesscard CD audioplayer based on a RaspberryPi Zero. With using Vocos, EnCodec or Lyra v2 you could fit 200 hours of stereo audio on the small cd at around 3 kbps and select them with some buttons and a LCD screen. Similar to the Imation RipGo or Memorex portable 8cm mini-cd players which could play mp3. https://languagecodec.github.io/
Alternatively I could use cassette or microcassette. https://hackaday.com/2021/10/20/audio-tape-interface-revives... https://blog.adafruit.com/2023/10/17/a-wind-up-cassette-play...
I could run a bootable OS on MicroSD and using external small cd's as data or app storage, perhaps also to boot from. An OS experience [Redox, Haiku, KolibriOS, Dragonfly, Fuchsia, MorphOS, Serenity] booting from a 8 cm business card CD depending on the day, weather or mood. https://en.wikipedia.org/wiki/Mini_CD
Or perhaps just boot into a Raspberry Pi zero menu to select or boot a random OS from the Zero and use Airtagged encrypted USB-C sticks (making sure each OS can read the encrypted volumes).
CD based: https://en.m.wikipedia.org/wiki/Bootable_business_card
PCB based: https://hackaday.com/2019/12/24/now-even-your-business-card-...
There’s also NFC based digital business cards, which are now really common. But they’re obviously it bootable / running Linux.
>Sony did. But...
If it was from Sony, it was probably ridiculously expensive. Everything they sold had (and still has I think) the "Sony tax", making it uncompetitive with other standards, especially for something like removable media where the per-unit cost adds up quickly.
You can run macOS from a USB disk, although it won't be a readonly live disc like the Linux ones.
Probably similar for BD-RE (recordable, erasable) and BD-R, too.
Also the Windows ADK to make a custom Windows PE is how HBCD is made to load a windows desktop with a bunch of tools off a CDROM
That means that Windows 3 was compatible with the newer DOS version that came underneath 95. If someone still has the software and wants to test it, IIRC the only thing needed was to edit autoexec.bat and have different directories for every Windows.
I'm always sort of amazed how well Windows 3.x runs on hardware that would have been a bit old even when 3.0 was released.
Companies still use Windows 3.X because of old software written for it that they don't have the source code for it anymore.
Yup, a particularly funny case was just recently the German Railways and/or their vendor Siemens...
I used a drivespace volume for a very very very long time, even when I had 80 GB HDDs, because it made it SO EASY to back up the entire windows installation - just copy the file.
No, at that time software didn't do anything by itself.
DriverSpace was the new version after the lawsuit was settled.
16 bit Windows was consciously designed, intentionally made modular, to accomplish things like this. Albeit the author was surely not the intended customer!
https://web.archive.org/web/20090120233733/http://oldfiles.o...
The site is now gone, but at least it isn't a SEO spamming blog.
There might also have been some way to convince the kernel a piece of RAM was a block device. The "ramdisk.c" driver in Linux was simpler before.
After that, it was a matter of creating an init script which formatted the block device as a swap device, then running swapon.
I know for a fact that it WILL work :)
npm i[0] https://www.tomshardware.com/news/tiny11-23h2-windows-releas...