discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

gnustep-objc (mingw): problem when using objc as dll


From: Michael Scheibler
Subject: gnustep-objc (mingw): problem when using objc as dll
Date: Thu, 26 Apr 2001 15:13:24 +0200

Using shared libraries on WIN32, example gnustep-objc:
On WIN32 every shared library (DLL) is something very similar to an
application. At least it has to be linked. Therefore it is necessary to have
the Objective-C runtime as a shared library, to ensure that a dynamically
loaded bundle does not use its own class tree but the same as the
application.
But... what if you have two objc applications? They must not have the same
class tree.
AFAIK every dll has its own - process independent - memory. This would mean
that there will be a conflict resulting in... I don't know, but propably
nothing good.
In gnustep-objc there is a file named libobjc_entry.c which implements
DllMain. The purpose of DllMain is to do exactly these intializing steps
when a new process/thread attaches/detaches. But look at the code:


libobjc_entry.c

WINBOOL WINAPI DllMain(HANDLE hInst, ULONG ul_reason_for_call,
        LPVOID lpReserved)
{
  switch(ul_reason_for_call)
    {
    case DLL_PROCESS_ATTACH:
      break;
    case DLL_PROCESS_DETACH:
      break;
    case DLL_THREAD_ATTACH:
      break;
    case DLL_THREAD_DETACH:
      break;
    }
  return TRUE;
}


There is nothing done. I think it is absolutely necessary to create a new
class tree for each process.


Another thing I have to mention: in gnustep-objc/GNUmakefile there is
following entry:

ifeq ($(GNUSTEP_TARGET_OS), cygwin)
  extra_C_FILES=libobjc_entry.c
else
  extra_C_FILES=
endif


But I didn't find anything for mingw32...



Michael




reply via email to

[Prev in Thread] Current Thread [Next in Thread]