Name Date Size #Lines LOC

..22-May-2021-

README.txtH A D22-May-2021972 2016

bridge_exports.mapH A D22-May-20211 KiB2928

cli_base.hH A D22-May-20217.6 KiB177130

cli_bridge.cxxH A D22-May-202112 KiB366271

cli_bridge.hH A D22-May-20213.8 KiB11760

cli_data.cxxH A D22-May-202180 KiB2,0081,797

cli_environment.cxxH A D22-May-20214.9 KiB170124

cli_environment.hH A D22-May-20213.6 KiB11140

cli_proxy.cxxH A D22-May-202143.4 KiB1,175981

cli_proxy.hH A D22-May-202111.5 KiB296133

cli_uno.cxxH A D22-May-20219.4 KiB287213

makefile.mkH A D22-May-20212.4 KiB9243

README.txt

1Because of the LoaderLock bug in .NET Framework 1.0 and 1.1 the cli_uno.dll is linked
2with the /NOENTRY switch, which prevent that the C-runtime is initialized when loading
3the dll.
4
5Also I removed all static c++ objects which need construction by the CRT,
6exception handling seems to need an initialised CRT. Therefore
7I added CRT initialization code in  uno_initEnvironment (cli_bridge.cxx)
8However there is no deinitialization done because bridge libraries remain
9in memory until the process dies. There is actually no good place where
10this had to be called. If we would do that we would have to implement that
11the bridge can be disposed.
12
13
14Sell also:
15
16http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vcconmixeddllloadingproblem.asp
17http://support.microsoft.com/?id=814472
18http://www.ddj.com/dept/windows/184416689
19http://blogs.msdn.com/cbrumme/archive/2003/08/20/51504.aspx
20http://msdn2.microsoft.com/en-US/library/ms172219.aspx