[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
- gnustep-objc (mingw): problem when using objc as dll,
Michael Scheibler <=