Date: Thu, 14 Jan 1999 15:01:49 +0200 (IST) From: Eli Zaretskii X-Sender: eliz AT is To: Martin Str|mberg cc: djgpp AT delorie DOT com Subject: Re: bash and format don't mix In-Reply-To: <77iv3m$crh$1@news.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com On 13 Jan 1999, Martin Str|mberg wrote: > : > If I try to format a floppy which is write protected in a: ("format /u > : > a:") the system becomes so sluggish it's impossible to do > : > anything. Only way to get the system back to useable state is to hit > : > the red button. > : > : Did you try this from some other DJGPP program, like Less, or Emacs, > : or RHIDE? If so, was the effect different? > > less and doing "!format /u a:" gives the same effect. Seems like some Windows bug (so what else is new?), because when I press Ctrl-Alt-Del after it freezes, most of the time I get the famous Blue Screen of Death telling me about exception inside VMM. Also, if I try invoking FORMAT on a write-protected floppy in plain DOS, I see no problems at all: it works from DJGPP programs exactly like it does from COMMAND.COM. A workaround for Windows is to say "start /r format /u a:". This runs FORMAT in another DOS box, and doesn't trigger this problem. I'd bet that, like in the case of __dpmi_yield, some interrupt FORMAT issues (another function of Int 2Fh?) hangs VMM when it is invoked under a DPMI program. If someone could trace all the interrupts issued by FORMAT, we could try to find out which one causes it to freeze, and then look for possible solutions. > : Trying to write to a protected floppy causes Int 24h. DJGPP programs > : by default make Int 24h silently fail the call. My theory with Int 24h was proved false. When the system freezes, the floppy isn't accessed at all, so Int 24h and retries have nothing to do with this. Besides, at least Less reverts all the interrupts, including 24h, when it shells out.