![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |