«

On Thu, 31 Dec 2009 17:16:31 +1300, Lawrence D'Oliveiro
<_zealand> wrote:

>In message <>, Erik Vastmasd wrote:
>
>> Does it force you to install Agent on C: ?
>
>What kind of stone-age OS is it where you even need to ask?

Agreed. Although I would rate that behaviour as somewhat earlier than
stone age - it is more like back before we developed brains.

On Fri, 01 Jan 2010 00:01:32 +1300, Lawrence D'Oliveiro wrote:

> In message <>, Carnations wrote:
>
>>> The reason is historical, as I understand it. There were two groups
>>> within Microsoft creating an email client, one associated with the
>>> browser group and one with the office system group.
>>
>> Thats as if Microsoft has very poor internal communication.
>
> Conway’s Law: any engineering endeavour reflects the organizational
> structure that produced it.

Which would explain why Microsoft Windows Vista Ultimate (and the various variously crippled
incarnations thereof) took about 10 years to evolve from the previously released version (MS Windows
XP Professional) and was released before it was actually ready; and why Microsoft's software in
general is hideously complicated, convoluted, and prone to multiple security flaws; and why many
longstanding fundamental usability flaws have not been fixed.


--
"Filtering the Internet is like trying to boil the ocean"

In message <>, Stephen Worthington
wrote:

> And IMHO, there are few reasons why apps actually need to use
> the registry at all ..

It was supposed to be a substitute for the previous profusion of .ini files
scattered willy-nilly over the filesystem. Trouble was, it was a
technological solution to what was really a social problem: because nobody
was in a position to enforce discipline in the form of a Filesystem
Hierarchy Standard (writable systemwide config in /etc, read-only data in
/usr/share and so on), the only way to manage the filesystem clutter was to
hide all that data in a centralized database. Which then became a single
point of failure.

> Last time I investigated, many years ago, the registry API calls were
> hideously slow ...

I’m really surprised this could ever have been the case. The whole point
with a binary file format is that you can make accesses fast with multiple
indexes etc. And enforcing access through a common API allows you to manage
locking for concurrent access, as well as caching of frequently-accessed
data.

But what you’re saying is that Microsoft has managed to incorporate the
worst of both worlds: the inefficiency of, say, storing everything in XML,
with the fragility of a binary file format.

In message <>, Stephen Worthington
wrote:

> On Thu, 31 Dec 2009 17:16:31 +1300, Lawrence D'Oliveiro
> <_zealand> wrote:
>
>>In message <>, Erik Vastmasd wrote:
>>
>>> Does it force you to install Agent on C: ?
>>
>>What kind of stone-age OS is it where you even need to ask?
>
> Agreed. Although I would rate that behaviour as somewhat earlier than
> stone age - it is more like back before we developed brains.

Most OSes around that time (1970s) used device specifiers of some sort in
their filespecs—though admittedly not usually limited to a single letter.

The notable exception was Unix, which from the beginning tried to make
everything look transparently like a single filesystem. Which, while it was
not a perfect abstraction, in retrospect looks amazingly farsighted.

Lawrence D'Oliveiro wrote:
> In message <>, Stephen
> Worthington wrote:
>
>> And IMHO, there are few reasons why apps actually need to use the
>> registry at all ..
>
> It was supposed to be a substitute for the previous profusion of .ini
> files scattered willy-nilly over the filesystem.
>
Except that they weren't. Applications kept there ini files in their own
directories, and the driver ini files were also in a well-known
location. The real reason was that what with applications being on slow
disks and floppies that *performance* was an issue.
>
> Trouble was, it was a technological solution to what was really a
> social problem: because nobody was in a position to enforce
> discipline in the form of a Filesystem Hierarchy Standard (writable
> systemwide config in /etc, read-only data in /usr/share and so on),
>
Microsoft was not in a position to enforce discipline and a FSS? Who are
you trying to kid?
>
> the only way to manage the filesystem clutter was to hide all that
> data in a centralized database. Which then became a single point of
> failure.
>
No, the simplest thing would be to have a single directory, let's call
it \etc which would contain all ini files in a hierarchy. Since they
were all in one place someone decided to make it a JET database.
(Incidentally the JET database is the Windows equivalent of, say, BDB.
It just works and rarely errors). That was not altogether a good
decision, since it did hide the data somewhat. But it wasn't altogether
a bad one either.

Cheers,

Cliff

--

The Internet is interesting in that although the nicknames may change,
the same old personalities show through.

On Sun, 03 Jan 2010 14:34:58 +1300, Enkidu wrote:

>> the only way to manage the filesystem clutter was to hide all that data
>> in a centralized database. Which then became a single point of failure.
>>
> No, the simplest thing would be to have a single directory, let's call
> it \etc which would contain all ini files in a hierarchy. Since they
> were all in one place someone decided to make it a JET database.
> (Incidentally the JET database is the Windows equivalent of, say, BDB.
> It just works and rarely errors). That was not altogether a good
> decision, since it did hide the data somewhat. But it wasn't altogether
> a bad one either.

Indeed it was a bad decision - it introduced a single point of failure for the entire OS and all applications
storing stuff in the registry.

Microsoft recognised that it was a single point of failure. How many backups of the registry does MS
Windows hold?

Despite that, how many times have you heard of accounts where the OS had to be completely
reinstalled due to the registry having been corrupted?

Also, if Apple is able to enforce a filesystem heirarchy standard, and if Linux distributions can do the
same, then why is Microsoft unable to do that?

I can't see why it would improve performance to use a registry like what MS used - over time it expands
and becomes like Swiss cheese, and there is no uniform size for each record in the registry.


--
"Filtering the Internet is like trying to boil the ocean"

Carnations wrote:
> On Sun, 03 Jan 2010 14:34:58 +1300, Enkidu wrote:
>
>>> the only way to manage the filesystem clutter was to hide all
>>> that data in a centralized database. Which then became a single
>>> point of failure.
>>>
>> No, the simplest thing would be to have a single directory, let's
>> call it \etc which would contain all ini files in a hierarchy.
>> Since they were all in one place someone decided to make it a JET
>> database. (Incidentally the JET database is the Windows equivalent
>> of, say, BDB. It just works and rarely errors). That was not
>> altogether a good decision, since it did hide the data somewhat.
>> But it wasn't altogether a bad one either.
>
> Indeed it was a bad decision - it introduced a single point of
> failure for the entire OS and all applications storing stuff in the
> registry.
>
The OS, be it Linux or Windows is a SPOF! If your /etc filesystem is
borked, your system is borked. It adds no extra SPOF to the system.
>
> Microsoft recognised that it was a single point of failure. How many
> backups of the registry does MS Windows hold?
>
What do you mean by backups? So far as I know there is one *copy*, and
the registry is usually help in RAM.
>
> Despite that, how many times have you heard of accounts where the OS
> had to be completely reinstalled due to the registry having been
> corrupted?
>
Not that many.
>
> Also, if Apple is able to enforce a filesystem heirarchy standard,
> and if Linux distributions can do the same, then why is Microsoft
> unable to do that?
>
They do. Every single Windows machine with the same OS has the same file
system structure.
>
> I can't see why it would improve performance to use a registry like
> what MS used - over time it expands and becomes like Swiss cheese,
> and there is no uniform size for each record in the registry.
>
That I believe is partly a side effect of the JET database but mostly
it's due to mostly non-MS apps that don't clear up after themselves. In
any case, the JET database will compact and tidy itself to some extent.
It sounds like you are talking about a very early version. The worst
thing that you can do is use a Registry Cleaner on it.

Cheers,

Cliff

--

The Internet is interesting in that although the nicknames may change,
the same old personalities show through.

On Sun, 03 Jan 2010 16:10:12 +1300, Enkidu wrote:

>> Indeed it was a bad decision - it introduced a single point of failure
>> for the entire OS and all applications storing stuff in the registry.
>>
> The OS, be it Linux or Windows is a SPOF! If your /etc filesystem is
> borked, your system is borked. It adds no extra SPOF to the system.

Yes, but how many times would /etc get trashed by simply writing to one document somewhere in that
directory?


>> Microsoft recognised that it was a single point of failure. How many
>> backups of the registry does MS Windows hold?
>>
> What do you mean by backups? So far as I know there is one *copy*, and
> the registry is usually help in RAM.

And when it's shut down where is the registry held? And when alterations are made to the registry
where are they written to?

And what happens if that copy on disc is corrupted?


--
"Filtering the Internet is like trying to boil the ocean"

In message <>, Sweetpea wrote:

> Yes, but how many times would /etc get trashed by simply writing to one
> document somewhere in that directory?

Never.

Sweetpea wrote:
> On Sun, 03 Jan 2010 16:10:12 +1300, Enkidu wrote:
>
>>> Indeed it was a bad decision - it introduced a single point of
>>> failure for the entire OS and all applications storing stuff in
>>> the registry.
>>>
>> The OS, be it Linux or Windows is a SPOF! If your /etc filesystem
>> is borked, your system is borked. It adds no extra SPOF to the
>> system.
>
> Yes, but how many times would /etc get trashed by simply writing to
> one document somewhere in that directory?
>
Well, I've never known the Windows registry get trashed by simply
writing to it. Adding a key or changing data is not that dangerous and
the shock horror warnings that are associated with doing things to the
registry are a) to scare off the fiddlers, b) overstated. I've seen
several trashed registries, and all, so far as I can remember, were due
to someone running a 'registry cleaner' application. I've seen far more
user profile corruptions than registry corruptions. Note that part of
the registry user hive is read from the user profile which could give
the impression of registry corruption.
>
>>> Microsoft recognised that it was a single point of failure. How
>>> many backups of the registry does MS Windows hold?
>>>
>> What do you mean by backups? So far as I know there is one *copy*,
>> and the registry is usually help in RAM.
>
> And when it's shut down where is the registry held? And when
> alterations are made to the registry where are they written to?
>
Registry changes are made to the memory copy. These are written to disc
redundantly when the system is shutdown (and possibly at other times).
>
> And what happens if that copy on disc is corrupted?
>
About the same as if your /etc gets corrupted.

Cheers,

Cliff

--

The Internet is interesting in that although the nicknames may change,
the same old personalities show through.