PETER FITZSIMMONS wrote something vaguely related to Programming
Language


DD> But DosFreeMem'ing a DosAllocMem'd pointer, I assume, would be safe?

PF> Yes,  but there are two problems with this:
PF> 
PF>   1) It is just bad.  If you have code different enough to put into a
PF>      dll -- why then do you go and start free'ing/closing stuff across
PF>      dll's?  This just strikes me as a bad programming practice -- heck,
PF>      I hardly even do this across *.obj's;  and it is totally abhorrent
PF>      to the C++ programmer, where,  luckily, destructors prevent this
PF>      type of thing (if you use them!).

I'd particularly thought of it after fooling around with the REXX
interface, where occasionally, (fr'instance in a subcommand handler)
you may need to pass the REXX interpreter a DosAllocMem'd pointer, if
you need to pass an RXstring of more than 256 characters.  I thought
that if the programmers writing the API did it, it might occasionally
be useful.

PF>   In fact, you should not let another dll (that has it's own runtime)
PF>   touch a 'FILE *' at all (for fread, fprintf,  anything).

Makes sense.  If, for some reason, you decided to let another dll
handle a file that had been opened by another bit of code, would you
suggest using DosOpen() with an 'HFILE' file handle, or _open() with an
'int' file handle?

 * KWQ/2 1.2g * All I want is a hot woman, cold beer and unlimited power.
--- QScan/PCB v1.17b / 01-0093