TIP: Click on subject to list as thread! ANSI
echo: os2prog
to: Daniel Doran
from: Peter Fitzsimmons
date: 1995-10-06 02:13:08
subject: Programming Language

PF> What you should be doing is compiling your Cset (1.0 or 3.0) code
PF> into a DLL, and using the IBM dll from your Watcom program;  thus
PF> both runtimes will be used (and Obviosly,  you should make sure the
PF> two never meet -- ie: don't try free'ing a malloc'ed pointer accross
PF> runtimes).

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

Yes,  but there are two problems with this:

  1) It is just bad.  If you have code different enough to put into a
     dll -- why then do you go and start free'ing/closing stuff across
     dll's?  This just strikes me as a bad programming practice -- heck,
     I hardly even do this across *.obj's;  and it is totally abhorrent
     to the C++ programmer, where,  luckily, destructors prevent this
     type of thing (if you use them!).
     
     I would _always_ have some sort of de-alloc/close function exported
     from the dll,  even if all the code did was call free.   For
     example:
     
     MYSTUFF *CreateAThing(...)           // exported DLL function
     {
          MYSTUFF *ret = malloc(sizeof(MYSTUFF));
          
          ... 
          
          return ret;
          
     }
     
     void FreeAThing(MYSTUFF *p)          // exported DLL function
     {
          free(p);
     }
     
     Not only have I totally isolated the C runtime from another copy of
     the runtime,  I have isolated the compiler from another vendor (any
     C[++] compiler can now use my exported C functions), but I have
     isolated it from other languages; there is no reason why a pascal
     or smalltalk program couldn't use the two functions above.
     
  2) It's not just malloc/free we are talking about.  fopen(),  for
     example,  probably calls malloc() [or something similar] under the
     covers to allocate storage for the 'FILE *' it returns.  fclose(),
     similarly,  will call free().  There is no way to get in there to
     call DosFreeMem().
     
     In fact, you should not let another dll (that has it's own runtime)
     touch a 'FILE *' at all (for fread, fprintf,  anything).
     
           

--- Maximus/2 3.00
* Origin: Sol 3 * Toronto * V.32 * (905)858-8488 (1:259/414)
SEEN-BY: 270/101 620/243 711/401 409 410 413 430 807 808 809 934 955 712/407
SEEN-BY: 712/515 628 704 713/888 800/1 7877/2809
@PATH: 259/414 400 99 229/2 3615/50 396/1 270/101 712/515 711/808 809 934

SOURCE: echomail via fidonet.ozzmosis.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.