www.digitalmars.com         C & C++   DMDScript  

c++.windows.32-bits - DLL hInstance problem

reply "Rajiv Bhagwat" <dataflow vsnl.com> writes:
After a grueling search (spanning weeks) in an app (complicated, really)
which worked with VC, but not with SC, it has been found that the hInstance
passed to DllMain on startup is different than the value returned by
GetModuleHandle("dll name"). For VC, the two are same, so saving the value
on start would work.
For DMC, the value of hInstance is something like '3', which is the segment
shown in the map file.
I know the workaround, (use GetModuleHandle!) but would like to know when
this was changed. I think the app used to work in 2000 or so. Is that
observation correct?

Please comment and add this to the 'to do' list.
(I will only distribute the DMC app, as I have my configuration management &
user management set up with it, so such fixes are still important.)
- Rajiv
Jan 28 2002
parent reply Jan Knepper <jan smartsoft.cc> writes:
This sounds VERY weird as I do not think this is really a compiler/library
issue.
A .DLL should be loaded using a Windows API function. This Windows API function
requires a DllMain.
Are you sure the DllMain is properly being prototyped and everything for both
compilers?
My first impulse would be to think that the parameter order is wrong for some
strange reason.
I used to use the following code... in a file called LibMain.cpp

Jan



#include <stdjak.h>

#if defined(__SC__)

#include <windows.h>

#ifdef __cplusplus
extern "C" {
#endif

#if defined(_WINDLL)



BOOL WINAPI _export  DllMain ( HINSTANCE  /* instance */, DWORD  /* reason */,
LPVOID /* reserved */ )
{
   return ( TRUE );
}



int FAR PASCAL _export  LibMain ( HINSTANCE  /* hinstance */, WORD  /* dataseg
*/, WORD  /* heapsize */, LPSTR  /* cmdline */ )
{
   return ( TRUE );
}



#endif

#ifdef __cplusplus
}
#endif



#endif


Rajiv Bhagwat wrote:

 After a grueling search (spanning weeks) in an app (complicated, really)
 which worked with VC, but not with SC, it has been found that the hInstance
 passed to DllMain on startup is different than the value returned by
 GetModuleHandle("dll name"). For VC, the two are same, so saving the value
 on start would work.
 For DMC, the value of hInstance is something like '3', which is the segment
 shown in the map file.
 I know the workaround, (use GetModuleHandle!) but would like to know when
 this was changed. I think the app used to work in 2000 or so. Is that
 observation correct?

 Please comment and add this to the 'to do' list.
 (I will only distribute the DMC app, as I have my configuration management &
 user management set up with it, so such fixes are still important.)
 - Rajiv
Jan 28 2002
parent reply "Walter" <walter digitalmars.com> writes:
The parameter order can get screwed up unless __stdcall is specified for
DllMain(). You can also look at \dm\src\win32\dllstart.c to see how it gets
passed. I don't believe it has changed. -Walter

"Jan Knepper" <jan smartsoft.cc> wrote in message
news:3C559F26.AA7974B9 smartsoft.cc...
 This sounds VERY weird as I do not think this is really a compiler/library
 issue.
 A .DLL should be loaded using a Windows API function. This Windows API
function
 requires a DllMain.
 Are you sure the DllMain is properly being prototyped and everything for
both
 compilers?
 My first impulse would be to think that the parameter order is wrong for
some
 strange reason.
 I used to use the following code... in a file called LibMain.cpp

 Jan



 #include <stdjak.h>

 #if defined(__SC__)

 #include <windows.h>

 #ifdef __cplusplus
 extern "C" {
 #endif

 #if defined(_WINDLL)



 BOOL WINAPI _export  DllMain ( HINSTANCE  /* instance */, DWORD  /* reason
*/,
 LPVOID /* reserved */ )
 {
    return ( TRUE );
 }



 int FAR PASCAL _export  LibMain ( HINSTANCE  /* hinstance */, WORD  /*
dataseg
 */, WORD  /* heapsize */, LPSTR  /* cmdline */ )
 {
    return ( TRUE );
 }



 #endif

 #ifdef __cplusplus
 }
 #endif



 #endif


 Rajiv Bhagwat wrote:

 After a grueling search (spanning weeks) in an app (complicated, really)
 which worked with VC, but not with SC, it has been found that the
hInstance
 passed to DllMain on startup is different than the value returned by
 GetModuleHandle("dll name"). For VC, the two are same, so saving the
value
 on start would work.
 For DMC, the value of hInstance is something like '3', which is the
segment
 shown in the map file.
 I know the workaround, (use GetModuleHandle!) but would like to know
when
 this was changed. I think the app used to work in 2000 or so. Is that
 observation correct?

 Please comment and add this to the 'to do' list.
 (I will only distribute the DMC app, as I have my configuration
management &
 user management set up with it, so such fixes are still important.)
 - Rajiv
Jan 28 2002
parent reply "Rajiv Bhagwat" <dataflow vsnl.com> writes:
This file contains only Win32 specific code. The exact code is:

BOOL WINAPI DllMain (HINSTANCE hDLL, DWORD dwReason, LPVOID lpReserved){
    if(dwReason == DLL_PROCESS_ATTACH){
//        note("hInstanceDll: %ld",hDLL);
        hInstanceDll = hDLL;
        MapFileMemory(sizeof(HookRec));
        hotkey.set();
//        pgms++;
        }
    else if( dwReason == DLL_PROCESS_DETACH){
//        pgms--;
        UnMapFileMemory();
        }
    return TRUE;
    }

And, the linker flags include:
lnk2_32=/CO /NOI /DO /DE /PACKF /XN /NT /DET /BAS:268435456
/ENTRY:_DllMainCRTStartup /A:512

But removing the ENTRY and BAS does not make any difference.
- Rajiv



"Walter" <walter digitalmars.com> wrote in message
news:a34qqr$2okk$1 digitaldaemon.com...
 The parameter order can get screwed up unless __stdcall is specified for
 DllMain(). You can also look at \dm\src\win32\dllstart.c to see how it
gets
 passed. I don't believe it has changed. -Walter

 "Jan Knepper" <jan smartsoft.cc> wrote in message
 news:3C559F26.AA7974B9 smartsoft.cc...
 This sounds VERY weird as I do not think this is really a
compiler/library
 issue.
 A .DLL should be loaded using a Windows API function. This Windows API
function
 requires a DllMain.
 Are you sure the DllMain is properly being prototyped and everything for
both
 compilers?
 My first impulse would be to think that the parameter order is wrong for
some
 strange reason.
 I used to use the following code... in a file called LibMain.cpp

 Jan



 #include <stdjak.h>

 #if defined(__SC__)

 #include <windows.h>

 #ifdef __cplusplus
 extern "C" {
 #endif

 #if defined(_WINDLL)



 BOOL WINAPI _export  DllMain ( HINSTANCE  /* instance */, DWORD  /*
reason
 */,
 LPVOID /* reserved */ )
 {
    return ( TRUE );
 }



 int FAR PASCAL _export  LibMain ( HINSTANCE  /* hinstance */, WORD  /*
dataseg
 */, WORD  /* heapsize */, LPSTR  /* cmdline */ )
 {
    return ( TRUE );
 }



 #endif

 #ifdef __cplusplus
 }
 #endif



 #endif


 Rajiv Bhagwat wrote:

 After a grueling search (spanning weeks) in an app (complicated,
really)
 which worked with VC, but not with SC, it has been found that the
hInstance
 passed to DllMain on startup is different than the value returned by
 GetModuleHandle("dll name"). For VC, the two are same, so saving the
value
 on start would work.
 For DMC, the value of hInstance is something like '3', which is the
segment
 shown in the map file.
 I know the workaround, (use GetModuleHandle!) but would like to know
when
 this was changed. I think the app used to work in 2000 or so. Is that
 observation correct?

 Please comment and add this to the 'to do' list.
 (I will only distribute the DMC app, as I have my configuration
management &
 user management set up with it, so such fixes are still important.)
 - Rajiv
Jan 28 2002
parent reply "Walter" <walter digitalmars.com> writes:
The hDLL passed to DllMain() is the same value passed to
_DllMainCRTStartup() in \dm\src\win32\dllstart.c.

My suggestion is look for some part of your program overwriting hInstance.

I also suggest that you try printing out the value of hDLL with MessageBox()
as the first statement in DllMain().


"Rajiv Bhagwat" <dataflow vsnl.com> wrote in message
news:a35drm$1t8o$1 digitaldaemon.com...
 This file contains only Win32 specific code. The exact code is:

 BOOL WINAPI DllMain (HINSTANCE hDLL, DWORD dwReason, LPVOID lpReserved){
     if(dwReason == DLL_PROCESS_ATTACH){
 //        note("hInstanceDll: %ld",hDLL);
         hInstanceDll = hDLL;
         MapFileMemory(sizeof(HookRec));
         hotkey.set();
 //        pgms++;
         }
     else if( dwReason == DLL_PROCESS_DETACH){
 //        pgms--;
         UnMapFileMemory();
         }
     return TRUE;
     }

 And, the linker flags include:
 lnk2_32=/CO /NOI /DO /DE /PACKF /XN /NT /DET /BAS:268435456
 /ENTRY:_DllMainCRTStartup /A:512

 But removing the ENTRY and BAS does not make any difference.
 - Rajiv



 "Walter" <walter digitalmars.com> wrote in message
 news:a34qqr$2okk$1 digitaldaemon.com...
 The parameter order can get screwed up unless __stdcall is specified for
 DllMain(). You can also look at \dm\src\win32\dllstart.c to see how it
gets
 passed. I don't believe it has changed. -Walter

 "Jan Knepper" <jan smartsoft.cc> wrote in message
 news:3C559F26.AA7974B9 smartsoft.cc...
 This sounds VERY weird as I do not think this is really a
compiler/library
 issue.
 A .DLL should be loaded using a Windows API function. This Windows API
function
 requires a DllMain.
 Are you sure the DllMain is properly being prototyped and everything
for
 both
 compilers?
 My first impulse would be to think that the parameter order is wrong
for
 some
 strange reason.
 I used to use the following code... in a file called LibMain.cpp

 Jan



 #include <stdjak.h>

 #if defined(__SC__)

 #include <windows.h>

 #ifdef __cplusplus
 extern "C" {
 #endif

 #if defined(_WINDLL)



 BOOL WINAPI _export  DllMain ( HINSTANCE  /* instance */, DWORD  /*
reason
 */,
 LPVOID /* reserved */ )
 {
    return ( TRUE );
 }



 int FAR PASCAL _export  LibMain ( HINSTANCE  /* hinstance */, WORD  /*
dataseg
 */, WORD  /* heapsize */, LPSTR  /* cmdline */ )
 {
    return ( TRUE );
 }



 #endif

 #ifdef __cplusplus
 }
 #endif



 #endif


 Rajiv Bhagwat wrote:

 After a grueling search (spanning weeks) in an app (complicated,
really)
 which worked with VC, but not with SC, it has been found that the
hInstance
 passed to DllMain on startup is different than the value returned by
 GetModuleHandle("dll name"). For VC, the two are same, so saving the
value
 on start would work.
 For DMC, the value of hInstance is something like '3', which is the
segment
 shown in the map file.
 I know the workaround, (use GetModuleHandle!) but would like to know
when
 this was changed. I think the app used to work in 2000 or so. Is
that
 observation correct?

 Please comment and add this to the 'to do' list.
 (I will only distribute the DMC app, as I have my configuration
management &
 user management set up with it, so such fixes are still important.)
 - Rajiv
Jan 28 2002
parent reply "Rajiv Bhagwat" <dataflow vsnl.com> writes:
Thats what note(...) does!
It is coming out as '3'. Later, I use the GetModulehandle and it gives a
huge number.
- Rajiv


"Walter" <walter digitalmars.com> wrote in message
news:a35fl8$1ua2$2 digitaldaemon.com...
 The hDLL passed to DllMain() is the same value passed to
 _DllMainCRTStartup() in \dm\src\win32\dllstart.c.

 My suggestion is look for some part of your program overwriting hInstance.

 I also suggest that you try printing out the value of hDLL with
MessageBox()
 as the first statement in DllMain().


 "Rajiv Bhagwat" <dataflow vsnl.com> wrote in message
 news:a35drm$1t8o$1 digitaldaemon.com...
 This file contains only Win32 specific code. The exact code is:

 BOOL WINAPI DllMain (HINSTANCE hDLL, DWORD dwReason, LPVOID lpReserved){
     if(dwReason == DLL_PROCESS_ATTACH){
 //        note("hInstanceDll: %ld",hDLL);
         hInstanceDll = hDLL;
         MapFileMemory(sizeof(HookRec));
         hotkey.set();
 //        pgms++;
         }
     else if( dwReason == DLL_PROCESS_DETACH){
 //        pgms--;
         UnMapFileMemory();
         }
     return TRUE;
     }

 And, the linker flags include:
 lnk2_32=/CO /NOI /DO /DE /PACKF /XN /NT /DET /BAS:268435456
 /ENTRY:_DllMainCRTStartup /A:512

 But removing the ENTRY and BAS does not make any difference.
 - Rajiv



 "Walter" <walter digitalmars.com> wrote in message
 news:a34qqr$2okk$1 digitaldaemon.com...
 The parameter order can get screwed up unless __stdcall is specified
for
 DllMain(). You can also look at \dm\src\win32\dllstart.c to see how it
gets
 passed. I don't believe it has changed. -Walter

 "Jan Knepper" <jan smartsoft.cc> wrote in message
 news:3C559F26.AA7974B9 smartsoft.cc...
 This sounds VERY weird as I do not think this is really a
compiler/library
 issue.
 A .DLL should be loaded using a Windows API function. This Windows
API
 function
 requires a DllMain.
 Are you sure the DllMain is properly being prototyped and everything
for
 both
 compilers?
 My first impulse would be to think that the parameter order is wrong
for
 some
 strange reason.
 I used to use the following code... in a file called LibMain.cpp

 Jan



 #include <stdjak.h>

 #if defined(__SC__)

 #include <windows.h>

 #ifdef __cplusplus
 extern "C" {
 #endif

 #if defined(_WINDLL)



 BOOL WINAPI _export  DllMain ( HINSTANCE  /* instance */, DWORD  /*
reason
 */,
 LPVOID /* reserved */ )
 {
    return ( TRUE );
 }



 int FAR PASCAL _export  LibMain ( HINSTANCE  /* hinstance */, WORD
/*
 dataseg
 */, WORD  /* heapsize */, LPSTR  /* cmdline */ )
 {
    return ( TRUE );
 }



 #endif

 #ifdef __cplusplus
 }
 #endif



 #endif


 Rajiv Bhagwat wrote:

 After a grueling search (spanning weeks) in an app (complicated,
really)
 which worked with VC, but not with SC, it has been found that the
hInstance
 passed to DllMain on startup is different than the value returned
by
 GetModuleHandle("dll name"). For VC, the two are same, so saving
the
 value
 on start would work.
 For DMC, the value of hInstance is something like '3', which is
the
 segment
 shown in the map file.
 I know the workaround, (use GetModuleHandle!) but would like to
know
 when
 this was changed. I think the app used to work in 2000 or so. Is
that
 observation correct?

 Please comment and add this to the 'to do' list.
 (I will only distribute the DMC app, as I have my configuration
management &
 user management set up with it, so such fixes are still
important.)
 - Rajiv
Jan 28 2002
parent "Walter" <walter digitalmars.com> writes:
Try doing it in _DllMainCRTStartup().

"Rajiv Bhagwat" <dataflow vsnl.com> wrote in message
news:a35hck$1vbv$1 digitaldaemon.com...
 Thats what note(...) does!
 It is coming out as '3'. Later, I use the GetModulehandle and it gives a
 huge number.
 - Rajiv


 "Walter" <walter digitalmars.com> wrote in message
 news:a35fl8$1ua2$2 digitaldaemon.com...
 The hDLL passed to DllMain() is the same value passed to
 _DllMainCRTStartup() in \dm\src\win32\dllstart.c.

 My suggestion is look for some part of your program overwriting
hInstance.
 I also suggest that you try printing out the value of hDLL with
MessageBox()
 as the first statement in DllMain().


 "Rajiv Bhagwat" <dataflow vsnl.com> wrote in message
 news:a35drm$1t8o$1 digitaldaemon.com...
 This file contains only Win32 specific code. The exact code is:

 BOOL WINAPI DllMain (HINSTANCE hDLL, DWORD dwReason, LPVOID
lpReserved){
     if(dwReason == DLL_PROCESS_ATTACH){
 //        note("hInstanceDll: %ld",hDLL);
         hInstanceDll = hDLL;
         MapFileMemory(sizeof(HookRec));
         hotkey.set();
 //        pgms++;
         }
     else if( dwReason == DLL_PROCESS_DETACH){
 //        pgms--;
         UnMapFileMemory();
         }
     return TRUE;
     }

 And, the linker flags include:
 lnk2_32=/CO /NOI /DO /DE /PACKF /XN /NT /DET /BAS:268435456
 /ENTRY:_DllMainCRTStartup /A:512

 But removing the ENTRY and BAS does not make any difference.
 - Rajiv



 "Walter" <walter digitalmars.com> wrote in message
 news:a34qqr$2okk$1 digitaldaemon.com...
 The parameter order can get screwed up unless __stdcall is specified
for
 DllMain(). You can also look at \dm\src\win32\dllstart.c to see how
it
 gets
 passed. I don't believe it has changed. -Walter

 "Jan Knepper" <jan smartsoft.cc> wrote in message
 news:3C559F26.AA7974B9 smartsoft.cc...
 This sounds VERY weird as I do not think this is really a
compiler/library
 issue.
 A .DLL should be loaded using a Windows API function. This Windows
API
 function
 requires a DllMain.
 Are you sure the DllMain is properly being prototyped and
everything
 for
 both
 compilers?
 My first impulse would be to think that the parameter order is
wrong
 for
 some
 strange reason.
 I used to use the following code... in a file called LibMain.cpp

 Jan



 #include <stdjak.h>

 #if defined(__SC__)

 #include <windows.h>

 #ifdef __cplusplus
 extern "C" {
 #endif

 #if defined(_WINDLL)



 BOOL WINAPI _export  DllMain ( HINSTANCE  /* instance */, DWORD
/*
 reason
 */,
 LPVOID /* reserved */ )
 {
    return ( TRUE );
 }



 int FAR PASCAL _export  LibMain ( HINSTANCE  /* hinstance */, WORD
/*
 dataseg
 */, WORD  /* heapsize */, LPSTR  /* cmdline */ )
 {
    return ( TRUE );
 }



 #endif

 #ifdef __cplusplus
 }
 #endif



 #endif


 Rajiv Bhagwat wrote:

 After a grueling search (spanning weeks) in an app (complicated,
really)
 which worked with VC, but not with SC, it has been found that
the
 hInstance
 passed to DllMain on startup is different than the value
returned
 by
 GetModuleHandle("dll name"). For VC, the two are same, so saving
the
 value
 on start would work.
 For DMC, the value of hInstance is something like '3', which is
the
 segment
 shown in the map file.
 I know the workaround, (use GetModuleHandle!) but would like to
know
 when
 this was changed. I think the app used to work in 2000 or so. Is
that
 observation correct?

 Please comment and add this to the 'to do' list.
 (I will only distribute the DMC app, as I have my configuration
management &
 user management set up with it, so such fixes are still
important.)
 - Rajiv
Jan 29 2002