Tagged as: DOS

Get FAT Drive Serial Numbers in Unix
December 31, 2009 by Noah
There's not a lot of information about this on The Google, so hopefully this blog will help anyone who wants to know how to get the serial number of a FAT partition from within a Unix-like operating system (including Linux and Mac OS X).

First, this is what I mean about serial numbers. Suppose you're using a Windows system, have a floppy disk at drive A:/ and a regular USB flash drive at E:/, and you run these commands in the command prompt:

C:\>vol E:
Volume in drive E is CRUZER
Volume Serial Number is 955C-59BF

C:\>vol A:
Volume in drive A has no label.
Volume Serial Number is EC2B-36AF
These serial numbers are assigned when the drive is formatted; reformatting a floppy disk or flash drive will give it a different serial number.

According to The Wikipedia, the serial number (ID) is kept in two different places on the partition depending on the version of FAT being used.

In FAT12 and FAT16 (used with floppy disks), the ID begins at byte offset 0x27 (39 in decimal); in FAT32 (used with flash drives and external hard drives), the ID begins at 0x43 (67 in decimal).

So, with the handy dd utility that comes standard on pretty much any Unix-like system, you can extract this information and display it. Here are a couple of one-liners you can run in a Unix terminal. I'll explain how they work afterward.

# For FAT32 filesystems (modern flash drives)
dd if=/dev/sdb1 skip=67 bs=1 count=4 | hexdump -v -e '1/1 "%02X" " "' | xargs perl -e '@_=@ARGV; print "Serial Number: $_[3]$_[2]-$_[1]$_[0]\n"'

# For FAT12/16 filesystems (old floppy drives)
dd if=testfloppy.img skip=39 bs=1 count=4 | hexdump -v -e '1/1 "%02X" " "' | xargs perl -e '@_=@ARGV; print "Serial Number: $_[3]$_[2]-$_[1]$_[0]\n"'
I underlined the input file (if) and byte offset (skip) in both of these commands. In the first one, I ran the command on a real, physical, flash drive, that had a device node at /dev/sdb1 for its one and only partition. In the second one, I ran it on a floppy disk image file (who has a computer with a real floppy drive these days?)

If you're going to be using a physical device like in my first command, you need to run the command with root privileges (regular users can't read directly from the device node). My second example (using an image file) can be run as a regular user, however.

These commands printed in the terminal for me:

(for the flash drive)
4+0 records in
4+0 records out
4 bytes (4 B) copied, 3.3445e-05 s, 120 kB/s
Serial Number: 955C-59BF

(for the floppy image)
4+0 records in
4+0 records out
4 bytes (4 B) copied, 3.1551e-05 s, 127 kB/s
Serial Number: EC2B-36AF
And now, how the commands work. I'll use the flash drive command as the example. In this one-liner, three commands are being executed at once:
dd if=/dev/sdb1 skip=67 bs=1 count=4
hexdump -v -e '1/1 "%02X" " "'
xargs perl -e '@_=@ARGV; print "Serial Number: $_[3]$_[2]-$_[1]$_[0]\n"'
The dd command gets the operating system to read raw data from the flash drive at /dev/sdb1, skipping the first 67 bytes, reading only 1 byte at a time, and reading a total of 4 bytes. This gets the 4 byte serial number; now we need to display it in hexadecimal like Windows and DOS.

The hexdump command takes the 4 binary bytes and displays them in hexadecimal. On my flash drive, it looks like this: BF 59 5C 95. Note that the hex codes are out of order; Windows shows them as 955C-59BF - basically, the reverse of what hexdump shows. Hexdump is showing the correct order; Windows and DOS reverse them when they show you the serial number.

So, we run it through xargs (which turns the four hex numbers into four separate parameters) and sends them to a quick Perl script, which prints out "Serial Number:" and puts the hex codes in the correct order, to give the same result as Windows and DOS.

One could use this information to make a vol command for Unix. If the command checks other places in the filesystem headers to determine the version of FAT, it could automatically use the correct byte offset and get the serial number from both floppy disks and flash drives.

Tags: 15 comments | Permalink
MS-DOS and Windows 3.1
February 14, 2009 by Noah
For a limited time only, files for installing MS-DOS 6.22 and Windows 3.1!

Windows 3.1

You can download everything from my MS-DOS page. I have some downloads for the following things:

  • MS-DOS 6.22 Installer Floppy Images
  • Windows 3.1 Installer Floppy Images
  • Drivers:
    • CD-ROM Driver (Floppy Image)
    • DOSIDLE to make DOS not consume 100% CPU(Floppy Image)
    • WQGHLT to make Windows not consume 100% CPU (Floppy Image)
    • SoundBlaster 16 Drivers (CD Image)

Installation Notes:

The version of Windows in this tarball is 3.1 -- not Windows for Workgroups 3.11 (for that, download it separately from my MS-DOS page). I got ahold of this version of Windows 3.1 from a CD image instead of floppies, so I had to convert them to floppy images myself, and not all the files fit on all the disks (there should only be 6 disk images but there's 7 in this tarball).

Windows 3.1 can still be installed from these images, it will just require more disk juggling. When you get a "Can't read file" error, you'll usually swap in the next numbered disk and hit enter. Sometimes you'll have to go to the previous disk instead.


If you want to download the components separately (DOS, Windows for Workgroups 3.11 and the drivers) you can find individual links on my MS-DOS page.

Another Update:


If you have issues with erratic mouse movement within Windows 3.1 on VirtualBox, some solutions are (from here):

  • Start Windows in standard mode (win /s)
  • Disable hardware virtualization (in the System/Acceleration tab in the VM settings)
  • Find a video driver that supports more than 16 colors (more info here).

Update (5/16/16):

I'm no longer hosting the bundled tarball that contains all the files + a VirtualBox preinstalled disk image to clean up disk space on my server. Instead, download all the components and install it yourself.


Tags: 209 comments | Permalink
Nostalgia for Windows 3.1
February 12, 2009 by Noah
My first computer ever was an old late-80s Tandy machine that was running MS-DOS and Windows 3.1 -- I got it when I was in kindergarten or first grade, and kept it until after I started 7th grade. So, I have more than a few nostalgic memories with the operating system, and have been trying to somehow virtualize it and relive a little bit of my past.

The first virtual machine software I found in the last year or two was QEMU. It wasn't an easy virtual machine to work with, and I could scarcely get even Windows XP to function to my liking with it, let alone try running a dinosaur of an operating system that isn't up to speed with current hardware, like what QEMU emulates for its virtual machines.

I was able to install Windows 3.1 on top of the DOSBox emulator. It installed, and ran, and I was able to install Chip's Challenge from Microsoft's Best of Windows Entertainment Pack and play it, with sound effects and everything.

However, DOSBox wasn't made to run Windows. Windows uses a VGA graphics driver by default, which gives it an entire 16 colors to use with a 640x480 pixel desktop. If I wanted to upgrade it to, say, Super VGA and get 800x600 pixels, or even do something as crazy as to get 256 colors, DOSBox didn't handle it well. Sure, Windows would still run, however its color palette would be off (brown dirt blocks in Chip's Challenge would be teal, for instance), and many programs would cause DOSBox to entirely crash.

So, DOSBox isn't a very satisfactory emulator for running Windows 3.1 on.

So, after I discovered VirtualBox, it became my favorite virtual machine software. I use it all the time to do all kinds of mad scientist experiments with my operating systems. So, I tried installing Windows 3.1 on this. First, though, I needed to install a DOS-like operating system, since Windows 3.1 itself is not a real operating system (more of an elaborate DOS game).


FreeDOS is an open source implementation of a DOS-like operating system. It may not be MS-DOS, but it should be enough to run Windows on. It's relatively easy to install FreeDOS in VirtualBox, and then the installation of Windows goes smoothly too -- until you've installed it and want to run it. Then you get an error like this:
Cannot start Windows in Standard Mode.

Make sure you are not running other protected-mode software,
or try starting Windows in 386 Enhanced mode by typing win /3.
Okay... what does win /3 do for us then?
Cannot start Windows in enhanced mode with the currently installed
protected-mode software.

Quit the protected-mode software and try again.
This is where I gave up. And then gave up again the next time I tried this. And so-on. Googling wouldn't help me much, and I'd just hear reports that "FreeDOS can't run Windows 3.1", accompanied by reports that "FreeDOS 1.0 can now run Windows 3.1 thanks to an update to its kernel" -- well, I had FreeDOS 1.0 and Windows wouldn't boot. I finally found the solution, though.

I had to edit C:\WINDOWS\SYSTEM.INI, and under [386Enh] I had to add the line InDOSPolling=True. Furthermore, I had to boot Windows by using the C:\WINDOWS\SYSTEM\DOSX.EXE program, instead of WIN.COM like normal.

Windows 3.1 in FreeDOS

The catch? You can't start another DOS shell on top of Windows again. So that "MS-DOS Prompt" shortcut, or the "IBM Professional Editor" couldn't be started from within Windows. Sort of defeats the purpose of having their icons there at all.

On the plus side, though, I was able to up the graphics support to Super VGA with no distortion of colors or general instability of the operating system. However, the SoundBlaster drivers wouldn't work, the networking wouldn't work, and I couldn't install a whole lot of actual software due to random odd error messages, which probably had to do with the unorthodox way that I needed to start Windows.

MS-DOS 6.22

Clearly, the best way to go is to use the real MS-DOS software. I obtained the floppy disk images for MS-DOS 6.22 a while back, but my Windows 3.11 installer was on a CD image, and MS-DOS doesn't have support for CD drives out-of-the-box. I was also more of a noob before when I tried this and wasn't very efficient at creating my own floppy images to be able to get a driver installer to MS-DOS.

But this time when I tried it, it was pretty easy. I just converted the Windows installers into disk images (not perfectly; the files for each disk wouldn't always fit in 1.44 MB and had to overflow to the following disk, so I ended up with 7 disk images for a 6 disk operating system). Windows didn't care, it would just give errors like "Read Error" and "Please insert disk #2", and I just had to do more disk juggling than usual until it got all the files it needed.

After getting a true MS-DOS installed with Windows 3.1, I was able to *gasp* start Windows in 386 Enhanced Mode, with no problems whatsoever. Then I installed a driver for the CD-ROM hardware, which made it easier to install SoundBlaster 16 drivers. Also I had to give it a couple of drivers (one for DOS and one for Windows) to stop them from consuming 100% of my CPU while running.

(I didn't upload another screenshot of Windows; it looks more or less the same as it did in FreeDOS!)

What works? Well...

  • 386 Enhanced Mode (WIN.COM)
    • The SoundBlaster drivers work; Windows can play audio.
    • New DOS shells can not be started from within Windows. So, that "MS-DOS Prompt" shortcut is useless again.
  • Standard Mode (WIN.COM /S)
    • SoundBlaster does NOT work.
    • New DOS shells CAN be started from within Windows.
A bit of a conundrum here. I can play graphical Windows 3.1 games with sound effects in 386 Enhanced mode, but can't play DOS games from within Windows. Or, I can play DOS games with sound effects but I have to run them from outside Windows.

Another interesting thing to note: before I installed the drivers for DOS and Windows that makes them stop consuming 100% CPU while idle, if I started a DOS shell on top of Windows, every key I pressed would be sent twice to the new shell. So this made it unusable. After installing those drivers though, the new shell works as it should.

This is definitely the best virtualization of Windows 3.1 I've gotten so far. It's at least 90% as "authentic" as running Windows on a real Tandy machine. I could nearly relive my computing childhood and install BOWEP and a handful of classic DOS games like Police Quest and Frederick Pohl's Gateway on it (not from within Windows, though!)

Or, I could just play it safe and use DOSBox for the games. :P

Tags: 18 comments | Permalink