Mail Archives: djgpp/1997/10/10/14:12:47
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
- Raw text -