The Windows registry. Apparently a lot of people hate it. Tom Kyte 
refers to it as "the Microsoft copy-protection system" (which is odd, 
considering it has absolutely nothing to do with copy-protection...) 
Apparently it's a *really* unpopular system.

The Unix way has always been for programs to populate your home 
directory with thousands of .rc files, each and every one of them in a 
different randomly-designed file format.

But now, there is a new hope for a unified configuration system. They 
call it "Gsettings". And the hilarious thing is that it is COMPLETELY 
ISOMORPHIC TO... the Windows registry.

It consists of a binary file containing a hierarchical tree of named 
folders, containing named keys, which easy have a value of a certain 
well-defined type. (Usually "integer" or "string".) Changing one of 
these settings has immediate effect on the owning application. And, for 
the most part, different application's keys are jumbled up in a random, 
haphazard manner.

...EXACTLY like the Windows registry.

Yes, it seems the GNU folks hate the Windows registry SO MUCH that they 
went out and added an exact reimplementation of it to their own 
software. :-P So much irony!



In fairness, it's not /completely/ identical. The folders are called 
"keys" under Windows, whereas Gsettings calls them "schemas". Both 
systems store this stuff in a binary file, but Gsettings loads the key 
definitions from XML files and "compiles" them into binary. Unlike the 
Windows registry, each key has a textual description (which is 
frequently very unhelpful), and a default value to which you can reset 
the key. Oh, and most keys for selecting options use text strings rather 
than weird code numbers. Also, the Windows registry supports storing 
stuff in multiple different "hives", whereas Gsettings apparently does not.

But apart from all this... totally identical. :-P

Post a reply to this message

On 10/28/2012 2:28 PM, Orchid Win7 v1 wrote:
> The Windows registry. Apparently a lot of people hate it. Tom Kyte
> refers to it as "the Microsoft copy-protection system" (which is odd,
> considering it has absolutely nothing to do with copy-protection...)
> Apparently it's a *really* unpopular system.
>
> The Unix way has always been for programs to populate your home
> directory with thousands of .rc files, each and every one of them in a
> different randomly-designed file format.
>
> But now, there is a new hope for a unified configuration system. They
> call it "Gsettings". And the hilarious thing is that it is COMPLETELY
> ISOMORPHIC TO... the Windows registry.
>
> It consists of a binary file containing a hierarchical tree of named
> folders, containing named keys, which easy have a value of a certain
> well-defined type. (Usually "integer" or "string".) Changing one of
> these settings has immediate effect on the owning application. And, for
> the most part, different application's keys are jumbled up in a random,
> haphazard manner.
>
> ...EXACTLY like the Windows registry.
>
> Yes, it seems the GNU folks hate the Windows registry SO MUCH that they
> went out and added an exact reimplementation of it to their own
> software. :-P So much irony!
>
>
>
> In fairness, it's not /completely/ identical. The folders are called
> "keys" under Windows, whereas Gsettings calls them "schemas". Both
> systems store this stuff in a binary file, but Gsettings loads the key
> definitions from XML files and "compiles" them into binary. Unlike the
> Windows registry, each key has a textual description (which is
> frequently very unhelpful), and a default value to which you can reset
> the key. Oh, and most keys for selecting options use text strings rather
> than weird code numbers. Also, the Windows registry supports storing
> stuff in multiple different "hives", whereas Gsettings apparently does not.
>
> But apart from all this... totally identical. :-P

Snort.. Actually, the problem with the windows registry are:

1. Can't read the damn thing, without the editor.

2. Things don't always uninstall cleanly.

3. There are no safeguards to stop program X from screwing with a key 
for program Y.

This might require some sort of, "mark this key as editable", or 
something, since there may be a few cases where you do want to allow 
this, for specific things.

4. It doesn't clean itself up.

Which is to say, some things you might want to keep, like program 
information for a DVD, or other removable media, but why load in keys, 
and settings, for permanently installed applications, which are no 
longer on the system, let alone keep the data on them, unless its, say, 
just pointers to data, or something that another program, again, maybe 
could need/be given access too?

All of these things make it a pain in the ass. Well, that, and the fact 
that, due to how some of the stuff like linked together in it, its hard, 
and there are no tools for, tracing how all the parts connect, so you 
can either kill all related keys, or figure out which one might have 
broken, like a file open function, pointing at a loader, which points to 
its application, where any one in the chain could be screwed, by they 
are all tied together using long chains of hexadecimal IDs. And, that is 
one of the simple cases...

Post a reply to this message

On 28/10/2012 09:41 PM, Patrick Elliott wrote:
> Snort.. Actually, the problem with the windows registry are:
>
> 1. Can't read the damn thing, without the editor.

Well, see, the idea is that *you* should never have to look at it. The 
program in question is supposed to provide a real UI for editing it. 
Much like you should never have to look at a JPEG file in a hex editor; 
you should use a real image viewer / editor.

> 2. Things don't always uninstall cleanly.

Gsettings might plausibly do this better. It looks like you just delete 
that program's XML file and then recompile the schemas... but I haven't 
tested this.

Under Windows, any program can just add or delete arbitrary keys.

> 3. There are no safeguards to stop program X from screwing with a key
> for program Y.
>
> This might require some sort of, "mark this key as editable", or
> something, since there may be a few cases where you do want to allow
> this, for specific things.

You realise that the Windows registry has ACLs, right? Exactly like 
files do? I'm not sure whether Gsettings does this, come to think of 
it... I suspect not. (After all, Unix doesn't have ACLs for files yet.)

> 4. It doesn't clean itself up.

That's really more a problem with crappy software than with the registry 
itself. It's like, very commonly you uninstall some program, and then 
months later realise that some of its files are still sitting on your 
harddrive. Is that a problem with filesystems? No, not really; it's a 
problem with badly written installers and uninstallers.

Post a reply to this message

On 28/10/2012 9:41 PM, Patrick Elliott wrote:
>
> Snort.. Actually, the problem with the windows registry are:
>
> 1. Can't read the damn thing, without the editor.

Why is that a problem? You always need some sort of software to read a 
computer file and regedit comes with Windows.

-- 
Regards
     Stephen

Post a reply to this message

didn't you know that bastard Miguel de Icaza has long been copying and pasting
Microsoft tech into Linux so they can get royalties?

he first developed Gnome and all Grelated stuff and damned mono

Post a reply to this message

Le 2012-10-28 17:41, Patrick Elliott a écrit :
> On 10/28/2012 2:28 PM, Orchid Win7 v1 wrote:
>> The Windows registry. Apparently a lot of people hate it. Tom Kyte
>> refers to it as "the Microsoft copy-protection system" (which is odd,
>> considering it has absolutely nothing to do with copy-protection...)
>> Apparently it's a *really* unpopular system.
>>
>> The Unix way has always been for programs to populate your home
>> directory with thousands of .rc files, each and every one of them in a
>> different randomly-designed file format.

AIX has had a binary configuration system for eons.

>>
>> But now, there is a new hope for a unified configuration system. They
>> call it "Gsettings". And the hilarious thing is that it is COMPLETELY
>> ISOMORPHIC TO... the Windows registry.

"Unified" for anyone who decides to use it.  It will probably become as 
popular as CDE.

>
> Snort.. Actually, the problem with the windows registry are:
>
> 1. Can't read the damn thing, without the editor.
>
> 2. Things don't always uninstall cleanly.

Even though it's mostly due to lazy uninstallers, that can be done on 
purpose.  For example, trial versions leave install info beihnd on 
purpose so that you can't simply reinstall your demo version when the 30 
days have expired.  Another reason might be shared keys between multiple 
applications of the same family.  If you uninstall app A from vendor X 
and it zaps the whole X branch of the registry, then app B from the same 
vendor will no longer function properly.  The real problem is that the 
Windows registry does not keep track of which applications need which 
key, so the uninstaller (or a defrag utility) can't really know which 
keys are still valid.


-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

Le 2012-10-28 18:04, Orchid Win7 v1 a écrit :
> On 28/10/2012 09:41 PM, Patrick Elliott wrote:
>> Snort.. Actually, the problem with the windows registry are:
>>
>> 1. Can't read the damn thing, without the editor.
>
> Well, see, the idea is that *you* should never have to look at it. The
> program in question is supposed to provide a real UI for editing it.
> Much like you should never have to look at a JPEG file in a hex editor;
> you should use a real image viewer / editor.
>
>> 2. Things don't always uninstall cleanly.
>
> Gsettings might plausibly do this better. It looks like you just delete
> that program's XML file and then recompile the schemas... but I haven't
> tested this.
>
> Under Windows, any program can just add or delete arbitrary keys.
>
>> 3. There are no safeguards to stop program X from screwing with a key
>> for program Y.
>>
>> This might require some sort of, "mark this key as editable", or
>> something, since there may be a few cases where you do want to allow
>> this, for specific things.
>
> You realise that the Windows registry has ACLs, right? Exactly like
> files do? I'm not sure whether Gsettings does this, come to think of
> it... I suspect not.
>

These ACLs are based on userID, not app.  So if I run an anti-virus 
installer as "Francois", and then click on a bad link, there's nothing 
that will prevent BadVirus.exe from messing with the anti-virus 
autostart keys with the same user ID.

 > (After all, Unix doesn't have ACLs for files yet.)

WAT?

Have you ever typed "ls -l"  ?  Do you know what the "rwxr-x---" mean on 
the left hand side.


-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

Francois Labreque <fla### [at] videotronca> wrote:
> Le 2012-10-28 18:04, Orchid Win7 v1 a écrit :
>  > (After all, Unix doesn't have ACLs for files yet.)
>
> WAT?
>
> Have you ever typed "ls -l"  ?  Do you know what the "rwxr-x---" mean on
> the left hand side.

good thing he was hired to work on *nix things ^_^

Post a reply to this message

On 29/10/2012 01:33 PM, Francois Labreque wrote:
>> (After all, Unix doesn't have ACLs for files yet.)
>
> WAT?
>
> Have you ever typed "ls -l" ? Do you know what the "rwxr-x---" mean on
> the left hand side.

No deary. I mean being able to set an *arbitrary* combination of 
permissions.

If you have a folder and you want all the people in QA to have read-only 
access, the people in Helpdesk to be able to create new files but not 
modify existing ones, and the guys in Development to have full 
read/write access, you can actually do exactly that with NTFS file 
permissions. Good luck trying to do it with umask...

Post a reply to this message

Am 29.10.2012 14:33, schrieb Francois Labreque:

>  > (After all, Unix doesn't have ACLs for files yet.)
>
> WAT?
>
> Have you ever typed "ls -l"  ?  Do you know what the "rwxr-x---" mean on
> the left hand side.

And you know that ACL is an acronym for "Access Control LISTS", right?

Full-fledged ACLs do allow you to specify individual access rights for 
an arbitrary number of users and/or user groups, not just for the owner, 
one user group and the rest of the world.

BTW, some commercial Unixes like HP-UX do provide proper ACLs (they even 
use that very term for the feature).

Post a reply to this message

On 10/28/2012 3:04 PM, Orchid Win7 v1 wrote:
> On 28/10/2012 09:41 PM, Patrick Elliott wrote:
>> Snort.. Actually, the problem with the windows registry are:
>>
>> 1. Can't read the damn thing, without the editor.
>
> Well, see, the idea is that *you* should never have to look at it. The
> program in question is supposed to provide a real UI for editing it.
> Much like you should never have to look at a JPEG file in a hex editor;
> you should use a real image viewer / editor.
>
A naive assumption imho. But, then, Windows is based around, "Sorry, but 
you can't be trusted to do that." lol Still, even something like, 
"Export all keys specific to this application.", would have been nice.

>> 2. Things don't always uninstall cleanly.
>
> Gsettings might plausibly do this better. It looks like you just delete
> that program's XML file and then recompile the schemas... but I haven't
> tested this.
>
> Under Windows, any program can just add or delete arbitrary keys.
>
Yep, more or less, though you do sort of contradict yourself later.

>> 3. There are no safeguards to stop program X from screwing with a key
>> for program Y.
>>
>> This might require some sort of, "mark this key as editable", or
>> something, since there may be a few cases where you do want to allow
>> this, for specific things.
>
> You realise that the Windows registry has ACLs, right? Exactly like
> files do? I'm not sure whether Gsettings does this, come to think of
> it... I suspect not. (After all, Unix doesn't have ACLs for files yet.)
>
Meaningless, since, as others have said, it only protect based on user, 
not application. A better solution, having thought a bit about it, would 
be if there was like a security key, which the installer, uninstaller, 
and the application itself (and any sub-apps) had, which let them 
manipulate the "non-public" parts of its key list, so that short of 
logging in as administrator, and using a tool/hand editing, the keys as 
the super user, nothing could make those changes.

>> 4. It doesn't clean itself up.
>
> That's really more a problem with crappy software than with the registry
> itself. It's like, very commonly you uninstall some program, and then
> months later realise that some of its files are still sitting on your
> harddrive. Is that a problem with filesystems? No, not really; it's a
> problem with badly written installers and uninstallers.

Well, yes and no. In principle, just nuking the entire key for that 
application should work. The problem is, its often got a dozen keys, 
there are assumptions made about other things installed, no way to 
double check if, for example, two application use the same extra things, 
and only one is being uninstalled, so its safer to just leave the key 
for that in there, even if its not being used, etc. Its not just bad 
uninstaller design, its just bad design from the stand point of the DB 
itself. A better design would be able to inform the application that 
something else is using something it wants to uninstall, not have the 
uninstaller tell you, "This is known to be sometimes used by a lot of 
other things, should I remove it anyway?" 99% of the time, it is in fact 
*not* used by anything else. Data is a bit iffier. Some of it you don't 
want to nuke, some of it is just settings, temp files, etc., which 
bloody well do need to be removed from the disk, not just from the 
registry. But.. almost everything leaves bits of that stuff floating around.

Post a reply to this message

On 10/28/2012 11:38 PM, Stephen wrote:
> On 28/10/2012 9:41 PM, Patrick Elliott wrote:
>>
>> Snort.. Actually, the problem with the windows registry are:
>>
>> 1. Can't read the damn thing, without the editor.
>
> Why is that a problem? You always need some sort of software to read a
> computer file and regedit comes with Windows.
>
Uh.. Because the editor sucks, and there are a lot of things you would 
like to be able to do, that it can't (like, for example, listing all 
related keys, in a filter of some sort, not using notepad, or a pad of 
paper to write down keys, while hunting through a dozen extra searches 
to find them all).

Post a reply to this message

On 10/28/2012 4:41 PM, Patrick Elliott wrote:
> On 10/28/2012 2:28 PM, Orchid Win7 v1 wrote:
>> The Windows registry. Apparently a lot of people hate it. Tom Kyte
>> refers to it as "the Microsoft copy-protection system" (which is odd,
>> considering it has absolutely nothing to do with copy-protection...)

A lot of developers write magic numbers to the registry so that when 
your trial period ends, uninstalling and reinstalling the application 
will not reset your trial period.

>> Apparently it's a *really* unpopular system.
>>
>> The Unix way has always been for programs to populate your home
>> directory with thousands of .rc files, each and every one of them in a
>> different randomly-designed file format.
>>
>> But now, there is a new hope for a unified configuration system. They
>> call it "Gsettings". And the hilarious thing is that it is COMPLETELY
>> ISOMORPHIC TO... the Windows registry.
>>
>> It consists of a binary file

STOP.

Why not XML?

>> In fairness, it's not /completely/ identical. The folders are called
>> "keys" under Windows, whereas Gsettings calls them "schemas". Both
>> systems store this stuff in a binary file, but Gsettings loads the key
>> definitions from XML files and "compiles" them into binary.

Okay, but why compile them?  It's not like drive space is a scarce 
resource anymore.

> Snort.. Actually, the problem with the windows registry are:
>
> 1. Can't read the damn thing, without the editor.
>
> 2. Things don't always uninstall cleanly.

That's mostly the uninstaller's fault.  I suppose there's a utility that 
allows you to record the registry changes made by an installer, so that 
when the utility is uninstalled you can follow up and scrub the registry 
completely.

5. All of your eggs are in one basket.  Yes, let's put the settings for 
your application, Jack's application, and the drivers for your hardware 
devices, all in one big file.  That won't cause any problems, no sir.

Regards,
John

Post a reply to this message

>>> It consists of a binary file
>
> STOP.
>
> Why not XML?
>
>>> In fairness, it's not /completely/ identical. The folders are called
>>> "keys" under Windows, whereas Gsettings calls them "schemas". Both
>>> systems store this stuff in a binary file, but Gsettings loads the key
>>> definitions from XML files and "compiles" them into binary.
>
> Okay, but why compile them? It's not like drive space is a scarce
> resource anymore.

Indeed. Considering that the original XML files *still exist*. It seems 
when you add a new application, it drops an XML file into a folder, and 
you recreate the binary file from everything in that folder. When you 
remove an application, it removes it's own XML file, and you rebuild the 
binary file from what's left.

I would imagine the reason for this is so that applications can access 
the binary file quickly and efficiently, rather than to save disk space. 
You don't have to search and parse lots of XML files, checking for 
syntax errors and name clashes and whatever at run-time.

Then again, the GNOME 3 shell appears to be written entirely in 
JavaScript, so what do I know?

>> 2. Things don't always uninstall cleanly.
>
> That's mostly the uninstaller's fault.

Yep.

> 5. All of your eggs are in one basket. Yes, let's put the settings for
> your application, Jack's application, and the drivers for your hardware
> devices, all in one big file. That won't cause any problems, no sir.

It won't as long as the OS itself is the only thing allows to access 
that file, and different parts of the file have different access 
permissions. In that respect, it's just like the filesystem itself; only 
the OS is allowed to touch the Master File Table that says where each 
file is, and individual files have different access permissions.

Then again, Gsettings doesn't appear to have access permissions, so...

Post a reply to this message

>>> Snort.. Actually, the problem with the windows registry are:
>>>
>>> 1. Can't read the damn thing, without the editor.
>>
>> Why is that a problem? You always need some sort of software to read a
>> computer file and regedit comes with Windows.
>>
> Uh.. Because the editor sucks

...which leads us back to "you're not supposed to touch this stuff 
manually".

Ever tried using e2fstune? Not very intuitive, is it? Then again, how 
often do you even need to touch it?

> (like, for example, listing all
> related keys, in a filter of some sort, not using notepad, or a pad of
> paper to write down keys, while hunting through a dozen extra searches
> to find them all).

1. The registry editor is perfectly capable of dumping chunks of the 
registry as text. It also has a search function. (Admittedly it's not 
very scriptable.)

2. You can write your own application to access the registry. Hell, it's 
probably quite easy to throw something together in VB to do a quick 
search or two...

Post a reply to this message

>>> 1. Can't read the damn thing, without the editor.
>>
>> Well, see, the idea is that *you* should never have to look at it. The
>> program in question is supposed to provide a real UI for editing it.
>
> A naive assumption imho.

Well, no, that's the way it's *supposed* to work. The fact that a few 
crappy applications don't do this is beside the point. (That and a few 
low-level OS things that typical users don't need to touch.)

> But, then, Windows is based around, "Sorry, but you can't be trusted to do that."

Well, yes. Just like regular users shouldn't be renaming system DLLs or 
whatever. The *average* user is pretty stupid, after all... (Although I 
admit it would be nice to have a version of Windows designed for 
computer experts!)

> Still, even something like,
> "Export all keys specific to this application.", would have been nice.

What makes you think you can't do that?

>> You realise that the Windows registry has ACLs, right? Exactly like
>> files do? I'm not sure whether Gsettings does this, come to think of
>> it... I suspect not. (After all, Unix doesn't have ACLs for files yet.)
>>
> Meaningless, since, as others have said, it only protect based on user,
> not application.

Well, yeah, if security could be managed per-application, that /would/ 
certainly be superior. But there we are.

Post a reply to this message

> A lot of developers write magic numbers to the registry so that when
> your trial period ends, uninstalling and reinstalling the application
> will not reset your trial period.

Is this method really used? There are programs to record all 
reads/writes to the registry, so you really can delete all the keys 
created. Or you just restore a backup of the registry to start the trial 
again. I suspect they are a bit more cunning than this.

>>> In fairness, it's not /completely/ identical. The folders are called
>>> "keys" under Windows, whereas Gsettings calls them "schemas". Both
>>> systems store this stuff in a binary file, but Gsettings loads the key
>>> definitions from XML files and "compiles" them into binary.
>
> Okay, but why compile them?  It's not like drive space is a scarce
> resource anymore.

Speed? At least on Windows the registry is accessed pretty much 
continuously, you want it to be as fast as possible so that means a 
binary format.

> That's mostly the uninstaller's fault.  I suppose there's a utility that
> allows you to record the registry changes made by an installer, so that
> when the utility is uninstalled you can follow up and scrub the registry
> completely.

That's dangerous though, because another program might have been 
installed since that changes or uses one of the settings the original 
program created/changed. If you go down this route (as some large 
companies do for custom automatic installer/uninstallers) then you need 
to do a lot of checking and testing for each program.

Post a reply to this message

On 30/10/2012 08:48 AM, scott wrote:
>> A lot of developers write magic numbers to the registry so that when
>> your trial period ends, uninstalling and reinstalling the application
>> will not reset your trial period.
>
> Is this method really used? There are programs to record all
> reads/writes to the registry, so you really can delete all the keys
> created. Or you just restore a backup of the registry to start the trial
> again. I suspect they are a bit more cunning than this.

We used an expensive commercial web application which only works 
properly if you use Internet Explorer and only if you disable all web 
caching between you and the server. Because, obviously, the developers 
were too stupid to know how to set pages to expire. Some developers are 
very stupid.

Most users don't know what the "registry" is. I'm sure the above method 
works just fine in the majority of cases. Also, lots of programs require 
you to get a temporary "activation code", which won't work the second 
time around...

>> Okay, but why compile them?
>
> Speed?

I concur.

>> That's mostly the uninstaller's fault. I suppose there's a utility that
>> allows you to record the registry changes made by an installer, so that
>> when the utility is uninstalled you can follow up and scrub the registry
>> completely.
>
> That's dangerous though, because another program might have been
> installed since that changes or uses one of the settings the original
> program created/changed. If you go down this route (as some large
> companies do for custom automatic installer/uninstallers) then you need
> to do a lot of checking and testing for each program.

I've seen Linux try to do this with text files. Like, when you install 
an application, it renames the old config file, and when you uninstall 
it, it renames the old one back. Find if you uninstall stuff in LIFO 
order. Not so fine otherwise...

Post a reply to this message

> We used an expensive commercial web application which only works
> properly if you use Internet Explorer and only if you disable all web
> caching between you and the server. Because, obviously, the developers
> were too stupid to know how to set pages to expire. Some developers are
> very stupid.

Developers are often just lazy, and they suddenly stop becoming lazy 
when it involves whether people pay for their product or not.

> Most users don't know what the "registry" is.

Most users will just search for "program X crack", if it was as simple 
as installing the trial and changing/deleting a registry key it would be 
all over the web.

 > I'm sure the above method
> works just fine in the majority of cases.

I'm pretty sure I've tried with a few trial apps (a long time ago) to 
find out how they were detecting I'd already run the trial but couldn't 
figure it out (after logging registry and file changes). They must be 
using something a bit more sophisticated.

Post a reply to this message

Am 30.10.2012 09:46, schrieb Orchid Win7 v1:

>> Still, even something like,
>> "Export all keys specific to this application.", would have been nice.
>
> What makes you think you can't do that?

The simple fact that the registry doesn't track which keys are specific 
to which application, maybe?

Post a reply to this message

Am 30.10.2012 04:16, schrieb John VanSickle:

>>> In fairness, it's not /completely/ identical. The folders are called
>>> "keys" under Windows, whereas Gsettings calls them "schemas". Both
>>> systems store this stuff in a binary file, but Gsettings loads the key
>>> definitions from XML files and "compiles" them into binary.
>
> Okay, but why compile them?  It's not like drive space is a scarce
> resource anymore.

Faster access, maybe?

>> Snort.. Actually, the problem with the windows registry are:
>>
>> 1. Can't read the damn thing, without the editor.
>>
>> 2. Things don't always uninstall cleanly.
>
> That's mostly the uninstaller's fault.  I suppose there's a utility that
> allows you to record the registry changes made by an installer, so that
> when the utility is uninstalled you can follow up and scrub the registry
> completely.

Except when the installer doesn't know that the application itself does 
make additional changes to the registry.

Or when the installer makes a change to parts of the registry that other 
installers are also likely to touch, and un-installing isn't done in 
reverse order.

> 5. All of your eggs are in one basket.  Yes, let's put the settings for
> your application, Jack's application, and the drivers for your hardware
> devices, all in one big file.  That won't cause any problems, no sir.

 From Orchid's postings, I gather that the Gsettings concept is 
different in this respect, by having the applications just add or modify 
their own private XML file, and then compile all such XML files into one 
blob (for, as I suspect, faster access).

Post a reply to this message

Le 2012-10-29 18:14, clipka a écrit :
> Am 29.10.2012 14:33, schrieb Francois Labreque:
>
>>  > (After all, Unix doesn't have ACLs for files yet.)
>>
>> WAT?
>>
>> Have you ever typed "ls -l"  ?  Do you know what the "rwxr-x---" mean on
>> the left hand side.
>
> And you know that ACL is an acronym for "Access Control LISTS", right?
>
Yes.

> Full-fledged ACLs do allow you to specify individual access rights for
> an arbitrary number of users and/or user groups, not just for the owner,
> one user group and the rest of the world.
>

I know that too.  But Andy was exagerating slightly (what else is new?).

> BTW, some commercial Unixes like HP-UX do provide proper ACLs (they even
> use that very term for the feature).
>

And recen versions of Novell's NDS are exactly that too.

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

Le 2012-10-29 18:11, Orchid Win7 v1 a écrit :
> On 29/10/2012 01:33 PM, Francois Labreque wrote:
>>> (After all, Unix doesn't have ACLs for files yet.)
>>
>> WAT?
>>
>> Have you ever typed "ls -l" ? Do you know what the "rwxr-x---" mean on
>> the left hand side.
>
> No deary. I mean being able to set an *arbitrary* combination of
> permissions.
>

Then if that's what you mean, say that.  ;)

> If you have a folder and you want all the people in QA to have read-only
> access, the people in Helpdesk to be able to create new files but not
> modify existing ones, and the guys in Development to have full
> read/write access, you can actually do exactly that with NTFS file
> permissions. Good luck trying to do it with umask...


-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

>  From Orchid's postings, I gather that the Gsettings concept is
> different in this respect, by having the applications just add or modify
> their own private XML file, and then compile all such XML files into one
> blob (for, as I suspect, faster access).

This is quite a good idea, because then it's up to the OS to decide how 
to handle conflicts (eg if two apps try to set the same thing in their 
own XML). Also then when you uninstall you can just delete the XML and 
know that any settings from that app no longer have any influence. In 
Windows on the other hand it's simply whichever application changed the 
value most recently that wins.

However does this mean that every time a program writes to the registry 
the OS must recompile everything?

Post a reply to this message

On 30/10/2012 04:11 PM, scott wrote:
>> From Orchid's postings, I gather that the Gsettings concept is
>> different in this respect, by having the applications just add or modify
>> their own private XML file, and then compile all such XML files into one
>> blob (for, as I suspect, faster access).
>
> This is quite a good idea, because then it's up to the OS to decide how
> to handle conflicts (eg if two apps try to set the same thing in their
> own XML). Also then when you uninstall you can just delete the XML and
> know that any settings from that app no longer have any influence. In
> Windows on the other hand it's simply whichever application changed the
> value most recently that wins.
>
> However does this mean that every time a program writes to the registry
> the OS must recompile everything?

Compiling just creates the key names and their default values. Actually 
reading and writing doesn't require recompilation.

Also, recompiling takes approx 400 ms on my virtual machine...

Let me just repeat again: Settings have default values. And textual 
descriptions [which are often less helpful than you'd like].

Under Windows, if you mistype the registry key, it just creates a new 
key [which then uselessly does nothing]. Under Gsettings, it whines "no 
such schema" or similar.

The *really* annoying part is that Gsettings appears to totally stop 
working if X isn't running. It's also maddeningly hard to change another 
user's settings...

Post a reply to this message

On Tue, 30 Oct 2012 11:33:22 -0400, Francois Labreque wrote:

>> BTW, some commercial Unixes like HP-UX do provide proper ACLs (they
>> even use that very term for the feature).
>>
>>
> And recen versions of Novell's NDS are exactly that too.

Well, Novell's product (actually, NetIQ's product now - since they were 
acquired by Attachmate last May and the identity products have mostly 
shifted to the NetIQ business unit) is eDirectory, and it doesn't do 
filesystem permissions - it manages the identities used in filesystem 
permission entries in the directory entry tables in NSS and TFS volumes.

I wonder, though, how difficult it would be to use eDir identities as 
part of *nix ACLs - probably not hard, just need the RFC2307 (IIRC) 
extensions installed to map uid/gid to the OS, and integrate pam 
authentication with the LDAP server. :)

Jim

Post a reply to this message

On 10/30/2012 1:46 AM, Orchid Win7 v1 wrote:
>> Still, even something like,
>> "Export all keys specific to this application.", would have been nice.
>
> What makes you think you can't do that?
>
It can't. To do that would require exporting "all linked keys". That 
means that you search for, say, Explorer, and you don't get get the key 
"USER-Explorer-...", you also get the 5-6 hexidecimal keys for its 
components, keys in other sections, which relate, etc. You have to know 
what all of them are, and either mark them yourself, or export them each 
separately, as far as I can tell. And, just searching for what key you 
need is a pain in the ass sometimes (especially if it turns out that the 
specific thing you are looking for is one of those "hidden" settings, 
which is not normally in the registry at all, nor documented any place 
obvious, no accessible through any of the user menus).

Post a reply to this message

On 10/30/2012 1:40 AM, Orchid Win7 v1 wrote:
>>>> Snort.. Actually, the problem with the windows registry are:
>>>>
>>>> 1. Can't read the damn thing, without the editor.
>>>
>>> Why is that a problem? You always need some sort of software to read a
>>> computer file and regedit comes with Windows.
>>>
>> Uh.. Because the editor sucks
>
> ...which leads us back to "you're not supposed to touch this stuff
> manually".
>
> Ever tried using e2fstune? Not very intuitive, is it? Then again, how
> often do you even need to touch it?
>
>> (like, for example, listing all
>> related keys, in a filter of some sort, not using notepad, or a pad of
>> paper to write down keys, while hunting through a dozen extra searches
>> to find them all).
>
> 1. The registry editor is perfectly capable of dumping chunks of the
> registry as text. It also has a search function. (Admittedly it's not
> very scriptable.)
>
> 2. You can write your own application to access the registry. Hell, it's
> probably quite easy to throw something together in VB to do a quick
> search or two...
:snark: and how much of what that is supposed to do is "undocumented", 
in the same way that, prior to completely changing the system, you 
couldn't find any documentation on how the hell ActiveX interfaced with 
the scripting system, in their own editor, and Informal Exploder, so you 
could move them around on your "form"? :/snark:

That was about when I gave up looking to Microsoft's own documentation 
for anything useful. Here is how to add scripting: ... Here is how to 
create and use ActiveX controls: ... What, you actually want to, without 
creating new wrappers, and all the other BS, use the inbuilt ActiveX 
controls, with scripting, and, *Gasp!* go into "design mode" with them, 
so you can create custom layouts in your own applications? What, are you 
one something!? Yeah.. It would be nice to do that!!!

At the time ***one*** company I could find found a solution to the 
problem. There solution turned out to be, "Design controls that act 
exactly like the inbuilt ones, but which *we* could switch modes with, 
ourselves." The other solution was to leave them active, but wrapper 
them in a completely redundant method, which did nothing more than 
temporarily make them non-visible, draw a box where they where supposed 
to be, and provide drag handles. Redundant because this wasn't necessary 
in the original controls, in the compiler suite, they already have that 
functionality.

There are hints, all over the place, that its, at least in theory, 
possible to tell the OS to switch a specific form to that mode. There is 
jack all saying how, what messages to use to do it, etc.

Later, as I said, they, sort of, fixed this, but basically killing the 
old ActiveX entirely, and replacing it with something else, which 
included more sane methods to talk to, and get information back from, 
never mind instance, controls.

But, even the documentation for that is minimalist, and nearly useless. 
I have no idea if "design mode" is still something only a hacker, with 
detailed understanding of the OS internal messaging, has a clue how to 
access.

So, sure.. You can probably write something to access the registry, 
but... will it actually do what it claims to?

Post a reply to this message

On 10/30/2012 1:48 AM, scott wrote:
>> A lot of developers write magic numbers to the registry so that when
>> your trial period ends, uninstalling and reinstalling the application
>> will not reset your trial period.
>
> Is this method really used? There are programs to record all
> reads/writes to the registry, so you really can delete all the keys
> created. Or you just restore a backup of the registry to start the trial
> again. I suspect they are a bit more cunning than this.
>
Yeah, it is. There are very few programs out that track changes though, 
and they are usually "security" type things, like one called scoty (or 
something like that), which watch dog they thing, so look for odd 
changes, like something adding a new startup program some place (it 
catches everything doing that, so even legit stuff gives a pop-up, which 
can be interesting...) Other cases may be hidden files, in odd places, 
etc. One of the kind of interesting ones is a "give away of the day" 
thing, which doesn't actually demo, its installer actually registers it, 
within the 24 hours of the give away, and flat refuses to install it as 
a working application, if the server says "no".

But, in general, adding some sort of flag to the registry, with a date, 
or the like, is the simplest solution. So, in principle, if you knew 
what changed, you could undo it.

Post a reply to this message

Am 31.10.2012 04:14, schrieb Patrick Elliott:

>> 2. You can write your own application to access the registry. Hell, it's
>> probably quite easy to throw something together in VB to do a quick
>> search or two...
> :snark: and how much of what that is supposed to do is "undocumented",
> in the same way that, prior to completely changing the system, you
> couldn't find any documentation on how the hell ActiveX interfaced with
> the scripting system, in their own editor, and Informal Exploder, so you
> could move them around on your "form"? :/snark:
[lots of ranting about ActiveX deleted]

What, exactly, does that have to do with accessing the registry?

> So, sure.. You can probably write something to access the registry,
> but... will it actually do what it claims to?

The question is not whether it will actually do what it claims to, but 
whether you know what you want it to do.


Your list of things you'd like to be able to do includes "listing all 
related keys". Guess what - per definition of the registry, regedit does 
that already: The only "native" relationship of registry keys is in the 
hierarchical tree structure of sections.

Each and every other relationship between registry keys is only by 
convention of individual services and applications - such as the Windows 
explorer assigning file extensions to file types, and file types to 
applications. Or the device manager linking drivers to devices. Or what 
the heck.

At the end of the day, you DO need service- or application-specific 
knowledge if you want to edit the registry, because it's services and 
applications that assign semantics to the raw data they store in there.

Post a reply to this message

> That was about when I gave up looking to Microsoft's own documentation
> for anything useful.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms724871(v=vs.85).aspx

or for .net languages:

http://msdn.microsoft.com/en-us/library/microsoft.win32.registry(v=vs.100).aspx

If you don't find that useful then I don't know what you are expecting...

Post a reply to this message

> Yeah, it is. There are very few programs out that track changes though,
> and they are usually "security" type things, like one called scoty (or
> something like that), which watch dog they thing, so look for odd
> changes, like something adding a new startup program some place (it
> catches everything doing that, so even legit stuff gives a pop-up, which
> can be interesting...)

A quick google for "registry watcher" gives millions of results, and the 
WinAPI even has a function RegNotifyChangeKeyValue that you can easily 
use to watch the whole registry if you can write a few lines of code. I 
just doubt they use this method as I have tried it before and failed, 
and if they did there would be simple registry hacks all over the web to 
get full versions of software (which there very rarely is).

> Other cases may be hidden files, in odd places,
> etc.

Maybe, but again that is easy to detect if they use standard API calls 
(there are plenty of "file watcher" type programs, or you can easily 
write your own). Again, if this were the case there would be simple 
instructions available online like "delete this file to restart the 
trial", but you don't often see that.

> One of the kind of interesting ones is a "give away of the day"
> thing, which doesn't actually demo, its installer actually registers it,
> within the 24 hours of the give away, and flat refuses to install it as
> a working application, if the server says "no".

Indeed, nowadays it's easy to do if you assume internet access is 
available, you just check with the server with some key generated from 
the machine (using mac address) and refuse to run if the server says no.

> But, in general, adding some sort of flag to the registry, with a date,
> or the like, is the simplest solution. So, in principle, if you knew
> what changed, you could undo it.

Of course it is the simplest, but does any real software actually use 
only that method? IME not, for example try www.bobstrackbuilder.net - 
even a low-budget program from a single coder does not use that method, 
so I highly doubt more "commercial" programs like PhotoShop etc would 
use such an easily hacked method.

Post a reply to this message

On 31/10/2012 03:01 AM, Patrick Elliott wrote:
> On 10/30/2012 1:46 AM, Orchid Win7 v1 wrote:
>>> Still, even something like,
>>> "Export all keys specific to this application.", would have been nice.
>>
>> What makes you think you can't do that?
>>
> It can't. To do that would require exporting "all linked keys". That
> means that you search for, say, Explorer, and you don't get get the key
> "USER-Explorer-...", you also get the 5-6 hexidecimal keys for its
> components, keys in other sections, which relate, etc. You have to know
> what all of them are, and either mark them yourself, or export them each
> separately, as far as I can tell. And, just searching for what key you
> need is a pain in the ass sometimes (especially if it turns out that the
> specific thing you are looking for is one of those "hidden" settings,
> which is not normally in the registry at all, nor documented any place
> obvious, no accessible through any of the user menus).

Grabbing all the keys related to one application is usually easy enough. 
Figuring out what all that stuff /means/? Yeah, not so easy. And finding 
all the settings that get changed for /other/ programs when you install 
the application (e.g., registering COM servers, changing the system 
search path, hooking into the Windows Explorer context menus, etc.) is 
not easy at all...

Then again, there are tools for monitoring the registry and recording 
changes to it. It still won't help you figure out what the changes 
/mean/, but it makes it fairly easy to capture them.

(My personal favourite is how changing from the lame "Windows XP" theme 
to the sane "classic theme" doesn't just change one registry key that 
says "theme name" or something - it actually changes eighty bazillion 
keys all over the registry. Consequently, it's absolutely impossible to 
script the damned thing!)

Post a reply to this message

On 31/10/2012 08:22 AM, scott wrote:
>> That was about when I gave up looking to Microsoft's own documentation
>> for anything useful.
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms724871(v=vs.85).aspx
>
>
> or for .net languages:
>
> http://msdn.microsoft.com/en-us/library/microsoft.win32.registry(v=vs.100).aspx
>
>
> If you don't find that useful then I don't know what you are expecting...

Now try finding any shred of useful documentation about the object model 
used for GNOME 3 shell extensions. Because I've wasted countless hours 
fruitlessly searching the web for anything like that. MS's documentation 
is vague at times, but at least you can /find/ it...

Post a reply to this message

> Compiling just creates the key names and their default values. Actually
> reading and writing doesn't require recompilation.

So compiling is only needed when new keys are created or existing ones 
deleted?

> Also, recompiling takes approx 400 ms on my virtual machine...

And how many key-value pairs is that compared to the Windows registry? 
:-) (comparing the size of the binary compiled version with the windows 
registry might be a rough indication)

Post a reply to this message

> (My personal favourite is how changing from the lame "Windows XP" theme
> to the sane "classic theme" doesn't just change one registry key that
> says "theme name" or something - it actually changes eighty bazillion
> keys all over the registry. Consequently, it's absolutely impossible to
> script the damned thing!)

How come it's impossible? Compare the registry before and after and 
export the changes to a .reg file. Plenty of software available to do 
that or write your own in a few lines.

Post a reply to this message

Le 2012-10-31 04:54, Orchid Win7 v1 a écrit :
> On 31/10/2012 08:22 AM, scott wrote:
>>> That was about when I gave up looking to Microsoft's own documentation
>>> for anything useful.
>>
>> http://msdn.microsoft.com/en-us/library/windows/desktop/ms724871(v=vs.85).aspx
>>
>>
>>
>> or for .net languages:
>>
>> http://msdn.microsoft.com/en-us/library/microsoft.win32.registry(v=vs.100).aspx
>>
>>
>>
>> If you don't find that useful then I don't know what you are expecting...
>
> Now try finding any shred of useful documentation about the object model
> used for GNOME 3 shell extensions. Because I've wasted countless hours
> fruitlessly searching the web for anything like that. MS's documentation
> is vague at times, but at least you can /find/ it...

Use the Source, Luke!

;)

-- 
/*Francois Labreque*/#local a=x+y;#local b=x+a;#local c=a+b;#macro P(F//
/*    flabreque    */L)polygon{5,F,F+z,L+z,L,F pigment{rgb 9}}#end union
/*        @        */{P(0,a)P(a,b)P(b,c)P(2*a,2*b)P(2*b,b+c)P(b+c,<2,3>)
/*   gmail.com     */}camera{orthographic location<6,1.25,-6>look_at a }

Post a reply to this message

On 10/31/2012 1:22 AM, scott wrote:
>> That was about when I gave up looking to Microsoft's own documentation
>> for anything useful.
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms724871(v=vs.85).aspx
>
>
> or for .net languages:
>
> http://msdn.microsoft.com/en-us/library/microsoft.win32.registry(v=vs.100).aspx
>
>
> If you don't find that useful then I don't know what you are expecting...
>
I am not saying that they don't "sometimes" provide clear documentation. 
Just that, the more specific the information, the less likely you will 
find something useful on it. The registry is fairly simple, so, its 
pretty hard for them to screw up documentation on the API to access it. 
Or, maybe they just didn't try hard enough. lol

Post a reply to this message

On 10/31/2012 1:42 AM, scott wrote:
>> But, in general, adding some sort of flag to the registry, with a date,
>> or the like, is the simplest solution. So, in principle, if you knew
>> what changed, you could undo it.
>
> Of course it is the simplest, but does any real software actually use
> only that method? IME not, for example try www.bobstrackbuilder.net -
> even a low-budget program from a single coder does not use that method,
> so I highly doubt more "commercial" programs like PhotoShop etc would
> use such an easily hacked method.
>
True. Sometimes its dang hard to work out how they do manage it, but, 
its got to be "someplace" on your machine, and there are a finite number 
of things they can do to manage it.

Post a reply to this message

On 31/10/2012 09:14 AM, scott wrote:
>> Compiling just creates the key names and their default values. Actually
>> reading and writing doesn't require recompilation.
>
> So compiling is only needed when new keys are created or existing ones
> deleted?

Yes, basically.

>> Also, recompiling takes approx 400 ms on my virtual machine...
>
> And how many key-value pairs is that compared to the Windows registry?
> :-) (comparing the size of the binary compiled version with the windows
> registry might be a rough indication)

Well, considering that only GNOME itself and a tiny few GNOME 
applications use this thing so far... yeah, not very big.

Post a reply to this message

On 31/10/2012 09:25 AM, scott wrote:
>> (My personal favourite is how changing from the lame "Windows XP" theme
>> to the sane "classic theme" doesn't just change one registry key that
>> says "theme name" or something - it actually changes eighty bazillion
>> keys all over the registry. Consequently, it's absolutely impossible to
>> script the damned thing!)
>
> How come it's impossible? Compare the registry before and after and
> export the changes to a .reg file. Plenty of software available to do
> that or write your own in a few lines.

Yes, but every time you click an icon or open a window hundreds of 
registry accesses happen. Trying to isolate just those related to the 
theme change is the hard part...

Post a reply to this message

>> Now try finding any shred of useful documentation about the object model
>> used for GNOME 3 shell extensions. Because I've wasted countless hours
>> fruitlessly searching the web for anything like that. MS's documentation
>> is vague at times, but at least you can /find/ it...
>
> Use the Source, Luke!
>
> ;)

Yeah. One guy said in a forum post "is there really no official list of 
[GNOME shell stock icon names]". And somebody replied "there is no such 
list, and nor should there be - the source code is the documentation".

Considering that the source code is in JavaScript, and it's nearly 
impossible to comprehend without knowing what the intention behind it 
was, this is an extremely stupid statement. :-P

Post a reply to this message

On Wed, 31 Oct 2012 18:16:22 +0000, Orchid Win7 v1 wrote:

> Yes, but every time you click an icon or open a window hundreds of
> registry accesses happen. Trying to isolate just those related to the
> theme change is the hard part...

"Compare before and after" is not the same as "track every access".

Jim

Post a reply to this message

>> Yes, but every time you click an icon or open a window hundreds of
>> registry accesses happen. Trying to isolate just those related to the
>> theme change is the hard part...
>
> "Compare before and after" is not the same as "track every access".

OK. But that still doesn't detract from the actual problem: whether you 
track every individual access, or just the before and after images, the 
problem is that you can't just grab a bunch of registry changes, apply 
them to another machine, and expect it to do the same thing. It's not 
that simple.

Every time I log onto a new machine, it takes me about 20 minutes to 
turn off all the annoying Explorer shell stuff I don't want. (The hiding 
of files and file extensions, the retarded Start menu, the tray 
auto-hide, etc.) The dream was that I could track down the actual 
registry changes that underlie each of these configurations, and write 
an automated script that would instantly turn off all the stupid 
settings and give me a usable desktop on any machine.

To some extent, I was able to do this. But theming never, ever worked. 
There are *far* too many registry keys involved. When you change theme, 
there are DLLs literally setting the number of pixels for the thickness 
of a window title bar, the number of pixels to allocate for button 
corners, and so forth. Way, way too much stuff to script, or even 
comprehend. Separating the significant registry changes from the 
insignificant ones proved just too hard.

(I still secretly dream that somewhere, there's some COM object you can 
invoke which just *does* it all for you... But since I'm no longer using 
Windows XP, I guess it doesn't even matter any more.)

Post a reply to this message

On Wed, 31 Oct 2012 21:12:15 +0000, Orchid Win7 v1 wrote:

>>> Yes, but every time you click an icon or open a window hundreds of
>>> registry accesses happen. Trying to isolate just those related to the
>>> theme change is the hard part...
>>
>> "Compare before and after" is not the same as "track every access".
> 
> OK. But that still doesn't detract from the actual problem: whether you
> track every individual access, or just the before and after images, the
> problem is that you can't just grab a bunch of registry changes, apply
> them to another machine, and expect it to do the same thing. It's not
> that simple.

Perhaps you're unaware that there are software distribution tools that 
employ just this sort of mechanism?  I worked for a company where about 
6,000 desktops had applications delivered to them using this type of 
application management technology, in fact.

It does require testing and knowledge to do right.  It's far from 
impossible.

I feel I must repeat something I've said to you over and over and over 
and over and OVER again:  Just because YOU can't do something does NOT 
mean it is "impossible".

Jim

Post a reply to this message

>> OK. But that still doesn't detract from the actual problem: whether you
>> track every individual access, or just the before and after images, the
>> problem is that you can't just grab a bunch of registry changes, apply
>> them to another machine, and expect it to do the same thing. It's not
>> that simple.
>
> Perhaps you're unaware that there are software distribution tools that
> employ just this sort of mechanism?  I worked for a company where about
> 6,000 desktops had applications delivered to them using this type of
> application management technology, in fact.
>
> It does require testing and knowledge to do right.  It's far from
> impossible.

6,000 *identical* desktops, I would imagine.

In that case, yeah, it might work. Just like if you have 6,000 
*identical* desktops, you can apply the same Ghost image to all of them, 
and this actually works correctly.

What *I* was trying to do is construct a script which will work on *any* 
Windows XP installation. That is a much harder task.

> I feel I must repeat something I've said to you over and over and over
> and over and OVER again:  Just because YOU can't do something does NOT
> mean it is "impossible".

If you want to split hairs, it is technically "possible" to unscramble 
an egg. According to the laws of physics, scrambling an egg ought to be 
a completely reversible operation. (Time invariance, and all that.) But 
to date, nobody has ever succeeded in actually doing this.

There are things which are truly *impossible*. (E.g., travel faster than 
light.) And then there are things which are theoretically possible, but 
so absurdly hard that nobody would bother trying. (E.g., unscrambling an 
egg.)

Some things are easy, some things are hard. Some things are hard enough 
that for all /practical/ purposes, it's impossible. Somebody with access 
to insider knowledge about how the Windows Explorer shell works 
internally might be able to put together a registry hack that changes 
the theme. Somebody with access to thousands of test systems and with 
the time and motivation to reverse-engineer this stuff might be able to 
figure it out. One lone guy with a registry monitor? Not a chance.

And that is really all I was trying to say.

Post a reply to this message

On Wed, 31 Oct 2012 21:54:42 +0000, Orchid Win7 v1 wrote:

>> It does require testing and knowledge to do right.  It's far from
>> impossible.
> 
> 6,000 *identical* desktops, I would imagine.

You imagine incorrectly.  A few base images to account for different 
hardware, but no, given that there were about 25 offices around the 
country and systems in different places in their usable life, no, they 
were not all identical.

> What *I* was trying to do is construct a script which will work on *any*
> Windows XP installation. That is a much harder task.

Not really, because application settings are generally not dependent on 
the hardware.  The same is true for theming elements.

>> I feel I must repeat something I've said to you over and over and over
>> and over and OVER again:  Just because YOU can't do something does NOT
>> mean it is "impossible".
> 
> If you want to split hairs, it is technically "possible" to unscramble
> an egg. According to the laws of physics, scrambling an egg ought to be
> a completely reversible operation. (Time invariance, and all that.) But
> to date, nobody has ever succeeded in actually doing this.
> 
> There are things which are truly *impossible*. (E.g., travel faster than
> light.) And then there are things which are theoretically possible, but
> so absurdly hard that nobody would bother trying. (E.g., unscrambling an
> egg.)

Yes, there are things that are impossible.  But you tend to take tasks 
that you've determined are non-trivial or that you can't figure out and 
declare that they're totally "impossible".  Exporting the correct Windows 
registry settings for a particular purpose is not "unscrambling an egg".

> Some things are easy, some things are hard. Some things are hard enough
> that for all /practical/ purposes, it's impossible. Somebody with access
> to insider knowledge about how the Windows Explorer shell works
> internally might be able to put together a registry hack that changes
> the theme. Somebody with access to thousands of test systems and with
> the time and motivation to reverse-engineer this stuff might be able to
> figure it out. One lone guy with a registry monitor? Not a chance.

Again, you are not correct about this.  There are tools that make it 
easier, and yes, a lone guy with a registry monitor does stand a chance 
at this "impossible" task - because (and I want you to listen very 
carefully here):  IT IS NOT IMPOSSIBLE! :)

> And that is really all I was trying to say.

And what I'm trying to say is that you are simply wrong.

Jim

Post a reply to this message

> Every time I log onto a new machine, it takes me about 20 minutes to
> turn off all the annoying Explorer shell stuff I don't want. (The hiding
> of files and file extensions, the retarded Start menu, the tray
> auto-hide, etc.) The dream was that I could track down the actual
> registry changes that underlie each of these configurations, and write
> an automated script that would instantly turn off all the stupid
> settings and give me a usable desktop on any machine.
>
> To some extent, I was able to do this. But theming never, ever worked.
> There are *far* too many registry keys involved. When you change theme,
> there are DLLs literally setting the number of pixels for the thickness
> of a window title bar, the number of pixels to allocate for button
> corners, and so forth. Way, way too much stuff to script, or even
> comprehend. Separating the significant registry changes from the
> insignificant ones proved just too hard.

Directly hitting the registry for that is probably not the best way, did 
you investigate using control.exe from the command line to do it? 
Something like "control.exe desk.cpl desk,@Themes" should get you 
started, but you'll need to google a few more parameters to set what you 
want.

Post a reply to this message

> Directly hitting the registry for that is probably not the best way, did
> you investigate using control.exe from the command line to do it?
> Something like "control.exe desk.cpl desk,@Themes" should get you
> started, but you'll need to google a few more parameters to set what you
> want.

Thinking about it a bit more, you'd be better off making all your 
changes by hand once then saving it as a custom theme file. Then google 
"set theme command line" - it's easy. No idea if the theme file format 
is the same for different versions of windows, you might have to make 
one for each version.

Post a reply to this message

scott wrote:
> I'm pretty sure I've tried with a few trial apps (a long time ago) to
> find out how they were detecting I'd already run the trial but
> couldn't figure it out (after logging registry and file changes). They
> must be using something a bit more sophisticated.

Some of them actually write something into the gap behind the master 
boot record. This works in the case of windows boot loaders which don't 
use it. Other boot loaders, for example GRUB, are located in this gap. 
Installing one of these trial applications can therefore ruin your 
bootloader. Luckily, this never happened to me. (Only report I found 
with a quick search: http://superuser.com/a/192082)

Post a reply to this message