Rewrite INI-Functions

[Xenobiologist]

Hi @all C/C++ freaks,

there is a feature request which could be done by YOU!

Link : http://www.autoitscript.com/trac/autoit/ticket/15

Anybody who wants to develop the code and submit it to the devs, so that they "only" need to review it?

This is a very encapsulated topic which enables the possibility to work on by some "non-standard-dev".

I would do it myself, but I'm no c/c++ geek.

I hope there is a volunteer for this, because ini functions are used very often and e.g. the 32K border sucks.

Mega

P.S.: If the devs don't like this, then just lock the thread or delete it. THANKS!

[trancexx]

If I'm allowed to comment.

It would be really interesting to see this happening. Further developing feature that is recommended to be left behind. As much as it is their discretion right it would be a real waste of resources.

Ini-matic should be left where it belongs - 20th century.

[Inverted]

I don't understand what trancexx means

Anyway, improving the ini functions is very important for many ppl, myself included. I'm not in a position to help though, I steer way clear of C.

[monoceres]

I agree with trancexx. Instead of spending valuable time on a deprecated feature (that should only be left in for legacy reasons) the time could be spent on something much better, like say XML instead.

Ini files are part of the past. I wonder when AutoIt users get that.

[jvanegmond]

XML support crew reporting in.

[Xenobiologist]

Well, so trancexx doesn't like the idea of working with ini or property files. OK! I like code which is data-driven and not hard-coded.

But that is not the point of this thread!

The point is, why should the devs develop all the code alone? When there is a closed functionality, somebody else could give it a try.

The concept works for udfs, why not for Autoit internal code?

So please, if you want to participate in developing Autoit and you are able to develop the ini functions as described in the thread, then please do so.

Mega

[Inverted]

Yeah, officially .ini files are deprecated but they are used heavily by all sorts of programs, for example bleeding-edge-of-technology games. It's selfish to declare any work on that huge aspect of windows a waste of time.

Don't take this the wrong way, but I suggest those that aren't interested to just leave the thread alone. It'll die off unless someone with the skills+time+interest comes.

(Or if Valik calls us all inbred morons and locks it anyway )

[monoceres]

Well, so trancexx doesn't like the idea of working with ini or property files. OK! I like code which is data-driven and not hard-coded.

But that is not the point of this thread!

Huh? Who's talking about hard coded stuff? All I'm saying is ini files are a thing of the past and newer more efficient data formats available that rest of the world has accepted as standard. Example: Are you still saving your images in bitmaps and your sound files in wav files? If not, do explain.

The point is, why should the devs develop all the code alone? When there is a closed functionality, somebody else could give it a try.

The concept works for udfs, why not for Autoit internal code?

Because AutoIt is not open source. If the developers wished that everyone and their grandmas submitted source to the core they would have put an open source license on it.

Yeah, officially .ini files are deprecated but they are used heavily by all sorts of programs, for example bleeding-edge-of-technology games. It's selfish to declare any work on that huge aspect of windows a waste of time.

So? Most anti-virus claim to use cutting bleeding edge technology while in fact they mostly is the biggest pile of shit you can find.

Also, ini-files used 15 years ago aren't a waste of time, they were standard then.

I (hopefully) don't have to explain why ini-files sucks, because everyone who think can figure it out. For those who can't, google is available for free of charge.

Don't take this the wrong way, but I suggest those that aren't interested to just leave the thread alone. It'll die off unless someone with the skills+time+interest comes.

Why? The only thing that makes me posting in this topic is that I want autoit to be the best it can be. I'm also trying to save some poor sob a great deal of work.

A closing word, you guys are always whining about autoit not being able to reach the wider masses. This is exactly why, the brutal raping I have seen of the ini format on this forum could scare even the nuttiest coder away. I mean, what you guys want to save in ini files that are >2^15 bytes long are truly beyond me.

For once, try to evolve, try to see out of the tight little bubble you have build around yourselves. Try to realize that autoit is not the end tool for everything and ini files are not the mother and god of all data formats. Try adapting some of the standard, thinking and languages rest of the world uses. It would not only make your program and coding better and more efficient, it will also increase your understanding of autoit and maybe even to such a degree that you might even do a valuable submission to the language.

Awaiting storm.

[James]

Plenty of different formats to use:

• SQL
• SQLite
• CSV
• MySQL

What's wrong with them guys?

[Mat]

The only thing I find... interesting... about the ini functions is that they do not accept file handles... I never understood that, but then... I have no Idea how they made the functions in the first place.

; testing ini functions
$sIni = @ScriptDir & "\example.ini"
IniWrite ($sIni, "test", "value", "WORKS!!!")

MsgBox (0, "Testing unopened ini file", IniRead ($sIni, "test", "Value", "DOESN'T WORK!!!"))  

$hFile = FileOpen ($sIni, 0)
   MsgBox (0, "Testing Opened ini file", IniRead ($hFile, "test", "Value", "DOESN'T WORK!!!"))
FileClose ($hFile)
FileDelete ($sIni)

If anyone is going to rewrite them, can that be considered? There are times i'm calling 5 - 10 inireads in a row, from different sections, and thats where opening them would be a good idea. I'm not an expert, AutoIt is my first and main language, so If this post was nonsense ignore it

Mat

[Valik]

I don't entirely agree that INI files are obsolete. I quite like them because they are quick and easy. They are easier and faster to work with (both from the human standpoint and the machine standpoint) than XML. INI is still human editable but XML is not as much. It's too easy to make a mistake that'll make the XML completely unparsable. XML is useful for complex data sets where-as INI is better for simple data sets or data that needs to be human editable. In other words, there are pros and cons to both INI and XML and like with everything else the choice of which one should be used should change on a case-by-case basis.

Here's the problem with some random person trying to submit something like an INI rewrite to AutoIt: Me. Only I really know what I want to see out of an INI parsing class. Chances are, somebody who wanted to contribute would sit down, rewrite the existing INI functions and think that's good enough. It's not. I want a class that encapsulates all the INI functionality. I want it to be well written and I want it to do things I probably haven't commented on in the ticket. If anyone knows of an existing class with a permissible license I could use as a building block to do what I want, that's fine. But otherwise, this isn't really something some random person can do without a ton of feedback from me on exactly what I want. Then, depending on the competency of that person, it might be more work explaining what I want than doing it myself.

Lastly, there's been a bit of a misunderstanding. My response on the ticket was not an open invitation for anybody to write the feature. It was simply to demonstrate that delegation is not how things work around here. We volunteer to work on the features we want. We don't sit around assigning things to one another beyond the broad scope that Gary handles UDF stuff, Jon handles AutoItX and Jos handles SciTE/Au3Check/All the stuff that comes with SciTE4AutoIt3. Beyond that anyone is free to work on whatever they want.

[Valik]

The only thing I find... interesting... about the ini functions is that they do not accept file handles... I never understood that, but then... I have no Idea how they made the functions in the first place.

We use the Windows API.

; testing ini functions
$sIni = @ScriptDir & "\example.ini"
IniWrite ($sIni, "test", "value", "WORKS!!!")

MsgBox (0, "Testing unopened ini file", IniRead ($sIni, "test", "Value", "DOESN'T WORK!!!"))  

$hFile = FileOpen ($sIni, 0)
   MsgBox (0, "Testing Opened ini file", IniRead ($hFile, "test", "Value", "DOESN'T WORK!!!"))
FileClose ($hFile)
FileDelete ($sIni)

If anyone is going to rewrite them, can that be considered? There are times i'm calling 5 - 10 inireads in a row, from different sections, and thats where opening them would be a good idea. I'm not an expert, AutoIt is my first and main language, so If this post was nonsense ignore it

Mat

INI files (via the Windows API) are buffered. In theory multiple writes won't cause an open - write - close sequence every single call. In reality, AutoIt flushes after every write so it does do that sequence every call. This is part of the trade-offs we have to make of performance versus simplicity. We could certain not flush the file after every write and leave that up to the scripter, but then we'd be fielding questions on why INI files aren't being updated.

[Xenobiologist]

Thanks for all your answers. Valik I think you answer is fair. It is your code and I understand that you want it the way you like it. No problem!

So, as mentioned in my first post. If there is a problem with the idea that somebody else helps to write Autoit fnuctions then lock the thread and all is fine.

I'll give FileRead and Stringsplit and so on a go until the functions work with content bigger than 32K.

P.S. : I totally agree that there are pros and cons concerning the use of ini files. (like mentioned by Valik) nevertheless they are quite useful.

Mega

Edited September 15, 2009 by Xenobiologist

[bo8ster]

INF files are still used for device drivers and other descriptions.

INI, INF, SIF files (at least in XP) are used greatly to define the boot sequence of the OS. Working with XPE recently, I found they are everywhere.

[Mobius]

(Indirect Holler for a moment, normal service will resume shortly)

horrible cliche coming "Oooh thats soooo 20th Century" (post 2)

Lets think about that comment for a moment, The person making this statement is basically griping that something was conceived within the time span of the last 100 Friggin years, a comment made ever lamer by the simple fact that we are only 9 (count em) years into the 21st Century.

Xml : first draft was in 1996

SQL : first commercial sql based product was released in 1976

CSV: could not find a creation date but the format dates way back.(And can be used loosely in Ini format anyway.)

Dropping of the Ini format in favor other formats!? well hell those are smart words. (blimey is that a snowflake I see)

Ini files remain widely in use today (and will for a good while yet) for 2 simple important reasons specified in post 11.

I am all for updating the Ini format (love it in fact), but surely such an update could be done via dll just as easily as tampering with the grail.

You have to admit that 32kb is quite large for a config file.

Vlad

Edited September 16, 2009 by Mobius

[trancexx]

(Indirect Holler for a moment, normal service will resume shortly)

horrible cliche coming "Oooh thats soooo 20th Century" (post 2)

Lets think about that comment for a moment, The person making this statement is basically griping that something was conceived within the time span of the last 100 Friggin years, a comment made ever lamer by the simple fact that we are only 9 (count em) years into the 21st Century.

Xml : first draft was in 1996

SQL : first commercial sql based product was released in 1976

CSV: could not find a creation date but the format dates way back.(And can be used loosely in Ini format anyway.)

Dropping of the Ini format in favor other formats!? well hell those are smart words. (blimey is that a snowflake I see)

Ini files remain widely in use today (and will for a good while yet) for 2 simple important reasons specified in post 11.

I am all for updating the Ini format (love it in fact), but surely such an update could be done via dll just as easily as tampering with the grail.

You have to admit that 32kb is quite large for a config file.

Vlad

You are projecting (again).

Would someone be kind to give the definition of the INI file?

@bo8ster, you are mentioning device drivers. Nice touch.

[Xenobiologist]

You are projecting (again).

Would someone be kind to give the definition of the INI file?

@bo8ster, you are mentioning device drivers. Nice touch.

Although there is a difference have a look at :

http://en.wikipedia.org/wiki/.properties

http://de.wikipedia.org/wiki/Initialisierungsdatei

Sometimes it is used like a key value hashmap. Which could be used in Autoit e.g. with Dictionary object.

You can easily read info from it. Just ask for the key and get the value. The parsing is done internally.

It can be read and changed by human without all the overhead needed for xml.

Mega

[jvanegmond]

Why do the ini files need to be reimplemented as a C++ class? Can't we use AutoIt for this stuff by now? An ini UDF seems like a good idea to me. That would bring much more versatility, because we can actually modify the Au3 at a basic level, whereas the C++ can not be modified.

By that logic a lot of functions can be rewritten in native AutoIt. But since the ini functionality is going to be rewritten anyway, why not in AutoIt?

[Valik]

If we begin porting things out then where do we draw the line drawn?

I think this is all a moot point. The INI stuff isn't even on my radar. Debating on the merits of C++ versus AutoIt or INI versus other formats is all academic really because things aren't going to change anytime soon.

[jvanegmond]

If we begin porting things out then where do we draw the line drawn?

Porting things out is not something bad in itself. Being against porting out would be like saying that the AutoIt developers never make a mistake. (Which I'm sure you don't do; but what about the other dev's?). A line doesn't always need to be drawn from the get go.

But this is just a generalization. I'm purposely letting out important details, like performance loss and backwards compatibility.