• Rajiv Bhagwat (14/14) Jan 28 2002 After a grueling search (spanning weeks) in an app (complicated, really)
• Jan Knepper (36/50) Jan 28 2002 This sounds VERY weird as I do not think this is really a compiler/libra...
• Walter (15/66) Jan 28 2002 The parameter order can get screwed up unless __stdcall is specified for
• Rajiv Bhagwat (26/114) Jan 28 2002 This file contains only Win32 specific code. The exact code is:
• Walter (10/127) Jan 28 2002 The hDLL passed to DllMain() is the same value passed to
• Rajiv Bhagwat (15/150) Jan 28 2002 Thats what note(...) does!
• Walter (11/167) Jan 29 2002 Try doing it in _DllMainCRTStartup().

"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 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

"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

"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

"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

"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

"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