[Mono-dev] local file based EventLog implementation

[Robert Jordan]

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