console

[w0uter]

ill probbly get yelled at for this but:

cant we make an option that specifies that autoit should be build as an console app.

[DaveF]

ill probbly get yelled at for this but:

cant we make an option that specifies that autoit should be build as an console app.

w0uter, what are you thinking?!?!

Sorry, I couldn't resist.

We could indeed, it's just a compile-time option that needs to be changed. But we'd just have to understand that then it would work like Windows XP's telnet.exe: if you run it from a command line it would open in the same console window, but if you ran your script by double-clicking it then Windows would "helpfully" open a console window, whether you wanted one or not.

I should say that all the behavior that I'm speaking of is assuming that Windows is running the script (i.e. ShellExec is spawning the process). If the script is being run otherwise (like from AutoIt's Run function) then the behavior is different.

[Angel]

We could indeed, it's just a compile-time option that needs to be changed. But we'd just have to understand that then it would work like Windows XP's telnet.exe: if you run it from a command line it would open in the same console window, but if you ran your script by double-clicking it then Windows would "helpfully" open a console window, whether you wanted one or not.

Yeah but if you really did not want the console window in that case, couldn't you simply use one of the AutoIt commands to hide the console? The only problem would be to detect whether you've beeen launced from a console or directly "from windows". Is there an easy way to know who the parent process is? And anyway, this does not seem like a very big issue.

I should say that all the behavior that I'm speaking of is assuming that Windows is running the script (i.e. ShellExec is spawning the process). If the script is being run otherwise (like from AutoIt's Run function) then the behavior is different.

But isn't that similar to what we do today for other console apps? When you want to run a console app from Autoit, normally you provide one by using run to call cmd.exe or command.exe (i.e. Run(@ComSpec & " /k yourprogram.exe" )).

So I guess that having the option to create a console app (or something that looks like it) could be a pretty good (or good enough) solution that would stop people asking this question anymore (wouldn't that be great, Valik? )

[Valik]

No, it wouldn't be great. It would double the number of binaries distributed with AutoIt and increase the size quite a bit as a result. I already feel the need for AutoItSC.bin should go away and now we're talking about adding a "slightly different" version of AutoIt3.exe and AutoItSC.bin. It would also add unneeded code complexity internally as two separate entry points must be written and maintained. It also introduces the problem that Console-centric scripts will only work correctly with the Console-specific version of AutoIt. There may also be other little quirks I'm not thinking of off the top of my head which will also add complexity.

What would be great is if people would be satisfied with AutoIt being a Windows-only and GUI-subsystem program. If they get the bright idea they want it to be a console application, then before they waste a bunch of people's time, it'd be great if they'd search the forum for one of the countless replies by myself and DaveF on this subject.

[neoviakleipk]

You can just use MS Linker to flag the application as a console application. Then it can be launched from dos. When AllocConsole is called, it has no effect. When all the output functions are called, the buffer is output to the console window the application was launched from.

I will give you an example of using the MS Linker that comes with VB6 (Peice of crap) if you need it.

You just compile your Script and then you flag the executable as a Win32 Console application.

Edited October 5, 2005 by neoviakleipk

[Angel]

What would be great is if people would be satisfied with AutoIt being a Windows-only and GUI-subsystem program. If they get the bright idea they want it to be a console application, then before they waste a bunch of people's time, it'd be great if they'd search the forum for one of the countless replies by myself and DaveF on this subject.

As developpers, it is your call whether a requested feature makes it into AutoIt or not. However, as users, it is our call to whine or complaine when our pet feature is not in AutoIt! By the way this is not one of my "pet" features, but I understand that some people might want something like this. If you are tired of answering this question just don't answer or add the answer the FAQ and point it out to however asks this again...

During this discussion, some seemed to imply that it is possible to modify the compiler to make console apps. However from your post it seems that that was a misunderstanding and that you'd in fact yet a different AutoItSC.bin. If the price of getting this feature is increasing the size of the AutoIt executable or making the build process more complex I don't think that it is worth it, but if it was possible to add it without those problems, why not? After all it is kind of surprising that in AutoIt it is so much easier to make a GUI than a console app! That is probably a quite unique case as far as programming or scripting languages is concerned!

Cheers,

Angel

[Dickb]

What would be great is if people would be satisfied with AutoIt being a Windows-only and GUI-subsystem program. If they get the bright idea they want it to be a console application, then before they waste a bunch of people's time, it'd be great if they'd search the forum for one of the countless replies by myself and DaveF on this subject.

I just have to say this:

Valik, I am very satisfied with AutoIt. Use it a lot in private and work environment.

Most of the time only people that want THEIR feature added to AutoIt post messages.

Please all you developpers , keep up the good work . And don't get upset with posts from this people that persistently declare why their feature should be added.

AutoIt is GREAT . Thank you all.

[DaveF]

As developpers, it is your call whether a requested feature makes it into AutoIt or not. However, as users, it is our call to whine or complaine when our pet feature is not in AutoIt! By the way this is not one of my "pet" features, but I understand that some people might want something like this. If you are tired of answering this question just don't answer or add the answer the FAQ and point it out to however asks this again...

During this discussion, some seemed to imply that it is possible to modify the compiler to make console apps. However from your post it seems that that was a misunderstanding and that you'd in fact yet a different AutoItSC.bin. If the price of getting this feature is increasing the size of the AutoIt executable or making the build process more complex I don't think that it is worth it, but if it was possible to add it without those problems, why not?

Not answering isn't fair to a genuine tyro, and I'm pretty fatalistic about folks reading the FAQ before asking. That being said, I'd rather expand on @neoviakleipk's post above and empower the reader. So:

To make a compiled script (or any win32 EXE) a for-real console app, one need only:

• Obtain a recent version of LINK.EXE, e.g. with the freely available Visual C++ Toolkit.
• Run this command line: LINK.EXE /EDIT /subsystem:console MYSCRIPT.EXE

...and there you are, Bob's Your Uncle, and enjoy.

After all it is kind of surprising that in AutoIt it is so much easier to make a GUI than a console app! That is probably a quite unique case as far as programming or scripting languages is concerned!

Cheers,

Angel

32-bit Windows GUI and console apps are the same, there's basically a one-byte difference in the whole binary file, it's the way the Windows treats them that differs...

[Valik]

And while what DaveF says is true, I do not recommend using that method. I do not think it is too far-fetched to assume that the linker looks at the subsystem at link time and does some optimizations or other stuff based on the selected subsystem. I'm also not sure I trust Microsoft's loader on every version of Windows to see an application with a Console subsystem and a WinMain() entry-point and do the right thing every time.

Until it is proved that the method is 100% safe, the moment anybody changes the subsystem, you are no longer dealing with AutoIt and as far as I'm concerned are no longer entitled to post support requests. I once mentioned this hack to a developer of another project and he simply scoffed and said it was a bad idea, although he wouldn't elaborate. I'm not the only one with reservations about the method listed above.

You use it at your own risk.

[DaveF]

the moment anybody changes the subsystem, you are no longer dealing with AutoIt and as far as I'm concerned are no longer entitled to post support requests

That's insightful and fair in my judgement.

As long as we're here, can someone give me some insight into why it's desired and important to make scripts into console-only apps? I understand that there's some behavior desired, can someone articulate what it is?

[Angel]

That's insightful and fair in my judgement.

As long as we're here, can someone give me some insight into why it's desired and important to make scripts into console-only apps? I understand that there's some behavior desired, can someone articulate what it is?

I think the main use would be to make "interactive console apps" where the user must type some text, for instance, and the script read it and react in accordance, perhaps even writing some text back into the console. Another reason would be if you wanted to make a program that writes into the console in which it was called, and you did not want to return to the prompt until your program was done.

These are not a very big deal for me, but in some cases (in particular when using AutoIt for automation purposes, or in conjunction with bath files) it might be necessary to work this way.

As I said, it is not a very big deal for me, but I understand that it might be for some.

DaveF, I think that your suggestion, although potentially unsafe, might be good enough for most people. In that case, perhaps it could be put in the help file (with a big warning or something)? Maybe that would stop people asking this anymore?

Cheers,

Angel

[seanhart]

That's insightful and fair in my judgement.

As long as we're here, can someone give me some insight into why it's desired and important to make scripts into console-only apps? I understand that there's some behavior desired, can someone articulate what it is?

I figure I should comment since I was one of the ones who was yelled at . Not that I blame Valik, I have to deal with help desk questions so I also get frustrated when the answers are there waiting to be searched. And I do try my best to search the forums before asking questions, but again if a feature is highly desired you'll only know from the number of posts it generates.

So, why do I want the console option? Because I use AutoIt to write lots of "behind the scenes" silent utilities. I jumped for joy the first time I saw the #notrayicon option. Although these utilities are designed to be run by an automated method and thus invisible to the user, sometimes a tech needs to run one manually. And there's where console output comes in useful. I'd like to output something like "install completed successfully" or "unable to access network", etc, etc, but only when someone wants to see it (runs it manually). Otherwise it's easy enough to hide the console window output when it's not wanted (e.g. through a logon script). And in this case I don't want to use a splashtext window or message box because 99% of the time I don't want anyone to see anything.

Of course I could require a command line option to make the utility silent or not silent (which I've done in the past) but some of our techs aren't too brite.

So there it is, hope Valik doesn't find out where I live.

[neoviakleipk]

I just said the same thing as DaveF before he said it. Why are you only responding to his suggestion?

[jftuga]

So there it is, hope Valik doesn't find out where I live.

Umm...

http://people.superpages.ca/wp/results.jsp...=ON&search=Find

-John

[Zach]

Ok, that is funny - didnt think much of it, was like so what - until I saw the Amherstburg, ON

[Richard Robertson]

I have a simple solution. Write a C++ console application and link to the AutoItX Dll. You get automation and C++ console functions.

[Zedna]

As long as we're here, can someone give me some insight into why it's desired and important to make scripts into console-only apps? I understand that there's some behavior desired, can someone articulate what it is?

I didn't need Console functionality till now,

but I think it would be useful for users of console application "Far manager".

It's Win32 console application that looks like Volkov/Norton commander.

So every console utilities (and scripts from that console Autoit) are sending their output (input)

directly to that Far console window...

Edited November 20, 2005 by Zedna

[DaveF]

I didn't need Console functionality till now,

but I think it would be useful for users of console application "Far manager".

It's Win32 console application that looks like Volkov/Norton commander.

So every console utilities (and scripts from that console Autoit) are sending their output (input)

directly to that Far console window...

I would think that the Script Host plugin for FAR would be the appropriate tool for automating FAR. I get broken links on the SourceForge page, but one can download it from the FAR plug-in ring site.

[Zedna]

I would think that the Script Host plugin for FAR would be the appropriate tool for automating FAR. I get broken links on the SourceForge page, but one can download it from the FAR plug-in ring site.

I didn't mean automate FAR,

but writing some AutoIt utilities (parse some TXT files, processing files,...)

which are called via commandline directly from FAR

and their input/output can be sent back to FAR console.

Before AutoIt times I wrote such simple commnadline utilities in Borland pascal (writeln(),...)

It's just idea for use...

Edited November 21, 2005 by Zedna

[erifash]

This is all very exciting, but I have two questions about DaveF's method:

Do you use ConsoleWrite() like cout?

How would you get input like cin?

Thanks!