Christian Franke | 1 Mar 20:13 2006
Picon

Re: [Patch] regtool: Add load/unload commands and --binary option

Attached is version 2 of the patch, including an update of utils.sgml

REG_BINARY can now be ether read as binary from stdin:

$ echo 0: 01 02 FE FF | xxd -r | regtool -b set KEY/BINVALUE -

$ regtool get KEY/BINVALUE | regtool -b set KEY/BINVALUE -

or specified as hex arguments:

$ regtool -b set KEY/BINVALUE 01 02 FE FF

$ x=$(regtool -b get KEY/BINVALUE)
$ regtool -b set KEY/BINVALUE $x

The load/unload actions are unchanged.

Christian

=====================

2006-03-01  Christian Franke <franke <at> computer.org>

        * regtool.cc: Add actions load/unload and option -b, --binary.
        * utils.sgml (regtool): Document it.

Index: regtool.cc
===================================================================
(Continue reading)

Corinna Vinschen | 1 Mar 23:25 2006

Re: [Patch] regtool: Add load/unload commands and --binary option

On Mar  1 20:13, Christian Franke wrote:
> Attached is version 2 of the patch, including an update of utils.sgml
> 
> REG_BINARY can now be ether read as binary from stdin:
> 
> $ echo 0: 01 02 FE FF | xxd -r | regtool -b set KEY/BINVALUE -
> 
> $ regtool get KEY/BINVALUE | regtool -b set KEY/BINVALUE -
> 
> or specified as hex arguments:
> 
> $ regtool -b set KEY/BINVALUE 01 02 FE FF
> 
> $ x=$(regtool -b get KEY/BINVALUE)
> $ regtool -b set KEY/BINVALUE $x
> 
> 
> The load/unload actions are unchanged.
> 
> Christian
> 
> =====================
> 
> 2006-03-01  Christian Franke <franke <at> computer.org>
> 
>        * regtool.cc: Add actions load/unload and option -b, --binary.
>        * utils.sgml (regtool): Document it.

Your patch looks pretty good to me, but I have a few minor nits.

(Continue reading)

Gary Zablackis | 2 Mar 19:11 2006
Picon

Patch for silent crash with Cygwin1.dll v 1.5.19-4

Hi,

Since installing Cygwin1.dll v 1.5.19-4, I have a
problem with the computer algebra system SAGE dying at
startup with no error messages (i.e. I get returned to
the bash prompt with no messages of any sort).
I tracked the problem down to
verifyable_object_isvalid() in winsup/thread.cc. The
added the check below corrects this problem:

CHANGELOG:
2006-03-02 Gary Zablackis gzabl <at> yahoo.com
 * thread.cc (verifyable_object_isvalid): check for
NULL object or reference

CVS DIFF FILE:
Index: cygwin/thread.cc
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/thread.cc,v
retrieving revision 1.196
diff -u -p -r1.196 thread.cc
--- cygwin/thread.cc    6 Feb 2006 18:24:06 -0000     
 1.196
+++ cygwin/thread.cc    2 Mar 2006 18:06:50 -0000
 <at>  <at>  -122,6 +122,9  <at>  <at>  verifyable_object_isvalid (void
const *
   if (efault.faulted ())
     return INVALID_OBJECT;

+  if(!object || !*object)
(Continue reading)

Christopher Faylor | 2 Mar 19:54 2006

Re: Patch for silent crash with Cygwin1.dll v 1.5.19-4

On Thu, Mar 02, 2006 at 10:11:39AM -0800, Gary Zablackis wrote:
>Since installing Cygwin1.dll v 1.5.19-4, I have a problem with the
>computer algebra system SAGE dying at startup with no error messages
>(i.e.  I get returned to the bash prompt with no messages of any sort).
>I tracked the problem down to verifyable_object_isvalid() in
>winsup/thread.cc.  The added the check below corrects this problem:
>
>CHANGELOG:
>2006-03-02 Gary Zablackis gzabl <at> yahoo.com
> * thread.cc (verifyable_object_isvalid): check for
>NULL object or reference

The "efault.faulted()" two lines above your change is supposed to catch
NULL dereferences.  I suspect that you were probably misled by the fact
that gdb might show a SEGV in this function but that is to be expected
(see lots of discussion in the cygwin mailing list about this) and there
are patches pending for gdb which will work around this behavior.

So, sorry, but I doubt that this is actually your problem.

cgf

>CVS DIFF FILE:
>Index: cygwin/thread.cc
>===================================================================
>RCS file: /cvs/src/src/winsup/cygwin/thread.cc,v
>retrieving revision 1.196
>diff -u -p -r1.196 thread.cc
>--- cygwin/thread.cc    6 Feb 2006 18:24:06 -0000     
> 1.196
(Continue reading)

Christian Franke | 2 Mar 21:59 2006
Picon

Re: [Patch] regtool: Add load/unload commands and --binary option

Corinna Vinschen wrote:
> ...
>   
>>    //printf("key `%s' value `%s'\n", n, value);
>>     
>
> Why is this printf commented out?  If it's not needed, please remove.
>   

cvs annotate regtool.cc
...
1.1 (cgf      17-Feb-00):     }
1.1 (cgf      17-Feb-00):   //printf("key `%s' value `%s'\n", n, value);
1.1 (cgf      17-Feb-00): }

Doing code-janitor work on historic code was not the intent of my patch ;-)
Uncommenting this line during testing was helpful, so I left it untouched.

>>  <at>  <at>  -577,7 +647,14  <at>  <at> 
>>    switch (vtype)
>>      {
>>      case REG_BINARY:
>> -      fwrite (data, dsize, 1, stdout);
>> +      if (key_type == KT_BINARY)	// hack
>>     
>
> Hack?  Why hack?  Otherwise, please remove this comment.
>   

Because {re|mis}using "set" key_type for as a "get" option has been 
(Continue reading)

Corinna Vinschen | 3 Mar 10:46 2006

Re: [Patch] regtool: Add load/unload commands and --binary option

On Mar  2 21:59, Christian Franke wrote:
> Corinna Vinschen wrote:
> >...
> >  
> >>   //printf("key `%s' value `%s'\n", n, value);
> >>    
> >
> >Why is this printf commented out?  If it's not needed, please remove.
> >  
> 
> cvs annotate regtool.cc
> ...
> 1.1 (cgf      17-Feb-00):     }
> 1.1 (cgf      17-Feb-00):   //printf("key `%s' value `%s'\n", n, value);
> 1.1 (cgf      17-Feb-00): }
> 
> Doing code-janitor work on historic code was not the intent of my patch ;-)

Urgh, sorry about that.  While scanning your patch I missed that this
printf isn't new but already in the code.

> >> <at>  <at>  -577,7 +647,14  <at>  <at> 
> >>   switch (vtype)
> >>     {
> >>     case REG_BINARY:
> >>-      fwrite (data, dsize, 1, stdout);
> >>+      if (key_type == KT_BINARY)	// hack
> >>    
> >
> >Hack?  Why hack?  Otherwise, please remove this comment.
(Continue reading)

Dave Korn | 3 Mar 14:12 2006

RE: [Patch] regtool: Add load/unload commands and --binary option

On 03 March 2006 09:46, Corinna Vinschen wrote:

> 
> Btw., since you seem to be interested in hacking the registry...  would
> you also be interested to introduce registry write access below
> /proc/registry inside of the Cygwin DLL?  That would be extra cool.
> I'm not quite sure how to handle the mapping from file types to
> registry key types, but there might be some simple way which I'm just
> too blind to see.

  Hey, how about using pseudo filename-extensions on the pseudo-files that
represent registry keys?

  i.e

$  echo "Foo" >/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.sz
creates /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName, type
REG_SZ, content "Foo<NUL>"

$  echo "%WINDIR%"
>/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.xsz
creates /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName as
REG_EXPAND_SZ

$  echo "23"
>/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.dword
$  echo "0x17"
>/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.dword

$  dd bs=1024 count=3 if=/dev/random
(Continue reading)

Corinna Vinschen | 3 Mar 14:21 2006

Re: [Patch] regtool: Add load/unload commands and --binary option

On Mar  3 13:12, Dave Korn wrote:
> On 03 March 2006 09:46, Corinna Vinschen wrote:
> 
> > 
> > Btw., since you seem to be interested in hacking the registry...  would
> > you also be interested to introduce registry write access below
> > /proc/registry inside of the Cygwin DLL?  That would be extra cool.
> > I'm not quite sure how to handle the mapping from file types to
> > registry key types, but there might be some simple way which I'm just
> > too blind to see.
> 
> 
>   Hey, how about using pseudo filename-extensions on the pseudo-files that
> represent registry keys?
> 
>   i.e
> 
> $  echo "Foo" >/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.sz
> creates /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName, type
> REG_SZ, content "Foo<NUL>"
> 
> $  echo "%WINDIR%"
> >/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.xsz
> creates /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName as
> REG_EXPAND_SZ
> 
> $  echo "23"
> >/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.dword
> $  echo "0x17"
> >/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.dword
(Continue reading)

Dave Korn | 3 Mar 16:40 2006

RE: [Patch] regtool: Add load/unload commands and --binary option


> That's actually an interesting idea.  I was always thinking along
> the lines of using POSIX file types (plain,socket,pipe,...).
> 
> However, file suffixes is something we're already suffering from
> a lot (it's not by chance that SUFFix and SUFFer are so similar, IMHO).

  Heh, yeh, who could ever forget the .exe/.lnk/.exe.lnk/.lnk.exe troubles?
However, we're in a special situation here, it's not really a dir tree and the
things in it aren't really files, and we may be able to get away with it.  I
posted the idea so that others could see if it works or if they can see
problems with the approach.

> What if a key "foo.sz" really exists and somebody wants to create
> a registry key "foo"?

  No problem.  If you want to create foo, you write to "foo.sz".  If you want
to create foo.sz, you have to write to "foo.sz.sz".  Unless of course foo.sz
is a dword, in which case you'd write to "foo.sz.dw", etc etc.

> When reading "foo", which file is meant?

  There can only be one at a time, because in the registry there can only be
one value with the name foo, regardless of what type it has.

> What's the order of checking suffixes?

  I'm proposing that the suffix is only used when creating or writing to the
file, to determine the type, but the suffix is stripped off for generating the
actual name, and is not shown in dir listings, and is not required to open the
(Continue reading)

Igor Peshansky | 3 Mar 17:02 2006
Picon

Re: [Patch] regtool: Add load/unload commands and --binary option

On Fri, 3 Mar 2006, Corinna Vinschen wrote:

> Btw., since you seem to be interested in hacking the registry...  would
> you also be interested to introduce registry write access below
> /proc/registry inside of the Cygwin DLL?  That would be extra cool.
> I'm not quite sure how to handle the mapping from file types to
> registry key types, but there might be some simple way which I'm just
> too blind to see.

Hmm, there is currently no way for the programs to find out the registry
key type, unless we introduce new functionality into stat() or something.

As it is, why would the programs need to know the key type, anyway?  They
just write the data, and fhandler_registry takes care of converting it to
the right format (using arbirtary conventions of some sort).  The only
potential problems are REG_MULTI_SZ and REG_EXPAND_SZ (in the former case
it's a question of picking a string delimiter, and in the latter it's
about annotating expandable values).

Am I missing something?
	Igor
P.S. Thanks a lot to Christian for this cool functionality.
--

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

"Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte."
(Continue reading)


Gmane