[Mono-dev] local file based EventLog implementation

Kornél Pál kornelpal at gmail.com
Thu Aug 17 15:14:44 EDT 2006


Hi,

>I do intend to support this for win32 using your supplied
>EventLogMessages.dll by default, and third-party message resource dll's 
>when
>these are registered.
>
>I just wondered whether there's a something similar to these message
>resource dll's for unix. With this we could also support lookup of messages
>from a resource file, and perform placeholder replacement on unix. This
>would allow localization of eventlog messages, like we have on windows (if
>third parties provide localized message resource dll's for their eventlog
>sources).
>
>We could ofcourse use managed resource assemblies for this purpose on unix.

> You can't use Windows API on Unix but you were talking about all the
> time.
> Everything I said is about the Windows API.

No message DLL can be registered using the class library so there is no need 
to message DLL support on non-Windows operating systems. If you want such 
support you have to implement it using registry and provide some compatible 
support but I don't think that it makes much sense.

>> A EventLogMessages.dll is required if you want to use the Windows API.
>It is not strictly required, but it would be better if we indeed use it.

On Windows it is required. OK, it can have any name but Windows API requires 
a message DLL and no message DLL can be specified using managed API so this 
is transparent to managed applications.

The purpose of a message DLL is probably to support multi-lingual user 
interface and/or to save disk space. But the managed event logging API has 
no support for this because it requires a message text rather than a message 
DLL and a message ID. Event ID is stored but does not affects the message 
used.

If you want strict Windows-like logging using registry then you may want to 
consider using the same .evt file format that is used by Windows. (But I 
think a correct implementation of the managed API don't has to be Windows 
compatible as well.)

Kornél 




More information about the Mono-devel-list mailing list