Making Any Command in CMD work in a .BAT as an .EXE - windows

Redirecting CMD Commands To An EXE File
Long story short, basically I have the problem that every time I run BCDedit on the .BAT that I converted into an .EXE it never worked and I thought that the reason why it wasn't work was because it wasn't on Path but my Path was fine and even if it was on Path is set by default thanks to foxidrive.
Now my main problem is that is there a way I can convert it to an .EXE file with every single command working, is there a technique I could use to get BCDedit working as an .EXE file?
All of the commands do work it just BCDedit and I say if every single command would work so if somebody has a similar command problem like me they know how to figure it out, it works perfectly as batch but is there a way I can convert it and make BCDedit still work as an .EXE?
Please answer As Soon As Possible and if you want to take a look at my Path and Batch the visit the link at the top.
Thank you so much!

Compile this batch file and see if it works:
#echo off
bcdedit /?
pause
Then try this version:
#echo off
c:\Windows\System32\bcdedit.exe /?
pause

Just as the SysWow64 Redirection link you listed states. If you want a x86 application to call the 64-bit system directory you need to call the bcdedit application as follows.
%SystemRoot%\SysNative\bcdedit
This is because of Windows backwards compatibility measures, it is looking at C:\Windows\SysWOW64 instead of C:\Windows\System32. Another alternative would be to compile the script as both x86 and 64-bit, but then you could only use each on the respective systems.
Update for Comments
Even though the path is correct, an x86 application will execute commands or batch scripts against the C:\Windows\SysWOW64\cmd.exe which will cause the path redirection issue. Example to illustrate my point. On a 64-bit version of Windows, open C:\Windows\SysWOW64\cmd.exe and using Windows explorer create two unique files , one is C:\Windows\System32\unique_test64.txt and the other in C:\Windows\SysWOW64\unique_test86.txt. Now on the x86 command prompt enter if exist C:\Windows\System32\unique_test86.txt echo true. You will see that it is being redirected to SysWOW64 and will print true. And if you enter if exist C:\Windows\System32\unique_test64.txt echo true, nothing will be found.
Screenshot Example: http://i.imgur.com/K4kkI29.png

Related

Running .cmd with 32 bit launcher?

I have spent a lot of hours trying to figure out this simple thing I want to accomplish. I have a .cmd file with one line: sfc /scannow
I wrapped this into a package with the command line as a program at: cmd /c sfc.cmd and this is set to install as required and hidden. (I can look at the cbs log if this actually did run).
So then it get's deployed and downloaded to the test machines and i see it in ccmcache folder. Looking at execmgr.log it executed the following:
"C:\Windows\system32\cmd.exe" /c sfc.cmd, Working Directory = C:\Windows\ccmcache\g\
Running "C:\Windows\system32\cmd.exe" /c sfc.cmd with 32bitLauncher
Those two indicators were noted around 4:43PM. I don't see exit code 0 or any other code. Then looking at cbs.log the last write time was 4:19PM. What am I doing wrong?
If I try to run sfc /scannow from a 32Bit cmd in 64Bit Windows I get an error so you probably have to use a trick to run the 64bit sfc.
Instead of the commandline
cmd /c sfc.cmd
use
C:\windows\sysnative\cmd /c sfc.cmd
Sysnative is an alias that you can unfortunately not see but if a program is started as 32bit process it can access it. What it does is avoiding the WoW64 redirection that intercepts every call to system32 and sends it to syswow64 which in your case leads to a problem.

Windows %CD% environment variable not being updated

I have this simple batch file (test.bat):
echo %CD%
pause
No matter where I run this .bat file from (i.e. C:\some\dir\test.bat), my system tells me that I'm in C:\ . This is obviously neither the intended nor the desired behavior, and if I try the exact same script on a different machine, it behaves as expected, giving me current directory of the .bat file. I've been googling for hours now and haven't been able to find anything relevant to my issue. Perhaps I missed up a windows setting somewhere? I have no idea, anyone have any ideas?
Found the issue: there was an AutoRun registry entry that would change directory to C:\ whenever a shell was opened. facepalm

Scheduling automated scripts suite run from schedular

So I tried and tried but couldn't figure out this one for some reason.
how can I run a task from a desired directory instead of System32 directory where cmd.exe is.
so, when I schedule a task and try to run it ..
command prompt suppose to go to "c:\users\aaa\bbb\ccc" and then pass the argument.
Instead, It's starts at c:\Windows\System32 and fails.
Could anybody help me with this please?
I really appreciate it.
Thank you.
EDIT --
so, now I have a run.bat file with following content in it ...
C:\Users\aaa\bbb\ccc\dd (location to my testrunner.bat file)
testrunner.bat Scripts/all.suite website-address ie (command for the task I wanna perform)
net stop schedule (since window is poping up and going away way to fast, I added this to stop it (not working))
type run.bat
#echo off
cd C:\Users\aaa\bbb\ccc\dd
rem this will show all files in dir
rem is the file you're expecting listed?
dir
rem notice how you can make comments with a leading rem(ark)
#echo starting scripts\all.suite
rem you have to change this to have the full path using Windows X:\dir\dir conventions
c:\home\Scripts\all.suite website-address
#echo done running scripts\all.suite website-address
#echo shutting down
net stop schedule
So its still not clear exactly to me your goal. The reason I added the cd c:\... command is that will **C**hange **D**irectory to the path specified.
This is what you need so you can "run a task from a desired directory instead of System32".
Copy everything from the first #echo off to the last net stop and using notepad, paste it into a file, fix command names and paths website-urls, etc, then save that file to c:\temp\testrunner.bat.
Open a cmd.exe window and test that the script works. Just paste c:\temp\testrunner.bat on to cmd-line and hit enter. If that works, then made an entry in the scheduler to run c:\temp\testrunner.bat . I don't know the specifics of running a script for scheduler, so look for clues on the input screen. Is the an option to run 'now'?
If the .bat file doesn't work from the command-line, then you have to fix the file before you try running it in the scheduler. As your command Scripts/all.suite website-address is a little vague, you'll do better to post a new question asking for help to fix the .bat file and use a sample command that people will be able to use on their PCs at home.
IHTH.

Basic windows commands (ping, ipconfig) need admin rights - looking for an option

On my main pc (Win 7 64bit) basic windows commands like ping and ipconfig suddenly need admin rights.
If I start a normal command-line window, these commands are not found anymore ("X is not recognized as an internal or external command, operable program or batch file.")
If I start the command-line window with "Run as Administrator" everything works as expected.
On my second PC (Win 7 32 bit) I do not need admin rights.
And I strongly believe that I did not need admin rights on my main pc a couple of weeks ago. Something must have changed, thus I think there must be some (registry) switch or something.
any ideas? thanks a lot
[edit]
I am still the admin user - just starting cmd normally, not with "run as admin"
[edit2]
It indeed was the PATH, variable. Problem was, that Path was saved as the wrong type of string in the registry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\Path
has to be a REG_EXPAND_SZ as explained in this thread. Path being of the wrong type of string made it unable to expand %SystemRoot%. Make sure that both your system PATH as well as your user PATH environment variables are of type REG_EXPAND_SZ.
In an effort to narrow down the issue try the following:
open command prompt
make sure you are on the C:\ directory
type this: windows\system32\ipconfig /all
That will point to the default location for the command... You can also follow the path out to see if the ipconfig.exe is there in the first place. If that doesn't work or the file is not there, it could be corrupt or you could possibly have a virus designed to disable these commands.
Srart normal cmd prompt and look at output of the following commands
set path
dir %windir%\system32\ping.exe
dir %windir%\syswow64\ping.exe
dir %windir%\sysnative\ping.exe
Thought, they will show you a problem. May be ping is not found by %path% or somehow...

Windows batch files: .bat vs .cmd?

As I understand it, .bat is the old 16-bit naming convention, and .cmd is for 32-bit Windows, i.e., starting with NT. But I continue to see .bat files everywhere, and they seem to work exactly the same using either suffix. Assuming that my code will never need to run on anything older than NT, does it really matter which way I name my batch files, or is there some gotcha awaiting me by using the wrong suffix?
From this news group posting by Mark Zbikowski himself:
The differences between .CMD and .BAT as far as CMD.EXE is concerned
are: With extensions enabled, PATH/APPEND/PROMPT/SET/ASSOC in .CMD
files will set ERRORLEVEL regardless of error. .BAT sets ERRORLEVEL
only on errors.
In other words, if ERRORLEVEL is set to non-0 and then you run one of those commands, the resulting ERRORLEVEL will be:
left alone at its non-0 value in a .bat file
reset to 0 in a .cmd file.
Here is a compilation of verified information from the various answers and cited references in this thread:
command.com is the 16-bit command processor introduced in MS-DOS and was also used in the Win9x series of operating systems.
cmd.exe is the 32-bit command processor in Windows NT (64-bit Windows OSes also have a 64-bit version). cmd.exe was never part of Windows 9x. It originated in OS/2 version 1.0, and the OS/2 version of cmd began 16-bit (but was nonetheless a fully fledged protected mode program with commands like start). Windows NT inherited cmd from OS/2, but Windows NT's Win32 version started off 32-bit. Although OS/2 went 32-bit in 1992, its cmd remained a 16-bit OS/2 1.x program.
The ComSpec env variable defines which program is launched by .bat and .cmd scripts. (Starting with WinNT this defaults to cmd.exe.)
cmd.exe is backward compatible with command.com.
A script that is designed for cmd.exe can be named .cmd to prevent accidental execution on Windows 9x. This filename extension also dates back to OS/2 version 1.0 and 1987.
Here is a list of cmd.exe features that are not supported by command.com:
Long filenames (exceeding the 8.3 format)
Command history
Tab completion
Escape character: ^ (Use for: \ & | > < ^)
Directory stack: PUSHD/POPD
Integer arithmetic: SET /A i+=1
Search/Replace/Substring: SET %varname:expression%
Command substitution: FOR /F (existed before, has been enhanced)
Functions: CALL :label
Order of Execution:
If both .bat and .cmd versions of a script (test.bat, test.cmd) are in the same folder and you run the script without the extension (test), by default the .bat version of the script will run, even on 64-bit Windows 7. The order of execution is controlled by the PATHEXT environment variable. See Order in which Command Prompt executes files for more details.
References:
cmd.exe
command.com
wikipedia: Comparison of command shells
These answers are a bit too long and focused on interactive use. The important differences for scripting are:
.cmd prevents inadvertent execution on non-NT systems.
.cmd enables built-in commands to change Errorlevel to 0 on success.
Not that exciting, eh?
There used to be a number of additional features enabled in .cmd files, called Command Extensions. However, they are now enabled by default for both .bat and .cmd files under Windows 2000 and later.
Bottom line: in 2012 and beyond, I recommend using .cmd exclusively.
No - it doesn't matter in the slightest. On NT the .bat and .cmd extension both cause the cmd.exe processor to process the file in exactly the same way.
Additional interesting information about command.com vs. cmd.exe on WinNT-class systems from MS TechNet (http://technet.microsoft.com/en-us/library/cc723564.aspx):
This behavior reveals a quite subtle
feature of Windows NT that is very
important. The 16-bit MS-DOS shell
(COMMAND.COM) that ships with Windows
NT is specially designed for Windows
NT. When a command is entered for
execution by this shell, it does not
actually execute it. Instead, it
packages the command text and sends it
to a 32-bit CMD.EXE command shell for
execution. Because all commands are
actually executed by CMD.EXE (the
Windows NT command shell), the 16-bit
shell inherits all the features and
facilities of the full Windows NT
shell.
RE: Apparently when command.com is invoked is a bit of a complex mystery;
Several months ago, during the course of a project, we had to figure out why some programs that we wanted to run under CMD.EXE were, in fact, running under COMMAND.COM. The "program" in question was a very old .BAT file, that still runs daily.
We discovered that the reason the batch file ran under COMMAND.COM is that it was being started from a .PIF file (also ancient). Since the special memory configuration settings available only through a PIF have become irrelevant, we replaced it with a conventional desktop shortcut.
The same batch file, launched from the shortcut, runs in CMD.EXE. When you think about it, this makes sense. The reason that it took us so long to figure it out was partially due to the fact that we had forgotten that its item in the startup group was a PIF, because it had been in production since 1998.
Still, on Windows 7, BAT files have also this difference : If you ever create files TEST.BAT and TEST.CMD in the same directory, and you run TEST in that directory, it'll run the BAT file.
C:\>echo %PATHEXT%
.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC
C:\Temp>echo echo bat > test.bat
C:\Temp>echo echo cmd > test.cmd
C:\Temp>test
C:\Temp>echo bat
bat
C:\Temp>
Since the original post was regarding the consequences of using the .bat or .cmd suffix, not necessarily the commands inside the file...
One other difference between .bat and .cmd is that if two files exist with the same file name and both those extensions, then:
entering filename or filename.bat at the command line will run the .bat file
to run the .cmd file, you have to enter filename.cmd
everything working in a batch should work in a cmd; cmd provides some extensions for controlling the environment.
also, cmd is executed by in new cmd interpreter and thus should be faster (not noticeable on short files) and stabler as bat runs under the NTVDM emulated 16bit environment
.cmd and .bat file execution is different because in a .cmd errorlevel variable it can change on a command that is affected by command extensions. That's about it really.
I believe if you change the value of the ComSpec environment variable to %SystemRoot%system32\cmd.exe(CMD) then it doesn't matter if the file extension is .BAT or .CMD. I'm not sure, but this may even be the default for WinXP and above.
The extension makes no difference.
There are slight differences between COMMAND.COM handling the file vs CMD.EXE.
a difference:
.cmd files are loaded into memory before being executed. .bat files execute a line, read the next line, execute that line...
you can come across this when you execute a script file and then edit it before it's done executing. bat files will be messed up by this, but cmd files won't.

Resources