I'm trying to get my head around a DLL load library problem. The Windows Dynamic-Link Library Search Order is supposed to be
Memory
Known DLL's
Application Directory
System Directory
...etc,
as discussed at https://learn.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-search-order and at many other places.
When I run a Windows Executable (Desktop Application) from a Batch file, does it inherit the 'application' folder from the Batch File? (Because I'm running out of other explanations)
Nope, you can't consider a batch file an application at all.
It's more like a script, as it needs to be run through an actual application/executable program (like the DOS runtime, or CMD on Windows)
You can setup environment variables much like in old DOS times (if you need to define a Paths variable) through sysdm.cpl, but I'm not sure that would help for DLL searching
Related
I am attempting to create a program that places a copy of itself into the windows start-up folder. if the program is being run from anywhere that isn't the start-up folder, I would like the program to add the users username to a text file where the original .exe is. hence I need a way to tell where the program is being run from. is there any inbuilt functions in the default units or will I have to write my own function? if so how would I accomplish this?
ParamStr(0) will get you the full path and application name.
Disclaimer: This could be invalid for some OS implementations.
Is their a way to zip a file without VB Script.I got a lot of examples on web to zip file or folder using vbs but i want to do it in a single BAT file.
Yes and no. There is no built in way to do this inside windows. You can use a external application like vbscript, a exe file like 7zip, rar, lots of resources can do this. Since windows is application poor when it comes to command lines is not really surprising. But no you do not need the VB Script for anything.
Just not so easy out of the box. Maybe makecab could do it for you? As a general rule you have a hard constraint in your question. A single BAT file which in general can not do almost anything without the support of hundreds of preinstalled or commonly installed other applications.
Could you specify a the constraints a bit better. Tel WHY you need this particular constraint? And what does it mean as even most of the bat command you use require more than one file.
I work on software that requires access to DLLs, usually wants environment variables set a certain way, and can take command line parameters. I'm generally opposed to setting/modifying system-wide environment variables for the purpose of launching these apps, since I might want to use different dependencies (different dlls), etc. and I don't want to accidentally get the wrong DLL loaded.
Up until now, I've been generating the visual studio .vcproj.user files and matching batch files from cmake ( see here for my script ) that extends the path to include the path to my dlls, sets any other environment variables as needed, and launches the application, forwarding all the command line arguments. (I do the same on Linux, but it's simpler because of RPATH). When we want to launch with a command line argument that wasn't just a file we could drop on the batch file, what we did is copy the batch file and edit the command to add our argument. (It's all GUI applications, but config files/flags can be passed on the command line)
This has become quite a hassle for me and my colleagues, and we end up with a ton of batch files, named similarly and difficult to maintain. It's not really a great interface for starting but there's a lot of apps we either use or develop that are like this, so it's a common task.
My question is this: I'd like a nicer way to configure dynamic library search paths, process-local environment variables, working directory, executable, and arguments for starting a program than hand-editing a batch file every time. I've done some digging to try to find one, but haven't been successful - "launcher" tends to bring me to "search-as-you-type" tools for frequently-used apps, and "command line argument" tends to find recommendations to use batch files. (It's not a windows-specific issue, either, but the dynamic library path stuff is less problematic during the code/compile/run cycle)
I've made a quick mockup of what I'm envisioning: it seems like the kind of thing that has to exist somewhere. Do you know of a tool similar to this (preferably cross-platform, and open source is even better)? It doesn't need all bells and whistles I put in the mockup, but that's what I'd build if I had time to build it myself. Thanks!
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).
What is the difference between the a.bat, a.com and a.exe extensions?
Originally, a .COM file was a literal blob of 8086 code (that is, 16-bit x86). It is meant to be loaded at a fixed address, and the loader would jump straight to the first byte of its address. It's also limited in size.
An .EXE file has more header information. So it has required structures for things like dynamic linking, where code from a DLL can be patched into the .EXE's memory space at load time.. It originally comes from DOS, but it's today used in Windows.
However DOS and Windows eventually went to a model where the file extension in a .COM and .EXE didn't mean anything. The program loader first checks the first two bytes of the file. If it happens to be the string MZ (legend has it this stands for the initials of an early Microsoft employee), it will treat it as an EXE, otherwise it will load it as if it were a COM file. Since MZ doesn't map to a sensible x86 instruction to start a program, they can get away with this. Net effect: In some versions of DOS/Windows, an .EXE can be named with .COM and vice versa. For example, in many versions of DOS/Windows, the famous COMMAND.COM was actually an EXE.
I am not sure how much the previous paragraph applies to NT based versions of Windows. I'd imagine by now they've abandoned the .COM stuff altogether.
Lastly, a .BAT file is a list of commands to be executed as if you typed them at your command prompt. However these days most people name them as .CMD.
.bat is a batch file. It is interpreted.
.exe is a regular executable program file.
A .com file, at least for MS-DOS, has many meta-data missing and is loaded into a specific offset in the main memory. It is smaller than .exe
I assume you mean for Windows?
"a.bat" is supposed to be a batch file, the Windows/DOS equivalent of a script file.
"a.com" and "a.exe" are supposed to be equivalent these days. However, back in the Windows 3.x days, a "com" file was a DOS executable, where an "exe" file was a portable executable, or a Windows-based executable. This is a gotcha these days, as files in the format "www.example.com" can exist on your hard drive, and many people mistake such a file for a web link. Even worse, Windows typically tries executing "com" files before "exe" files.
A bat(ch) file is a script that is executed by the command interpretor.
A exe file is compiled binary code to be executed directly on the cpu.
A com file is a relic from the past to create a small exe.
.BAT - Batch File: list of commands (basically a text file with command-line commands)
.COM - DOS Executable loaded into a fixed block of memory (stems back from before multi-tasking)
.EXE - Executable file - standard application on the Windows platform
While EXE and BAT files often serve a similar purpose, they use completely different file formats. Both file types can be used for creating executable content in Windows, but BAT files are limited in the commands they can perform. Since BAT files contain human-readable text, they can be easily edited and therefore are often used for custom scripting tasks. EXE files, on the other hand, contain complex binary data that is built using a compiler. Since EXE files support more complex commands than BAT files, most Windows applications are saved in the EXE format.
I was also looking for the same query and found something that have pasted here.
Please refer the below link, you will find it useful, it perfectly answers your question:
Difference between .BAT and .EXE
Actually, .com and .exe are both binary executable files, whereas .bat is basically a batch file. Now suppose you have got many files with the same name, but different extensions.
For instance, a.com, a.exe and if you are running through the command prompt file a. It will first execute a.com (only if it exists), else it will run a.exe. Or say a.exe is also not there then it will look for a.bat execution.
A .BAT (short for "batch") file is a plain text file that contains a
series of Windows commands.
An .EXE (short for "executable") file is a binary file that contains
much more complex executable binary code.
A .COM file was a DOS executable and nowadays its same as .EXE.
.bat file effects directly on the performance of CPU.
While, the .exe file will be compiled by interpreter and then executed on CPU.