[RELEASE] Fiesta Auto-Login Tool

[MaxOff]

k i took a look at it.

1.) Do never and i mean never trust someone who asks for your login informations.(not even a tool).
Which is why I provide the source, compile it yourself if you don't trust me.
I do trust the code, but not the binary. Noone says that the binary contains the same instructions as the source code
2.) For me the tool just chrashes the launcher
I doubt it crashes it, since it is only happening to you it's your problem not the programs.
Well it chrashed, and since its your programm that forced the launcher to crash. Make out of it what u want
3.) Never add yourself in "HKLMSoftwareMicrosoftWindowsCurrentVersionRun " without asking the user, a lot of secrurity tools go are very sensitive about that key.f
I find it pointless to ask since security tools are going to go off when the person says yes anyway, plus this program isn't useful if you have to run it every time...
It is good pratice to ask the user before. But of course u dont have to do it.
Programming Tips
4.) Close a file after u are not using it anymore. Same goes for all handels
Again, the file handle for the loginsettings.ini was never closed because I didn't want people editing it while the program was running. Also the other handle to the launcher(hProcess) never needed to be closed because it was used to kill the launcher. I.E. The handle became invalid anyway.
Mhh great, u are so smart. Opening a file in with read and write share, so u block out other readers? Wait that makes no sence.... read and write share? Yes! Other programm can read and write the file while your Fiesta Auto-Login is running. But Notepad saves files without sharing so it fails. (anoying "feature" of notepad)
And actually expecting that windows cleans up after u, isnt very good pratice too
5.) Change the timer proc.
- The handels wont change, in the same launcher instance
No, the window handles don't change. Your point?
The code expect them to change nearly all the time
- Check if the launcher is ready for input or still initialising
Again, an extra piece of code that windows checks for itself. Pointless. The only time this is needed is when I wait for the Login button to become enabled.
There is a big difference between if the message queue is ready and if a button is enabled or not. Apperently u dont know that difference. And no Windows doesnt check that
- Check if the client was closed, because the launcher stays in the bg while fiesta is running.
No, it doesn't. I terminate it once Fiesta is running for that reason.
So what happends if Fiesta Auto-Login.exe is launched after a manual login?
I admit i wasnt very preciese. I actually meant the overall status of the client, not only if its running.
- Move all the code out of the Form(the best is if u dont need any form or timer)
Again, that would have been more complicated and pointless.
Actually it would have made the programm: easier to read, faster and smaller. Especialy in the case of delphi.
- Make a little bit more readable it looks kinda weird will all the exits(returns).
It's perfectly readable to me, sorry but I don't take everyone's reading preferences into account.
U dont have, too

----

And if the tool is talkactive or not i can not say. Delphi applications are a pain in the ass to debug. So i wont take a look into it
How are they a pain in the ass, you just need to know what your doing. The source isn't provided for you to change, it's there in case you don't trust the compiled executable.
With debugging i ment debugging on asm level, because i dont have an delphi debugger avaible right now, so asm had to suffice. And debugging delphi on asm level IS a pain in the ass.
And believe me, no windows user compiles progs before they use them. And i dont know why the linuxer love to do it. I only see wasted computer ressources in it.

Red: ThievingSix commentar
Blue: MaxOff commentar

[ThievingSix]

I want to be green now =)

k i took a look at it.

1.) Do never and i mean never trust someone who asks for your login informations.(not even a tool).
Which is why I provide the source, compile it yourself if you don't trust me.
I do trust the code, but not the binary. Noone says that the binary contains the same instructions as the source code
Which is why, if you didn't trust the binary, you can compile it yourself.

2.) For me the tool just chrashes the launcher
I doubt it crashes it, since it is only happening to you it's your problem not the programs.
Well it chrashed, and since its your programm that forced the launcher to crash. Make out of it what u want
OK, in a technical view it "crashes". A better word would have been "terminates". I suppose that I could have been nicer to the launcher and close it with a WM_Close message, but since it's not doing anything Windows critical I see no need to.

3.) Never add yourself in "HKLMSoftwareMicrosoftWindowsCurrentVersionRun " without asking the user, a lot of secrurity tools go are very sensitive about that key.f
I find it pointless to ask since security tools are going to go off when the person says yes anyway, plus this program isn't useful if you have to run it every time...
It is good pratice to ask the user before. But of course u dont have to do it.
Yeh, you got me there. I should have asked but I didn't see a big reason to.

Programming Tips
4.) Close a file after u are not using it anymore. Same goes for all handels
Again, the file handle for the loginsettings.ini was never closed because I didn't want people editing it while the program was running. Also the other handle to the launcher(hProcess) never needed to be closed because it was used to kill the launcher. I.E. The handle became invalid anyway.
Mhh great, u are so smart. Opening a file in with read and write share, so u block out other readers? Wait that makes no sence.... read and write share? Yes! Other programm can read and write the file while your Fiesta Auto-Login is running. But Notepad saves files without sharing so it fails. (anoying "feature" of notepad)
And actually expecting that windows cleans up after u, isnt very good pratice too
Ok, I guess I didn't set it to deny because I use a simpler version of file handles. A stream should do fine. Doesn't matter though, the resources used are discarded anyway when Windows shuts down. If your worried about a 300 byte file staying open then please, get over it =). Also, while it's not good practice. Windows does clean it up.


5.) Change the timer proc.
- The handels wont change, in the same launcher instance
No, the window handles don't change. Your point?
The code expect them to change nearly all the time
OK, the reason for an expected change in handles is because the fiesta launcher may run more than once. When a program is closed and reopened you need to refine them.

- Check if the launcher is ready for input or still initialising
Again, an extra piece of code that windows checks for itself. Pointless. The only time this is needed is when I wait for the Login button to become enabled.
There is a big difference between if the message queue is ready and if a button is enabled or not. Apperently u dont know that difference. And no Windows doesnt check that
There is NO possible way that the message queue not being ready will do anything to affect anything. Sending text to the text boxes after windows has established handles for them means, they are ready. "Apperently u dont know that difference".

- Check if the client was closed, because the launcher stays in the bg while fiesta is running.
No, it doesn't. I terminate it once Fiesta is running for that reason.
So what happends if Fiesta Auto-Login.exe is launched after a manual login?
I admit i wasnt very preciese. I actually meant the overall status of the client, not only if its running.
Re-read this entire conversation and you might realize that the program is meant to run at startup. Anyway, if it is run after a manual login, nothing would happen. What might?

- Move all the code out of the Form(the best is if u dont need any form or timer)
Again, that would have been more complicated and pointless.
Actually it would have made the programm: easier to read, faster and smaller. Especialy in the case of delphi.
OK, to me the size, speed, and ease of read didn't make it worth doing, but your right it would. I have a file path issue to fix as well so I can change it in the next release. The only reason that is a bit more complicated is because you can just drop the timer component on the form. When removing the form from the question it entails more work for a slight boost.

- Make a little bit more readable it looks kinda weird will all the exits(returns).
It's perfectly readable to me, sorry but I don't take everyone's reading preferences into account.
U dont have, too

----

And if the tool is talkactive or not i can not say. Delphi applications are a pain in the ass to debug. So i wont take a look into it
How are they a pain in the ass, you just need to know what your doing. The source isn't provided for you to change, it's there in case you don't trust the compiled executable.
With debugging i ment debugging on asm level, because i dont have an delphi debugger avaible right now, so asm had to suffice. And debugging delphi on asm level IS a pain in the ass.
And believe me, no windows user compiles progs before they use them. And i dont know why the linuxer love to do it. I only see wasted computer ressources in it.
Waste in computer resources??! LOL!

Red: ThievingSix commentary
Blue: MaxOff commentar
Green: ThievingSix commentary

[Belaslav]

Lol, battle of the programmers.

[Ralath]

Too... much... quoted text.... x.x

[ThievingSix]

Lol, read. YOU MUST ALL READ!!

[Belaslav]

I did. And?

[ThievingSix]

Idk, go have some coffee or something.

Edit: Version 2 is up. See details in the changelog section of the Readme.