[Mono-dev] local file based EventLog implementation
robertj at gmx.net
Mon Aug 21 08:02:09 EDT 2006
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.
More information about the Mono-devel-list