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)