[Mono-dev] local file based EventLog implementation

Atsushi Eno 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".

Atsushi Eno

Robert Jordan wrote:
> Hello,
> Miguel de Icaza wrote:
>>> I'd prefer the "pure" approach, meaning using your original
>>> EventLogMessages.dll. 
>>> 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.
> Robert
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list

More information about the Mono-devel-list mailing list