[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