Wt

Because I couldn't think of an easy way to make it work. Now it's nice and clean: you get one DLL and that's your Wt ISAPI plugin. Otherwise, you must configure the connector DLL to load another DLL (the application?) which must be able to make callbacks to the connector DLL that loaded it. I'm open to listen to suggestions, though.

Any special reason why you'd like to build with SHARED_LIBS set?

BR,

Wim.

Because my application is divided into separate DLL modules (plugins), and access to the singleton (such as WApplication ::instance()) is not possible.

Maybe should leave the implementation of functions HttpExtensionProc, GetExtensionVersion, TerminateExtension on the conscience of the application developer and to make classes of the ISAPI connector as dllexport / dllimport?

So in that case:

- entry point is HttpGetExtensionVersion(), which takes the role of main() in normal applications.

- HttpGetExtensionVersion() starts a thread that calls WRun (since WRun has the semantics to block until the server is stopped), or instantiates a WServer object, both of which are located in wtisapi.dll

- The function pointer to createApplication is passed to WRun or WServer as in the usual case

- DLL that contains createApplication links to wt.dll, wtext.dll, dbo, ...

• the isapi connector also links to wt.dll

To do this, the code in isapi/Isapi.C and isapi/Server.C has to be rearranged a little.

I didn't go for this approach because it is then no longer possible to compile the examples out of the box, since those expect that their main() will be called. But indeed, if you're willing to give this up, we could add a compilation mode that behaves this way. Alternatively, we could also write an Isapi.C that works with the examples and include that file during the compilation of the examples.

(note that WApplication::instance() is stored in thread local storage, but I don't know how that behaves across DLL boundaries)

BR,

Wim.