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)