I don't understand why the following code returns "'bcdedit' is not an internal or external command" when ran from a c program. bcdedit works perfectly fine on cmd line. How can I get this to work?
#include <stdio.h>
int main ()
{
system("bcdedit");
system("TIMEOUT /T 3");
return(0);
}
It happens because when you run the Command Prompt via Start Menu or even the Execute window you are running the 64-bit cmd version, located at C:\Windows\System32\cmd.exe, however when call cmd from your c program it calls the 32-bit cmd version, located at C:\Windows\SySWOW64\cmd.exe. This happens because your C compiler generates a 32-bit application.
According to MSDN:
The %windir%\System32 directory is reserved for 64-bit applications.
Most DLL file names were not changed when 64-bit versions of the DLLs
were created, so 32-bit versions of the DLLs are stored in a different
directory. WOW64 hides this difference by using a file system
redirector.
In most cases, whenever a 32-bit application attempts to access
%windir%\System32, the access is redirected to %windir%\SysWOW64.
Source: http://msdn.microsoft.com/en-us/library/windows/desktop/aa384187%28v=vs.85%29.aspx
If you compare both cmds you will realize that they are identical, what differs are the dll's.
The problem is that Windows x64 provides a 64-bit bcdedit.exe in the System32 folder, but doesn't provide a 32-bit bcdedit.exe anywhere. So the 32-bit cmd can't run the 64-bit bcdedit, so it returns that this command is invalid.
Solution: You can both obtain a 32-bit bcdedit from a Windows x86 version or you can compile a 64-bit application.
Most likely because it cannot find the executable. Either ensure your path is correct(a) or use the full path name:
system ("c:\\windows\\system32\\bcdedit.exe");
And, of course, this should go without saying: make sure you run it as an administrative user.
(a) You should be able to confirm this with something like:
system ("path");
I think you have cut one command into two part.And I think you want to run "bcdedit.exe /timeout 3",but you give the
argument of the system command two parts, one is "bcedit.exe", another is "/timeout 3". I think you should wrote this
system("bcdedit.exe /timeout 3");
to run the command you wanted.Hope this will help you
Related
I have compiled a string matching tool SMART in windows using MSYS2, the tool is implemented in C programming language. The instruction was (in the the instruction set):
makefile is the bash file used for compiling the C source files of the tool. Run the command ./makefile in order to compile the smart
tool. The code of each string matching algorithm is compiled an
tested separately.
The problem now is, each algorithm is compiled properly but tested unsuccessfully.
Also, when the following command is given to execute (see how to run experimental tests):
./smart -text englishTexts
I get the following error:
shmget: Function not implemented
I doubt both issues are related/due to the failure of managing shared memory, note that author created the system on a POSIX system (whereas I am trying to run this on a Windows system). Author wrote about the Manage shared memory on LINUX:
In order to configure shared memory on linux you have to login as
root, then edit the file
/etc/sysctl.conf.
The kernel.shmax parameter defines the maximum size in bytes for a
shared memory segment. Determine the value of kernel.shmax by
performing the following:
cat /proc/sys/kernel/shmmax
33554432
The kernel.shmall parameter sets the total amount of shared memory in
pages that can be used at one time on the system. Set the value of
both of these parameters to the amount physical memory on the machine.
As in the previous case you can determine the value of kernel.shmax by
performing the following:
cat /proc/sys/kernel/shmmall
2097152
Set the values of kernel.shmax and kernel.shmall, as follows:
echo MemSize > /proc/sys/shmmax
echo MemSize > /proc/sys/shmall
where MemSize is the number of bytes. For example, to set both values
to 2GB, use the following:
echo 2147483648 > /proc/sys/kernel/shmmax
echo 2147483648 > /proc/sys/kernel/shmall
Then reboot the machine using. Shared memory can be viewed with the
ipcs command and you can delete shared memory segments with the ipcrm
command.
But there is nothing specific about Windows (though there is a paragraph for "Manage shared memory on WINDOWS VISTA").
At this point I ask your help, to inform me whether there is a package for MSYS2 to solve shmget error mentioned above? Or there are other ways to solve this problem?
Unfortunately I think you're out of luck with msys2. msys2 takes out cygserver from cygwin, which is required for shared memory.
Intel fortran parallel studio in VS2019 provides two cmd shortcuts, each sets the environment appropriately for either a 32bit or 64bit compiler command line build. The process window title includes this compiler type name.
I am running a bat file that compiles .f90s to give .obj files and combines them to build a dll for use with 32 bit or 64 bit excel. I am therefore running it in both 32 and 64 bit compiler cmd processes. All of this works well. But is there a way for the bat to get the cmd process name, ie whether I am building the dll for 32 bit or 64 bit and add to this to the stringfileinfo or the dll filename? Currently both get the same filename and version info.
tasklist /v |find "whatever the window-title or part-title or processname is">nul
should set errorlevel to 0 if the title, etc. is found, non-zero otherwise.
I have been using the deploytool in Matlab for the past few months in my 2010b 64bit version of Matlab. I just recently found out that I need to create a 32 bit version of my c shared library.
To do this I follow the same methods I had been using previously (pretty much calling the command mcc -W lib:MYLIB -T link:lib -d 'MYOUTPUTFOLDER' -v 'MFILE1' 'MFILE2') in my 2009b 32 version of Matlab. I keep getting the error LNK1811: cannot open input file LIBRARY.obj. I have tried to find this LIBRARY object file but I cannot seem to find it anywhere.
So far I have checked to ensure all of the correct libraries are available (found at $MATLABROOT$\extern\include\win32), I have made sure all of my paths are correct in the compopts.bat file, and I have used the option -T compile:lib which works fine and creates a dll. This would be great but I need a lib file to use later in mbuild.
My current path forward is to take the compopts from my 64 bit version of Matlab (on a different machine) and compare it with my compopts for the 32 bit. I will post if it makes a difference.
To summarize our comments in the question and make it an answer. Here is how I manage to create both x32 and x64 libraries/standalones with mcc.
NB: Maybe there are more elegant solutions to configure deploytool, anyway with brute force I'm sure it works and I can automate global deployment process for my applications ...
Machine setup
Install Matlab x32 and x64 on your machine
Run Matlab x32 and setup compiler options typing msbuild -setup
This will generate a compopts.bat file in ~user\AppData\Roaming\MathWorks\MATLAB\R2013b (path may differ upon your version)
Rename this file to compopts.x32.bat (see later)
Run Matlab x64 and setup compiler options typing msbuild -setup
This will generate a compopts.bat file in ~user\AppData\Roaming\MathWorks\MATLAB\R2013b (!!Overwrites x32!!)
Rename this file to compopts.x64.bat (To workaround file overwrite)
EDIT Just tested ... In R2014b, Matlab does no longer overwrites same compots.bat file ... it now generates two separate MBUILD_C++_win64.xml and MBUILD_C++_win32.xml files (which is a good thing!).
Compilation in x32
Force your compilation script to point to ~matlabx32\bin\win32\mcc.exe and force mcc.exe to use previously saved compopts.x32.bat file using the -f option. Your command line should be something like:
~matlabx32\bin\win32\mcc.exe -f "compopts.x32.bat" ... other mcc options ...
Compilation in x64
Force your compilation script to point to ~matlabx64\bin\win64\mcc.exe and force mcc.exe to use previously saved compopts.x64.bat file using the -f option. Your command line should be something like:
~matlabx64\bin\win64\mcc.exe -f "compopts.x64.bat" ... other mcc options ...
I am new to this forum. I am in need of a program in C that runs an exe file in Windows.
While googling I found the code below :
1.
Code:
#include<stdlib.h>
#include<stdio.h>
int main()
{
(void)system("C:\\Windows\\notepad.exe");
return 0;
}
The above code compiles successfully in Borland Turbo C. But it fails to run Notepad.
2
Code:
#include<stdlib.h>
#include<stdio.h>
void main()
{
int result ;
result=system("C:\\Windows\\notepad.exe");
printf("%d",result);
}
The above code on running gives -1 as output. Why am I getting -1.
My OS Windows XP
Borland Turbo C Compiler
Please help.
There are at least two wrong things here:
you're using system();
you're hardcoding a path.
For the first problem, I already wrote a long rant some time ago, you can have a look at it here; long story short, to start a process you should go with the platform-specific way, namely, on Windows, CreateProcess or, if you want to open a file with it's associated application, ShellExecute.
For the second problem, you're assuming (1) that c:\windows exists, (2) that it is the windows directory of the currently running windows instance (3) that notepad.exe actually exists and (4) that it is in such directory.
While notepad.exe is pretty much guaranteed to exist on every Windows installation, it's not clear where you should search it. Since Windows 3.0 it was in the Windows directory, but on the NT family it used to stay in the system32 subdirectory. So, from some Windows version onward Microsoft put two copies of notepad, both in the windows directory and in the system32 directory (see this blog post).
Additional fun: from Windows Server 2008 the copy from the Windows directory has been removed (link - incidentally, the title of the post is What idiot would hard-code the path to Notepad? :D), so your program will fail to open notepad even if Windows resides in c:\windows.
But the biggest problem here is that Windows isn't guaranteed to be installed in c:\windows; on every NT-family Windows before Windows XP it was actually installed by default in c:\winnt, so your code would fail here.
Moreover, if you have more than one copy of Windows installed (say Windows 7 64 bit on c:, Windows XP 32 bit on d:) c:\windows may actually exist, but it may contain a copy of Windows different from the one currently executing, so you'd be opening the notepad from another copy of Windows (and if that copy is 64 bit and the running one is 32 bit it won't run).
Similar stuff may happen also if you install Windows on a disk that already contains a windows directory; in that case the setup will put Windows in a Windows(01) directory (or something like that), and c:\windows may be empty.
Long story short:
avoid using system: apart from its other flaws, in all these scenarios your application wouldn't have any clue that notepad didn't start;
avoid hardcoding paths: c:\windows isn't guaranteed to exist; if you need to get the path of the Windows directory, you can expand the environment variable %windir% (or %systemroot), or use the API GetWindowsDirectory;
if your app is in PATH, you may exploit this fact: the Windows and system32 directory are in the PATH environment variable, which means that, if you just try to start notepad, you can avoid to specify it's full path; on the other hand, you're exposing yourself to vulnerabilities if a malicious user put a dangerous application in the working directory of your application;
if you want to open a file, use ShellExecute: it will automatically open that file with the associated application.
I'm not sure notepad has ever been stored in the Windows directory. This code works under WinXP.
#include<stdlib.h>
#include<stdio.h>
/* main() returns int, not void. */
int main( void ) {
int result ;
result=system("C:/Windows/system32/notepad.exe");
printf("%d",result);
return 0;
}
Look where you save your source file, alway C++ Compilers generate two files, let say your source named "hello.cpp"
These files should be in your source path:
hello.obj
hello.exe <--your prgram to distribut
ALSO
I think you should use new free IDE/Compiler for better result such as:CodeBlocks at http://www.codeblocks.org
As per me I dont see any problem with the code, did you try running the program with some standard IDE like, dev-cpp or code-blocks.
And do one thing
try running the same command on the command prompt first and tell the result.
I would also like to tell you to go inside the Windows directory and check if Notepad.exe is there or not.
It is not likely but there is a chance.
Thanks
Alok Kr.
Could be that your path is wrong in some way. I would suggest following Kumar's advice and try running it in the command prompt first just to see that you are using the right path.
Also, you might want to try running notepad.exe without a path at all. As it is located in the PATH, you should be able to specify just "notepad.exe".
I am using Visual Studio 2010 Pro for simple C programming, I would like to know how I can provide input to the program without having to manually do so. The enviroment I am used to working is your standard commandline Unix enviroment. Once I compile a C file call "inputsInts" it becomes "a.out" and to test input I would type:
The easy way
echo 1 2 3 4| ./a.out //to provide input
The number of ints input was 4 //output
The easier way
more input.txt| ./a.out //to provide input
The number of ints input was 4 //output
The tedious way
./a.out
//now I would manually type
1 2 3 4 s //in this case I have to type a letter to move on
The number of ints input was 4 //output
Hard is how I have to do it in Visual Studio 2010. I would like to be able to just input in an area the input ahead of time or at least have it read a text file. Obviously I can't test large sets of data by manually typing it in. At the moment I am just doing the coding in VS2010 and going to the unix enviroment to do most testing. I would like to stay in the VS2010 enviroment until I am ready to do a final test in Unix.
I have altered the question quite a bit since I first posted, so the original answers may seem off a bit. Again I appretiate everyone's time and help.
This is just the simple code for an example:
#include
int main () {
int x, n = 0;
while (scanf("%d", &x)==1)
n++;
printf("The number of ints input was %d\n", n);
return(0);
}
You need to create a "Console Application" when you start a new Visual Studio project. This will give you a program that runs from a Windows Command Prompt window, otherwise known as the Cmd window after the name of the shell program that runs underneath it. The command window is located under Programs->Accessories in Windows XP, not sure about other versions of Windows. Once you open a command window, things will work similarly to what you're used to on Linux.
cd MyProject
echo 1 2 3 4|.\MyProject.exe
MyProject.exe <input.txt
The cmd.exe shell has a pipe operator that works similar to the Unix pipe operator. It has some quirks in some versions of Windows but in general, you should be able to do many of the same things with it.
You can run your program pretty much the same way at the Windows command line, the only obvious difference being that you need to specify the correct executable name instead of a.out.
To do roughly the same from inside the VS IDE, you'd probably need to store your sample input in a text file, and then specify something like < sample.txt as the arguments to supply to the program in the project's debug settings.
In the Windows Shell (cmd.exe) you can use a pipe similar to linux for commands like
dir|more
Outside the shell, you're talking about a GUI environment (as in Linux's GUI) so passing info from one program to the next will be a bit different.
However, you can achieve similar functionality using pipes (shared memory in Windows). See here for a full explanation with examples from the folks at Microsoft Developer Network:
http://msdn.microsoft.com/en-us/library/aa365780%28v=VS.85%29.aspx
Or if you're feeling to lazy to poke around, here's an example of transactions on named pipes:
http://msdn.microsoft.com/en-us/library/aa365789%28v=VS.85%29.aspx
...or you can simply dump and read from output files.
(Both of these methods are similar to those used with Linux programs)
More info on your specific needs would be helpful.