Firefox/4.0b8pre SeaMonkey/2.1b2pre   
   hCO[;VZ?>A2GYQY^CT1A^BL@[^:`T\l73PAkZ:86c=4nMLSTD7Vih3VTf1V   
   From: Lars Erdmann    
      
   Lars Erdmann wrote:   
   > Peter Brown wrote:   
   >> Hi Rich   
   >>   
   >> Rich Walsh wrote:   
   >>> On Wed, 8 Dec 2010 01:06:22 UTC, Peter Brown wrote:   
   >>>   
   >>>> I think I've discovered why USBcfg hangs when Lars drivers are in use.   
   >>>>   
   >>>> The driver build level detection code in USBcfg is looking for a string   
   >>>> starting with a '@' followed by a '#' and ending with a '#' - ie   
   >>>> @#IBM:10.162#   
   >>>>   
   >>>> Lars drivers id string starts with '@@' - ie @@#Lars Erdmann:10.163#   
   >>>>   
   >>>> So, USBcfg is probably "going around in circles" trying to find the   
   >>>> "standard" build level identifier string.   
   >>>>   
   >>>> Looks like I'll have to add this to the list of minor bits to do on the   
   >>>> next update of USBcfg - unless Lars reverts to the "standard" identifier   
   >>>> string with just the 1 '@'.   
   >>>   
   >>> The build ID string is preceeded by a byte that identifies its length.   
   >>> The length is 64 or 0x40. Rendered as a character, this is '@' - whence   
   >>> the two '@' in a row.   
   >>>   
   >>>   
   >>   
   >>   
   >>   
   >> Thanks for the explanation.   
   >>   
   >> As you may have guessed I simply opened usb drivers in a text editor to   
   discover how to find the build identifier string - no technical knowledge used   
   :-)   
   >>   
   >> As this is obviously not a mistake by Lars - Sorry to Lars for suggesting   
   it could be - I'll have to update USBcfg to cope with the '@@'.   
   >>   
   >> Regards   
   >>   
   >> Pete   
   > Peter, you should have a look at the DOS and NE executable header format:   
   >   
   > \OS2TK45\h\newexe.h   
   >   
   > It'll take a little trial and error to find the offset field that points to   
   the description string.   
   > Also be aware that there exist tools (NELITE.EXE from Veit Kannegieser comes   
   to mind) that are capable   
   > of stripping away the DOS header and only leave the NE header so don't rely   
   on finding the DOS header.   
   > But this is the only safe method to find the description string.   
   >   
   > Lars   
      
   Here is: first, find the NE header. The best is to search for "NE" magic   
   string and then compute complete file CRC and compare with CRC   
   in NE header. If that goes well you know that you properly found the NE header   
   (CRC is a CRC32, try with the most commonly   
   used polynoms, see internet).   
   Then the offset to the non-resident names table (given from beginning of the   
   file) will directly point to the description   
   string length value (1 byte). After the byte follows the description string:   
      
   struct new_exe NEHeader;   
      
   offset_to_length_byte = NE_NRESTAB(NEHeader);   
      
   Lars   
      
      
   --- Internet Rex 2.31   
    * Origin: Arcor (1:261/20.999)