[Solved] TC 16bit and riva128 or TNT driver in 3.11 = errors

[dallasl]

...so?
after ruling out ram what is left to test?

[dallasl]

I made some more test with older versions:

16-bit 5.00 -> 100 times crc32 checking of tc directory files: no errors
16-bit 5.11 -> 100 times crc32 checking of tc directory files: no errors
16-bit 6.03a -> 100 times md5 checking of tc directory files: no errors

then I installed 6.53 on top to make more tests and in the first 2secs I get the corrupted error, didn't even made it to create a new .md5 file.

installed 6.03 again on top and at 31st md5 check I get an error.

[white]

2dallasl

Please try this:

1) Copy TCMD16.EXE to A.EXE and B.EXE
2) Compare A.EXE and B.EXE by content (using Total Commander)
3) Repeat step 2) until a difference is found

Do A.EXE and B.EXE sometimes differ?

[dallasl]

already did something similar that when I was checking 5.00 and 5.11 , had both wiccmd and totalcmd executables in my tc directory (due to installing versions in the same dir), on the 5.xx crc checking never fails (or get the error corrupted message) but on the 6.xx versions the md5 check can fail in any random file, most times is the exe, some times it's even my key file...

Bottom line for me is that md5 checking can fail in any file for me in 6.xx version. I am about to do a more interesting test so I don't waste anyone's time in vain: I have prepared a FAT16 2GB HDD with DOS6.22 and 3.11 - no patches - no fat32 , I will see what happens there and report back.

[dallasl]

Finished the fat16/dos6.22 test, you can't get more 16bit/stock than this IMHO. Disk was a 2GB one, BIOS recognizes it fully, no drive overlays or drivers needed.

HDD summary: Image: http://i125.photobucket.com/albums/p55/restqp/IMG00065-20120326-1132.jpg

MSD summary: Image: http://i125.photobucket.com/albums/p55/restqp/IMG00066-20120326-1133.jpg

unfortunately 6.58 still reports md5 errors.

Image: http://i125.photobucket.com/albums/p55/restqp/IMG00064-20120326-1128.jpg

ram is tested with memtest86+ btw...

[gulikoza]

Bad IDE cable? Before UDMA, there was not CRC check in the ATA protocol...

[dallasl]

Bad IDE cable? Before UDMA, there was not CRC check in the ATA protocol...

nah, I doubt it... this happens in 2 different computers and tc is the only apps that exhibits this... wouldn't other stuff crash or start getting corrupted archives? Especially on the pentium machine I do much work with archives, haven't had a single crc error... (not to mention the 5x86 machine has new stuff inside since it's a recent build, even the IDE cables are new)
I believe that maybe there is some small bug in 16bit TC , I mean how many still use it? and that's why it keeps living

[white]

2dallasl

Please try this:

1) Copy TCMD16.EXE to A.EXE and B.EXE
2) Compare A.EXE and B.EXE by content (using Total Commander)
3) Repeat step 2) until a difference is found

Do A.EXE and B.EXE sometimes differ?

Could you please try step 2) mentioned above the following way:
1) Select the file A.EXE
2) Select menu option Files/Compare by content
3) In the Compare contents dialog set B.EXE as right file
4) Click the Compare button
5) If the files are the same click OK and repeat step 4)

I would like to know if the data from the files is sometimes read wrong and if so, exactly which bytes are read wrong.

[dallasl]

yes, I will try it ASAP and report

[dallasl]

tough luck, the compare by content function is different in 16bit 6.58 , there is no view of the differences, only a small dialog box saying the files are identical or different...

[gulikoza]

Use fc /b?

[white]

tough luck, the compare by content function is different in 16bit 6.58 , there is no view of the differences, only a small dialog box saying the files are identical or different...

You are right. Well, at least you can test whether the file is read OK. You could use Synchronize Dirs for that. Copy TCMD16.EXE to a new folder named "A" and to a new folder named "B". Open folder A in left panel and folder B in right panel and start Synchronize Dirs. Check the option "by content" and repeatedly click the Compare button to see if the files are the same.

Use fc /b?

I was going to suggest that too

2dallasl
You may also want to try "fc /b A.EXE B.EXE" in a DOS window (make sure Windows is loaded). If a difference is found sometimes, then check if it also happens when booting to MS-DOS (and not loading Windows).

[dallasl]

ok FC it is...

pure DOS: 100 fc's = OK
DOS box in 3.11: 100 fc's = OK
TC6.58 compare/content: 100 times = OK
TC6.58 make md5 -> compare md5: fail on first time, the md5 made had read the file wrong so every check is fail.

...man this get's boring counting to 100

[white]

...man this get's boring counting to 100

Code: Select all

COMMAND /C FOR %i IN (0 1 2 3 4 5 6 7 8 9) DO @FOR %j IN (0 1 2 3 4 5 6 7 8 9) DO @COPY TCMD16.EXE %i%j.EXE

Then mark all 100 files and create checksums. Then verify

Do MD5 and CRC both fail?


EDIT:
As mentioned by dallasl below. The code above does not work. It does work when using CMD of later Windows versions instead of COMMAND. For MS-DOS 7 using the batch files A.BAT and B.BAT listed below should work. Create the files and run A.BAT.

A.BAT

Code: Select all

@echo off
for %%i in (0 1 2 3 4 5 6 7 8 9) do call b.bat %%i

B.BAT

Code: Select all

@echo off
for %%i in (0 1 2 3 4 5 6 7 8 9) do copy TCMD16.EXE %1%%i.EXE

[dallasl]

white , this command does not work outside ntvdm so it's pretty much useless for my DOS7 setup...
also there is no need to do this, crc will work fine in 5x, md5 will crap out in 6x, I already tested it with various files, not just the tc executables. There is no pattern, any random file can fail md5.


@thread
Quite frankly I am not doing another checksum test and that's the end of it.
Ghisler obviously has no intention to look on the matter further than "hey yeah, your hardware has something wrong" when I have proven clearly that there is nothing wrong with my RAM, cpu, FAT16, FAT32, patches etc. (haven't heard from him since the memtest86+ report)

I have run memtest 86+ on both my machines, I have made many TC crc checks, I have made 600+ MB of zip files moumerous times and tested them and I have made the last 300 checks yesterday.
I even made a vanilla 2GB HDD with fat16 + dos6.22 + win3.11 with everything at stock settings and TC still fails (and it's the only program that gives me troubles btw)

CRC works fine in 5x versions and md5 does not work for me in 6x versions. I can't comment on CRC for 6x because TC fails it's own check so you never get to test much.

IMHO TC16 has something wrong with it's md5 routine.
Trying to prove/test that my computers have some sort of failure does not really help at this point since I believe we are beyond that. And if memtest/archiving/suggestions from here/my own personal usage all this time does not prove that the hardware is OK then I don't know what will.

I am sorry for the outburst but unless a dev of TC wants me to do some new tests that could lead to a clue then I am not doing anymore "integrity testing" because it is proven that only TC6x fails such tests. (and no this is not directed to white that tried to help, thanks man!) , I'll just use 5x while in 3.11 and let others that have more working setups than mine enjoy the 6x version.

edit:
also here is F-PROT for DOS with 2009 virus definitions saying that I have no viruses (as expected)
Image: http://i40.tinypic.com/2wpp3sm.jpg
Image: http://i40.tinypic.com/2ed62ci.jpg