Using packet level drivers for MS-DOS network connectivity

Posted on By Mark Wilson
This content is 16 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

One of the reasons to use Windows PE for operating system deployment is that it’s built on a modern version of Windows so, at least in theory, driver support is less of an issue than it would be using MS-DOS boot disks.

Even so, there are still times when a good old MS-DOS boot disk comes in handy and networking is a particular pain point – NDIS drivers are a pain to configure so packet-level drivers are often useful for operating system deployment tasks (but not optimised for anything more substantial). Available for many of the more common Ethernet cards, they are generally 16-bit utilities for MS-DOS and so will not work in 32-bit or 64-bit operating systems.

As this is not exactly cutting edge technology, many of the useful sites are starting to drop off the ‘net (but a surprising number remain) – here’s a few links I found that might come in handy:

MS-DOS revisited: building a handy utility disk

Posted on By Mark Wilson
This content is 16 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

A couple of years back I was writing about trying to squeeze Windows PE onto a 128MB/256MB USB thumb drive and how times change – these days I have piles of unused 128MB, 256MB and 512MB USB sticks that have become redundant because I have larger portable data storage devices available.

Then, as I was preparing to image a PC, I found myself using 1.44MB floppy disks and it all got very frustrating. Just enough to boot the system used half the disk and that was without any utilities – the version of Symantec Ghost that I used recently won’t even fit on a floppy disk. So, I decided to put one of my old USB sticks to use as an “ultimate boot disk” – much easier to update than the CD-based versions we were putting together a few years back.

Despite having a pile of smaller USB thumb drives doing nothing, I decided to use one of the 1GB sticks that EMC were giving away at the Windows Server 2008 launch (plenty of space for expansion).

The first step is to make the drive bootable – I used the HP USB disk storage format tool v2.1.8 (SP27608) to format the drive and put a basic Windows ME boot subsystem on it (using a disk created with the Windows XP disk format tool as a reference image) but there are other options.

Why Windows ME? Well, because it’s easy – Windows XP creates ME boot disks – and because it was a prerequisite for the the next stage – network booting using Brad Driver’s universal TCP/IP network boot disk. There are many sites on the ‘net that offer network boot disks (including bootdisk.com) but the one I chose manages to include a huge range of drivers and it fits on 1.44MB floppy.

Basically, the disk boots a very basic operating system before expanding itself to a RAM disk and reloading the command shell. USB device support is still experimental (at v6.2) but after much experimentation I worked out that I could use the makedisk script provided with the download but in order to avoid a loop of pressing CTRL+ALT+DEL to restart the computer I needed to edit the config.sys file so that the line shell=n:\command.com /e:4096 /p used c: instead of n: for the command interpreter (my drive was formatted as USB-HDD, this may not be necessary for other USB boot options) and I also removed the hidden attribute from command.com to avoid a file not found error (that didn’t seem to affect the operation of the disk in any other way). After this, the NIC is auto-detected and an appropriate network driver loaded, obtaining TCP/IP information from DHCP and logging on to the network.

With network booting working well (at least on the IBM ThinkPad T40 that I tested against – older machines may not have the necessary BIOS support), I added an autorun.inf file for when I use the drive within Windows. This file includes the following items and really just sets the drive icon and description:
Custom USB drive icon
[autorun]
label=USB Network Boot Disk (1GB)
icon=shell32.dll,12

Finally, the whole purpose of this disk is to run some utilities. At this point you can name your own poison but I created a C:\Tools folder (C:\Utilities is too long for 8.3 file naming, although C:\Utils could have worked) and started to pile in my favourite 16-bit .COM and .EXE files – I’m sure the list will grow substantially over time. There may be some issues with memory management but there is plenty of space to add a variety of tools and theoretically there could be multiple boot options too.

It’s been a long time since I played around in MS-DOS and there is very little call for it these days (I should really be doing this with Windows PE) but every so often it’s good to return to your roots.

Troubleshooting an MS-DOS application which hangs the NTVDM subsystem in Windows XP and Windows Server 2003

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

I’ve been working on an intriguing (and frustrating) issue for a few weeks now and a couple of days back we finally resolved the issue.

My client has an MS-DOS (FoxPro 2.6a database) application running within an NTVDM on Windows XP. Every now and then, the application will hang – seemingly randomly. Windows XP did have service pack 2 applied, but the issue also occurs on service pack 1 PCs (I didn’t try the RTM version). Only the application hangs – it is possible to terminate the NTVDM process and carry on working as normally.

Normal actions for troubleshooting MS-DOS applications in Windows XP were not helping to resolve the issue, but the software vendor managed to narrow the issue down to FoxPro waiting for input. Occasionally, the input does not timeout and return control to the calling program – it seems that this is the root cause of the NTVDM hang. Identifying this allowed them to construct a test program which polled for input, timing out every few seconds and would reliably hang an NTVDM at a seemingly random time, but always within an hour.

Using their test program on a variety of PCs, the software vendor found that the problem was related to the Intel hyper-threading technology (my client has standardised on a version of the IBM ThinkCentre M50 which includes a single 3GHz Intel Pentium 4 processor with HT technology). Whilst disabling hyper-threading is unlikely to result in any significant performance degradation (hyper-threading only provides an average 10-20% performance gain as most applications do not fit completely with the hyper-threading model), it was still considered by IBM, Microsoft, my client and myself as a tactical workaround, rather than a strategic fix.

After seeking advice from Microsoft, I ran the test program on a Compaq ProLiant DL380 G2 server with two Pentium III 1.26GHz processors and found that the issue is not limited to Windows XP and hyper-threading, but to both Windows XP and Windows Server 2003 when running with an ACPI Multiprocessor PC HAL. Turning off hyper-threading on the PCs was no longer good enough as we can expect to see multiple processor cores constructed on a single die in the near future, leading to a rise in the use of multi-threaded applications (the logical processor provided by the hyper-threading technology in the Intel Pentium 4 processor is simply a precursor to this).

So why does an MS-DOS application running within an NTVDM on a 32-bit version of Windows use multiple processors? The answer it seems is that although the MS-DOS application is not multi-threaded, modern versions of Windows are, and can allocate parts of the NTVDM process to any available processor. With that in mind we re-ran the test program with processor affinity set to use only CPU0 in Task Manager. The results were the same as disabling hyper-threading – no NTVDM hang! Obviously, setting processor affinity manually is not sustainable outside the test environment, and short of running the application on Windows Server 2003 Enterprise Edition (with the Windows System Resource Monitor to control processor affinity) we needed to find an alternative solution.

That solution came in the form of the imagecfg.exe tool provided with the Microsoft Windows 2000 Resource Kit (supplement one). This can be used to edit an executable file and permanently set the processor affinity for a given application:

Using the imagecfg -a 0x1 c:\windows\system32\ntvdm.exe command did the trick, although Windows File Protection/System File Checker quickly restored the original ntvdm.exe file so I needed to perform this on a copy of ntvdm.exe in a temporary folder, and then overwrite both c:\windows\system32\ntvdm.exe and c:\windows\system32\dllcache\ntvdm.exe.

Once updated, the NTVDM process runs on CPU0. Of course, this limits all programs under the control of the NTVDM subsystem but it is far more preferable to disabling logical or physical processors in the BIOS; however, as this is a change to an operating system file, it must be considered alongside the implementation of any service packs and/or hotfixes from now on. Reversing the change is simply a case of restoring the original ntvdm.exe file.