Hi Andrew,   
      
   Wednesday June 05 2013 09:40, you wrote to me:   
      
    AL> Hello Ulrich!   
    AL> Tuesday June 04 2013 03:15, Ulrich Schroeter wrote to Andrew Leary:   
    US>> first, I've found the compile problem that is caused by   
    US>> the filepointer around BatchFILE in main routine (makenl.c  line   
    US>> ~325) see latest report under bug#17   
    AL> ...   
    US>> Whatever workaround I've tried to fix the return sequence   
    US>> it crashes under OS/2 32-bit  :(   
    AL> Yes, I know.   
      
    US>> the problem may relate to the local int variable, that will be   
    US>> used to return the result to the calling routine, where the   
    US>> result will be assigned to a static int variable.   
    AL> That is a definite possibility.  I'll have to research that further.   
      
   int variables tested around, that I can exclude to be the problem.   
   Yes, one shown bug with the  in maxnum = 0;  results in whatever value ...   
   but this isn't the cause for the crashing OS/2 32-bit executable   :-P   
      
   the last tests I've running without an integer return value   
   in the return sequence by setting   
      void SearchMaxMSG()   
   and transfering the integer value via a static int variable SearchFeedback   
      
      
      
    AL> It shouldn't be, but I'll look into that.  Maybe this is the result   
    AL> of the work that was done to get the code to compile on 64-bit Linux   
    AL> systems.   
      
    US>> Someone with much more C/C++ experiences then me should dig into   
    US>> this code section   
      
    AL> I'm learning more all the time.   
      
   me too  =:)   
      
   ok, results found so far:   
      
   1. int variable problems doesn't interfer with the OS2 crash   
      in SearchMaxMSG()   
      
   2. the OS/2 executable crashes in the SearchMaxMSG() routine while trying   
      to jump to the return address within the calling function OpenMsgFILE()   
          return ;   
      this will do the executable guranteed (but I don't know why :( ......)   
      
   3. If the codebase (filesize of makenl.exe) increases, the crash address    
   increases   
      if the codebase decreases, the crash address decreases   
      
   4. The crash address is around 50.000 bytes below the variables areas   
      
   5. At least one known stack pointer problem we've found with the   
      DOS/16 compile with OW19 while calling OpenMSGFile() (fixed 2012-06-28)   
      
   Research about OW19 bug reports about stack failures gives only diffuse results   
   that doesn't match exactly to our current problem.   
   No reports found that relates to function return exceptions   
      
      
      
    AL> Andrew   
      
   regards, uli   ;-)   
      
   ---   
    * Origin: AMBROSIA - Frankfurt/Main - Germany (2:244/1120)