Message-Id: <m0xJdp0-000S1oC@inti.gov.ar>
Comments: Authenticated sender is <salvador AT natacha DOT inti DOT gov DOT ar>
From: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT edu DOT ar>
Organization: INTI
To: hslama AT datacomm DOT ch (Heribert Slama), djgpp AT delorie DOT com
Date: Fri, 10 Oct 1997 15:18:57 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: RHIDE 1.4 (debugger) MANGLED File Allocation Table
Precedence: bulk

hslama AT datacomm DOT ch (Heribert Slama) wrote:

> Two days ago, I downloaded the latest release of RHIDE __1.4__
> (binaries only) after reading
> http://www.tu-chemnitz.de/~rho/rhide.html
> and Installed it.
> 
> Re-compiled and linked a program in a _Windows_DOS-box_, then selected
> 'Run / Go to Cursor'.
> 
> This raised hell; Windows (3.1) issued a cryptical message going like
> this: 'System Integrity lost ....... re-start your System'. I clicked
> OK. Screen went black, then msg  'COMMAND.COM not found'.
> 
> Ctrl-Alt-Del,......., Beeeeeeeeeeeeeeeeeeeeeeeeep continuously!!!
> 
> I shoved in my emergency diskette and during the next hours found out:
> 
> Harddisk 1 containing drives C: (home of DOS) and D: (home of Windows)
> had their FAT's (File Allocation Tables) corrupted. One of the FAT's
> was obviously overlaid by TEXT (part of the mouse drivers INI-file).
[rest of sad history] 
> re-installed, because ini-files and registry are lost.
> 
> A few technical details:
> I downloaded not from Robert's site, but from a local one:
> ftp://sunsite.cnlab-switch.ch/mirror/simtelnet/gnu/djgpp/v2apps/rhide14b.zip
> (file date not recorded in FTP log).
> I run Windows 3.1 on MS-DOS 6.2; RHIDE 1.3b worked well. I didn't
> upgrade any of the other DJGPP components (binaries only): GCC2721,
> GDB416. DJGPP stuff always runs under control of a special PIF file.

That's the price we must paid for running bad designed OSs.
From my point of view RHIDE isn't the problem here. I used RHIDE 1.4 under 
Windows 3.1, doesn't work on some .EXEs because of some problem that I don't 
know related to /dev/null but doesn't hang the computer.
 
> Has anybody observed a similar incident?
> (Can't see much of Oct 8+9 on my (infamous) news server.)
I got hard crashes, 90% of the time due to my code (and I used very deep beta 
and alpha RHIDE versions, even compiled at home) but never got garbage over the 
FAT (unsynchronised FATs, yes). 
 
> If I may give an advice: Try RHIDE 1.4 (debugging) first under plain
> DOS, with write disk caching disabled. If there really is a bug, the
> damage may be much smaller this way.
I use RHIDE 1.4 to debug an EXE of 3.5Mb of size (I guess Robert uses it for a 
5Mb or more EXE) without problems.
 
I think the problem was:
1) Or RHIDE dereferenced a bad pointer and the Windows DPMI simply detected it 
too later (the Windows protection is very weak).
2) Just was a driver of your Windows installation. 

SET
------------------------------------ 0 --------------------------------
Visit my home page: http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-sot AT usa DOT net - ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013