Too many code-breaking changes

[Anteaus]

Have just spent two head-banging evenings trying to find an obscure and irritating bug in code I'd recently updated. I decided to use 3.3 instead of 3.2 as I needed the program to work with Windows 7. Turned out the problem was not even in my code, but in a seemingly-unnecessary and pointless change made to one of the registry functions in 3.3. Worse, the change wasn't even documented in the manual, only in the version history.

Problems of this kind beset other languages like VB, and it's one of the reasons I have come to prefer working with AutoIt, because it used to be largely free of such issues. Note past tense.

A few examples:

Presence of RunAsSet() will now crash the program. -OK, so maybe RunAs() is a better syntax, but making the change in such a way that existing scripts will crash is NOT a better option. It is a worse option than leaving things alone.

RunAs() now uses the system dir as its default.(The standard throughout AutoIt is for working files to be in the script folder. Why buck the standard for this one command, and cause confusion and errors, seemingly for the sake of some trivial convenience?)

The presence of a RunErrorsFatal option will crash the script in later compilers. Yet, in earlier compilers this statement is pretty-much mandatory.

These are just a few examples of many. Basically, it's got to the stage where writing AutoIt code is like the proverbial exercise of building a house on a sand-dune.

Now, granted you may meet this kind of thing with all languages, for example php4 code will often not work with php5. BUT, it would be extremely rare for a minor php version-increment to break code. Only a major version-number change would do this. With AutoIt's present policy of wildcat changes to core functions, this is now a constant risk, even with a single-digit version increment.

The worst aspect of all of this is that it's largely pointless to build any sort of collection of libraries, since -even if they have been religiously coded by the rules of good AutoIt practice- it can be pretty-much guaranteed that with the next update they will all be reduced to unreliable junk.

OK, that's my rant for tonight. Flame away. I'm sure y'all will.

[monoceres]

Now, granted you may meet this kind of thing with all languages, for example php4 code will often not work with php5. BUT, it would be extremely rare for a minor php version-increment to break code. Only a major version-number change would do this. With AutoIt's present policy of wildcat changes to core functions, this is now a constant risk, even with a single-digit version increment.

While I can see your frustration note that there where a lot of versions between 3.2 and 3.3 and you should know that the second digit is pretty much the biggest version upgrade you'll ever see. AutoIt4 is pretty much just in everyones dreams ^^

[Valik]

First of all, you're a dumbass. We'll get to that in a bit.

Have just spent two head-banging evenings trying to find an obscure and irritating bug in code I'd recently updated. I decided to use 3.3 instead of 3.2 as I needed the program to work with Windows 7. Turned out the problem was not even in my code, but in a seemingly-unnecessary and pointless change made to one of the registry functions in 3.3. Worse, the change wasn't even documented in the manual, only in the version history.

READ THE FUCKING VERSION HISTORY. This is the biggest duh there is. If you blindly update your software and it doesn't work the same way, it's YOUR fault. I don't see anybody else with pitchforks lambasting us for improving the languages. Those that do inevitably admit they didn't read the version history.

Problems of this kind beset other languages like VB, and it's one of the reasons I have come to prefer working with AutoIt, because it used to be largely free of such issues. Note past tense.

So you suggest we should do things wrong or poorly just because we've always done them wrong or poorly? No.

A few examples:

Presence of RunAsSet() will now crash the program. -OK, so maybe RunAs() is a better syntax, but making the change in such a way that existing scripts will crash is NOT a better option. It is a worse option than leaving things alone.

Congratulations on being well over a year late to the party. Oh, and the RunAs() changes were in beta for god knows how long. Your right to bitch about this change went out the window about 18 months ago. It's also a documented script breaking change.

RunAs() now uses the system dir as its default.(The standard throughout AutoIt is for working files to be in the script folder. Why buck the standard for this one command, and cause confusion and errors, seemingly for the sake of some trivial convenience?)

It's not for convenience. It's because 99% of the time people say "RunAs() doesn't work" and it's because they haven't set an explicit working directory so it's defaulting to something like @DesktopDir or @MyDocumentsDir which are not accessible by the alternate user credentials. It's to PREVENT errors. Also, write good code and you won't have the issue (AKA, set the fucking working directory explicitly).

The presence of a RunErrorsFatal option will crash the script in later compilers. Yet, in earlier compilers this statement is pretty-much mandatory.

If I've said it once, I've said it a thousand times. Fatal errors are bad and are being removed from the language. I was not aware that an unrecognized Opt() caused a fatal error. This is stupid and wrong behavior and will be fixed. Bitching about it, however, is not the right way to bring it up.

These are just a few examples of many. Basically, it's got to the stage where writing AutoIt code is like the proverbial exercise of building a house on a sand-dune.

Now, granted you may meet this kind of thing with all languages, for example php4 code will often not work with php5. BUT, it would be extremely rare for a minor php version-increment to break code. Only a major version-number change would do this. With AutoIt's present policy of wildcat changes to core functions, this is now a constant risk, even with a single-digit version increment.

The worst aspect of all of this is that it's largely pointless to build any sort of collection of libraries, since -even if they have been religiously coded by the rules of good AutoIt practice- it can be pretty-much guaranteed that with the next update they will all be reduced to unreliable junk.

OK, that's my rant for tonight. Flame away. I'm sure y'all will.

If you don't like it, find another language. I am not going to sit here idly and let some dumbass who can't be bothered to read the changelog tell me to leave shitty behavior in the language just so he can be lazy. Did it ever occur to you that if you cared so much maybe you'd keep a cursory glance on the beta versions to see what sort of changes are upcoming? Or maybe, *gasp*, read before you upgrade and use compiled versions of scripts if you don't want to update everything. It's not like you can't compile your non RunAs() supporting scripts with an older version of AutoIt that still contains RunAsSet(). Since clearly improvements to the language are irrelevant to you then you shouldn't mind using buggy versions to keep your precious poor features.

We go out of our way to document every change we make. We try to be very thorough in documenting script breaking changes. But it's not enough for idiots like you who just want to bitch because they can't be bothered to take some initiative on their own to ensure things will work as expected. Well, fuck off. I'm not interested in this kind of feedback. The feedback I want from the users of this language is how to make it better. Not how to let it stagnate with poorly implemented features that are awkward, buggy, unintuitive, insecure, et cetera.

[pdaughe]

Have just spent two head-banging evenings trying to find an obscure and irritating bug in code I'd recently updated. I decided to use 3.3 instead of 3.2 as I needed the program to work with Windows 7. Turned out the problem was not even in my code, but in a seemingly-unnecessary and pointless change made to one of the registry functions in 3.3. Worse, the change wasn't even documented in the manual, only in the version history.

Problems of this kind beset other languages like VB, and it's one of the reasons I have come to prefer working with AutoIt, because it used to be largely free of such issues. Note past tense.

A few examples:

Presence of RunAsSet() will now crash the program. -OK, so maybe RunAs() is a better syntax, but making the change in such a way that existing scripts will crash is NOT a better option. It is a worse option than leaving things alone.

RunAs() now uses the system dir as its default.(The standard throughout AutoIt is for working files to be in the script folder. Why buck the standard for this one command, and cause confusion and errors, seemingly for the sake of some trivial convenience?)

The presence of a RunErrorsFatal option will crash the script in later compilers. Yet, in earlier compilers this statement is pretty-much mandatory.

These are just a few examples of many. Basically, it's got to the stage where writing AutoIt code is like the proverbial exercise of building a house on a sand-dune.

Now, granted you may meet this kind of thing with all languages, for example php4 code will often not work with php5. BUT, it would be extremely rare for a minor php version-increment to break code. Only a major version-number change would do this. With AutoIt's present policy of wildcat changes to core functions, this is now a constant risk, even with a single-digit version increment.

The worst aspect of all of this is that it's largely pointless to build any sort of collection of libraries, since -even if they have been religiously coded by the rules of good AutoIt practice- it can be pretty-much guaranteed that with the next update they will all be reduced to unreliable junk.

OK, that's my rant for tonight. Flame away. I'm sure y'all will.

I generally tend to stay away from threads that may become "inflamatory", but the subject matter of this thread is a fundamentally important one.

I read Valik's response and although he sets diplomacy aside, if you think about the points he made, viewed from my 30+ years of dealing with programming languages and operating systems, he is spot-on, 100% spot on.

My (prehistoric) background is primarily in mainframe programming and what you would have to experience (and suffer the consequences of) is a reluctancy to make changes just because it may require minor maintenance changes to existing programs.

Progress waits upon change. What is important, critically important, is that changes are documented and here the developer's of AutoIt shine, not as a matter of opinion, but as a matter of fact. Not only are changes fully documented in the release notes, but script-breaking changes are clearly identified.

I won't give examples of other providers where changes are not documented because if you've worked in this field for any appreciable amount of time, you've already encountered that.

While I can relate to your frustration, you do have to take personal responsibility to review the release notes and change logs. It's just part of our job as developers.

[Anteaus]

First of all, you're a dumbass. READ THE FUCKING VERSION HISTORY.

An analysis of the bug revealed that the problem arose when a binary registry-key written by RegWrite() was read-back by another program. Yet, no error was being reported, and a test script seemed to write and read-back a test-value correctly.

On searching the changelog I spotted this statement:

"Changed: RegRead() and RegWrite() no longer use hex strings for REG_BINARY types - native binary datatypes are enforced."

-which looked as if it might be relevant. I puzzled over what this was trying to say, since according to the manual, AutoIt uses only the variant data-type. OK, so let's make a stab and try the C convention of adding 0x to the string. Yes, this seems to fix the problem.

Today I compiled the test script in a number of versions, and made the following analysis:

Aut2EXE 3.3.0.0:

RegWrite: Requires input string to be prefixed by '0x'

Returns non-error condition (1) and writes corrupt data if unprefixed hex string is supplied. (The data written looks like it's the ASCII codes of the characters instead of their values)

RegRead: Returns 0x-prefixed string representing hex data.

Aut2EXE 3.2.12.1/3.2.8.1:

RegWrite: Requires unprefixed hex string.

Returns error-condition (0) and does not write data if string is prefixed with 0x.

RegRead: Returns string representing hex data.

That said, why change the behaviour anyway? How hard is it to add or strip '0x' from a string if you don't agree with the presentation? How hard was it to trace this bug, plus I'm guessing a good few others like it around the world?

Bottom line: If it works...

[Valik]

Aut2EXE 3.3.0.0:

RegWrite: Requires input string to be prefixed by '0x'

Returns non-error condition (1) and writes corrupt dataif unprefixed hex string is supplied. (The data written looks like it'sthe ASCII codes of the characters instead of their values)

RegRead: Returns 0x-prefixed string representing hex data.

You are flat out wrong. Read the fucking documentation (I'm noticing a trend here). See the IsBinary(), StringToBinary(), BinaryToString() and Binary() functions in the documentation. All you are passing with your example is a string that happens to contain "0x" as the first two characters. You are not passing binary data like you think you are.

That said, why change the behaviour anyway? How hard is it to add or strip '0x' from a string if you don't agree with the presentation?

To make it work right instead of being a hack? Why do you think it has anything to do with presentation

Bottom line: If it works...

If it works, don't recompile it with a new version of AutoIt without taking time to read the changelog and understand what the changes mean. Edited August 30, 2009 by Valik

[Anteaus]

You are flat out wrong. Read the fucking documentation

I did. Line one of the section on data types says:

"In AutoIt there is only one datatype called a Variant. A variant can contain numeric or string data and decides how to use the data depending on the situation it is being used in."

-Which seems pretty clear to me, and in all other instances is borne-out in practice. With the possible exception of DLL calls, which I think most people realise are a special situation which cannot be handled this way. I see no similar justification for one fairly trivial type of registry data requiring a special data conversion. As far as I'm aware the writing of binary data worked perfectly well before the change, so is there actually a bug/problem which justifies the change, or not? If yes then it might be a change we have to accept, but if not, then why have one function which now fails to comply with the groundrules of the language? That would make no sense to me.

In any case, Valik, I find it hard to believe that guy with a temperament like yours could possibly do coding. First sign of a bug, and there would be a honkin' great dent in the case and a new collection of bad sectors on the HD. Not to mention the air turning blue within a five-mile radius. Now, I've been known to swear at computers occasionally, I guess we all have, but your behaviour takes the biscuit.

'Nuff said.

[Valik]

I did. Line one of the section on data types says:

"In AutoIt there is only one datatype called a Variant. A variant can contain numeric or string data and decides how to use the data depending on the situation it is being used in."

Picking and choosing what you read is not helpful.

-Which seems pretty clear to me, and in all other instances is borne-out in practice. With the possible exception of DLL calls, which I think most people realise are a special situation which cannot be handled this way. I see no similar justification for one fairly trivial type of registry data requiring a special data conversion. As far as I'm aware the writing of binary data worked perfectly well before the change, so is there actually a bug/problem which justifies the change, or not? If yes then it might be a change we have to accept, but if not, then why have one function which now fails to comply with the groundrules of the language? That would make no sense to me.

Where exactly has it been stated that the binary sub-type exists solely for registry functions? As for the binary stuff working fine before? Well, that depends. There was one implementation of binary which sucked. It was then revised to be what it is today. At some point after the good implementation was introduced, functions were updated to use it. Evolution of the language. I don't care enough to look at the changelog to construct a timeline to bury you with.

In any case, Valik, I find it hard to believe that guy with a temperament like yours could possibly do coding. First sign of a bug, and there would be a honkin' great dent in the case and a new collection of bad sectors on the HD. Not to mention the air turning blue within a five-mile radius. Now, I've been known to swear at computers occasionally, I guess we all have, but your behaviour takes the biscuit.

I don't swear at computers. They do what I tell them (and if they don't I make them do so). I do, however, swear at people for various reasons, including stupidity.

'Nuff said.

Indeed, you have said quite enough. Your ignorance pours forth with each post you make.

[Anteaus]

OK, so we have a situation where the manual states that AutoIt is an untyped language.

The manual than goes-on to state that for specific reasons, DLL data-structures use typed variables. This is made clear. No problem here.

However, we then discover that RegWrite() has been modified so as to to require explicity-typed variables. Yet, the relevant manual section makes no mention of this. Nor is it entirely clear as to how the variable types should be declared. It is also (painfully) apparent that this function implements no validity-check (whereas previously it did) and will now quite happily output garbage data if the variant type is inputted.

This begs the question: How many other functions now require explicitly-typed data? The answer seems to be that we don't actually know.

This means we now have a situation where any function could in principle output garbage data, at any time.

Now, I'm not even going to get-into the arguments for variant or strongly-typed data. Both can and do work successfuly. The problem arises when on a function-by-function basis you don't know which groundrules apply.

Call that observation stupid if you wish. I call it commonsense.

[Valik]

Alright, let's clear up some confusion (some of it I introduced):

• RegWrite() accepts anything and writes is as binary data. It doesn't have to be cast to binary first and it does not have to be a hex string. For example, to write the binary representation of "abc" you pass "abc" and tell RegWrite() the data is REG_BINARY. Done. You DO NOT try to write the hex representation of "abc" as "0x616263" and then expect it to be magically translated to the binary representation of "abc". That may have been a hack solution years ago now but is no longer necessary.
• RegRead() returns REG_BINARY data as VAR_BINARY. You may or may not need to cast this to a more suitable type depending on how you are trying to use it.

You want to argue about the data being typed. Well what the fuck do you call it when you have to pass a specially formatted string? That's far more typed than what we have now. What we have now mostly frees you from having to think about the type of the data. All you need to know is that the data needs written as REG_BINARY. You don't have to manually convert it to binary any longer. In addition, when binary data is read it is stored in a format AutoIt can safely store (embedded NULL characters are stored correctly in the binary sub-type). It's also stored in a format that is consistent with other functions and the data read can be easily passed to other functions which will Do The Right Thing™.

So yeah, you're bitching about improving the language to be more intuitive. But you're too stupid/stubborn/retarded/busy touching yourself at night to actually learn how the function works now. Instead you wish to sit around bitching and arguing with us for making the behavior of binary data more consistent with all other sub-types (string, int, float) in the language. Wait, what?

[wraithdu]

@Anteaus

I don't see the problem. All the rules of Binary() conversions must be followed to correctly write a binary reg type:

#NoTrayIcon
ConsoleWrite("+Right:  " & Binary("0x12345678") & @CRLF)
ConsoleWrite("-WRONG:  " & Binary("12345678") & @CRLF)
RegWrite("HKCU\aaatest", "test_binary", "REG_BINARY", "0x12345678") ; also works as explicity Binary("0x12345678")
$a = RegRead("HKCU\aaatest", "test_binary")
ConsoleWrite("RegRead() value type (3=REG_BINARY):  " & @extended & @CRLF)
ConsoleWrite("Variable $a variant type:  " & VarGetType($a) & @CRLF)
ConsoleWrite("String representation of the value of $a:  " & $a & @CRLF)
RegDelete("HKCU\aaatest")

RegRead: Returns 0x-prefixed string representing hex data.

This is just wrong. RegRead() returns the correct variant for the data type it has read. ConsoleWrite() converts the variant to a string type. So the '0x' prefixed string is only ConsoleWrite()'s string representation of the binary variant. Edited August 31, 2009 by wraithdu

[Shark007]

to toss in my 2 cents .. I am a nobody on these forums.

I have no programming experience other than working with MSI's

I have been using autoit for all of 6 months at best.

I barely understand this thread. BUT ... I do have a need to write REG_BINARY data.

Luckily for me, the data I needed to write pre-existed in the registry. In my testing stages, I exported the registry key, and was able to import it back - success! I can now try it with autoit. A function of my script removes the data, and at some future time, this data needs to be placed back to the registry. Learning to do this was a simple forum search to reveal that I needed to use $data = BINARY() and add the exported data prefixed with '0x' from the reg export funtion to create the binary data; then when doing the regwrite; use $data as the value.

The point of my story is that with next to no programming experience,

I was able to figure this out without even posting to ask for help.

Did I mention I love the simplicity of AutoIt?

Thanks (to its developers).

Edited September 22, 2009 by Shark007

[crystalburner]

Sorry but I have to Agree here, I've been using AutoIT for years and finally moved to ASP because I am thoroughly sick of having to upgrade AutoIT because of a bug only to break my scripts.

AutoIT is a nice toy but can't be taken seriously until it is managed properly and some thought goes into the fundamental design to maintain backward compliance.

[crystalburner]

ASP is a shit load faster as well

[jvanegmond]

Moving to ASP is a dumb move to begin with. It's deprecated and no longer supported. I can't say this for sure, but I don't think ASP is faster either. ASP.NET definitely is, though.

Also, AutoIt and ASP(.NET) are worlds apart.. You can't compare the two because they are meant to do different things. The fact that you're switching only means that you initially made the wrong choice picking a programming language or you are making the wrong choice now.

Edited September 22, 2009 by Manadar

[crystalburner]

Not at all, the applications I made in AutoIT are for business use. ASP.NET 3.5 is what is installed on my Server, and I am converting these standalone apps to web based apps. They are faster, more portable and they don't break everytime I do an update like I did from 2 to 3.5

When you are running a serious business, not playing with yourself you really can't afford the kind of unreliability AutoIT gives you between versions. You just don't have the time.

If you script kiddies want to flame me feel free, this is entirely my opinion and I am exercising freedom of speech here to tell you all what I think of the conversation on this thread.

Moving to ASP is a dumb move to begin with. It's deprecated and no longer supported. I can't say this for sure, but I don't think ASP is faster either. ASP.NET definitely is, though.

Also, AutoIt and ASP(.NET) are worlds apart.. You can't compare the two because they are meant to do different things. The fact that you're switching only means that you initially made the wrong choice picking a programming language or you are making the wrong choice now.

[monoceres]

When you are running a serious business, not playing with yourself you really can't afford the kind of unreliability AutoIT gives you between versions. You just don't have the time.

You seem like a awesome guy. Can I maybe touch you? That would be awesome since you are like all serious buisness all the time.

You're argument is seriously flawed. AutoIt is not the only language in the world that sometimes breaks scripts. Have you ever heard of Python? Python is one of the best languages in the world (imho of course) and they decided to break kinda every script ever written in Python when Python 2.6 became 3.0.

So I guess Python is only good for playing with yourself. Too bad (Valik hear that? Your Python script that pretty much is the gatekeeper of this place is NOT any good! Convert to asp.net ASAP!).

Backwards compatiblity is great as long as it doesn't cripple new functionality or the old functionality was retarded. The question is, if the code is so important, why upgrade in the first place? Just compile the autoit script and there you go, a fully functional copy that will never break.

(Ps. C++ then? It's not a very buisness like language that hotshots like yourself need to use, but the new standard will also break. Too bad, guess that's another language of the chart).

If you script kiddies want to flame me feel free, this is entirely my opinion and I am exercising freedom of speech here to tell you all what I think of the conversation on this thread.

Well then. Fuck you. I refuse the title of script kiddie.

I just exercised my rights to insult you.

[Valik]

I get the impression you don't have a clue what you are doing and are in over your head at your job. As has been mentioned before, you're making poor choices on language. You're making poor and uninformed choices in upgrading your software. Forgive me if your comments about "poor management" sound a little hypocritical and hollow given the pretty clear demonstration of your stupidity in managing which languages you use and how you upgrade them.

If you don't like AutoIt, I hear there are other languages out there. Use them and leave us alone. Believe it or not: We don't need you and you aren't important. So if all you have to say is something we've already covered do us both a favor and get lost. I bet I can justify my breaking changes to the language a hundred time more than you can justify your need to blindly upgrade. So unless you want to play a game called "Valik shoves your shitty arguments down your throat so hard your children choke on it" I suggest dropping this subject because unless you've repeatedly demonstrated you are a competent and knowledgable individual, your opinion means less to me on the direction AutoIt should go than my cat's opinion.

[crystalburner]

You don't have any right to insult me.

You seem like a awesome guy. Can I maybe touch you? That would be awesome since you are like all serious buisness all the time.

You're argument is seriously flawed. AutoIt is not the only language in the world that sometimes breaks scripts. Have you ever heard of Python? Python is one of the best languages in the world (imho of course) and they decided to break kinda every script ever written in Python when Python 2.6 became 3.0.

So I guess Python is only good for playing with yourself. Too bad (Valik hear that? Your Python script that pretty much is the gatekeeper of this place is NOT any good! Convert to asp.net ASAP!).

Backwards compatiblity is great as long as it doesn't cripple new functionality or the old functionality was retarded. The question is, if the code is so important, why upgrade in the first place? Just compile the autoit script and there you go, a fully functional copy that will never break.

(Ps. C++ then? It's not a very buisness like language that hotshots like yourself need to use, but the new standard will also break. Too bad, guess that's another language of the chart).

Well then. Fuck you. I refuse the title of script kiddie.

I just exercised my rights to insult you.

[crystalburner]

Thought you might be interested in the opinion of people who use the software you create. if it is just for your own use and you don't value others opinions why bother putting this forum here and inviting feedback and discussion?

If however all you want to do is take out the void within yourself on others around you and use offensive language when you don't hear what you want to hear then I want nothing more to do with you either.

I get the impression you don't have a clue what you are doing and are in over your head at your job. As has been mentioned before, you're making poor choices on language. You're making poor and uninformed choices in upgrading your software. Forgive me if your comments about "poor management" sound a little hypocritical and hollow given the pretty clear demonstration of your stupidity in managing which languages you use and how you upgrade them.

If you don't like AutoIt, I hear there are other languages out there. Use them and leave us alone. Believe it or not: We don't need you and you aren't important. So if all you have to say is something we've already covered do us both a favor and get lost. I bet I can justify my breaking changes to the language a hundred time more than you can justify your need to blindly upgrade. So unless you want to play a game called "Valik shoves your shitty arguments down your throat so hard your children choke on it" I suggest dropping this subject because unless you've repeatedly demonstrated you are a competent and knowledgable individual, your opinion means less to me on the direction AutoIt should go than my cat's opinion.