[Mono-dev] local file based EventLog implementation

[Gert Driesen]

> -----Original Message-----
> From: mono-devel-list-bounces at lists.ximian.com [mailto:mono-devel-list-
> bounces at lists.ximian.com] On Behalf Of Kornél Pál
> Sent: zondag 20 augustus 2006 19:01
> To: Gert Driesen; 'Robert Jordan'; mono-devel-list at lists.ximian.com
> Subject: Re: [Mono-dev] local file based EventLog implementation
> 
> >> > b) adding EventLogMessages.dll to the binary distributions (for
> >> win32,
> >> > and linux too)
> >> >
> >> > If we do not get approval for (b) (not sure why, but could be
> >> > ofcourse), then we could still embed the dll into the System
> >> > assembly
> > > and extract it at runtime (if it doesn't exist yet).  But I'd
> rather
> >> avoid this.
> >>
> >> The Debian folks usually don't accept binaries. I wish you good luck
> >> to explain them the difference between a managed DLL, an unmanaged
> >> DLL and an unmanaged DLL consisting of just one PE resource :-)
> >
> >I think it would indeed be better to either build it at compile time,
> >or if is too difficult to achieve (especially on linux) that we can
> >always embed it. Or as a (very) last resort, do not register one for
> >event sources created from Mono.
> 
> Mono is only "copied" by Debian folks so I think we don't have to
> explain them anything.:) Along with EventLogMessages.dll I posted a
> batch file that builds EventLogMessages.dll. I think that there are
> open scource build tools that can do the same so building is not a big
> deal but those tools are not likely to be installed on non-Windows
> operating systems. If you are really freaking binaries it's quite easy
> to write a managed exeutable that will generate it.:) But as this is
> not a code module you should think of it more like a .png image than a
> .dll library. Or if you prefer it even can be a managed assembly that
> has the appropriate unmanaged resources but that way it will become a
> file containing code as well.

I'd prefer the "pure" approach, meaning using your original
EventLogMessages.dll. 

But we need approval from Miguel on this.

> >> > In what form should EventLogMessage.dll added to svn (and the
> >> > source
> >> > distributions) ? Can we juist include it as is, or do we need to
> >> build
> >> > it at compile time ?
> >>
> >> Please excuse my ignorance, but why on earth do we need
> >> EventLogMessage.dll with its PE resources under Unix?
> >
> >It's definitely not needed, but Kornél proposed to use it on unix too.
> >IT would be nice to have, but not necessary.
> >
> >On Windows, I think we should definitely use it. But there it's also
> >not strictly necessary (but more than one unix).
> 
> For Windows: Windows event log requires a message DLL. If you can
> provide a simple test case (that calls Windows API directly) that show
> that no message DLL is required I believe you otherwise I cannot
> because all my experiences and even Platfrom SDK documentation is clear
> that the messages are read from a DLL.
> If I don't set (or delte)
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\Applicati
> on\<source>\EventMessageFile
> I get the following error message in Event Viewer:
> The description for Event ID (...) in Source (...) cannot be found. The
> local computer may not have the necessary registry information or
> message DLL files to display messages from a remote computer. You may
> be able to use the /AUXSOURCE= flag to retrieve this description; see
> Help and Support for details. The following information is part of the
> event: ...

Indeed, this matches the behavior I see and suspected. Which means that an
EventLogMessages.dll is not strictly necessary to write event entries, but
ofcourse I'd like to ship one with Mono too !

> So strictly speaking it works (because the function calls succeed) but
> as you can see you will see no message when you use no message DLL.

You do get the message, it's where you dots are ;-)

> So I think message DLL dependency can hardly be named not strictly
> necessary because the message is an esential part of an event log
> entry.

I definitely agree with you that we need it to do the right thing. It's just
not necessary to write events, only to read them.

> For Unix (and others):
> Because you are going (or already done) to implement message DLL
> handling on Unix (according to your previous messages using registry)
> as well I think it's quite obvious to use EventLogMessage.dll as well.
> If it's OK for you to use registry on Unix I don't see any reason not
> to use EventLogMessage.dll as well because message DLL can be read and
> written using registry methods and the no message DLL situation should
> have the same result as on Windows.

Miguel has decided against using the registry on linux, but that doesn't
mean that we cannot use EventLogMessages.dll on unix.

> >> I understand why it's needed for Win32 and even why
> >> Win32 demands it (performance and log file size optimization), but
> >> since MS.NET installs EventLogMessage.dll, no one will ever use
> >> resource DLLs with .NET, IMO. No one wants to deal with MC and RC
> >> just for eventlogging's sake.
> >
> >In .NET 2.0, MS provided better support for using message resource
> >dll's, so I'm pretty sure its usage will pick up.
> >
> >Reading event entries created by event sources that use a message
> >resource has already been implemented (for the win32 implementation).
> 
> If you want to implement message DLL support on non-Windows operating
> systems you should use PE files as well because otherwise it will be
> incompatible with MS.NET for no reason. Managed modules are PE files so
> they can containt PE resources and it somebody uses it's own executable
> or some bundled DLL as messages, event logging will simply not work on
> non-Windows operating systems for no reason, because it contains no
> native code.

Compatibility is the reason why I started on this implementation, so I'm
completely with you on this.

> As for EventLogMessage.dll: We don't need it. But we need a PE file
> with the same message resources. And I think it's quite easy to use the
> same file name and it improves compatibility as well so I don't see any
> reason to put these resource to System.dll for example instead.
> 
> Gert: If you send me your latest patch I'll have a look at it.

It's committed in svn (after approval from Miguel). The win32 implementation
is feature complete.

The only thing missing is that we currently do not register an
EventLogMessages.dll (as we do not ship with one).

Let me know if you want me to send a patch to you anyway.

Gert