You need a flag? Why not create a file for that!
-
It's a documentation rather than a coding horror, but to good to let it pass. Either I'm seriously missing something, or MSDN has gone really bonkers. msdn:DllMain[^] writes: There are serious limits on what you can do in a DLL entry point. To provide more complex initialization, create an initialization routine for the DLL. You can require applications to call the initialization routine before calling any other routines in the DLL. So far so good, so true. But now, what does MSDN recommend to make that initialization automatic? Alternatively, the initialization routine can create a file with an ACL that restricts access, and each routine in the DLL would call the initialization routine if the file does not exist. :wtf: If complex per-process initialization is required, use a "private" global flag. If cross-process initialization is required (that's what would be closest to creating a file...), use a flag in a shared data segment.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!| FoldWithUs! | sighistmodified on Tuesday, December 25, 2007 4:00:09 PM
-
It's a documentation rather than a coding horror, but to good to let it pass. Either I'm seriously missing something, or MSDN has gone really bonkers. msdn:DllMain[^] writes: There are serious limits on what you can do in a DLL entry point. To provide more complex initialization, create an initialization routine for the DLL. You can require applications to call the initialization routine before calling any other routines in the DLL. So far so good, so true. But now, what does MSDN recommend to make that initialization automatic? Alternatively, the initialization routine can create a file with an ACL that restricts access, and each routine in the DLL would call the initialization routine if the file does not exist. :wtf: If complex per-process initialization is required, use a "private" global flag. If cross-process initialization is required (that's what would be closest to creating a file...), use a flag in a shared data segment.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!| FoldWithUs! | sighistmodified on Tuesday, December 25, 2007 4:00:09 PM
:eek: I am not sure about that.
"Real programmers just throw a bunch of 1s and 0s at the computer to see what sticks" - Pete O'Hanlon
-
It's a documentation rather than a coding horror, but to good to let it pass. Either I'm seriously missing something, or MSDN has gone really bonkers. msdn:DllMain[^] writes: There are serious limits on what you can do in a DLL entry point. To provide more complex initialization, create an initialization routine for the DLL. You can require applications to call the initialization routine before calling any other routines in the DLL. So far so good, so true. But now, what does MSDN recommend to make that initialization automatic? Alternatively, the initialization routine can create a file with an ACL that restricts access, and each routine in the DLL would call the initialization routine if the file does not exist. :wtf: If complex per-process initialization is required, use a "private" global flag. If cross-process initialization is required (that's what would be closest to creating a file...), use a flag in a shared data segment.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!| FoldWithUs! | sighistmodified on Tuesday, December 25, 2007 4:00:09 PM
I agree whole-heartedly with their solution.
peterchen wrote:
If complex per-process initialization is required, use a "private" global flag
...You mention "complex" and then "private global flag" in the same sentence?? To me..."complex" would imply...well.....complex. And "private global flag" would imply....well....an improper implementation for a "complex" solution A "private global flag" (regardless of the fact that declaration of anything with global scope is incorrect) would create an incredibly fragile, convoluted solution. Creating an access list (along with the other MSDN suggestions) would be extensible and compartmentalized.
"I need build Skynet. Plz send code"
modified on Thursday, January 03, 2008 10:04:15 AM
-
I agree whole-heartedly with their solution.
peterchen wrote:
If complex per-process initialization is required, use a "private" global flag
...You mention "complex" and then "private global flag" in the same sentence?? To me..."complex" would imply...well.....complex. And "private global flag" would imply....well....an improper implementation for a "complex" solution A "private global flag" (regardless of the fact that declaration of anything with global scope is incorrect) would create an incredibly fragile, convoluted solution. Creating an access list (along with the other MSDN suggestions) would be extensible and compartmentalized.
"I need build Skynet. Plz send code"
modified on Thursday, January 03, 2008 10:04:15 AM
-
I agree whole-heartedly with their solution.
peterchen wrote:
If complex per-process initialization is required, use a "private" global flag
...You mention "complex" and then "private global flag" in the same sentence?? To me..."complex" would imply...well.....complex. And "private global flag" would imply....well....an improper implementation for a "complex" solution A "private global flag" (regardless of the fact that declaration of anything with global scope is incorrect) would create an incredibly fragile, convoluted solution. Creating an access list (along with the other MSDN suggestions) would be extensible and compartmentalized.
"I need build Skynet. Plz send code"
modified on Thursday, January 03, 2008 10:04:15 AM
"complex", in the context of above post, meaning "anything you may not do in DLL Main" (such as loading other DLLs). How would creating an "access list" make the decision when to run some initialization "extensible and compartmentalized"? Please provide a sample.
Alaric_ wrote:
And "private global flag" would imply....well....an improper implementation for a "complex" solution
The initialization may be complex, but the decision where to call it may be very simple.
Alaric_ wrote:
declaration of anything with global scope is incorrect
If you said "questionable", I could follow you - while still arguing that it depends on the scenarion. But with such a blatant statement... do you know what "global" means? In what way would a file be "more" or "less" global than a variable in a private data segment? Can you argue for your point? the gist of it: global flag not always bad.
We are a big screwed up dysfunctional psychotic happy family - some more screwed up, others more happy, but everybody's psychotic joint venture definition of CP
My first real C# project | Linkify!| FoldWithUs! | sighist