[BUG] TC calls plugin functions before DLLMain returned

[m^2]

As written in the title. I think this shouldn't happen..

[gigaman]

How could it do that? I mean, if DLLMain of a plugin hasn't returned yet, the corresponding LoadLibrary call hasn't returned as well - so TC doesn't have a handle for the library yet, so it can't GetProcAddress it and call its exported function...
Even if you meant thread attaching, I can't imagine a way... so, do you have any more information about your problem?

[m^2]

I have logs with calls to ContentGetSupportedField and ContentGetValue before DLLMain finished it's job.

[Valentino]

Maybe logger itself isn't thread safe, I mean maybe it can intermix log entries?

[ghisler(Author)]

Sorry, I have no idea how this could happen. TC calls LoadLibrary and then GetProcAddress for all the functions. Then it calls ContentSetDefaultParams (if present) and then any other functions.

What does your plugin do in DLLMain?

[m^2]

There was a MessageBox, so passing DllMain took really long. I'll make more tests tomorrow.
I use multithreaded IO library, but I doubt it writes something in wrong order (msvcrt.dll).

[m^2]

Unfortunately I can't reproduce it with any simple example.
ADD:
2 Ghisler:
If you find it important (or maybe interesting), I can send you my sources.

[ghisler(Author)]

What exactly are you calling in DLLMain? For example, you should not call LoadLibrary there in any case!

From MSDN:

The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code. Similarly, the entry-point function must not call the FreeLibrary function (or a function that calls FreeLibrary) during process termination, because this can result in a DLL being used after the system has executed its termination code.

You can find a list of what you should/should not do here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/base/dllmain.asp

So if you need to load any DLLs, please do it in the ContentGetSupportedField and ContentGetValue functions.

Just set a variable "DllLoaded" to false in DLLMain when it is called with DLL_PROCESS_ATTACH, and then load your dlls on the first call to ContentGetSupportedField or ContentGetValue.

If you find it important (or maybe interesting), I can send you my sources.

Yes, maybe I can find ou what is going wrong.

[Lefteous]

So if you need to load any DLLs, please do it in the ContentGetSupportedField and ContentGetValue functions.

The best place to call initialization stuff is ContentSetDefaultParams - don't you agree?

[ghisler(Author)]

No I don't. This is during loading of the DLL. Loading should be as fast as possible. Slowly loading DLLs should only be loaded when needed, which would be on the first call to an actual dll function. Sometimes they don't even need to be called on ContentGetSupportedField (the plugin may already know what it supports), only on ContentGetValue. This way, such additional dlls wouldn't be loaded e.g. in the multi-rename tool when opening the entire list of plugins...

[Lefteous]

Well I used the suggested mechanism once in one of my plug-ins but recieved mainly complaints from 3rd party tool creators...

Beside that I'm not aware of case where TC loads the library without calling ContentGetSupportedFields.

In all other cases you are of course right but I guess these cases are quite rare.

[m^2]

I had all my initialization (almost 400 lines, many Windows API calls) in DllMain .
I moved it to separate function, and it seems that my problem disappeared.
Thank you!

[tbeu]

For example, you should not call LoadLibrary in DLLMain in any case!

Would be helpful to read this statement in the plugin interface documentations. I was not aware of this coding policy.

[m^2]

There are too many thing like this.
It's not bad to assume that plugin writers know how to do their job.
I think that "How to write a plugin" guide would be suitable place for it...if it existed.

[ghisler(Author)]

Would be helpful to read this statement in the plugin interface documentations. I was not aware of this coding policy.

This isn't a problem with Total Commander, it's a general Windows problem with DLLs.