delorie.com/archives/browse.cgi   search  
Mail Archives: opendos/2002/01/12/03:47:21

X-Authentication-Warning: delorie.com: mailnull set sender to opendos-bounces using -f
Message-ID: <000801c19b45$8a1eaf40$c03dfea9@atlantis>
From: "Matthias Paul" <Matthias DOT Paul AT post DOT rwth-aachen DOT de>
To: <opendos AT delorie DOT com>
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
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
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

-- 

<mailto:Matthias DOT Paul AT post DOT rwth-aachen DOT de>; <mailto:mpaul AT drdos DOT org>
http://www.uni-bonn.de/~uzs180/mpdokeng.html; http://mpaul.drdos.org


- Raw text -


  webmaster     delorie software   privacy  
  Copyright Đ 2019   by DJ Delorie     Updated Jul 2019