Starting the Command Promt from a program using 'system(...)' - c

If I start the Command Prompt the Standard" way, go to 'C:\Windows\System32' and do "dir m*.exe", I get "several screensful" of listing. Among others 'msg.exe' is there. And if I do 'msg /?' :
C:\WINDOWS\system32>msg /?
MSG {username | sessionname | sessionid | #filename | *}
[/SERVER:servername] [/TIME:seconds] [/V] [/W] [message]
e
tc.
And the 'msg' command works as expected.
But if I start the Command Prompt from a program, with the 'system(...)' function, i.e. like this (Console application in Visual Studio):
#include "stdafx.h"
#include <stdlib.h>
int _tmain(int argc, _TCHAR* argv[])
{
system("cmd") ;
return 0;
}
'msg' does not work:
C:\WINDOWS\system32>msg /?
'msg' is not recognized as an internal or external command,
operable program or batch file.
And dir m*.exe in this Command Prompt gives only half a screen of listing. Especially, msg.exe is not there.
Somebody who can explain why? Somebody who knows a walk-around? Or (even better) how I can do 'msg' from a program? I.e.
system("msg * /server:undis "Directory 'expenses' synced") ;
I would embed it in a program run via "Program after / When changes are made" in SyncBack Pro (2BrightSparks).

As n.m. comments, most likely the problem is that you're building a 32-bit program so the cmd you run with system is the 32-bit cmd emulator and not the nomral win64 cmd program.
This is what leads to your problem -- whenever you try to access C:\WINDOWS\system32 in 32-bit mode, the system silently sends you to C:\WINDOWS\sysWOW64 instead. That's because on win64, system32 actually contains 64-bit programs and dlls, not 32-bit ones. The 32-bit ones are in sysWOW64.
Now normally this isn't an issue -- most of what you want in the 32-bit program is in sysWOW64, so everything is fine. The problem is that msg is not. So to get around that, you need to "escape" from the 32-bit sandbox. To do that, you need to go to C:\WINDOWS\sysnative. This directory (which is only available/visible in 32-bit mode) silently redirects to the (real, 64-bit) C:\WINDOWS\system32 directory. If you cd to that directory, you should see msg.exe and be able to run it. Or just run it directly from your system command:
system("C:\\WINDOWS\\sysnative\\msg * /server:undis "Directory 'expenses' synced") ;

Related

system() command does not detect the extension I want. Program detects "set path" but cannot the path

#include<stdio.h>
main()
{
char path[]="\"set path=C:\\Program Files\\WinRAR\""; //the extension I want to path
system(path); //the command
system("UnRAR x filename.rar");
}
OUTPUT
'UnRAR' is not recognized as an internal or external command,
operable program or batch file.
it works when i try it myself in cmd
Every call to system() starts a fresh shell, and so things like environment variables don't carry over from one to the next.
You need to include both commands in one system() call. According to How do I run two commands in one line in Windows CMD? it looks like you can separate them by &, but I haven't tested this.

awk scripts in windows with MinGW

We have an old legacy system that uses awk script for the deploy. I want to make minimum changes in it. We used to work with Cygwin and recently we've replaced it to MinGW.
Long story short, the script uses the system() command in order to run a cmd batch file like this:
system("cmd /c addVersion.bat " f ".map " f "." major "." minor ".map " f)
(I know complex and not ideal, but again I want minimum changes in that thing)
With Cygwin this command used to run the addVersion.bat and print the output to the console. with MinGW it only opens a new instance of CMD and does nothing.
we are working on windows10 with MinGW and Msys.
I looked a lot on the internet and found nothing. (guess cause I didn't know the right keywords in order to find a relevant solution)
if anyone has any idea or suggestion please let me know.

32/64 bits Issue with psr.exe

I currently have an issue with psr.exe. Actually, it works perfectly with the following command :
C:\windows\system32\psr.exe
C:\windows\syswow64\psr.exe
psr.exe (with system32\cmd.exe and syswow64\cmd.exe).
BUT, it does not work when my program (a 32 bits program running on a 64 bits windows 7) use this bat to start the application. Nothing happens.
My programm can open a notepad from a bat files, or execute whatever you want, but it does not work with psr.exe.
Can you give me some tips? Maybe it is not a 32/64 bits compatibility issue but I have other no idea about why this does not works...
EDIT :
The batch file content is:
C:\windows\system32\psr.exe
The program running this bat is written in C, it uses this function to start it:
CreateProcessAsUser(
hTokenDup,
NULL,
"C:\\toto\\mybat.bat",
NULL,
NULL,
FALSE,
NORMAL_PRIORITY_CLASS | CREATE_NEW_CONSOLE,
lpEnvironment,
NULL,
&sInfo,
&ProcessInfo)
It works perfectly if the .bat file contains C:\windows\system32\notepad.exe instead of C:\windows\system32\psr.exe.
If I double click on my bat files containing C:\windows\system32\psr.exe from my desktop, it works perfectly, but from my C program, it does not work.
(NB : My c program works with other .exe files like notepad for example)
Many thanks.
Johan
If a 32-bit program running on 64-bit windows OS tries to access a file C:\windows\system32\psr.exe, Windows redirects the request to file C:\windows\syswow64\psr.exe.
To start a 64-bit system application from 32-bit environment you need to execute C:\windows\sysnative\psr.exe which will be redirected to "real" C:\windows\system32\psr.exe.
To run the bat-file entirely in a 64-bit environment, execute C:\windows\sysnative\cmd.exe with following parameters: /c "C:\toto\mybat.bat"
However, this does not appear to be a problem in your case.
Could it be that the user you are trying to impersonate has a corrupted profile, home folder, environment, or does not have some sort of privilege required by psr.exe application?
Or maybe the app requires user profile to be loaded but you didn't load it by calling LoadUserProfile() beforehand?
Try testing by running your batch file like this:
c:\windows\syswow64\runas.exe /noprofile /env /user:INSERT_USERNAME_HERE "C:\toto\mybat.bat"
Does it work? Now try removing /env and/or replacing /noprofile with /profile. Does it now?

StartService error 2

I've written a very simple batch file that bluescreens windows 7 (ultimate,enterprise,home) beyond normal repair, by making an attempt of loading a Win32 exe-file (the well known notepad.exe) into the operating system's kernel. Feel free to test it in a Virtual Machine, just open it as an administrator. Do NOT run this as administrator on your primary computer.
#echo off
sc create bluescreener binpath = C:/Windows/System32/notepad.exe type= filesys start= boot
sc start bluescreener
timeout /t 30
However: When I run this program on windows 10, it successfully creates the service, but it doesn't start. Instead it returns the following error:
[SC] StartService Failed 2: The system cannot find the file specified.
It is referring to the binpath I set in the batch file. I am sure this path exists, and that this is the exact path name. I don't understand why it can't find the file. I have tried using backslashes instead of forward-slashes, and that didn't work either. (I have forward-slashes because I have a python program that writes this batch file, and the line break in python uses a backslash, and that conflicts with the path.)
I tried the "sc qc bluescreener" test that shows information about the service I have created. This is what comes up. (It is the same thing that comes up when I test it on windows 7, where it works.)
[SC] QueryServiceConfig SUCCESS
SERVICE_NAME: bluescreener
TYPE : 2 FILE_SYSTEM_DRIVER
START_TYPE : 0 BOOT_START
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : \SystemRoot\System32\notepad.exe
LOAD_ORDER_GROUP :
TAG : 0
DISPLAY_NAME : bluescreener
DEPENDENCIES :
SERVICE_START_NAME :
I can't find any explanation for why it can't find the file.
When I try to reboot windows 10 after creating the service, it can't boot, which means that the service is probably working and that the file was located. I just want to know why Windows 7 can find the file and immediately bluescreens, while Windows 10 can't find the file and needs to be rebooted for the service to run.
Any suggestions on how I might reproduce the same effect i get on Windows 7, but on Windows 10?

.bat to .sh converting for SQL*Loader Start on UNIX PC

I have a simple .bat file
#echo; set nls_lang=russian_cis.ru8pc866
#echo off
SET NLS_NUMERIC_CHARACTERS=. '
sqlldr.exe userid=PRB/0611#TSESTDB control=control_file.ctl LOG=fdb_log.log errors=100
cmd
and i need to convert to .sh file for running on the UNIX based pc.
I began to read "BASH Programming - Introduction HOW-TO" (is it suitable for beginners?), but it is a episodical task and dead line comes.
Could anybody help me to convert file? Thanks a lot!!!
rewriting your script.
#!/bin/bash
# #echo;
# set nls_lang=russian_cis.ru8pc866
export NLS_LANG=russian_cis.ru8pc866
# not needed #echo off
# SET NLS_NUMERIC_CHARACTERS=. '
export NLS_NUMERIC_CHARACTERS='.'
PATH="/path/to/sqlDir/install:${PATH}"
# sqlldr.exe userid=PRB/0611#TSESTDB control=control_file.ctl LOG=fdb_log.log errors=100
sqlldr userid=PRB/0611#TSESTDB control=control_file.ctl LOG=fdb_log.log errors=100
# ? cmd
I've left your code in, but commented out (using the shell comment char '#'). The uncommented lines are the 'translation' of .bat syntax into Linux/Unix bash/shell syntax.
There some things above that you may need to fix:
You'll have to include the correct value in the resetting of PATH,
note that the value there is strictly to illustrate the issue.
export is used so that variables set in the current shell (the
shell script) are visible to child processes that run from the shell
script, in this case the important one being sqlldr
I'm not sure what values you really need assigned to
NLS_NUMERIC_CHARACTERS. Note that by quoting with the single-quote
char ' available to the shell, you should get exactly the value
used that you intended. If '*' or other reg-exp chars are used, this
may cause problems.
You may find that sqlldr.exe has a different name altogether. The
linux/unix convention for executable commands does not require the
.exe extension, so I have used sqlldr. Just use the full name of
the program you find in the installed directory.
The line with #!/bin/bash needs to be the first line in the file, with no leading spaces.
You'll also need to inform your OS that the script is intended to be executable. From a bash cmd line, IN the directory that contains this script, do
chmod 755 mySQLLDR_runningScript
Finally, not sure why you have cmd at the end of your .bat file, to open a new window? You'll need to experiment on your system to find the correct cmd to do that. Maybe xterm.
I hope this helps.

Resources