Hello Ulrich!   
      
   24 Jun 13 00:39, you wrote to me:   
      
    AL>> This appears to be an OpenWatcom issue.  I've already modified   
    AL>> the code to use version b, with no effect on the SearchMaxMSG   
    AL>> crash under OS/2.   
      
    US> today I've got the debugger running   
      
    US> the program crashes 'cause the _dos_findnext() routine moves a memory   
    US> segment into another memory area, which helds the content of the local   
    US> int variables   
      
    US> the debug report you'll find under   
    US> https://sourceforge.net/p/makenl/bugs/17/?limit=10&page=1#2cd6   
      
    US> based on the oswatfnd.c, oswatful.c, oswatxxx.h, osgenaps.c and os.c   
    US> an ASM routine _dos_findnext() starts moving around some memory   
    US> in the debugger it identifies itself as:   
    US> Assembly: findos2   
    US>    005B:0002AF6A      findos2@copydir_+0000002A   
      
    US> the code section   
    US>  0002AF59                mov      ecx,dword ptr 10[edx]   
    US> 0053:00049474=000000EF 0002AF5C                lea   
    US> edi,1E[eax] 0002AF5F                mov      dword ptr 1A[eax],ecx   
    US> 0053:000497DE=000000EF 0002AF62                mov   
    US> ecx,00000040 0002AF67                lea      esi,1D[edx]   
      
    >> 0002AF6A                rep movsd    0053:0004987A=00030   
      
    US> loops until all the defined memory area is moved.   
      
    US> The memory address of maxnum is defined &49878  and aktnum at &4987C   
    US> so in every _dos_findnext() the previously maxnum = 0 was reset   
    US> to whatever value moved into the ram location by the findnext routine   
    US> :-P   
      
   Yes, that is definitely a problem.   
      
    US> Solution(s) ?   
    US> I don't realy know ...   
    US> I assume, that the findfirst() / findnext() code requires a defined   
    US> memory allocation ?!?   
    US> -or-   
    US> further investigation is needed to discover the reason, why   
    US> _dos_findnext() writes into a memory area that is allocated by the   
    US> active process   
      
   It appears to be a problem with OpenWatcom 1.9.  I will attempt to compile the    
   code with an older version to see if this resolves the issue for MakeNL.   
      
    US> but the source under oswatfnd.c   
      
    US> char *os_findnext(struct _filefind *pff)   
    US> {   
    US>     if (_dos_findnext(&pff->fileinfo) == 0)   
    US>         return pff->fileinfo.name;   
      
    US>     return NULL;   
    US> }   
      
    US> doesn't give much info what's go wrong within _dos_findnext()   
      
   No, it isn't very helpful at all...   
      
    US> As least similar findfirst() findnext() routines   
    US> as shown under   
    US> http://www.openwatcom.org:4000/@md=d&cd=//&cdf=//depot/public/4os2/c/w   
    US> rappers.c &ra=s&c=rGG@//depot/public/4os2/c/wrappers.c?ac=64 has some   
    US> more code included.   
      
    US> here 2 comments are of interest:   
    US>   20 Aug 07 GKY Move #pragma alloc_text to end for OpenWatcom compat   
    US>   01 Sep 07 GKY Add xDosSetPathInfo to fix case where FS3 buffer   
    US> crosses 64k   boundry   
      
    US> maybe something similar is required for the makenl_ng code  ?!?   
      
   Possibly; if so it will take some time to research and implement.   
      
   Thanks for the help in debugging this; it is greatly appreciated.   
      
   Andrew   
      
      
   --- GoldED+/LNX 1.1.5-b20130111   
    * Origin: Phoenix BBS * bnbbbs.dyndns.org:2323 (1:320/219)