X-Authentication-Warning: delorie.com: mailnull set sender to opendos-bounces using -f Message-ID: <000801c19b45$8a1eaf40$c03dfea9@atlantis> From: "Matthias Paul" To: References: <01FD6EC775C6D4119CDF0090273F74A455A903 AT emwatent02 DOT meters DOT com DOT au> <04a901c19a6d$d537c800$c03dfea9 AT atlantis> <001f01c19a7c$e258d7e0$17fea8c0 AT RESNETBJ1084> Subject: Re: Bugs in DR-DOS 7.03 Date: Sat, 12 Jan 2002 09:43:00 +0100 Organization: University of Technology, RWTH Aachen, Germany MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id g0C8j3T26214 Reply-To: opendos AT delorie DOT com On 2002-01-11, Ben A L Jemmett wrote: > > Right now, I have no idea, what this "IHC" stands for and > > which component actually creates it. (It might also depend > > on the machines ROM-BIOS. Whoīs the manufacturer of your > > BIOS?) > > I'm almost certain I've seen it mentioned in connection with BIOS anti-virus > protection functions, but why that may be the case I'm not sure. Very intersting, this might not give a complete explanation, but at least it is a very good hint... I too speculated that it might have to do with some anti-virus protection scheme, and I think, I mentioned this a long time ago in this forum, but I never found any real prove for it, so I didnīt mentioned it in the "Bugs in DR-DOS 7.03" post. However, if you have seen someone else (not me) making this connection as well, I would be *very* interested in it, in case you can remember where it was, as this might help to find out why this happens. Another vague assumption was that it might be another artefact of Windows long filename support somehow, but this appears to be unlikely. Personally I have seen this on several modern ASUS machines (max. two years old) which had Award BIOSes with ChipAwayVirus protection. (Maybe: "IHC" | "CHI" -> *Chi*pAwayVirus??? But thereīs also a virus named "CHI", IIRC.) This /might/ mean something, but not necessarily, as I have no recent machine in reach without an anti-virus protection, only one machine with an AMI BIOS (on which I didnīt check the behaviour), and none machine with Phoenix BIOS. Also, we almost solely use ASUS boards around here. I have *not* seen this IHC thing occuring on my own main machine (an ASUS T2P4 board from 1997) which also has an Award BIOS but no anti-virus protection built into the BIOS (except for a simple Master Boot Protection). The problem occurs only under Windows and not under plain DOS, but this does not mean that it cannot be something in or with the BIOS. So far I have seen it on Windows 98 and 98 SE machines, I donīt have 95 or ME installations in reach. Which version(s) do you use? I also found pre-install disk images intended for a DeLL Pentium II machine from 1997, which have the same IHC signature in the boot sector in the file images... This would indicate that it does not only occur with DR-DOS formatted floppies. These have just been the only ones where I have seen this so far. This also does not necessarily mean anything, because I usually format new floppies (under DR-DOS) before using them. My interpretation so far is: For unknown reasons "something" (Windows or the BIOS) causes the IHC signature to be written to the OEM string. Thereīs probably some trigger condition like an unrecognized format or bootstrap code. Whatever it is, it happens so fast that I assume, it only analyzes the first sector and then writes the IHC signature and something like a fingerprint or checksum (of the whole sector?), so that, when you insert a floppy later, it either recognizes the boot sector by itself or would at least find the IHC signature and corresponding fingerprint in there again, and thereby can check the sector for modifications. Assuming a mass-installation of this mechanism on multi-millions of machines, this sounds like a valid and working anti-virus protection scheme for boot sectors to me, although I still find it very questionable that something writes something on a floppy (overwrites seemingly "useless" data in the OEM string) without being asked to do so. Well, not so "useless", after all... As we know meanwhile from other discussions - and I am still thankful to Charles Dye for originally spotting a OEM label problem with DR-DOS 7.02/7.03 FDISK (which caused other effects, though, but caused me to investigate the issue) -, the OEM label is not completely useless for MS-DOS/PC DOS. Analysis has shown, that - beyond the obvious changes with extended BPBs - MS-DOS/PC DOS switch between various "interpretation schemes" of the BPB contents depending on the version number in the OEM label, presumably to work around bugs in old issues of MS-DOS/PC DOS or OS/2 FORMAT and/or SYS, which calculated wrong values for some of the entries - at least, this would be the only "reasonable" interpretation I can possibly think of for doing this... The problem now is that the BPB of a DR-DOS formatted floppy is not exactly the same as the BPB of a floppy formatted under MS-DOS/PC DOS. Changing this would not only require (minimal) changes to FORMAT, SYS, and FDISK, but also to the DR-DOS kernel, and this might cause older issues of these tools under a future modified DR-DOS kernel to write strange BPBs... As far as I can tell, when MS-DOS/PC DOS finds the "IBM 3.3" OEM signature, it will correctly interpret the BPB, but not when it finds a different version number or no valid version number at all (as it happens, when the IHC signature was written to the disk), probably because it then just /assumes/ the BPB entries to exactly match those of MS-DOS/PC DOS, instead of reading the actual value... So, regardless of if the IHC signature is caused by Windows or by some kind of anti-virus-protection in the BIOS, or both, it unfortunately manifests as a compatibility problem with DR-DOS formatted floppies... I am really interested in the observations otherīs have made, so we can narrow down the problem as much as possible. Greetings, Matthias -- ; http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org