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.
> >>@@ -577,7 +647,14 @@
> >> 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
> called a hack many years ago:
>
> 1.1 (cgf 17-Feb-00): case REG_EXPAND_SZ:
> 1.3 (cgf 10-Jan-01): if (key_type == KT_EXPAND)// hack
> 1.1 (cgf 17-Feb-00): {
Well, I can't see a hack in what you're using KT_BINARY here. I removed
the comment from your patch.
> Attached is a new version of the patch.
> Thanks to your help regarding SE_BACKUP_NAME, the "save" action is now
> included.
Cool.
> 2006-03-02 Christian Franke <[EMAIL PROTECTED]>
>
> * regtool.cc (options): Add 'binary'.
> (usage): Document 'load|unload|save' and '-b'.
> (find_key): Add 'options' parameter, add load/unload.
> (cmd_set): Add KT_BINARY case.
> (cmd_get): Add hex output in KT_BINARY case.
> (cmd_load): New function.
> (cmd_unload): New function.
> (set_privilege): New function.
> (cmd_save): New function.
> (commands): Add load, unload and save.
> (main): Add '-b'
> * utils.sgml (regtool): Document it.
I applied the patch. I just had to reformat your ChangeLog slightly
(a TAB before all lines, no extra indentation for lines which don't
start with a '*').
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.
Thanks,
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat
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" $ 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 of=/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.bin $ touch /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.none etc etc ? (We might even want a $CYGWIN option to make the extension show up in dir listings, but it wouldn't be backwardly-compatible to do so in general). Hmm, and how about for MULTI_SZ taking account of the open mode? $ echo "String1" >/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.msz $ echo "String2" >>/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.msz $ echo "String3" >>/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.msz $ echo "String4" >>/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.msz $ od -c < /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.msz String1\0String2\0String3\0String4\0\0 cheers, DaveK -- Can't think of a witty .sigline today
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" > > $ 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 > of=/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.bin > > $ touch /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.none > > etc etc ? (We might even want a $CYGWIN option to make the extension show up > in dir listings, but it wouldn't be backwardly-compatible to do so in > general). > > Hmm, and how about for MULTI_SZ taking account of the open mode? > > $ echo "String1" > >/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.msz > $ echo "String2" > >>/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.msz > $ echo "String3" > >>/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.msz > $ echo "String4" > >>/proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.msz > $ od -c < /proc/registry/HKEY_CURRENT_USER/Software/App/Key/ValueName.msz > String1\0String2\0String3\0String4\0\0 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). What if a key "foo.sz" really exists and somebody wants to create a registry key "foo"? When reading "foo", which file is meant? What's the order of checking suffixes? When somebody writes to a key "foo", what's the default suffix, er..., key type? Or does that fail with an error message? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
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 file for read. > When somebody writes to a key "foo", what's the default suffix, > er..., key type? Or does that fail with an error message? Either; I haven't a strong opinion on the matter. cheers, DaveK -- Can't think of a witty .sigline today
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/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] 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." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac"
RE: [Patch] regtool: Add load/unload commands and --binary option
On Fri, 3 Mar 2006, Dave Korn wrote: > > That's actually an interesting idea. I was always thinking along > > the lines of using POSIX file types (plain,socket,pipe,...). > > > > 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 file for read. > > > When somebody writes to a key "foo", what's the default suffix, er..., > > key type? Or does that fail with an error message? > > Either; I haven't a strong opinion on the matter. Now, what if you write a file as foo.sz, and then write it as foo.dw. Do we change the key type? Do we fail with ENOENT? What is the semantics there? Also, this suffix idea reminds me more of versions on VMS or streams on NT, rather than real extensions. I wonder if we could/should use "foo:dw" or "foo:sz", rather than using the extension... IOW, "foo.sz" might be a valid filename, but "foo:sz" already cannot be on certain filesystems... The question about using two different filetypes in a row still applies, though. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] 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." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac"
RE: [Patch] regtool: Add load/unload commands and --binary option
> Now, what if you write a file as foo.sz, and then write it as foo.dw. Do > we change the key type? Absolutely. > Do we fail with ENOENT? What is the semantics there? Well, the semantics of the registry API is that you specify the type explicitly every time you set a value, and that doing so overrides the old type in just the same way as setting the value overrides the old value. > Also, this suffix idea reminds me more of versions on VMS or streams on > NT, rather than real extensions. I wonder if we could/should use "foo:dw" > or "foo:sz", rather than using the extension... I don't think it would matter very much precisely how we do it; after all it's a virtual FS and we can implement whatever standards we like. > IOW, "foo.sz" might be a > valid filename, but "foo:sz" already cannot be on certain filesystems... Yes, but then again it's perfectly valid on others, including managed mounts, and given that it's *not* a filename that could /never/ occur, it doesn't really gain you any real separation of the namespaces. > The question about using two different filetypes in a row still applies, > though. Like I said, setting a value always sets the content and type at the same time; same would apply in this case. cheers, DaveK -- Can't think of a witty .sigline today
RE: [Patch] regtool: Add load/unload commands and --binary option
On 03 March 2006 16:02, Igor Peshansky wrote: >> 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? Because they aren't writing it for their own benefit, but in order for it to be read by some other app that requires it to be of a specific type. > 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? You're thinking of the registry as some place where a program puts its own private data and reads it back and therefore assuming that it doesn't matter what actually is /in/ the registry as long as the program gets back the exact same stuff it put in there, but sometimes programs want to alter or set registry values for external apps that require a specific type. If cygwin chose a type and didn't provide a way to specify, this feature would be of much more limited use as you couldn't use it to modify an existing value because cygwin might decide to write it back as a different type and break whatever-it-was that depended on it. cheers, DaveK -- Can't think of a witty .sigline today
Re: Patch for silent crash with Cygwin1.dll v 1.5.19-4
--- Christopher Faylor <[EMAIL PROTECTED]> wrote: > 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 > Christopher, Actually, as far as I can see, the "efault.faulted()" does NOT catch the NULL dereference, unless it is confused about where to return. If it did, the code I added should not stop my program from crashing. I will go back and look into this further, though, to see if I have missed something. Thanks for your time. Gary __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [Patch] regtool: Add load/unload commands and --binary option
On Fri, Mar 03, 2006 at 01:12:01PM -, 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? As long as we are how-bouting, I'm looking at http://search.cpan.org/~tyemq/Win32-TieRegistry-0.24/TieRegistry.pm as another example of non-traditional access to the registry. How about /proc/registry//machinename/... to access the registry of other computers on the network? Or is // not at the beginning a no-no?
RE: [Patch] regtool: Add load/unload commands and --binary option
On 03 March 2006 17:42, Yitzchak Scott-Thoennes wrote: >> Hey, how about using pseudo filename-extensions on the pseudo-files that >> represent registry keys? > > As long as we are how-bouting, I'm looking at > > http://search.cpan.org/~tyemq/Win32-TieRegistry-0.24/TieRegistry.pm > > as another example of non-traditional access to the registry. How > about /proc/registry//machinename/... to access the registry of other > computers on the network? Or is // not at the beginning a no-no? There may be POSIX-y issues with // anywhere else. And the idea of having /proc contain objects related to another machine altogether does somewhat make my skin crawl. If we wanna do this at all, I'd rather it was done as //machine/registry/..., i.e. make a UNC share for the registry virtual fs tree this I guess would require a cygwin MUP, which isn't gonna happen any time soon though. Should we move this thread off the -patches list perhaps? cheers, DaveK -- Can't think of a witty .sigline today
Re: [Patch] regtool: Add load/unload commands and --binary option
Corinna Vinschen wrote: I applied the patch. Thanks. I just had to reformat your ChangeLog slightly (a TAB before all lines, no extra indentation for lines which don't start with a '*'). SeaMonkey expands tabs to spaces... Will use attachment for ChangeLog next time. 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. In fact I had the idea to hack the registry, in particular fix the read access to registry values starting with backslash: $ cd /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/MountedDevices $ ls ... \DosDevices\C: \DosDevices\D: ... $ cat \\DosDevices\\C: cat: \DosDevices\C:: No such file or directory Using a URL-like "%XX" encoding for invalid characters (/\?%) may be the right thing to do. $ ls ... %5cDosDevices%5cC: I found that all standard ascii chars except ^ % ` are used in value names 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. Because POSIX has no notion about file types, the type has to be somehow encoded into the name if a new key is created. The major drawback of this approach is that the read path is different from the write path. I would suggest to add a second R/W view to the registry where both path are identical. A type extension should be added via a rarely used character: $ ls /proc/registry/SUBKEY reg_sz_value reg_binary_value reg_dword_value $ ls /proc/registry-rw/SUBKEY reg_sz_value,sz reg_binary_value,bin reg_dword_value,dword Then you should have the ability to copy subkeys to file trees and vice versa: cp -r /dev/registry-rw/SUBKEY /tmp/SUBKEY rm -r /dev/registry-rw/SUBKEY cp -r /tmp/SUBKEY /dev/registry-rw/SUBKEY Suggest to start a new thread for this discussion Christian
RE: [Patch] regtool: Add load/unload commands and --binary option
On Fri, 3 Mar 2006, Dave Korn wrote: > On 03 March 2006 16:02, Igor Peshansky wrote: > > >> 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? > > Because they aren't writing it for their own benefit, but in order for > it to be read by some other app that requires it to be of a specific > type. > > > 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? > > You're thinking of the registry as some place where a program puts its > own private data and reads it back and therefore assuming that it > doesn't matter what actually is /in/ the registry as long as the program > gets back the exact same stuff it put in there, but sometimes programs > want to alter or set registry values for external apps that require a > specific type. If cygwin chose a type and didn't provide a way to > specify, this feature would be of much more limited use as you couldn't > use it to modify an existing value because cygwin might decide to write > it back as a different type and break whatever-it-was that depended on > it. Actually, I did think of registry as shared data, but I also assumed that the creation of value files would be separate from writing to them, and that the actual writing would not change the type. That still might not be a bad approach -- maybe introduce extra, registry-specific, flags for open() that reflect the file (i.e, key) type, and then implement writes to the files based on those flags... Just another alternative to consider... Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] 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." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac"
Re: [Patch] regtool: Add load/unload commands and --binary option
On Fri, 3 Mar 2006, Christian Franke wrote: > In fact I had the idea to hack the registry, in particular fix the read > access to registry values starting with backslash: > > $ cd /proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/MountedDevices > $ ls > ... > \DosDevices\C: > \DosDevices\D: > ... > $ cat \\DosDevices\\C: > cat: \DosDevices\C:: No such file or directory This is more likely a problem with Cygwin's path handling, which treats any path with an embedded '\' as a Windows path that doesn't get translated into POSIX (so you're not trying to open '/proc/registry/HKEY_LOCAL_MACHINE/SYSTEM/MountedDevices/\DosDevices\C:', but '\DosDevices\C:'. Look at the strace to confirm it. Maybe Cygwin should check if a path starts with /proc/registry (or any virtual filesystem) before deciding to not translate it... > Using a URL-like "%XX" encoding for invalid characters (/\?%) may be the > right thing to do. > > $ ls > ... > %5cDosDevices%5cC: Yep, in effect making /proc/registry a managed mount. You'd need something like this anyway to process values that have '/'s in them. > I found that all standard ascii chars except ^ % ` are used in value names > > > 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. > > Because POSIX has no notion about file types, the type has to be somehow > encoded into the name if a new key is created. What's wrong with using open() flags? > The major drawback of this approach is that the read path is different > from the write path. > > I would suggest to add a second R/W view to the registry where both path > are identical. > A type extension should be added via a rarely used character: > > $ ls /proc/registry/SUBKEY > reg_sz_value > reg_binary_value > reg_dword_value > > $ ls /proc/registry-rw/SUBKEY > reg_sz_value,sz > reg_binary_value,bin > reg_dword_value,dword Yep, except I suggested ':'. > Then you should have the ability to copy subkeys to file trees and vice > versa: > cp -r /dev/registry-rw/SUBKEY /tmp/SUBKEY > rm -r /dev/registry-rw/SUBKEY > cp -r /tmp/SUBKEY /dev/registry-rw/SUBKEY > > Suggest to start a new thread for this discussion Right, good idea, except not on this list (as Dave pointed out). What would be a good place -- cygwin-developers? Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] 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." "But no -- you are no fool; you call yourself a fool, there's proof enough in that!" -- Rostand, "Cyrano de Bergerac"
Re: [Patch] regtool: Add load/unload commands and --binary option
Igor Peshansky wrote: What's wrong with using open() flags? Save/restore registry tree in/from file tree wont work. Suggest to start a new thread for this discussion Right, good idea, except not on this list (as Dave pointed out). What would be a good place -- cygwin-developers? If you consider to accept my subscription request to this list ;-) Christian
