#7 add minimalistic support for pure CLI mode

[Alexander Stohr]

The attached patch adds command line interface (CLI) support to CUDA-Z so that the option "--cli" or "--CLI" lets CUDA-Z run on the command line and report the detection result to the console (or whereever it is redirected). The returned error code can be 0 for success or 1 for failure. No GUI interaction is intended. Further extensions inside the routine main_cli() can be added at any later time.

This feature allows interaction with other command line tools whilst the tool itself runs "silent". There might be reasons and benefits to have this, e.g. in some automated installer scenarios where it needs to be determined if the current set of dirvers is still sufficient or better some drivers update is caried out. (Somtimes the user just insists on a driver that just works for him, sometimes he already has an even newer but still functional driver installed.)

The patch has this special attribues:
it was written based upon the existing open source codes - thus its licensed & free to use as the original CUDA-Z codes
it was written on Windows with only the MSVS/VC text editor's error highlighting (compilation not done due to extended setup effort) - but i am highly confident it will work for you with nearly no issues in your standard build environment.
* it was not verified using any Linux or MacOS build environment - but i have to assume it has a good chance to run out of the box there

PS: when trying standard QT command line switches on existing CUDA-Z64 bit binaries on windows i saw no reaction at all despite i expected a bit to happen. i am wondering if there is any UPX or alike wrapper "consuming" such args or if just the used QT is configured with none of the items i tried to trigger.

PS2: a switch for command line help (-?, -h, -H, --help, --HELP, /?, /h, /H, /...) would be nice for a further extension, but its not included in the current patch. if you want something like that - feel free to add.

[Andriy Golovnya]

Hi!

Thanks for your patch.

I've tried it out. Unfortunately I’ve stumble over some difficulties with Windows variant of CLI version of CUDA-Z.
First of all is that Windows applications can be built only as window-based or console-based application. I have no idea how to avoid this limitation.

Do you have any suggestions to this challenge?

-- Ag

PS: try CUDA-Z-xxx.exe -reverse
looks cute! ;)

[Andriy Golovnya]

Just have a look on this post:
https://blogs.msdn.microsoft.com/junfeng/2004/02/06/how-to-make-an-application-as-both-gui-and-console-application/

[Alexander Stohr]

you are probably right.
(when going for a bit of GUI i currently most often use things like OpenCV and there are a few things a bit different with the console oputput and the windows main loop. but that will not help here as the framework is a CLI one that finds a way to add GUI.)
hmmm. i am digging the web right now... maybe there is already a simple solution out there.

[Andriy Golovnya]

The last mentioned ildasm.exe can be solution.
https://blogs.msdn.microsoft.com/junfeng/2004/02/06/how-to-make-an-application-as-both-gui-and-console-application/
But it’s a kind of workaround, not a solution.

Perhaps it will be better to compile another application based on the same code.

[Alexander Stohr]

There seems to be some alternate approach - that re-attaches to the parent process and thus gains access to the embedding console and its file handles. someone said you can not have stdin with the code as it is.

the site with the MIT licensed codes:
https://www.tillett.info/2013/05/13/how-to-create-a-windows-program-that-works-as-both-as-a-gui-and-console-application/
the site (talking about c# and providing compareable codes) that hinted me, including the note on stdin:
http://stackoverflow.com/questions/493536/can-one-executable-be-both-a-console-and-gui-application

[Andriy Golovnya]

It's hard to say if this methods will work with Qt application.

What I see for now as realistic and easy:
1. The ildasm.exe solution might work but it's a (SMALL) hack which doesn't work against Qt. (I’ve seen no code for this solution but I assume second instance will be started with suppressed/hidden console window - this is possible)
2. The idea with two applications seams easier way to me but is not really easy to use (from user perspective)

[Alexander Stohr]

a hidden executeable might somewhat work - like copying your own exe to a temp folder and then patching some 1-2 items: the application startup type and a the value of a little switch variable (which in fact can be the same as the first item, just read back from some state, e.g. file handle values or from the executeable itself.) - the user would be able to see a little temporary copy on the file system if he looks after it and maybe the system memory will see a bit more burden for a short moment.

(still in creative phase - and no tools in reach to test it... - havent had the time to re-install any compiler since i did a clean install for the SSD.)

Hmm, the anti-virus software of the target should be able to cope with that. else trouble says hello.

[Andriy Golovnya]

I've checked how ildasm.exe does his magic.

It starts in 1) console mode, 2) checks options, 3a) if no option given it starts itself again with console window suppression and 3a) terminates first instance if itself.

The disadvantage of this method is that for a short time user sees console window from a first instance. Not really nice...

-- WBR, Ag