Kitty says to me today she's having printing problems. About ½ the time, the machine just hangs when she tries to print. I reply with the standard help desk response of "reinstall the print drivers". Oh boy.

Shortly thereafter, not only did the new printer software fail to find the printer, the damned thing would BSOD (Win98) if it was booted WITHOUT the USB printer attached!

Then USB just stopped working for a while. That was cute.

Long story short - after many (many) reboots, including logged boots and many BSODs (and just plain lockups on boot) I finally noticed that even with it all supposedly uninstalled, it still BSODd without the printer attached. I'm talking manual Registry wipes uninstall. It wouldn't lock if I deleted the USB hub from Windows. Until I rebooted again and then BSOD. I found it was still loading a VxD file.

Yes folks, think WAY back. 16 bit. Windows 3.1 - "System.ini"!!! But it wasn't there either. In there is a line that says to load "*.VxD".

So I erased (OK, moved) all the HP*.VxD files in C:\Windows\System\VMM32\ (WTF?) and wow - everything was A-OK when there was no printer attached! I figured that would make a good baseline - if it don't boot without the printer, it will never boot with.

I connected the printer, pointed it to the directory where I had downloaded the drivers, and it installed without a hitch. Even installed the accessory utils automagically.

So I went back to that VMM32 directory. The HP files were back. Copied them all to my fileserver, and ran diff on them. No differences. Except… there was a file "hpziop98.vxd" what wasn't reinstalled. Lo and behold, the old directory had both "hpziop98.vxd" and "hpziop00.vxd". Kinda suspicious, huh?

Here's a Linux command for you to file away:

strings *.vxd | grep -A 20 ProductVersion'''

hpziop00.vxd:
ProductVersion
1, 18, 6, 0
ProductName
Hewlett-Packard 1284 Driver.
OriginalFilename
hpziop00.vxd
LegalCopyright
Copyright
1998. All rights reserved.
InternalName
hpziop00
FileVersion
1, 18, 6, 0
FileDescription
1284 Driver.
CompanyName
Hewlett-Packard Company
Comments
Built on 12/30/99 2:00pm

hpziop98.vxd:
ProductVersion
1, 16, 7, 0
ProductName
Hewlett-Packard 1284 Driver.
OriginalFilename
hpziop00.vxd
LegalCopyright
Copyright
1998. All rights reserved.
InternalName
hpziop00
FileVersion
1, 16, 7, 0
FileDescription
1284 Driver.
CompanyName
Hewlett-Packard Company
Comments
Built on 10/12/99 2:30pm

Yes folks, some time between Oct and Dec 1999, HP renamed their 1284 driver file, and didn't tell the uninstaller (which I ran at least 3 times!) to remove the older version if it saw it! AND, IEEE 1284 is PARALLEL PORT!!! Lastly, you'll note the "OriginalFilename" entry for the __98 file?!?

Fixed. Total time: almost 2.5 HOURS.

Stolen from ​http://www.tat.physik.uni-tuebingen.de/~rguenth/linux/binfmt_misc.html

This is binfmt_misc - the generic 'wrapper'-binary handler!

WARNING: if you use recent kernel versions from Alan Cox (2.4.2acXX and later) or versions 2.4.13 and up you need to mount binfmt_misc using

mount -t binfmt_misc none /proc/sys/fs/binfmt_misc

Please dont ask me for reasons - ask Alexander Viro who did this during the stable series.

Abstract

Binfmt_misc provides the ability to register additional binary formats to the Kernel without compiling an additional module/kernel. Therefore binfmt_misc needs to know magic numbers at the beginning or the filename extension of the binary.

You can get a patch to include binfmt_misc into your Kernel here. There is a patch to 2.0.30, a patch to 2.0.33/34 and a patch to 2.0.35. Binfmt_misc is integrated to Kernel 2.1.43, so there is no need to get a patch for them, just upgrade to the latest (stable ) 2.1.xx Kernel.

Read Documentation/binfmt_misc.txt and Documentation/java.txt for more information on how to use binfmt_misc (or continue reading this page). The 'magic' behind binfmt_misc

binfmt_misc works as follows:

• it maintains a linked list of structs, that contain a description of a binary format, including a magic with size (or the filename extension), offset and mask, and the interpreter name.
• on request it invokes the given interpreter with the original program as argument, as binfmt_java and binfmt_em86 and binfmt_mz do.
• binfmt_misc does not define any default binary-formats, you have to register an additional binary-format via the /proc interface (see below).

The /proc interface of binfmt_misc

You can find the following binfmt_misc related files/directories below /proc/sys/fs/binfmt_misc:

• register

To register a new binary format do an echo :name:type:offset:magic:mask:interpreter: > register with appropriate name (the name for the /proc-dir entry), offset (defaults to 0, if omitted), magic and mask (which can be omitted, defaults to all 0xff) and last but not least the interpreter that is to be invoked (for example and testing '/bin/echo'). Type can be 'M' for usual magic matching or 'E' for filename extension matching (give extension in place of magic).

• status

If you do a cat status you will get the current status (enabled/disabled) of binfmt_misc. Change the status by echoing 0 (disables) or 1 (enables) or -1 (caution: clears all previously registered binary formats) to status. I.e. for example echo 0 > status to disable binfmt_misc (temporarily).

• name (where name is the name you gave to register)

This file does exact the same thing as status except its scope is limited to the actual binary format. By cating this file you also recieve information about the interpreter/magic, etc. of the binfmt.

Example usage of binfmt_misc (emulate binfmt_java):

cd /proc/sys/fs/binfmt_misc
echo ':Java:M::\xca\xfe\xba\xbe::/usr/local/java/bin/javawrapper:' > register
echo ':HTML:E::html::/usr/local/java/bin/appletviewer:' > register
echo ':Applet:M::<!--applet::/usr/local/java/bin/appletviewer:' > register
echo ':DEXE:M::\x0eDEX::/usr/bin/dosexec:' > register

These three lines add support for Java executables and Java applets (like binfmt_java, additionally recognising the .html extension with no need to put '<--applet>' to every applet file). You have to install the JDK amd the shell-script /usr/local/java/bin/javawrapper, too. It works around the brokeness of the Java filename handling. To add a Java binary, just make a link to the .class-file somewhere in the path.

For full featured wrapping of deeply nested class files you will have to use the wrapper script created by Colin Watson (cjw44@…) /usr/local/java/bin/javawrapper and the additionally needed little c-proggy javaclassname.c (just compile it and stick it to /usr/local/java/bin/). These C/Script combination handles nested classes properly by looking up the fq classname from the class file.

Configuration of binfmt_misc ideally takes place in one of your init scripts (see init manual to find out where they resist, usually /etc/rc.d/). This is my personal binfmt_misc configuration script, it gets called in /etc/rc/boot.local .

​http://www.ncsu.edu/felder-public/kenny/home.html

I found it doing a quick search for entaglement, etc b/c of some questions I had regarding the book I am reading: ​http://www.amazon.com/exec/obidos/ASIN/0452284570/aarondmarascoaar/