Hi Andrew,   
      
   Tuesday June 25 2013 12:09, you wrote to me:   
      
    AL>    Hello Ulrich!   
    AL> 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.   
    AL> ...   
      
    US>> based on the oswatfnd.c, oswatful.c, oswatxxx.h, osgenaps.c and   
    US>> os.c an ASM routine _dos_findnext() starts moving around some   
    US>> memory in the debugger it identifies itself as: Assembly: findos2   
    US>>    005B:0002AF6A      findos2@copydir_+0000002A   
    AL> ..   
    AL> Yes, that is definitely a problem.   
    AL>   
    US>> Solution(s) ?   
    US>> I don't realy know ...   
    US>> I assume, that the findfirst() / findnext() code requires a   
    US>> defined memory allocation ?!? -or- further investigation is   
    US>> needed to discover the reason, why _dos_findnext() writes into a   
    US>> memory area that is allocated by the active process   
    AL>   
    AL> It appears to be a problem with OpenWatcom 1.9.  I will attempt to   
    AL> compile the code with an older version to see if this resolves the   
    AL> issue for MakeNL.   
      
   ok, I've worked on a workaround for the _dos_findfirst() / _dos_findnext()   
   routines together with Markus the last 2? 3? weeks.   
      
   Today I've got an alternate bundle of  DosFindFirst() / DosFindNext()   
   routines compiled.   
      
   The program started running ... and crashed too :(   
      
   Of special interest is, that the program crashed unrelated to   
   the SearchMaxMSG routine.   
      
   In the preparation steps, makenl collects the files defined in the makenl   
   control file, while scanning  update, inbound and working directory   
   through the myfnmerge() routine.   
      
   With the new routines included (findfirs.c, findnext.c from watcom ow19 src   
   Bld/Clib/File/C)   
   the program probably crashes, while trying to transfer the results   
   found in the low-level clib routines to the makenl data working area.   
      
   As seen in my debug run of the original makenl code, the _dos_findnext()   
   information transfer started overwriting areas of the codes local data area.   
      
   It looks like, that there is not enough memory available, so the   
   segments started overlapping that results in the crash   
   that brings me back to below still known report   
      
   (I still did not a debug run, but probably the result is similar   
   to the previously published debug result ... that the low level routine   
   starts overwriting local data area of the running code)   
      
      
    US>> As least similar findfirst() findnext() routines   
    US>> as shown under   
    US>> http://www.openwatcom.org:4000/@md=d&cd=//&cdf=//depot/public/4os   
    US>> 2/c/w rappers.c   
    US>> &ra=s&c=rGG@//depot/public/4os2/c/wrappers.c?ac=64 has some more   
    US>> code included.   
    AL>   
    US>> here 2 comments are of interest:   
    US>>   20 Aug 07 GKY Move #pragma alloc_text to end for OpenWatcom   
    US>> compat  01 Sep 07 GKY Add xDosSetPathInfo to fix case where FS3   
    US>> buffer crosses 64k   boundry   
      
         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^   
      
    US>> maybe something similar is required for the makenl_ng code  ?!?   
    AL> Possibly; if so it will take some time to research and implement.   
    AL> Thanks for the help in debugging this; it is greatly appreciated.   
      
   my C experiences are far from such experiences required, to get such   
   a task running ...   
   I still have no idea how such extended memory usage monitoring   
   can be implemented, to prevent overlapping of data areas   
      
   From other non-C compile and link projects, I know that its possible   
   to receive a map of memory layout for the compiled program, that may help in   
   analysing the memory requirements by the compiled program. But I'm currently   
   don't know how I can add this to the watcom compile and link configuration   
      
   I still start the compile with the following commandline   
   wmake -f makefos2.wat DEBUG=1 OS=OS2 >> comp_os2.log   
   where makefos2.wat is the copied watcom.compile file from the makenl_ng   
   distribution package   
      
   within the watcom.compile file I don't know which flags I can set   
   so that a map layout file will be written in the  compile run   
      
    AL> Andrew   
      
   regards, uli   ;-)   
      
   ---   
    * Origin: AMBROSIA - Frankfurt/Main - Germany (2:244/1120)