From: mert0407 AT sable DOT ox DOT ac DOT uk (George Foot) Newsgroups: comp.os.msdos.djgpp Subject: Re: Exclusive access to drive Date: 5 Jun 1997 12:27:11 GMT Organization: Oxford University, England Message-ID: <5n6bav$l1f@news.ox.ac.uk> References: NNTP-Posting-Host: sable.ox.ac.uk Lines: 39 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk Eli Zaretskii (eliz AT is DOT elta DOT co DOT il) wrote: : On Tue, 3 Jun 1997, Mike A. Harris wrote: : > Hmmm. Where do you think the problem lies then? CHKDSK? or : > DJGPP, or DPMI? : I'm clueless. When CHKDSK is run from a DJGPP program, it should be no : different from it running from the DOS box. DPMI has no effect on CHKDSK : unless Microsoft have explicitly made it check for its presence (and even : then I don't understand why should it care). When our programs run on : Windows 95, they don't even have an open file, since the page file is : managed by Windows, so there really is no problem related to the : filesystem integrity. That's why I said that it seems like they wanted it : to be too safe. Hmm, I've been following this for a while, and I just booted into Win95 and tried a few things I haven't seen discussed yet. Firstly I confirmed the problem existed on my system. Then, I wrote a short program which waited for a keypress, and tried running chkdsk in another DOS box - it worked fine. Then, I made a program to system("command") and ran chkdsk from that command prompt. The problem recurred. These show a few things: 1) It's not just Windows' reaction to running DPMI programs (chkdsk still works when a DPMI program is running) 2) It's not because chkdsk is being directly spawned by the DPMI program I also tried using PFE to execute CHKDSK (worked fine) and to start a DOS prompt and chkdsk there (again, it worked fine). Perhaps someone with Watcom could try a similar program there and see whether it suffers the same way? -- George Foot Merton College, Oxford