If you think the heuristics in "file" are sometimes a bit scary, take a look at how PC hardware used to work back before the PCI bus become dominant. The heuristics there ended up bricking two expensive motherboards for me.
The older ISA bus, which was quite common until at least the end of the '90s, did not have any way standard way for software to identify cards, nor any way for software to specifically talk to the card in a specific slot.
PCI cards have a required Vendor ID assigned by the PCI-SIG, and a Device ID assigned by the vendor, and the PCI bus has a way to address by slot. A driver that supports a particular kind of card can scan the bus by slot, checking Vendor ID and Device ID to find cards it works with.
With ISA cards, all that driver would know is that the card it is looking for has, say, 4 registers that appear at consecutive I/O addresses, and that there are jumpers on the card that can set the base I/O address to 0x200, 0x240, 0x280, or 0x2CO.
The safe way to use a card was to install it in the PC, noting the jumper settings, and then install the driver and tell the driver what jumper settings you used. To know what jumper settings to use, you had to know what other cards were in the system and what I/O addresses they used so you could pick settings that didn't conflict with an existing card.
No one wanted to make someone installing a new operating system on a working system open up the thing, find all the settings on all the cards, and report that to the OS. They wanted to just automatically work with cards that had drivers built-in to the OS.
So what the OS installer would do is go through each built-in card it supported, and use heuristics to figure out if it is installed. For example, take that card I mentioned earlier that can be at 0x200, 0x240, 0x280, or 0x2C0. The OS might now that after reset that card should have 0x1F in register 0, 0x00 in register 1, and random values in registers 2 and 3. So if it doesn't see 0x1F at 0x200, 0x240, 0x280, or 0x2C0, it knows that the card is not present.
But suppose there is 0x1F at 0x200 and 0x00 at 0x201. Then the card might be there. So now the driver would have to write to some of the registers, and see if the card responds the right way. Mostly it would do this be setting various modes, and then reading those mode settings, and see if they are right. If the card is not the right one, hopefully some of those commands don't make any sense to it, and so its responses are different.
Think about this for a moment. Suppose the OS is looking for a network controller, and the card at that address is actually a disk controller that happens to have the same read values in its registers after a reset, so the probe for the network card has to go on to the writing part of the test.
It's then writing network controller commands to a disk controller. If the command for "set status" on the network controller happens to be the same as the command for "write to disk" on the disk controller--you may have just trashed your disk. Oops.
And so the OS vendors had to very carefully construct their device probes. If writing commands for card X to different kind of card Y could trash things on Y, they needed to make sure that they had probed for Y first, and so if any Y were present skip them when probing for X.
Note that this doesn't necessarily work if you have any cards that the OS does not know about. If you card is going to need a third party driver installed after the OS is installed, it was best to take that card out during OS installation if having random junk written to it could cause harm.
One day at work, we bought two very expensive top of the line motherboards. The box said that they required Windows 98 or later. I tried to install Windows 95 on one of them. The install went fine until it got to one of the places where it reboots, and the reboot failed utterly. It did not even show the BIOS messages. The system appeared to be thoroughly bricked.
Figuring one of the motherboards was defective, I tried the other one. Same damn thing. Bricked during Windows 95 install!
We eventually found out what happened. The Windows 95 searching for devices on the ISA bus ended up writing to some registers that on this machine controller the BIOS flashing. It had erased the BIOS. Windows 98 and later knew about the flash controller in the chipset used in this motherboard, and avoiding trashing your BIOS. (Not sure why the motherboards either didn't have a jumper to disable BIOS flashing, or shipped with that jumper set to enabled).