This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: event logging -- cron


BB,

The reason I'm opposed to the use of mc.exe is that one should be able to
re-build Cygwin using Cygwin tools only, and introducing a dependence on a
Microsoft tool will go contrary to that goal.

As for using a .rc file to define a struct, why not simply create a .c
with an exported variable?  I may be missing something here, but the
simpler the code, the easier it'll be to build and understand.  I'm
guessing the .bin file you provided earlier is the same as the data
section of a similar .o file would be, correct?  Something like the
following:
----------CUT----------
#include <windows.h>
struct {
	MESSAGE_RESOURCE_DATA data;
	/* Note: _ENTRY should be the same as MESSAGE_RESOURCE_ENTRY */
	/* in winnt.h except for the Text size */
	struct _ENTRY {
		WORD Length;
		WORD Flags;
		BYTE Text[8];
	} entry;
} msg_tbl =
{
  {1, {0, 0, sizeof(MESSAGE_RESOURCE_DATA)}},
  {sizeof(struct _ENTRY), 0, "%1\r\n\0\0\0\0"}
};
----------CUT----------
Of course, there's then a need for the .rc file to refer to the .o, but
I'm sure it could be done...

There have been various aborted attempts at this in the past.  I wonder if
this time we would be able to finally beat this into an acceptable shape
and get it into Cygwin...
	Igor

On Wed, 9 Apr 2003, BB wrote:

> Igor,
>
> I don't think mc.exe can output the .bin file as human readable data in the
> rc file.  Even if it could, the data contains offsets so it might be
> difficult to edit manally.  I have a good handle on the format of the data,
> so if I knew exactly what subset of the .mc file needed to be supported, I
> could write something that would generate a  human readable .rc file based
> on an input file.  Duplicating the functionality of mc wouldn't be too
> difficult, but I don't think I would want to do that.   If the Cygwins
> syslog() implementation will not change, the attached rc file should be
> sufficient.
>
> Attached is an updated tar file with a human readable .rc file. It contains
> the 1 message required to support messages as currently generated by
> syslog().
>
> BB
>
>
> "Igor Pechtchanski" <pechtcha at cs dot nyu dot edu> wrote in message
> news:Pine dot GSO dot 4 dot 44 dot 0304091456130 dot 8179-100000 at slinky dot cs dot nyu dot edu dot  dot  dot 
> > BB,
> >
> > Thanks for providing this example.  Is there a way to instruct "mc" to
> > produce a human-readable syslogmsg.rc instead of the .bin file and the
> > wrapper .rc file?  If so, could you please provide an example of such
> > a .rc file?  It would then be possible to edit the .rc file by hand,
> > and there would be no need for having "mc" installed.
> > Igor
> > P.S. FYI, "mc" is also the name of the Midnight Commander binary, so you
> > might wish to provide a full path to "mc" in your makefile and have people
> > change that...
> > P.P.S. I know it's a minor nit, but it would probably be a good idea to
> > use "Makefile" instead of "makefile" - IMO, more aesthetically pleasing.
> >
> > On Wed, 9 Apr 2003, it was written:
> >
> > > I tackled this one a while back...
> > >
> > > Attached is a tar file syslogmsg.tar containing a message dll and
> > > the files needed to create it.  It defines 1 message with id 0.
> > > The message has 1 substitution string, so the strings passed to
> > > ReportEvent by syslog() are output as is.  This message dll handles
> > > the messages currently output by cygwin.
> > >
> > > ****
> > > To quickly use the dll, copy the dll to c:\cygwin and apply the .reg
> > > file. Or delete the dll and res file and rebuild it.  The .reg file
> > > only has a few entries in it for inetd, init, cron and login.  Add
> > > more entries for other programs. You need the microsoft message
> > > compiler mc.exe to create syslogmsg.rc and MSG0000.bin, so don't
> > > delete them if you don't have it.
> > > ****
> > >
> > > There needs to be a registry entry for every program that calls
> > > syslog (init, inetd, etc.) because the program name is used as the
> > > event source. There is a .reg file with example entries.  The reg
> > > file assumes the file syslogmsg.dll is in c:\cygwin
> > >
> > > Perhaps a better solution would be to have the message souce always
> > > be "Cygwin" and the category specific to the application.  I have
> > > added two categories to the file syslogmsg.mc to show how this is
> > > done.  The call to ReportEvent would then need to specify the
> > > correct id for the category string.  So using the syslogmsg.mc file
> > > in the tar file, for inetd, category 0x1000 would need to be
> > > specified.  The problem is that syslog doesn't have way to know the
> > > correct category.  Using categories would require only one message
> > > dll registry entry for Cygwin instead of one for every program
> > > calling syslog.
> > >
> > > It really depends how important seeing the program name in the
> > > 'source' column is.  The messages themselves contain the program
> > > name, so maybe seeing Source=Cygwin Category=None wouldnt be a
> > > problem.
> > >
> > > BB
> > >
> > > "Igor Pechtchanski" <pechtcha at cs dot nyu dot edu> wrote in message
> > > news:Pine dot GSO dot 4 dot 44 dot 0304081911380 dot 21921-100000 at slinky dot cs dot nyu dot edu dot  dot  dot 
> > > > On Tue, 8 Apr 2003, Andrew DeFaria wrote:
> > > >
> > > > > Igor Pechtchanski wrote:
> > > > >
> > > > > > For all those interested: <http://cygwin.com/contrib.html>
> > > > > > contains complete instructions on how to submit patches. To
> > > > > > summarize: a) use "diff -up"; b) include a ChangeLog; c) use
> > > > > > the <cygwin-patches at cygwin dot com> list.
> > > > > >
> > > > > > As for your specific suggestion, Andrew, you'll also need to
> > > > > > provide the resource with the specific code, so that event
> > > > > > viewer is able to decipher it.
> > > > >
> > > > > The reference you provided to MS's site didn't exactly describe
> > > > > what a "resource" is, how you define/create it and how you use
> > > > > it. I believe the parameter we are talking about is dwEventID
> > > > > which MS defines as:
> > > > >
> > > > > dwEventID
> > > > >     [in] Event identifier. The event identifier specifies the
> > > > > entry in the message file associated with the event source.
> > > > >
> > > > > There is no description of the format of message file. Indeed
> > > > > the example code at
> > > > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/debug/base/reportevent.asp
> > > > > shows a simple example were the only defintion of dwEventID is a
> > > > > #define. If you note carefully I even used the same DWORD value
> > > > > as the example there.
> > > > >
> > > > > Searching around MS's site does not seem to describe how one
> > > > > goes about making such resources except in apparently an MS
> > > > > Visual C++ style with some sort of .mc file. As such this
> > > > > becomes out of my league as to how to map this MS concept of
> > > > > resource compiler/resources and inhertient dependency on MS
> > > > > tools with Cygwin's environment (probably exactly why this
> > > > > wasn't done in the first place).
> > > >
> > > > Andrew,
> > > >
> > > > FYI, the binutils package contains the "windres" utility that lets you
> > > > compile resource files.
> > > >
> > > > As for the example, follow the link to RegisterEventSource, and
> > > > from there to EventSources for information on how to provide the
> > > > necessary resources.
> > > > Igor
> > >
> > > [attached syslogmsg.tar snipped]

-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha at cs dot nyu dot edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor at watson dot ibm dot com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

Knowledge is an unending adventure at the edge of uncertainty.
  -- Leto II


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]