[Mono-dev] local file based EventLog implementation

[Gert Driesen]

----- Original Message ----- 
From: "Robert Jordan" <robertj at gmx.net>
To: <mono-devel-list at lists.ximian.com>
Sent: Monday, August 21, 2006 2:02 PM
Subject: Re: [Mono-dev] local file based EventLog implementation


> 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.

Not sure we need a message compiler (mc), other open-source projects (eg. 
log4j) also include the .rc and bin files in the source repository.

To complile the rc file, we could use windres (no?).

> 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).

We could use a small (XML) file to store this information for each event 
source (instead of using the unix registry API). Shouldn't take too long.

Our unix eventlog implementation already is API compatible. If you forget 
about the message resource stuff and access to remote eventlogs,  it is even 
feature complete.

It would be great if Kornél (or anyone else) would want to add support for 
reading strings from a PE messagetable (for unix), but it is not strictly 
required on unix. I'd still very much like it, ofcourse.

> 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've already written a small SWF viewer for the eventlog (which still needs 
a lot of love). The eventlog API is very simple, it shouldn't take more than 
a few days to have a great event viewer that also supports event source 
creation & deletion.

> 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.

I don't think the 2.0 implementation is more win32-centric. It just exposes 
more functionality of the win32 eventlog.

To ensure interoperability (with .NET and native win32 applications) we 
should indeed use a PE dll on Windows, but we could still implement it in a 
non-win32 specific way for unix (using, for example, managed resource 
assemblies). But that would make the resource dlls non-interoperable between 
Mono/Unix and Windows.

Gert