Hi Andrew,   
      
   Wednesday June 19 2013 08:50, you wrote to mark lewis:   
      
    AL>    Hello mark!   
    AL> 05 Jun 13 13:09, you wrote to Ulrich Schroeter:   
    US>>> version a:   
    US>>>    int maxnum = 0;   
    US>>>    print maxnum results in =>  710691913   
    ml>> he aims...   
    ml>> C shoots!   
    ml>> C Scores!!   
    AL> This appears to be an OpenWatcom issue.  I've already modified the   
    AL> code to use version b, with no effect on the SearchMaxMSG crash under   
    AL> OS/2.   
      
   today I've got the debugger running   
      
   the program crashes 'cause the _dos_findnext() routine moves a memory segment   
   into another memory area, which helds the content of the local int variables   
      
   the debug report you'll find under   
   https://sourceforge.net/p/makenl/bugs/17/?limit=10&page=1#2cd6   
      
   based on the oswatfnd.c, oswatful.c, oswatxxx.h, osgenaps.c and os.c   
   an ASM routine _dos_findnext() starts moving around some memory   
   in the debugger it identifies itself as:   
   Assembly: findos2   
      005B:0002AF6A      findos2@copydir_+0000002A   
      
   the code section   
    0002AF59                mov      ecx,dword ptr 10[edx]                          
   0053:00049474=000000EF   
    0002AF5C                lea      edi,1E[eax]   
    0002AF5F                mov      dword ptr 1A[eax],ecx                          
   0053:000497DE=000000EF   
    0002AF62                mov      ecx,00000040   
    0002AF67                lea      esi,1D[edx]   
      
   >0002AF6A                rep movsd    0053:0004987A=00030   
      
   loops until all the defined memory area is moved.   
      
   The memory address of maxnum is defined &49878  and aktnum at &4987C   
   so in every _dos_findnext() the previously maxnum = 0 was reset   
   to whatever value moved into the ram location by the findnext routine :-P   
      
   Solution(s) ?   
   I don't realy know ...   
   I assume, that the findfirst() / findnext() code requires a defined   
   memory allocation ?!?   
   -or-   
   further investigation is needed to discover the reason, why _dos_findnext()   
   writes into a memory area that is allocated by the active process   
      
   but the source under oswatfnd.c   
      
   char *os_findnext(struct _filefind *pff)   
   {   
       if (_dos_findnext(&pff->fileinfo) == 0)   
           return pff->fileinfo.name;   
      
       return NULL;   
   }   
      
   doesn't give much info what's go wrong within _dos_findnext()   
      
   As least similar findfirst() findnext() routines   
   as shown under   
   http://www.openwatcom.org:4000/@md=d&cd=//&cdf=//depot/public/4o   
   2/c/wrappers.c &ra=s&c=rGG@//depot/public/4os2/c/wrappers.c?ac=64   
   has some more code included.   
      
   here 2 comments are of interest:   
     20 Aug 07 GKY Move #pragma alloc_text to end for OpenWatcom compat   
     01 Sep 07 GKY Add xDosSetPathInfo to fix case where FS3 buffer crosses 64k     
   boundry   
      
   maybe something similar is required for the makenl_ng code  ?!?   
      
    AL> Andrew   
      
   regards, uli   ;-)   
      
   ---   
    * Origin: AMBROSIA - Frankfurt/Main - Germany (2:244/1120)