Question related to Windows platform only.
I can't find documentation on how to approach this.
There are dozens of posts about this, yet most provide answers for mac/linux, most windows specific parts lead to dead links or README's that have no useful information.
How do I, for example, make an .exe of the code below? The intent being to share it with another windows user, so that when they click it...it automatically runs the program in command prompt or wherever .exe are supposed to run without them needing to have lua/luac installed on their system.
Or perhaps I'm missing the point here and you need lua/luac installed, otherwise you would need to convert to a program language that's already installed on everyones' windows systems like C...? Regardless I need something that works for the purpose described. Could I make a folder with lua.exe and luac.exe and input.lua and make an .exe that loads command prompt and runs the command to compile input.lua? new_folder: lua.exe, luac.exe, input.lua, run.exe
> --input.lua
print("type ur name")
name=io.read()
print(#name)
print("your name is " name)
I'm not aware of anything in wxlua that can compile a lua file into an executable. There is wxLuaFreeze executable that allows to concatenate a lua script to it to generate a new executable that will run that script when executed. See the documentation for details: http://wxlua.sourceforge.net/docs/wxlua.html#C7.3.
Related
I want to create a self-extracting file (SFX) named Setup.exe which contains a Windows application with some dependencies.
It is possible to start the Windows application with arguments, and I would like to put them at my Setup.exe and then it should pass them to the Windows application. Furtermore, I would like to pass the Windows application exit code to the Setup.exe.
Currently I have tried to use 7zip, but it seems that it isn't sufficient.
Is it even possible with 7z or do you know how to do with other tools?
You've asked a lot of questions and I am trying to answer a few here, maybe not all of them.
Yes it is possible to start a Windows Application with arguments. Ideally for that you need to open command prompt and navigate to the directory of your application then type in theProgramName.exe - arguments options but that I assume you already know.
Another approach would be to Create ShortCut for the Program you are targeting and then you can just Right click -> Properties -> and append your arguments to the Target field. Example : C:\Games\Counter-Strike\hl.exe -steam -game cstrike -noforcemparms -noforcemaccel
Another approach that I assume you would want when you are creating a SFX is to create a .bat (batch) file with the contents being theProgramName.exe - arguments options and put it in the same directory as your program and set it to run as our main application when it extracts. If you want the exe and not the bat you can use some bat to exe conversion tools, there are tons out there.
The best way I can think of is using programs like Advanced Installer. You can directly make an msi or a sfx and send a shortcut anywhere (more than one) and it could contain arguments you specify just like what I described in the second way.
So yeah that other tool I'd vouch for that will do what I think you want to do is Advanced Installer.
After some experiments, I changed the implementation so instead of using 7 zip to create a SFX I just embed all I need like *.msp and such as embedded resources in my Windows application.
On that way my arguments and return code worked out of the box.
I used this link to do actual implementation: https://www.telerik.com/blogs/how-to-merge-assemblies-into-wpf-application
Is there a way to prevent direct startup of a .exe program, and only start up when a shortcut is run? I'd like this to work also when opening up a filetype that is assigned to a program.
The only thing that comes close to what you want is checking for certain command line parameters. This is actually a rather common way for concealed executions - for instance programs that want you to run a loader program first (online games would be an example).
So you would have to generate a shortcut that privdes the specific command line arguments needed for the start. This ensures that your exe cannot be executed directly, however there are no guaranties that a specific shortcut file is startet as it only provides a link to the exe file.
No, that is not possible, in my knowledge.
This is not possible, the shortcut is executing the program in its location. The .exe has to be executable for the shortcut to work. Assigned file extensions also execute the actual .exe the shortcut is just a symbolic link to the actual file.
If you can give more information as to what your trying to accomplish I could maybe offer another solution.
I'm not aware of any way built in to do this, as an executable is still launched as that user by the shortcut. You can disable shortcut locations, allow only certain executables, etc but not deny access to executable but also allow it via shortcut.
C:\Users\redacted\Documents\redacted>gfortran hibrac.f -o hibrac.exe
'gfortran' is not recognized as an internal or external command,
operable program or batch file.
https://gcc.gnu.org/wiki/GFortranBinariesWindows seems similar to my problem: gfortran.exe is in C:\Windows\MinGW\bin -- except the solution appears not to apply to Windows 8.1 Pro:
Right click on My Computer, Properties, Advanced Tab, Environment Variables.
Instead I tried: Right click on 'This PC' within File Explorer, Properties, Advanced system settings, Advanced Tab -- and I cannot find an equivalent-looking section that allows me to proceed with the advised solution.
As background information:
I had installed MinGW Installation Manager which installed mingw32-gcc-fortran (together with mingw32-base, -gcc-g++, and -gcc-objc) in the recommended C:\Windows\MinGW folder, without any apparent error message.
Isn't it acceptable -- standard practice -- to have one's code in a folder separate from this MinGW folder? i.e. a subdirectory of my Users\account rather than a subdirectory of MinGW. This isn't the problem, is it? What do I need to do to get it to recognize the gfortran.exe, or call it correctly?
Please tell me what to do to get it working. If it's relevant, I have a Japanese computer with an English language pack installed (it seems to have some gaps, such as some text in the Settings charm or startup/shutdown text being in Japanese).
This looks very much like you have neglected to add C:\MinGW\bin to the effective PATH for the command window, in which you are attempting to run the gfortran command.
Your question isn't entirely specific on this point, (i.e. you could improve the question), but you hint that you were unable to add the appropriate PATH entry to the global environment variables, because you couldn't find the appropriate control panel applet? I know that this is often recommended as part of a MinGW setup, but the installer will not do it for you, because I, as the maintainer of mingw-get, don't consider that to be best practice; much better, IMO, to add it for each specific command window in which you need it to take effect, by running (once, at the start of each command prompt session) the command:
path %PATH%;C:\MinGW\bin
If you prefer, you may create a batch file to do this for you, along with any other initializations you wish to perform, (or better still, use MSYS as the working shell environment, in which case the PATH initialization is taken care of by the shell's own initialization scripts).
I am trying to compile the following software so that I can step through and debug it. I am only a novice programmer and I am trying to understand how this whole makefile business works with Fortran. I know that there is a ton of literature on makefiles but I just need to insert a simple debug flag and I think if someone provided me with the answer to this question that would be the best way for me to learn.
So the program I am trying to compile, TINKER, is actually made up of several packages, located at http://dasher.wustl.edu/tinkerwiki/index.php/Main_Page. I would like to compile and debug JUST ONE specific executable, "analyze". I contacted the developer and received the following reply but I am still stuck...
Since TINKER has lots of small source code files, what we do is
compile each of the small files to an object file using the "-c" flag.
Then we put all of these object code files (ie, the ".o" files) into
an object library. Finally, we link each of the TINKER top level
programs, such as "analyze", against the object library. There is a
Makefile supplied with TINKER that does this. We also supply
individual scripts called "compile.make", "library.make" and
"link.make" for various CPU/compiler combinations that can be run in
order to perform the steps I describe above. To build a "debuggable"
executable, you just need to include the appropriate debug flags
(usually "-g") as part of the compile and link stages.
I am currently running OSX 10.6.8. If someone could show me which folders I cd into, what commands I enter that would be so great!
Thanks!
My follow up question (once I can figure out how to answer the above via command line will concern how to import the same procedure but using the Photran IDE - http://wiki.eclipse.org/PTP/photran/documentation/photran5#Starting_a_Project_with_a_Hand-Written_Makefile)
The directions are at http://dasher.wustl.edu/tinkerwiki/index.php/Main_Page#Installing_TINKER_on_your_Computer
Maybe out of date? g77 is obsolete -- it would be better to use gfortran.
The key steps: "The first step in building TINKER using the script files is to run the appropriate compile.make script for your operating system and compiler version. Next you must use a library.make script to create an archive of object code modules. Finally, run a link.make script to produce the complete set of TINKER executables. The executables can be renamed and moved to wherever you like by editing and running the ‘‘rename’’ script."
So cd to the directory for the Mac -- based on "we also provide machine-specific directories with three separate shell scripts to compile the source, build an object library, and link binary executables." Then run the command scripts. Probably ./compile.make. Look around for the directories ... you can probably figure it out from the names. Or search for the file "compile.make".
Or find someone local to you who knows more about programming.
EDIT: This is due to stupidity. It is a multiple monitor issue. It's just that from cmd.exe we always opened in the primary monitor, whilst from explorer, we always opened in the secondary. Thanks all for the help!
We hit a weird bug recently. We have a Qt + osg app that behaves differently if we run it from explorer than if we run it from a command line. Running from explorer is unusable, while running from command line (or by running from the explorer a simple batch file that calls the .exe) works as expected.
We suspect environment variables, because that's all we can think of. But the fact that it runs fine with a one line batch file seems to refute this. I'm not familiar enough with windows to know of any subtle differences in how it loads executables, nor where to look to find out.
Are there any other differences that could explain this? Does windows load different sets of user environment variables in each case? OS is Windows XP Service Pack 3.
The behavior experienced when running from explorer (double click program.exe) is consistent with a driver issue or improper OSG scene setup: image artifacts, flashing, and weird colors.
The behavior experienced when running the same executable from cmd.exe (or by double clicking a .bat file next to the .exe containing only a line to run the .exe) is the correct, expected behavior: the scene is correct, no flashing, etc.
To rule out potential library load path issues, try using dot-local DLL redirection.
Towards that end, create an (empty) file in the same directory as your executable and give it the same name as your binary, except with .local appended. I.e., if your binary is named yourbinary.exe, name that file yourbinary.exe.local. That will force the PE loader to first look in that directory to resolve LoadLibrary calls (and that includes DLLs loaded indirectly via system DLLs or via COM, no matter how many indirection levels are involved.) Place as many supporting DLLs (including Qt DLLs) in that directory. If you're using Qt plugins, also place the plugins directory there (or use a custom trolltech.conf.)
More details on dot-local redirection here, for example.
This thread looks like it might have the answer to your question:
http://forum.soft32.com/windows/Start-Run-Command-Prompt-ftopict353085.html
In short, I think it might be looking for your executable in different places depending on which method you attempt to use to run it. Perhaps you have 2 different versions hiding somewhere that explorer uses instead of the one you want?
You have not given enough details so I will give you a general answer. In order to use QT and its tools you need 2 environment variables. *QTDIR, and PATH * Make sure you have these variables set instructions are below. I have taken them from this site. See also this link for deployment on windows.
Setup the QTDIR environmental
variable.
1) Create a new System variable
called: QTDIR
a. Right click on My Computer -> Properties -> Advanced Tab ->
Environment Variables button
b. Find System variables -> New -> Type in "QTDIR" 2) Set the value to: C:\your\Qt\directory (NOTICE: No
trailing '\' character!!!)
Now, add the QTDIR on to your PATH
variable.
1) Edit your PATH variable, add onto
the end of it a ';' if one isn't
already on the end. 2) Now add on:
%QTDIR%\bin;
Example:
Before
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;
After,
PATH=%SystemRoot%\system32;%SystemRoot%;%SystemRoot%\System32\Wbem;%QTDIR%\bin;
That will make sure that our Qt
application(s) will be able to find
the Qt DLL files when you go to run
it.
I hope this helps.
Perhaps there is a difference caused by the way Explorer launches an executable vs directly running it from the console. I think that Explorer uses ShellExecute or ShellExecuteEx and I doubt that executing an application from a console or batch file does the same.
I would create a test app that tries some of the ShellExecute variants and use different parameters to see if the Explorer behavior can be reproduced in order to try to diagnose what parameters passed to ShellExecute might be causing the problem.
There is an interesting community note on the ShellExecuteEx page that may or may not be applicable:
ShellExecuteEx ignores the current input desktop. It always uses winsta0\default. Instead use ShellExecute or CreateProcess.
I would also investigate whether or not AppCompatFlags affect console executed applications (or see if any AppCompatFlags have been set for your application).