[Mono-dev] local file based EventLog implementation
atsushi at ximian.com
Mon Aug 21 11:34:59 EDT 2006
What is more important to know is that this extra dll is "required"
only for Win32 mode of the implementation.
If I wrote about it, I'd have never said it is "required".
Robert Jordan wrote:
> Miguel de Icaza wrote:
>>> I'd prefer the "pure" approach, meaning using your original
>>> But we need approval from Miguel on this.
>> Someone please send me a summary ;-)
>> My feeling: I dont know why we need another dll.
> 1) The Win32-EventLog doesn't log strings. For performance
> reasons it logs the resource IDs of strings stored as
> a PE text resource in a PE-DLL that has to be registered
> with the EventLog services.
> The strings may contain substitution symbols (%1, %2 ...),
> since EventLog's API supports parameter substitution.
> 2) Because (1) is not very comprehensible for MS.NET users,
> MS came up with a brilliant idea to register a dummy
> DLL (EventLogMessages.dll) consisting of resource strings
> with a parameter substitution symbol: "%1".
> 3) MS.NET's EventLog class logs the resource ID of the
> "%1" together with the real message as an argument,
> simulating the ability to log plain text strings.
> 4) Mono's EventLog implementation for Win32 needs the same hack,
> if its implementation is based on the Win32 EventLog API
> (it is already).
> 5) Mono's EventLog implementation for Unix doesn't need
> EventLogMessages.dll, because Unix doesn't have an
> EventLog with the same restrictions like the Win32-EventLog.
> 6) MS.NET 2.0 supports registration of resource DLLs and
> logging by ID.
> If Mono's EventLog implementation for Unix will support
> this features, providing EventLogMessages.dll makes sense
> again, because Mono's internal EventLog is almost Win32
> compatible and already supports those resource DLLs.
> -- end of summary --
> The question is whether (6) will be feature-complete.
> The tool-chain (MC, RC) for creating such DLLs usually doesn't
> exist on Unix, so probably no one is willing to use this API,
> but it could useful for porting existing 2.0 apps.
> The problem I see is: for the sake of 100% API compatibility
> the full Win32-EventLog has to be simulated on Unix, and,
> because it comes in handy, even the internals of Win32-EventLog
> are simulated (the registry configuration). Not to speak about
> the need of a viewer for this logs, because otherwise the entries
> were unreadable. All this for a small range of applications
> that use custom message DLLs.
> I don't like this, but of course I fully respect the work
> already done! I'd rather blame MS because its 2.0 EventLog
> implementation became even more Win32-centric.
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
More information about the Mono-devel-list