Re: DllMain vs. DllMain

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

OK "m" you are right on one point, but my hand still needs holding.

You are right that page
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_Initialize_Non.2d.MFC_DLLs.asp
concerns VS .Net.  So I apologize for quoting that page.

Now let's look at pages for VC++6.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore98/html/_core_initialize_non.2d.mfc_dlls.asp
This one says the same as the .Net version said, but this is for VC++6.

BOOL APIENTRY DllMain(
  HANDLE hModule,

>   DWORD ul_reason_for_call,
>   LPVOID lpReserved)

Meanwhile the other page
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dllmain.asp
still says what it said before.

BOOL WINAPI DllMain(
  HINSTANCE hinstDLL,
  DWORD fdwReason,
  LPVOID lpvReserved)

Now, is a user of VC++6 supposed to obey the MSDN page that tells VC++6 programmers how to interact with the API, or is a user of VC++6 supposed to obey the MSDN page that says what the API itself is?

I'm looking again at a page that you cited.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/dllprocessthreads.asp
In that page, I do not see any statement about whether it (or other pages) contains instructions for VC++6 programmers or descriptions of the APIs themselves. You said that this page was the way that you knew some of the information you wrote, but I don't see it on this page. So I'm afraid my hand still needs holding.

Thank you for your descriptions of internal behaviour of some parts of Windows. Indeed I am not opposed to learning about such things and I don't have any complaint about that. However, I am opposed to writing programs that depend on such undocumented internal behaviour. Such a program might work this morning and fail this afternoon because undocumented behaviour is subject to change at any time. Some famous Microsoft employees hate companies that depend on undocumented behaviour, and in this kind of situation I agree.


"m" <m@xxx> wrote in message news:u84U6tnJGHA.1192@xxxxxxxxxxxxxxxxxxxxxxx 
At the top of page #1 it says:

'Visual C++ Concepts: Adding Functionality'



At the top of page #2 it says:

'Platform SDK: DLLs, Processes, and Threads'



Page #1 is part of the documentation for Visual Studio .NET - this is
included to help people use VS.NET and is geared toward Win32 development.



Page #2 is part of the actual Win32 API documentation.  This is the page
that documents the actual API.



Now you may ask, "how do you know this?".  I respond: I know this because
on the page

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/dllprocessthreads.asp

it tells me that the platform SDK contains this type of documentation.
MSDN is NOT a single API ref for windows, it is a library with lots of
stuff - most of it junk - that includes the API references for windows.
if you want, you can even look in the archives for lot of old junk.



BTW: always use WINAPI, APIENTRY will work (it is __stdcall), but it is
the wrong macro



The actual PE entry point prototype (which you can find in MSDN too - look
for PE) is:



int __stdcall Entry(void* var1, DWORD var2, void* var3)



This is usually implemented by the CRT as WinMainCRTStartup,
mainCRTStartup, or DllMainCRTStartup (you can see this in crt0.c and
crtdll.c if you installed the CRT source with VS.NET)



The CRT initializes itself and then calls your entry point.





"Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx> wrote in message
news:%23cRz9dgJGHA.1192@xxxxxxxxxxxxxxxxxxxxxxx

"m", I GAVE YOU TWO (2) URLS TO HELP.
I QUOTED FROM BOTH OF THEM.

But yes, if you know how to determine that one of those MSDN pages is
right
while the other one is wrong, then yes I do need your fu**ing hand to
point
me to where MSDN says which of its pages is wrong.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_Initialize_Non.2d.MFC_DLLs.asp
says:

BOOL APIENTRY DllMain(
  HANDLE hModule,
  DWORD ul_reason_for_call,
  LPVOID lpReserved)


http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dllmain.asp
says:

BOOL WINAPI DllMain(
  HINSTANCE hinstDLL,
  DWORD fdwReason,
  LPVOID lpvReserved)


"m", you wrote "Rest assured: HANDLE is NOT equivalent to HINSTANCE."
Excellent, thank you, now you know why I posted my question.  Now RTFM
and
lend a hand.


"m" <m@xxx> wrote in message
news:u3x92QgJGHA.1388@xxxxxxxxxxxxxxxxxxxxxxx

If you need a URL to help:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winprog/winprog/windows_data_types.asp

"m" <m@xxx> wrote in message
news:%23NfbCNgJGHA.2704@xxxxxxxxxxxxxxxxxxxxxxx

Should I hold your hand?



1) go to http://msdn.microsoft.com

2) in the search box type 'DLLMain'

3) click the first link

4) copy the prototype

BOOL WINAPI DllMain(

 HINSTANCE hinstDLL,

 DWORD fdwReason,

 LPVOID lpvReserved

);



Rest assured: HANDLE is NOT equivalent to HINSTANCE.  HISNSTANCE IS
equivalent to HMODULE - this IS documented in MSDN

"Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx> wrote in message
news:euKUyzfJGHA.2864@xxxxxxxxxxxxxxxxxxxxxxx>I am looking at the
definition of the DECLARE_HANDLE macro in file Winnt.h

in the Platform SDK from year 2003.  It does not tell me the
definition
of HINSTANCE.  In fact the entire file does not tell me the definition
of HINSTANCE.  However, if the STRICT macro is defined then the
Platform
SDK makes a half-hearted effort to catch programs that accidentally
interchange different kinds of handles.  So I think HANDLE and
HINSTANCE
are intended to be not interchangeable.

I am looking again at the definition of the DECLARE_HANDLE macro in
file
Winnt.h in the Platform SDK from year 2003.  It does not tell me if a
service pack will change the definition tomorrow.  It does not tell me
where to find a statement in MSDN to say "Don't read MSDN, read the
source code to see what definitions you should rely on when you write
programs (or DLLs)."

Some very famous Microsoft employees hate programmers relying on
undocumented behaviour.  I think they might hate programmers violating
documented behaviour too.  Well in this case, no matter how I define
dllmain, my definition will violate at least one of these two MSDN
pages.

Now, is one of these pages correct?  If so, which one?  If not, then
what is the correct calling sequence for dllmain?

"Arkady Frenkel" <arkadyf@xxxxxxxxxxxxxxxx> wrote in message
news:ONPaefZJGHA.1032@xxxxxxxxxxxxxxxxxxxxxxx

Look windef.h and at definition of DECLARE_HANDLE macro in Winnt.h
Arkady


"Norman Diamond" <ndiamond@xxxxxxxxxxxxxxxx> wrote in message
news:eiM$rcYJGHA.528@xxxxxxxxxxxxxxxxxxxxxxx

Are types HANDLE and HINSTANCE guaranteed to be interchangeable?
If yes, where?  (Other than logical inference from the following
^_^)
If not, which of the following is correct?

While we're at it, are APIENTRY and WINAPI guaranteed to be equally
"noisy"?

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/_core_Initialize_Non.2d.MFC_DLLs.asp
says:

BOOL APIENTRY DllMain(
  HANDLE hModule,
  DWORD ul_reason_for_call,
  LPVOID lpReserved)


http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dllmain.asp
says:

BOOL WINAPI DllMain(
  HINSTANCE hinstDLL,
  DWORD fdwReason,
  LPVOID lpvReserved)













.

Relevant Pages

  • Re: NullPointerException
    ... > programmers do make that assumption. ... I told them how they can prevent NullPointerExceptions. ... > public boolean hasAddress() ... It was returned from some API. ...
    (comp.lang.java.programmer)
  • Re: Asynchronous Programming Patterns and Techniques - No Concensus?
    ... Recommendations usually come with explanation. ... I would definitely agree that there are numerous examples in MSDN of recommended practices that don't do a good job of justifying those practices. ... If you must expose both the event-based pattern and IAsyncResult pattern on a single calss, use the EditorBrowsableAttribute set to Advanced to mark the IAsyncResult pattern implementation as an advanced feature... ... That line of thinking would support an argument that the IAsyncResult model is actually better, because it imposes a slightly higher barrier, which should hopefully reduce the number of unqualified programmers attempting to use it. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: DllMain vs. DllMain
    ... It does not, except by coincidence, document any of the Win32 API. ... >> BOOL WINAPI DllMain( ... is a user of VC++6 supposed to obey the MSDN page that tells VC++6 ... Use the documentation for the API. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Transaction Oriented Architecture (TOA)
    ... Given embedded SQL mapping an account /thing/ to the DB as: ... then the SQL is dependent on: an account table/view, its columns, and the explicit reference to accountKey. ... Procedure names and their arguments should be considered as an API to the DB's solution domain. ... this kind of interface is common among object oriented languages and isn't a foreign concept to OO programmers. ...
    (comp.object)
  • Re: Shortage of qualified Java programmers
    ... library of Java is what you have computers for -- not people. ... every detail of the API. ... to figure out how a Comparator works given the Javadocs. ... programmers written by Bill Venners. ...
    (comp.lang.java.programmer)