RM> Hi Paul



 >>>> moved here from TML's LOCSYSOP in the faint hope of

 RM>      attracting hints.. 



Good luck :-)



 RM> The real reason I asked was to see if you had fun with file

 RM> handles. I ran into the 20 limit real fast. Found a solution called

 RM> relocate() that uses dos interrupt 0x67 in the Snippets file,

 RM> though, but it took some work to get it running:



Yeah, seen that in there but never tried it.



 RM> a) The fix provides heaps more handles, but only of the int handle

 RM> variety. The FILE *fp file pointer system gets no assistance.

 RM> Therefore, all the nice fopen() type functions are out. FILE is

 RM> limited by the constant MAX_HANDLES, which is 20 under BC3 and 16-

 RM> bit BC4, or 40 with BC4 in flat 32 bit mode. What is it in the OS/2

 RM> compiler?



With the OS/2 compiler, I hit the limit with somewhere around 30 packets
open. OS/2 has a function to increase the number of file handles available,
but it didn't help. Possibly it's only of use if you call the OS/2 file
open functions rather than using the ones built into BCOS2. This was about
the stage that I decided to change the approach.



 RM> When BC4 compiles it, I get warnings that "_read() and _write() are

 RM> obsolete".... Damned cheek. I've been insulted by a bloody

 RM> compiler .



ROFL!



If it's so smart let it fix the program!



 RM> The program now runs, but... It crashes in spectacular fashion when

 RM> the pc is running Qemm (no multitasker, just Dos5 and Qemm). Runs

 RM> fine under Himem.sys . This is a real pain, because I need Qemm to

 RM> run Dv properly, and Dv is the target environment for this program.

 RM> As well as that, TD386v3 is the best debugger I have for this work,

 RM> because of its partial resistance to being crashed by the program

 RM> it is debugging. TD386 won't run under Qemm. I'm stuck with TDv3,

 RM> and the TDv4 that comes with BC4, which seems nearly identical to

 RM> TDv3. It certainly crashes just as easliy.



Sounds like you've got a stray pointer corrupting memory. You're probably
getting away with it under some circumstances but not others. I would have
thought TD386 would be able to trap that problem though. If you want, send
your code back to me and I'll compile and run it under OS/2 and see if it
can pick up any memory addressing problems.



 RM> The program seems to go bananas during function returns. At one

 RM> stage, I could get it to crash when main() returned, by feeding it

 RM> incorrect parameters so it would terminate without doing any packet

 RM> sorting. That particular crash went away all by itself, though.

 RM> More work. Sigh.



Don't worry, it might be gone now but it'll probably turn up again later :-)



Are you running with stack checking turned on?



 RM> And I think I will include date/time sorting after all. The current

 RM> setup seems to throw the msgs in reverse order more often than

 RM> not...



Yeah, the others are complaining about that as well. Probably a good idea,
but it'll limit the number of messages you can sort.





Paul



--- GoldED/2 2.42.G1114