Current Working Directory in Windows Console Programs

Pursuant to an argument at this Super User question, I have done some testing and written a test program to try to clarify the situation with current-working-directories.

As Raymond Chen explains, per-drive CWDs have been around since DOS, which makes sense because DOS’s only interface was the command-line. He goes on to explain that in Windows, the command prompt keeps track of per-drive CWDs by using environment variables.

The point is that while the actual manner in which they are tracked may differ, there are per-drive CWDs in all Microsoft operating systems from DOS, up to Windows 7. This can be easily demonstrated with the following program (adjusting drive letters and paths as appropriate).


void PrintCWDs() {
	char cwd[260]="";
	for (int i=3; i<27; i++) {
		if (!_chdrive(i)) {
			printf("  %c: = %s\n", 64+i, cwd);
	printf("Press a key...\n");
	char key=getch();

void ChangeCWDs() {
	for (int i=3; i<27; i++) {
		if (!_chdrive(i)) {
			switch (i) {
				case 'C'-'A'+1	:chdir("\\Windows\\System32\\Drivers");		break;
				case 'H'-'A'+1	:chdir("\\Temp\\Chromium\\Cache");			break;
				case 'K'-'A'+1	:chdir("\\Data\\eMail\\OE");				break;
				case 'P'-'A'+1	:chdir("\\Videos\\Commercials");			break;
				case 'T'-'A'+1	:chdir("\\Program Files\\Common Files");	break;

int main(int argc, char**argv) {
	printf("\nOriginal CWDs:\n");
	printf("\nChanging CWDs...\n");
	printf("\nNew CWDs:\n");
	printf("\nAnd again:\n");

	return 0;

This program shows that the CWD is maintained for each drive in DOS, Windows XP, and Windows 7 as seen below.


CWDTest run in DOS without NTFS support.

CWDTest run in DOS with NTFS support.


CWDTest run in XP from the command-prompt.

CWDTest run in XP from the desktop or an Explorer folder.

CWDTest run in XP from the Run dialog.


CWDTest run in 7 from the command-prompt.

CWDTest run in 7 from the desktop or an Explorer folder.

CWDTest run in XP from the Run dialog.

DOS Games in Windows XP

Support for old software is not a high priority anymore and is fading fast. This is bad news for gamers who want to play those old DOS (and even Windows) games that do not run on modern hardware and operating systems.

One solution is to find old hardware to run those old games on. This is the ideal solution from a compatibility standpoint, but has its own drawbacks like extra physical hardware, electricity, space, cost, and so on. Another solution is to use hardware emulation software that tricks the old software into thinking that it is running on the hardware that the emulator tells it. This is less compatible, but has advantages like price and convenience.

Emulators like DOSBox, VMWare, Virtual PC, Parallels, QEMU, and the like are a great way to go in a lot of cases. But, for really intensive games like FPSes, you will probably want to run them natively to get better performance.

The three biggest obstacles in running old software on modern computers natively are CPU, sound, and audio.

Old software was not designed to run on modern CPUs which are often too fast, and also have multi-threaded/core functions. Worse, modern systems are moving to a model that old software developers could not even conceive of in those days. There are programs that can slow a system down (usually by running the CPU in a controlled, but infinite loop) so that the old program gets fewer CPU cycles, but a much better solution is to use an emulator.

Audio in a program running natively has been handled for the most part by VDMSound. It has not been updated in a long time, but most class-gamers will attest that it works for most purposes. Emulators work well too, but they do not usually offer as wide a variety of sound cards.

Video has had its share of hacks as well. Ken Silverman—they guy who created the Build engine which powered games like Duke Nukem 3D—released a couple of tools (NOCLI and NOLFB) that will modify old apps so that they can run in XP without locking up. However, even with those, most graphics programs (eg games) will usually freeze in XP on startup and display only the first frame. The way to fix this is to install the Full Screen Video Driver For Console which comes with Windows XP but is not installed by default:

  1. Open the Control Panel
  2. Run the Add Hardware applet, click Next, wait
  3. Select Yes…already connected
  4. Scroll down and select Add a new hardware device
  5. Select …manually…(Advanced)
  6. Select Show All Deviced
  7. Select Microsoft Corporation for Manufacturer and Full screen video driver for console for Model

That’s it. Now graphical DOS software should run properly in Windows. You can still use NOLFB and NOCLI if needed. Windows 2000 could not only run graphical DOS software full-screen, but it could even run them in a window, which XP cannot do. That was a great feature that is missed. Windows Vista has changed quite a bit that a lot of even XP softare will not run in it. It’s adoption has been pretty slow, so we’ll just have to see what gamers come up with for it, although it may very well be the case that XP is the last OS for classic-gamers: future classic-gamers will probably have to run emulators that hopefully will be much better.