• Please review our updated Terms and Rules here

DOS programs can't create files in XP

Chuck(G)

Chuck(G)

25k Member
Joined
Jan 11, 2007
Messages
44,636
Location
Pacific Northwest, USA
Has anyone else seen this? All of the sudden (after who knows how many XP security upgrades), none of my MS-DOS programs will create files under Windows XP. Try, for instance, to create a ZIP archive using PKZIP--it won't work. 32-bit CLI programs work just fine, but DOS ones appear to be broken.

Has anyone else seen this? Has Microsoft decided in one of its security updates that DOS programs shouldn't be able to create files?
 
Perhaps they think that DOS is a hacker/terroist tool since it uses text. Seriously, you never know these days. :) However, looking around I see that you are not alone:

From reading posts on the Comodo forum a few minutes ago, I see that almost everybody who did this upgrade in the last few days, running DOS programs under XP, is having our problem.
Click to expand...

Edit: OK, so I stuck my foot in my mouth again. That quote was from July 2009. Still, it could give a hint.
 
Last edited:
Path too long? Probably not since it used to work.
Maybe 8.3 filename creation has been removed somehow? Not sure if that would cause this kind of problem.

Can you create files on any volume? On floppies?
What error is returned by the OS when trying to create files?
Are you running as admin or under a limited user account?
 
What is the error message? Might be KB2724197. Disables upper memory and EMS on XP. IIRC PKZIP uses UMBs and EMS so that may be why it's failing. DPMI should still work if you have DOSX enabled though.
 
The DOS create call (INT 21H, AH=3CH) works just fine; however, 'C' programs using the Microsoft 16-bit C (8.00c) stdio.h stream routines cannot create a file using fopen(). The same code works just fine on MS-DOS or Win9X or older versions of XP. Here's a sample program:

Code: 
# include <stdio.h>

void main( int argc, char *argv[])
{

  FILE *tf;

  if ( argc == 2)
  {
    tf = fopen( argv[1], "w");
    if ( tf)
    {
      fprintf( tf, "Hello world\n");
      fclose( tf);
    } else
      fprintf( stderr, "Did not create %s\n", argv[1]);
  }
}  // end of main

So, I've got to see what the MSC library is doing, I guess. This is very strange.

===================================================================
Addendum: A trace shows that Int 21H, AH=3DH (open file) is failing the wrong way when the file doesn't exist. Instead of returning carry set and AX=2 (file not found), it returns AX=5 (access denied), which then aborts the whole process.

Anyone care to verify this on their copy of XP?
 
Last edited:
Chuck(G) said:
Addendum: A trace shows that Int 21H, AH=3DH (open file) is failing the wrong way when the file doesn't exist. Instead of returning carry set and AX=2 (file not found), it returns AX=5 (access denied), which then aborts the whole process.

Anyone care to verify this on their copy of XP?
Click to expand...

This works as expected for me. Are you running as admin or as a limited user? Have you tried this on another user account? Have you tried it running in safe mode?
 
Chuck,

Stupid question but have you checked your permissions/security on that volume? Could be that something got reset and now write privilege is taken away.
 
I'll be a little more specific--function AX=3D01 fails with "access denied' instead of "file not found", 3D00 works as expected, returning "file not found". I've reset the security descriptors on the entire volume to "full control". I've done a file compare of all of the DOS-related NT DLLs (NTIO, NTDOS, NTVDM, etc.) with a working system and they're the same. AUTOEXEC.NT and CONFIG.NT are as they should be. Running as admin doesn't change a thing. I've replaced the anti-virus software, nothing.

I can take a separate XP machine and run the same program on the problem system's disk via a network share and everything works fine.

Short of reloading the operating system at this point, I'm at my wits' end.
 
Maybe permissions in the registry are the problem? Registry keys support the same ACL's as files in XP (XP Pro, anyway). I have no idea where to look though :)

Are you running XP Pro or Home? Permissions are very different between the two versions. If you're on Pro also take a look at "simple file sharing" setting. If you have simple file sharing enabled the Security tab goes away in explorer file properties and you can't manipulate ACL's. In XP home, I think you have to do some registry hack to use ACL's.
 
XP Pro.

Here's a clue. Let's call the system with the issue "System A". Let's call another system running the same rev level of XP "System B".

Running the test program on System A locally, it always fails, regardless of drive or permissions. that is, DOS function 3D01 returns "access denied" instead of "file not found". Now, if the file is present, the funciton successfully opens the file for write access, no problem there.

Running the same program on System B locally, it always works. That is, 3D01 when there's no file present returns status 2 = "file not found" .

If I open up a share to System B from System A and attempt to run my test program from System A on System B's share, it fails. If I open up a share to System A from System B and run the same program from System B to the drive on System A, it works.

That tells me that it's very definitely the DOS environment on System A that's flakey.

I'll keep digging, but suggestions are very welcome.
 
On a hunch, I ran MEM /P on both of the above systems.

Something very curious surfaces. On the system with a problem (A), it shows that the length of the IO memory partition is the same (370H), but the length of the MSDOS memomry area is different (1740H on system A, but 1670H on system B). The problem is very likely here.

Any hints before I start looking? NTDOS, NTVDM and NTIO are the same on both machines.
 
You could wander around security policies. Run gpedit.msc from a command prompt, maybe you'll see something interesting there. There are some settings for different compatibility levels of NTLM and filename munging that I don't think you can review/modify anywhere else (except a direct regedit hack).

But I'm actually clueless about your problem. I had a weird similar problem once with samba from linux and files that existed not being found, it turned out there was some strange difference in the algorithms used for filename munging to 8.3 giving different 8.3 filename results on the windows side vs. the samba side.

I just stumbled on this microsoft document about filenames that might be helpful: http://msdn.microsoft.com/en-us/library/windows/desktop/aa365247(v=vs.85).aspx
 
Yes, I've seen that document. But here's the odd thing--any other XP system on the network can get the right response for "Open, write only" on the subject system's drives but the subject system can't get the right response when it tries to open files on other systems' drives. Further, note that the Win32 API works just fine; this behavior is restricted to the MSDOS API 3Dh; most specifically, 3D01 returning the wrong error code when a file isn't present.

I've got a drive I imaged for this system from about 4 months ago; I'm going to put it into the system and see if the problem is still there. If not, then it's a matter of comparing things until something jumps out.
 
Chuck(G) said:
Yes, I've seen that document. But here's the odd thing--any other XP system on the network can get the right response for "Open, write only" on the subject system's drives but the subject system can't get the right response when it tries to open files on other systems' drives. Further, note that the Win32 API works just fine; this behavior is restricted to the MSDOS API 3Dh; most specifically, 3D01 returning the wrong error code when a file isn't present.

I've got a drive I imaged for this system from about 4 months ago; I'm going to put it into the system and see if the problem is still there. If not, then it's a matter of comparing things until something jumps out.
Click to expand...

Before going to the drive route do you have a "restore Point" you can go back to?
 
I gave up. I had a backup drive from a couple of months ago, so I synced the data files there and found that it works even after 33 Windows security updates. I attempted to do a Windows repair on the original drive, but repair crashed, so I installed a fresh copy of XP Pro that I'd already slipstreamed with SP3. I guess I'll never know what went nuts--I compared all the system files that I could with no obvious clunkers. Fortunately, this wasn't my primary system and I have multiple backups.

Right now, Xubuntu running WINE and DOSEMU is doing just fine as my regular system but I just got a quad-core AM3 system, so I'm installing OpenSUSE there and going to give VirtualBox with XP a try.
 
You must log in or register to reply here.
Back
Top