Firefox/4.0b8pre SeaMonkey/2.1b2pre   
   hCOK4b4Z?GW2:IG^CT1A^BL@[N:`T\l73PAkJMboTUGjl8iOn2   
      
   Lars Erdmann wrote:   
   > 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   
   >   
      
   struct new_exe NEHeader;   
   CHAR DescriptionString[256];   
   LONG off;   
   UCHAR len;   
      
   ... find NE header in file and copy to NEHeader ...   
      
   off = NE_NRESTAB(NEHeader);   
   fseek(fDriverFile,(LONG)off,SEEK_SET);   
   fread(&len,sizeof(UCHAR),(size_t)1,fDriverFile);   
      
   memset(DescriptionString,0,sizeof(DescriptionString));   
   fread(DescriptionString,sizeof(CHAR),(size_t)len,fDriverFile);   
      
   You then have the Description string in "DescriptionString".   
   It might contain spaces at the very end which you can strip away.   
      
      
   Lars   
      
      
      
      
      
      
   --- Internet Rex 2.31   
    * Origin: Arcor (1:261/20.999)