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

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)

# if defined(__NT__)

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

# else

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

# endif

#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

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)
>
> # if defined(__NT__)
>
> BOOL WINAPI _export  DllMain ( HINSTANCE  /* instance */, DWORD  /* reason
*/,
> LPVOID /* reserved */ )
> {
>    return ( TRUE );
> }
>
> # else
>
> int FAR PASCAL _export  LibMain ( HINSTANCE  /* hinstance */, WORD  /*
dataseg
> */, WORD  /* heapsize */, LPSTR  /* cmdline */ )
> {
>    return ( TRUE );
> }
>
> # endif
>
> #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
>

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)
> >
> > # if defined(__NT__)
> >
> > BOOL WINAPI _export  DllMain ( HINSTANCE  /* instance */, DWORD  /*
reason
> */,
> > LPVOID /* reserved */ )
> > {
> >    return ( TRUE );
> > }
> >
> > # else
> >
> > int FAR PASCAL _export  LibMain ( HINSTANCE  /* hinstance */, WORD  /*
> dataseg
> > */, WORD  /* heapsize */, LPSTR  /* cmdline */ )
> > {
> >    return ( TRUE );
> > }
> >
> > # endif
> >
> > #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
> >
>
>

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)
> > >
> > > # if defined(__NT__)
> > >
> > > BOOL WINAPI _export  DllMain ( HINSTANCE  /* instance */, DWORD  /*
> reason
> > */,
> > > LPVOID /* reserved */ )
> > > {
> > >    return ( TRUE );
> > > }
> > >
> > > # else
> > >
> > > int FAR PASCAL _export  LibMain ( HINSTANCE  /* hinstance */, WORD  /*
> > dataseg
> > > */, WORD  /* heapsize */, LPSTR  /* cmdline */ )
> > > {
> > >    return ( TRUE );
> > > }
> > >
> > > # endif
> > >
> > > #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
> > >
> >
> >
>
>

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)
> > > >
> > > > # if defined(__NT__)
> > > >
> > > > BOOL WINAPI _export  DllMain ( HINSTANCE  /* instance */, DWORD  /*
> > reason
> > > */,
> > > > LPVOID /* reserved */ )
> > > > {
> > > >    return ( TRUE );
> > > > }
> > > >
> > > > # else
> > > >
> > > > int FAR PASCAL _export  LibMain ( HINSTANCE  /* hinstance */, WORD
/*
> > > dataseg
> > > > */, WORD  /* heapsize */, LPSTR  /* cmdline */ )
> > > > {
> > > >    return ( TRUE );
> > > > }
> > > >
> > > > # endif
> > > >
> > > > #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
> > > >
> > >
> > >
> >
> >
>
>

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)
> > > > >
> > > > > # if defined(__NT__)
> > > > >
> > > > > BOOL WINAPI _export  DllMain ( HINSTANCE  /* instance */, DWORD
/*
> > > reason
> > > > */,
> > > > > LPVOID /* reserved */ )
> > > > > {
> > > > >    return ( TRUE );
> > > > > }
> > > > >
> > > > > # else
> > > > >
> > > > > int FAR PASCAL _export  LibMain ( HINSTANCE  /* hinstance */, WORD
> /*
> > > > dataseg
> > > > > */, WORD  /* heapsize */, LPSTR  /* cmdline */ )
> > > > > {
> > > > >    return ( TRUE );
> > > > > }
> > > > >
> > > > > # endif
> > > > >
> > > > > #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
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>