When we build a project, we can define that under which subsystem we want to run our program in windows. But how it would affect the output exe file. Or in other words when we call a CreateProcess() API we just pass it an exe file, So which header inside the exe file, it
checks to determine that which subsystem going to handle this process? Or it uses some other method in order to accomplish it?
i guess, i will look into EXE header
Look
http://www.delorie.com/djgpp/doc/exe/
http://www.fileformat.info/format/exe/corion-mz.htm
Tools update:
I like:
http://www.heaventools.com/PE-file-header_viewer.htm
http://www.mitec.cz/exe.html
You Can:
http://blogs.msdn.com/b/securitytools/archive/2010/01/28/how-to-view-the-header-of-an-exe-dll.aspx
online :http://exe.urih.com/
In the primary header of executable, that information is present. As you are talking about .exe(or rather binary), linker stage is performed. Linker is part of OS, and every OS has a code number through which it is recognized as its binary.
As in case of windows and CreateProcess(), consider reading this
Related
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.
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.
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).
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I have a DLL file and I want to execute it on Windows. I obtained this DLL file from a challenge site which alleges the DLL should be executed independently.
To run the functions in a DLL, first find out what those functions are using any PE (Portable Executable) analysis program (e.g. Dependency Walker).
Then use RUNDLL32.EXE with this syntax:
RUNDLL32.EXE <dllname>,<entrypoint> <optional arguments>
dllname is the path and name of your dll file, entrypoint is the function name, and optional arguments are the function arguments
You can execute a function defined in a DLL file by using the rundll command. You can explore the functions available by using Dependency Walker.
While many people have pointed out that you can't execute dlls directly and should use rundll32.exe to execute exported functions instead, here is a screenshot of an actual dll file running just like an executable:
While you cannot run dll files directly, I suspect it is possible to run them from another process using a WinAPI function CreateProcess:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682425(v=vs.85).aspx
DLLs are shared libraries which are used by other windows programs while EXEs are the files which are actually executed and are linked to DLL files so that they can use DLLs. Both are of same format, PE(portable executable or format of machine code in windows in simple words).
In other words EXEs contain the entry point(main) and the DLLs contain the library functions.. You cannot execute a file which just contains library functions you can just use them via other programs.
But still there are programs like rundll32.exe which provides that entry point and some minimal framework required by DLL functions to be called.
The point that I want to make is, you can never execute a DLL file you can just use it's code by providing an entry point through an EXE or some other program.
You can't "execute" a DLL. You can execute functions within the DLL, as explained in the other answers. Although .EXE files and .DLL files are essentially identical in terms of format, the distinguishing feature of an .EXE is that it contains a designated "entry point" to go and do the thing the EXE was created to do. DLLs actually have something similar, but the purpose of the "dll main" is just to perform initialization and not fulfill the primary purpose of the DLL; that is for the (presumably) various other functions it contains.
You can execute any of the functions exported by a DLL, assuming you know which one you want to execute; an EXE may contain a whole lot of functions, but one and only one is specially designated to be executed simply by "running" it.
To Run a .dll file..First find out what are functions it is exporting..Dll files will excecute
the functions specified in the Export Category..To know what function it is Exporting refer "filealyzer"
Application..It will show you the export function under "PE EXPORT" Category..Notedown the
function name--
Then open the command prompt,Type Rundll32 dllname,functionname
(dllname--name of your dll)
(Functionname-- name of the function you found under the PE Export)
Note:Makesure that your command prompt location is your dll file location
It should be mentioned that since it is entirely possible to run DLL's just as any other executable, it has long been considered a security issue. As such, there have been a number of security improvements and registry hacks (sorry no longer have ref-links) that prevents running DLL's from regular user space without extra privileges.
As a good example. I recall making these hacks, but since I no longer remember what exactly I did. I can no longer run any DLLs from normal user shell environment, even though starting various Win apps from GUI works just fine.
That said, one should definitely read "Dynamic-Link Library Security" and "Best Practices to Prevent DLL Hijacking".
.DLL files are not executable in the sense that .EXE/.COM/.BAT files are executable, so I'm not sure what you mean.
You can use the Dependency Walker application that comes with the Windows SDK to interrogate a .DLL and see what functions are exported by the file.
The following series of steps might be helpful:
Open Windows Explorer
In the top-left corner, click "Organize"
select "Folder and Search Options"
Switch to the "View" tab
Scroll down and uncheck "Hide file extensions for known file types"
Click OK
Now find the dll file
Right-click on it and select "Rename"
Change the extension(what comes after the last .) and change it to .exe
I want to know what is the standard way of doing it.
currently I'm thinking in add a series of defines in a header file and inlcudie that file in the main resource file win win32 to update the version resource in win32 and in *nix make some global functions to return this information.
and in windows make the msi install file also reflect the same version.
That sounds like a reasonable way to do it. I don't think there IS a standard way of doing this; there aren't any real standards for version reporting that are cross-platform.
Since we wanted to avoid the overhead of changing a "version.cpp" or equivalent every time we hit build -- and thereby taking the time to do at least one compile and link -- we modify the binary after the build.
If you're outputting to e.g. ELF or PE format executables, you can use some basic knowledge of ELF or PE and a linker map to figure out what to replace, otherwise you can scan through the binary looking for a set pattern (we use something like static const char VERSION[] = "[VERSIONBLOCK xxxxxxxxxxxxx]";) and replace a portion (e.g. the xxxx part above) with relevant info:
build date and time
build machine
username
output of e.g. svnversion
Note that this won't work very well if your binaries are signed or compressed before this step, but usually you can engineer your build process so the signing/compressing happens after this step.
I'm sure a variant of this could be extended to hit the Win32 PE version metadata as well as any embedded version string.