Reading .ini files in ANSI C

[Guillaume Dargaud]

Hello all,
anybody knows if there's some ANSI-C conformant code around that can read
Windows-style .ini files ? I don't care about writing to it but I need to be
able to read it from various OSs, so there shouldn't be any Windows
includes.

It doesn't look like it's too hard to do, but there are a few tricks (like
multiple line strings), so I'd love to save some time (who doesn't).
--
Guillaume Dargaud
http://www.gdargaud.net/

[Jens Thoms Toerring]

Guillaume Dargaud <us*****************************@www.gdargaud.netw rote:

anybody knows if there's some ANSI-C conformant code around that can read
Windows-style .ini files ? I don't care about writing to it but I need to be
able to read it from various OSs, so there shouldn't be any Windows
includes.

What's wrong about using fopen(), fread() and fclose()?

It doesn't look like it's too hard to do, but there are a few tricks (like
multiple line strings), so I'd love to save some time (who doesn't).

Ah, you don't just want to read it but parse it also.
Well, a quick look at Google for "parser .ini files"
comes up with e.g. http://ndevilla.free.fr/iniparser
and http://sourceforge.net/projects/libini nearly at
the top.
Regards, Jens
--
\ Jens Thoms Toerring ___ [e-mail]
\__________________________ http://toerring.de

[Kenny McCormack]

In article <6b*************@mid.uni-berlin.de>,
Jens Thoms Toerring <[e-mail]:

>Guillaume Dargaud <us*****************************@www.gdargaud.netw rote:

>anybody knows if there's some ANSI-C conformant code around that can read
Windows-style .ini files ? I don't care about writing to it but I need to be
able to read it from various OSs, so there shouldn't be any Windows
includes.

You really gotta wonder why people bother to take the time to post these
useless responses. See below for further exposition.

>What's wrong about using fopen(), fread() and fclose()?

This is just useless posturing. Do you think anyone is amused by it.

(Oops, sorry. I guess Heathfield, et al, would be)

>It doesn't look like it's too hard to do, but there are a few tricks (like
multiple line strings), so I'd love to save some time (who doesn't).

Ah, you don't just want to read it but parse it also.
Well, a quick look at Google for "parser .ini files"
comes up with e.g. http://ndevilla.free.fr/iniparser
and http://sourceforge.net/projects/libini nearly at
the top.

Anybody can Google. The point is to see if anyone has been down this
road (presumably, many people have, though probably not many from the
CLC regs camp) and can recommend anything. Remember, Sturgeon's Law
applies to what you get from Googling, as much as it does to anything
else.

Now, for some actual content: I was down the road once long ago - I had
a need to use INI files in a Linux context, and I asked for help on Usenet,
making, in fact, a query quite similar to this one. I got, as you would
expect, a healthy dose of the usual anti-MS ranting, but I did
eventually get a pointer to a package that someone had developed that
looked quite good and useful. However, I never quite followed through
on it, and it was long ago, so I can't say anything more.

It might well have been the "libini" to which you refer to above, but do
keep in mind that Sturgeon's Law also applies to the projects at
sourceforge nowadays, as well.

[user923005]

On Jun 18, 9:24*am, "Guillaume Dargaud"
<[e-mail] rote:

Hello all,
anybody knows if there's some ANSI-C conformant code around that can read
Windows-style .ini files ? I don't care about writing to it but I need tobe
able to read it from various OSs, so there shouldn't be any Windows
includes.

It doesn't look like it's too hard to do, but there are a few tricks (like
multiple line strings), so I'd love to save some time (who doesn't).

Windows applications don't use ini files any more (or at least they
are not supposed to). Now they use the registry.

Anyway, maybe this can help:
http://sourceforge.net/search/index....de=0&limit=100

[Richard Heathfield]

user923005 said:

<snip>

Windows applications don't use ini files any more (or at least they
are not supposed to).

Tough cookies. Over the last couple of days I've been working on a Windows
application that uses an ini file...

Now they use the registry.

....because[1] I'm sick and tired of programs that clog up the stupid stupid
registry with stupid stupid cruft.

To install that application, my users need only copy it from wherever it is
to wherever they want it. If the ini file is not present, it will be
generated automagically.

To remove the application, they need only delete it. The user (who, for
this particular program, is very likely to be non-technical) doesn't have
to choose between messing about with a vital system component or trusting
an "uninstall" program to get it right (which very often turns out to be
trust misplaced, does it not?).

<snip>

[1] The "because" applies to the use of an ini file, not to the fact of
writing the program!

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[CBFalconer]

Guillaume Dargaud wrote:

>
anybody knows if there's some ANSI-C conformant code around that
can read Windows-style .ini files ? I don't care about writing to
it but I need to be able to read it from various OSs, so there
shouldn't be any Windows includes.

No problem. They are really just text files, obeying some
formatting rules. fopen, getc, and fclose can access them all.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Mark McIntyre]

Richard Heathfield wrote:

user923005 said:

<snip>

>Windows applications don't use ini files any more (or at least they
are not supposed to).

Tough cookies. Over the last couple of days I've been working on a Windows
application that uses an ini file...

>Now they use the registry.

...because[1] I'm sick and tired of programs that clog up the stupid stupid
registry with stupid stupid cruft.

Blame the programme writer, not windows. Check out how much cruft is
cluttering up /etc, /opt and /usr/local sometime.

To install that application, my users need only copy it from wherever it is
to wherever they want it. If the ini file is not present, it will be
generated automagically.

Fine if you're writing simple programmes that don't require much in the
way of support services. Not so fine if you have to install kernel
drivers, new versions of libraries etc.

And does this simple approach remove the config file from /etc the libs
from /usr/local/lib and the manpages and....

Please try not to sidestep into religious wars in CLC.

To remove the application, they need only delete it. The user (who, for
this particular program, is very likely to be non-technical) doesn't have
to choose between messing about with a vital system component or trusting
an "uninstall" program to get it right (which very often turns out to be
trust misplaced, does it not?).

Just as trust in 'make uninstall' is often misplaced (assuming the
writer actually shipped a makefile)?

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Richard Heathfield]

Mark McIntyre said:

Richard Heathfield wrote:

>user923005 said:

<snip>

>>Windows applications don't use ini files any more (or at least they
are not supposed to).

Tough cookies. Over the last couple of days I've been working on a
Windows application that uses an ini file...

>>Now they use the registry.

...because[1] I'm sick and tired of programs that clog up the stupid
stupid registry with stupid stupid cruft.

Blame the programme writer, not windows.

The existence of the stupid stupid registry *is* Windows's fault.
The existence of stupid stupid cruft in the stupid stupid registry is
indeed the fault of third-party program-writers - but Windows
documentation connives at and indeed encourages this stupidity.

Check out how much cruft is
cluttering up /etc, /opt and /usr/local sometime.

Right. How does that change anything about the stupid stupid registry?

<snip>

Please try not to sidestep into religious wars in CLC.

What religious wars? My reply wasn't anti-Windows. It was
anti-put-all-your-eggs-in-one-really-slow-and-heavy-basket. That isn't
anti-Windows any more than "don't use gets" is anti-C.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Mark McIntyre]

Richard Heathfield wrote:

Mark McIntyre said:

>Richard Heathfield wrote:

>>user923005 said:

<snip>

Windows applications don't use ini files any more (or at least they
are not supposed to).
Tough cookies. Over the last couple of days I've been working on a
Windows application that uses an ini file...

Now they use the registry.
...because[1] I'm sick and tired of programs that clog up the stupid
stupid registry with stupid stupid cruft.

Blame the programme writer, not windows.

The existence of the stupid stupid registry *is* Windows's fault.

There's nothing stupid about storing configuration information in a
database.

The existence of stupid stupid cruft in the stupid stupid registry is
indeed the fault of third-party program-writers - but Windows
documentation connives at and indeed encourages this stupidity.

Documentation is an entirely different matter, of course. Much of hte
Windows developer documentation is woeful.

>Check out how much cruft is
cluttering up /etc, /opt and /usr/local sometime.

Right. How does that change anything about the stupid stupid registry?

How does the stupid stupid registry differ from the stupid stupid /etc
and /opt and /usr/local? Answers such as "I can view /etc with a text
editor" will be laughed at.

>Please try not to sidestep into religious wars in CLC.

What religious wars? My reply wasn't anti-Windows.

Hmm. And Cromwell wasn't anti-Monarchist.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Richard Heathfield]

Mark McIntyre said:

Richard Heathfield wrote:

>Mark McIntyre said:

>>Richard Heathfield wrote:
user923005 said:

<snip>

Windows applications don't use ini files any more (or at least they
are not supposed to).
Tough cookies. Over the last couple of days I've been working on a
Windows application that uses an ini file...

Now they use the registry.
...because[1] I'm sick and tired of programs that clog up the stupid
stupid registry with stupid stupid cruft.
Blame the programme writer, not windows.

The existence of the stupid stupid registry *is* Windows's fault.

There's nothing stupid about storing configuration information in a
database.

Agreed, but it's a bit daft to put everybody's config info in the same
place, and then provide only a clunky O(n) interface to it. In my view,
that's pretty much the main reason that Windows boxes tend to slow to a
crawl over time, as more and more applications pour their gunk into the
registry.

A more sensible approach is for each application to store its own
configuration information in its own database - i.e. an ini file or
similar. This gives faster access and easier maintenance.

>The existence of stupid stupid cruft in the stupid stupid registry is
indeed the fault of third-party program-writers - but Windows
documentation connives at and indeed encourages this stupidity.

Documentation is an entirely different matter, of course. Much of hte
Windows developer documentation is woeful.

Actually, I find it quite reasonable compared to some of the Unix docs! :-)

>>Check out how much cruft is
cluttering up /etc, /opt and /usr/local sometime.

Right. How does that change anything about the stupid stupid registry?

How does the stupid stupid registry differ from the stupid stupid /etc
and /opt and /usr/local?

Not a lot, really - that's pretty dumb too - but at least each application
stores its stuff in its own files. Spreading it around over so many
(shared!) directories is what's dumb about it. Better to keep each
application and all its gubbinses in one place.

Answers such as "I can view /etc with a text
editor" will be laughed at.

<shrugI have never even /tried/ to view /etc with a text editor. It's a
directory, for pity's sake. Even granted that it's possible, I don't
really see the point.

>>Please try not to sidestep into religious wars in CLC.

What religious wars? My reply wasn't anti-Windows.

Hmm. And Cromwell wasn't anti-Monarchist.

Whether he was or wasn't, my reply wasn't anti-Windows.

I'm not a great fan of Windows, and I'm certainly not a great fan of
Microsoft, but I thoroughly enjoy writing Win32 programs - they're a lot
more fun than Unix or mainframe stuff, or even ISO C (which is what I do
most of). I will even go so far as to say that the Win32 API is the best
thing since sliced bread.

But the registry is just a dumb idea.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Dann Corbit]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:E-******************************@bt.com...
[snip]

But the registry is just a dumb idea.

Of course, Operating System stupidity is OT in news:comp.lang.c

<ot:Dann joins into the sin party>
The registry has been recommended by MS since <at least1996:
http://msdn.microsoft.com/en-us/library/ms970651.aspx
Actually, the idea of storing system information in a database is a very
good one.
However, the interface for exposing that information was a very bad design.
Dare I say 'bletcherous hack'?
Be that as it may, my statement was a statement of fact, and not an
endorsement.

If I were king of the operating system forest, all file operations would be
database operations, and file systems would use the network model like IMS
on the mainframe, CODASYL DBMS on the minicomputer or like Raima/Birdstep on
PCs. It is an obvious and natural fit. Things would be an enormous speedup
for anything and everything.

Since I am not king of the operating system forest (nor even prince nor
duke) I will just have to suffer along with whatever tragic cruft is handed
to me.

But hey, if they made this stuff to easy, what would we do with our
afternoons?
P.S.
I do think it makes a bit more sense to install user applications into
/usr/bin
rather than:
c:\program files\company name\application name\bin
especially since installation of a few hundred applications can bend our
poor little pc's path specification into something rather unpleasant.

But that is neither here nor there.
</ot:Dann joins into the sin party>
** Posted from http://www.teranews.com **

[Mark McIntyre]

Richard Heathfield wrote:

Mark McIntyre said:

>There's nothing stupid about storing configuration information in a
database.

Agreed, but it's a bit daft to put everybody's config info in the same
place, and then provide only a clunky O(n) interface to it.

I disagree the first point, but agree the second.

A more sensible approach is for each application to store its own
configuration information in its own database - i.e. an ini file or
similar. This gives faster access and easier maintenance.

The first is questionable, the second plain wrong.

However while this would be vaguely topical over in comp.programming its
not remotely so here so I don't propose to say anything further - except
to note that you're sounding more and more like an old fart by the
sentence ..... "its not money if you can't scratch glass with it..."
:-)

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Richard Heathfield]

Mark McIntyre said:

Richard Heathfield wrote:

>Mark McIntyre said:

>>There's nothing stupid about storing configuration information in a
database.

Agreed, but it's a bit daft to put everybody's config info in the same
place, and then provide only a clunky O(n) interface to it.

I disagree the first point, but agree the second.

Then you're wrong on the first point, and right on the second.

>A more sensible approach is for each application to store its own
configuration information in its own database - i.e. an ini file or
similar. This gives faster access and easier maintenance.

The first is questionable, the second plain wrong.

Not so. Applications can open and read files in nothing flat, whereas
reading the registry on a Win32 box with lots of apps installed is like
wading through treacle. Maintenance is easier too, because it's a darn
sight simpler to hack an ini file around than to go rooting around in the
registry (which is in any case an inherently unsafe thing to do for your
typical user). If an ini file gets corrupted, you might lose the use of an
application. If some heavy-booted fool messes up the registry, you could
lose the whole system.

However while this would be vaguely topical over in comp.programming its
not remotely so here so I don't propose to say anything further -

Fine by me.

<nonsense snipped>

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Bartc]

"Guillaume Dargaud" <us*****************************@www.gdargaud.netw rote
in message news:g3**********@ccpntc8.in2p3.fr...

Hello all,
anybody knows if there's some ANSI-C conformant code around that can read
Windows-style .ini files ? I don't care about writing to it but I need to
be able to read it from various OSs, so there shouldn't be any Windows
includes.

It doesn't look like it's too hard to do, but there are a few tricks (like
multiple line strings), so I'd love to save some time (who doesn't).

What do the files look like exactly? And what sort of interface do you want
to the file?

From memory, they were divided into 'sections' like this (made-up example):

[display]
resolution=640 480

[paths]
programs="c:\appl\bin\"
docs="c:\appl\doc\"

You would have to explain what is meant by multiline strings. From the above
so far it seems straightforward (or as straightforward as C's string
processing can make it).

I created an interface years ago to ini files looking something like this:

openinifile()
closeinifile()
nextinisection()
nextinivar()
findinisection()
findinivar()

The next..() functions were used to enumerate the contents of a file. The
find..() functions were used to return the value of a specific section or
var (by var I mean the name of an ini item).

So if you can't find ready-made code, a few C functions wouldn't be
difficult.

For updating ini files, I found it easier to just rewrite the whole file;
then no special functions are needed.

--
Bartc

[Mark McIntyre]

Richard Heathfield wrote:

>
Then you're wrong on the first point, and right on the second.

no

Not so.

*sigh*

>However while this would be vaguely topical over in comp.programming its
not remotely so here so I don't propose to say anything further -

Fine by me.

And yet you still felt obliged to continue the thread.

[Richard Bos]

Mark McIntyre <ma**********@TROUSERSspamcop.netwrote:

Richard Heathfield wrote:

Mark McIntyre said:

There's nothing stupid about storing configuration information in a
database.

Agreed, but it's a bit daft to put everybody's config info in the same
place, and then provide only a clunky O(n) interface to it.

I disagree the first point, but agree the second.

I must agree with both points. Without a proper DBMS (which M$ have
never had, and no, I don't count M$SQL), it's a security nightmare, and
the way they've "solved" _that_ is broken.

Richard

[Nick Keighley]

On 19 Jun, 18:46, Richard Heathfield <[e-mail]:

I'm not a great fan of Windows, and I'm certainly not a great fan of
Microsoft, but I thoroughly enjoy writing Win32 programs - they're a lot
more fun than Unix or mainframe stuff, or even ISO C (which is what I do
most of). I will even go so far as to say that the Win32 API is the best
thing since sliced bread.

I too like Win32 but the old Mac OS (it didn't actually have a name)
actually *was* sliced bread. Hell it was orthogonal, you could
actually
guess (often correctly) what a function would be called and what
parameters it would likely need based on similar stuff you'd already
seen.

<mutterwhere did I put "Inside Mac"?
--
Nick Keighley

[Richard Heathfield]

Mark McIntyre said:

Richard Heathfield wrote:

>>
Then you're wrong on the first point, and right on the second.

no

Well, simply denying it doesn't make you right. If you want to convince
anyone, you'll have to explain yourself.

>Not so.

*sigh*

**bigger sigh**

>

>>However while this would be vaguely topical over in comp.programming
its not remotely so here so I don't propose to say anything further -

Fine by me.

And yet you still felt obliged to continue the thread.

You said /you/ didn't propose to say anything further, which - as I said -
is fine by me. I didn't say /I/ didn't propose to say anything further.

When you stop saying dumb stuff, I'll stop responding to it. Or possibly
before, if I get bored before that.

As for your proposal not to say anything further, it doesn't seem to have
worked out for you, does it?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Guillaume Dargaud]

I was sure this question was going to degenerate, so I tried to frame it
carefully as a C library request... Anyway thanks for the answers, I should
have thought about SourceForge. And it stays STDC which was my main
requirement (cross compiler with no options whatsoever).

The reason for the INI use is personal, but as one of you stated, it's
convenient when exchanging progs and their configs: there will be one config
file shared on NFS between Linux server, Windows user stations and embedded
Linux devices.

I also like the liberty to be able to edit the ini file by hand when
something goes wrong in a configuration. The registry is useful in _some_
cases, but writing a portable C prog certainly isn't one of them !
--
Guillaume Dargaud
http://www.gdargaud.net/

[Kenny McCormack]

In article <T8******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:

>Mark McIntyre said:

>Richard Heathfield wrote:

>>>
Then you're wrong on the first point, and right on the second.

no

Well, simply denying it doesn't make you right. If you want to convince
anyone, you'll have to explain yourself.

>>Not so.

*sigh*

**bigger sigh**

Could you two just go get a room somewhere and work out your
frustrations in private?

(No, I'm just kidding - I just love watching a chick fight in action!)

[Mark McIntyre]

Richard Bos wrote:

Mark McIntyre <ma**********@TROUSERSspamcop.netwrote:

>Richard Heathfield wrote:

>>Mark McIntyre said:

There's nothing stupid about storing configuration information in a
database.
Agreed, but it's a bit daft to put everybody's config info in the same
place, and then provide only a clunky O(n) interface to it.

I disagree the first point, but agree the second.

I must agree with both points.

You think that using a database to store configuration info is daft?

Without a proper DBMS (which M$ have
never had, and no, I don't count M$SQL),

That's just a plain silly remark. Next you'll be saying that Oracle
don't have a decent BI package.

[Mark McIntyre]

Richard Heathfield wrote:

Mark McIntyre said:

>Richard Heathfield wrote:

>>Then you're wrong on the first point, and right on the second.

no

Well, simply denying it doesn't make you right. If you want to convince
anyone, you'll have to explain yourself.

Sure. Just raise this point again over where its topical (such as
comp.os.ms-windows or one of hte MS newsgroups) and I'm sure many people
will debate it with you.

You said /you/ didn't propose to say anything further, which - as I said -
is fine by me. I didn't say /I/ didn't propose to say anything further.

Naturally - when did being wrong ever stop anyone from wittering on?

As for your proposal not to say anything further, it doesn't seem to have
worked out for you, does it?

Like yourself, I'm unable to ignore continued idiocy from other posters.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Richard Tobin]

In article <Ix********************@en-nntp-05.dc1.easynews.com>,
Mark McIntyre <ma**********@TROUSERSspamcop.netwrote:

>You think that using a database to store configuration info is daft?

The evidence from Windows users I've encountered seems to be "yes".

The amount of time they spend messing around with binary editors to
"fix" things is ridiculous. In every case I've seen, the information
could have been stored straightforwardly in a human-readable file.

I see similar problems cropping up in the unix world. Firefox uses
some ludicrous database to store form data. SVN initially used a
database to store revisions, but endless problems of corruption
resulted in them adding a plain file method, which almost everyone
seems to use now.

Unless you really need the things databases are good for, I recommend
sticking with plain old files.

-- Richard
--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

[Richard Heathfield]

Mark McIntyre said:

Richard Heathfield wrote:

>Mark McIntyre said:

>>Richard Heathfield wrote:
Then you're wrong on the first point, and right on the second.
no

Well, simply denying it doesn't make you right. If you want to convince
anyone, you'll have to explain yourself.

Sure. Just raise this point again over where its topical

If you care that much, you raise it.

>You said /you/ didn't propose to say anything further, which - as I said
- is fine by me. I didn't say /I/ didn't propose to say anything
further.

Naturally - when did being wrong ever stop anyone from wittering on?

You continue to prove the opposite.

>As for your proposal not to say anything further, it doesn't seem to
have worked out for you, does it?

Like yourself, I'm unable to ignore continued idiocy from other posters.

"Disagreeing with Mark" doesn't mean the same as "continued idiocy",
despite what you might think. I've given reasons that support my opinions,
but you doesn't seem to have anything to support yours other than polemic
and insult. If you had a technical point to make, presumably you'd have
made it by now.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard]

Richard Heathfield <rj*@see.sig.invalidwrites:

Mark McIntyre said:

>Richard Heathfield wrote:

>>Mark McIntyre said:

Richard Heathfield wrote:
Then you're wrong on the first point, and right on the second.
no

Well, simply denying it doesn't make you right. If you want to convince
anyone, you'll have to explain yourself.

Sure. Just raise this point again over where its topical

If you care that much, you raise it.

>>You said /you/ didn't propose to say anything further, which - as I said
- is fine by me. I didn't say /I/ didn't propose to say anything
further.

Naturally - when did being wrong ever stop anyone from wittering on?

You continue to prove the opposite.

>>As for your proposal not to say anything further, it doesn't seem to
have worked out for you, does it?

Like yourself, I'm unable to ignore continued idiocy from other posters.

"Disagreeing with Mark" doesn't mean the same as "continued idiocy",
despite what you might think. I've given reasons that support my opinions,
but you doesn't seem to have anything to support yours other than polemic
and insult. If you had a technical point to make, presumably you'd have
made it by now.

Heathfield's talons are out! Watch it. Hiss!

[Mark McIntyre]

Richard Heathfield wrote:

Mark McIntyre said:

>Sure. Just raise this point again over where its topical

If you care that much, you raise it.

I'll take that as a concession that you can't argue your point with the
pros.
Don't bother replying as I've killed this thread.

[Mark McIntyre]

Richard Tobin wrote:

In article <Ix********************@en-nntp-05.dc1.easynews.com>,
Mark McIntyre <ma**********@TROUSERSspamcop.netwrote:

>You think that using a database to store configuration info is daft?

The evidence from Windows users I've encountered seems to be "yes".

That would be confusing the implementation from the theory.

[Richard Heathfield]

Mark McIntyre said:

Richard Heathfield wrote:

>Mark McIntyre said:

>>Sure. Just raise this point again over where its topical

If you care that much, you raise it.

I'll take that as a concession that you can't argue your point with the
pros.

How you misinterpret what I write is entirely up to you. What I said was
that if you wish to raise a subject in another newsgroup, it's up to you
to raise it. If you choose not to raise it there (as seems to be the
case), that doesn't necessarily mean that you can't argue your point with
the pros, does it? Well, neither does it mean that if I choose not to
raise it.

Don't bother replying as I've killed this thread.

You decide what you want to reply to, and I decide what I want to reply to.
That's how Usenet works. If I were addressing you alone, I'd have sent you
an email.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard Heathfield]

Mark McIntyre said:

Richard Tobin wrote:

>In article <Ix********************@en-nntp-05.dc1.easynews.com>,
Mark McIntyre <ma**********@TROUSERSspamcop.netwrote:

>>You think that using a database to store configuration info is daft?

The evidence from Windows users I've encountered seems to be "yes".

That would be confusing the implementation from the theory.

The implementation is what matters, and it's the implementation that's
daft. If someone can come up with a registry implementation that *isn't*

* unnecessarily awkward for programmers
* harder than it should be to back out arbitrary changes at arbitrary
times
* unnecessarily vulnerable to "gefingerpoken" user damage
* slow for large N

then great, let's see it - and let's hope that MS takes it up. In the
meantime, yes, the registry is daft.

By the way, for someone who claims to have killed a thread, you seem to be
perfectly happy to continue to post to it.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[marika]

On Jun 18, 1:17*pm, [e-mail] (Kenny McCormack)
wrote:

>>

You really gotta wonder why people bother to take the time to post these
useless responses. *See below for further exposition.

My sister and I once conducted a social experiment.

We both have friends who send us these emails that aren't personal at
all.
They receive and then reforward to the whole world, jokes, photos,
chain
letters (send this to ten people or you will experience bad luck) etc

There's a point where it's funny and enjoyed, but there's a point
where
it's a mania and they just send every single thing along, including
flamingly offensive stuff without thinking it through, things that
clog up
your mail box and you can't download, and worst of all things that are
neither cute nor funny even tho the subject line claims it.

My sister has been going out to the web and clipping photos and links
and
creating fake spam of her own. It's actually pretty funny.
Yesterday, she
sent a link to "Danielle and Michelle visit the Mosque". And another
one
that listed approved FAA airplane mechanics.

I'm waiting for the first idiot to say "but I don't fly a plane why
did you
send this"

Or the second idiot to say stop sending me your fascinating sites.
Because
after all why should we find interesting some of what they think is
interesting. Do unto others. Share your fascinating bits.

Today she sent out a huge spam that she built around this one.

http://www.directindustry.com/indust...accessories-an
d-equipment-112/water-chiller-76824.html

I give you permission to clip liberally from it in answers OR to the
person who you think really WOULD find it interesting.

mk5000

"I wish I was dead... *again*!"-- Igor: Dr Goldfoot and the Bikini
Machine