#148 NTEventLogAppender calls virtual open() from constructor

[Jac Goudsmit]

I would like to make a class derived from NTEventLogAppender that initializes the registry keys with a full path to the NTEventLogAppender.dll so I don't have to copy that file into a directory on the path.

The most obvious way to do this would be to override the NTEventLogAppender::open( ) function. The function is virtual so overriding is possible. The problem is that the open( ) function is called from the constructor.

In C++, when a constructor calls a virtual function, it always calls the implementation of that function in its own class, even if a derived class calls that constructor. See e.g. https://stackoverflow.com/questions/962132/calling-virtual-functions-inside-constructors

The NTEventLogAppender could provide a protected constructor that doesn't call open( ). That way, a subclass can call that constructor and can call either its own version of open( ) or the NTEventLogAppender version of open( ). But obviously this is not the best solution because open( ) really does need to be called at construction time because Appenders are expected to be ready for appending as soon as they are constructed...

[Alexander Perepelkin]

Hi Jac,

I agree that calling virt func from ctr there is not good idea.
It could be changed I think.
I am not sure I have got your reason regarding the path although.
Would you possibly explain your intention with a pull request or patch or somehow else please?

Thanks,
Alex.

[Jac Goudsmit]

The existing code stores the string "NTEventLogAppender.dll" into the HKLM\System\CurrentControlSet\Services\eventlog\CategoryMessageFile and ...EventMessageFile. Because the directory of NTEventLogAppender.dll isn't stored, it's necessary to manually copy the NTEventLogAppender.dll file to a directory that's in the %path%, or to manually add the location of that DLL to the %path% system variable.

If the NTEventLogAppender class would store the full path to NTEventLogAppender.dll into the registry, it would be unnecessary to ask the user to move the DLL into the %path%, or modify the %path% to add the location of the DLL.

I think I have a solution that's better than what I proposed in my first comment. I'll try to do some work on this in the next few days and I'll post a pull request.

I also want to propose some other changes to improve the Visual Studio build (for example: generating the NTEventLogAppender.dll in several projects causes a race condition when building all projects); I'll post a pull request for those changes as well.

[Jac Goudsmit]

Hi Alex. I just submitted a merge request for my changes to fix this problem and a few more that I found with NTEventLogAppender along the way. I tried as hard as possible to make them easy to understand, which made it necessary to split up the change into several commits.

Next, I will put some work into fixing a few problems with the Visual Studio 2010 build.