Why system() always return 127 on win7? - c++

I'm porting a c++ program from Unix to Win7. The program only does some background computing tasks, it's a command line program. So I use build the program on cygwin with g++ on a 32bit win7 VM.
My target system is a 64bit win7 physical PC. After I copied my program to the target PC, it always fails at a system() call. I need to use system() to run a curl command. This works on my 32bit win7 VM, but always fails on the target 64bit win7 PC.
You may guess if curl command has problem. I would say no. Because I can manually run the curl command from a cmd window. I also tried to system("dir"), it also fails with same error.
On 64bit win7 PC, system() always return 127, error is "Permission denied". Does anybody have idea what the problem is.

Two points. 1) Use a 64-bit VM to build a program for a 64-bit physical machine. You must have a 32-bit or 64-bit cygwin installed on the physical machine to provide the cygwin1.dll with the bitness required by the exe. Use the mingw32 or mingw64 version of the g++ compiler if you don't want to install cygwin on the physical machine. Use the cygwin file command to check the bitness of the exe and to check if it is a cygwin or mingw exe.
2) The windows API provides for a 8-bit return code from a child process to its parent. Using 0 to 127 avoids specifying if the code is signed or unsigned. BTW, there is not dir.exe, it is part of command processor, e.g cmd.exe.

Related

GDB: File runs on Cent OS 7 but not Ubuntu

I am getting the below error when using the gdb command run group3.
I installed gdb on Windows Bash as well as an Ubuntu VM on Virtualbox and am getting the same error.
Some important notes:
This program worked at my school using Cent OS 7
I tried changing the file to have a .exe file extension but that didn't work. It should not require a file extension because it worked at my Uni without one.
This program worked at my school using Cent OS 7
Did you use ftp to copy this program into VM?
Chances are you did the transfer in ASCII mode, corrupting the binary in the process.
You can verify this has happened by running md5sum group3 on both systems. If my guess is correct, the checksum will be different.
Use binary mode FTP instead, or use scp.
I ended up corrupting my 64 bit Ubuntu VM when running out of space when trying to install the i386 packages. I ended up installing a new 32-bit Ubuntu VM and the program ran on that successfully.

Cannot build cpp file with tdm-gcc on windows 7, 32bit(says exe is not compatible)

Environment and What I'm Trying to Do: I'm trying to set up a C++ coding/debugging environment with sublime text 3 on a 32 bit Windows 7 PC.
I installed Sublime Text 3 for Windows and Dev-C++(from http://orwelldevcpp.blogspot.kr/) which includes TDM-GCC 4.9.2 (32bit and 64bit).
Problem: After adding "C:\Program Files\Dev-Cpp\MinGW64\bin" to the PATH environment variable, I tried to build a simple Hello World! code, but only got this messege:
[Finished in 5.1s with exit code 1]
[shell_cmd: g++ "D:\SublimeText\main.cpp" -o "D:\SublimeText/main" && "D:\SublimeText/main"]
[dir: D:\SublimeText]
[path: (all the directories added to PATH)]
When I try to execute the main.exe file generated in D:\SublimeText, a warning that says something like 'This program is not compatible with this OS. Check your OS type if it's 32 bit or 64 bit and execute the right one'.
If I compile and run the same code in Dev-C++ after choosing the 'TDM-GCC 32bit compiler', it compiles and runs just fine.
Expected Cause: Maybe Sublime Text compiles my code with a 64bit compiler, but I couldn't find how to make it use the 32bit compiler.
I'm new to coding(registered to stack overflow an hour ago..), so a kind and detailed answer would be very appreciated! Thank You.
The TDM GCC 64 bit compiler can be installed and run on a 32-bit host
(like yours) because the compiler executables are themselves all 32-bit.
The 64-bit compiler can generate both 64- and 32-bit executables for
you, and by default will generate 64-bit ones, which will not run
on your 32-bit host. To get 32-bit executables you must explicitly tell gcc
you want them by passing it the -m32 option, for both compilation
and linkage.

Run cygwin built exe in windows without cygwin's environment

I'm trying to port a linux software in Windows.
My software depends on gtk, boost and libgerbv (which I've manually compiled on cygwin)
I've successfully compiled it and it works if I run it in the cygwin's terminal, but if I copy the .exe in a folder with cygwin1.dll and I run it, it terminates silently
Same result if I run it within cmd.exe.
How can I "export" this executable outside the cygwin environment? I want to distribute it with just the needed shared libraries and cygwin1.dll
Thanks
"How can I "export" this executable outside the cygwin environment?"
In short: That's not possible. You'll need to have a cygwin environment installed on the target machine, and run the programs created in cygwin from a cygwin shell.
Cygwin requires a number of it's own .dll files, to bind to the underlying Windows OS. These cannot be just copied to another windows system without having a complete installation of cygwin.
Here're some more details about this: What is the difference between Cygwin and MinGW?
That's why I prefer to use MinGW to target windows systems portably. Cygwin has it's powers and right to exist, when it comes to cross compile code for different (e.g. embedded) targets running on windows as host.

Building a Windows Console App In Cygwin 1.7.16 Targeted to Cygwin 1.5.24

I have a Windows console app that is pure standard C++. I am building it in Cygwin 1.7.16 (running on Windows 7) for target Cygwin 1.5.24 (running on Windows XP SP 2).
My build command is:
g++ -o mgen_stats.exe -I ../include ../src/*.cpp
On the target, my path includes /usr/bin, which is where cygwin1.dll lives.
When I run the application with no arguments on the target in a Cygwin 1.5.24 shell, I immediately get the command prompt back. I should see the application's usage printed out.
Some immutable constraints I'm working under:
The build and target machines are isolated from each other.
There is no C++ build tool chain on the target.
I may not install a C++ build tool chain on the target.
I may not modify the C++ build tool chain I have on the build machine.
As a result of the above, I must build on my build machine, burn the .exe to a CD, and copy it onto the target machine.
I would be just as happy for my application to be a native Windows application (i.e. run it in a DOS shell rather than a Cygwin 1.5.24 shell). To this end, I tried using g++ build flag -mno-cygwin. g++ tells me that flag -mno-cygwin has been removed. It then suggests that I "use a mingw-targeted cross-compiler". I do not know how to tell if I have the mingw-gcc, mingw64-i686-gcc, and mingw64-x86_64-gcc packages (which, according to the Cygwin FAQ, contain the suggested cross-compilers), and if I do have them, I do not know what the names of the compiler executables are.
Can anybody help me get this app built such that it will run successfully under either a DOS or Cygwin 1.5.24 shell on my Windows XP SP 2 target?
Thank you in advance.
The MinGW packages (like any other Cygwin package) can be installed on Cygwin using the "setup.exe" that Cygwin provides on its website. If you do have them installed, you'll find the compilers as i686-w64-mingw32-g++ or x86_64-w64-mingw32-g++.
Alternatively, you can also install the MinGW packages directly (without using Cygwin).

Why does my C++ program crash on one machine and not on another?

I have written a simple C++ program that I am compiling using g++ in command prompt and also running it through command prompt. The code of my program is as follows:
#include<iostream>
int main()
{
std::cout<<"Hello world"<<std::endl;
return 0;
}
When I run this code. I get a "hello_world.exe has stopped working" kind of error on my office machine. But when I run the same portion of code at home it works fine. Any idea why this is happening? Also, if I remove std::endl it works fine.
I am using Notepad++ to code.
UPDATE: I am not running the same binary on both machines. I compile on both the machines separately. I am using windows 7 32-bit at both the locations. I am using mingw. For compiling I type "g++ hello_world.cpp -o hello_world.exe". For running I typed "hello_world.exe". I downloaded mingw from the site mingw.org and used the "mingw-get-setup.exe" to install. And I installed g++ and gcc through the command prompt using the command "mingw-get install gcc g++".
When you return from main(), your program stops working. In a gui-based environment, I wouldn't be surprised to see a pop-up message warning about a terminal-based application reaching completion where the user has to click "dismiss" before the terminal spawned to support the application is terminated as well. Windows 9x used to have such checkboxes in launcher preferences for MS-DOS programs.
Questions you should use to find out the issue are:
- Is it showing the same error message if you launch the shell yourself ?
- Do you use the very same binary on both machine, and if so, are your machines both capable of running it (e.g. not trying to launch a 64-bit binary on a 32-bit OS as one of the case)
It would help to see the exact text of the error message.
Your program depends on C and C++ runtime libraries. I suspect you have the libraries installed on the machine where it works and don't where it doesn't, probably because you installed Visual Studio on the machine where you wrote the code but not on the machine where you're trying to run it.
You can install the runtime libraries on the second machine by search Microsoft Download for vcredist for the version of Visual Studio that you compiled the program with.
Works fine for me on Windows 7 32-bit using MinGW. I suspect that you've not installed all the components you need to run the program. I would re-install MinGW and Msys and be sure you install all the necessary C and C++ components.
g++ --version
g++.exe (GCC) 4.6.2
a.exe
Hello World
I have used MinGW and Msys on Windows for many years (several different versions) and have never had issues compiling, linking or executing standard C and C++ programs.