This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
how to find the location of the executable in C
I'm writting an multi-platform app in C++ using GTK+ and I have a problem. I must get program path. E.g., when program is in /home/user/program (or C:\Users\user\program.exe), i have /home/user/ (or C:\Users\user\).
Can and how I can do this?
For Win32/MFC c++ programs:
char myPath[_MAX_PATH+1];
GetModuleFileName(NULL,myPath,_MAX_PATH);
Also observe the remarks at
http://msdn.microsoft.com/en-us/library/windows/desktop/ms683156%28v=vs.85%29.aspx,
In essence: WinMain does not include the program name in lpCmdLine, main(), wmain() and _tmain() should have it at argv[0], but:
Note: The name of the executable in the command line that the
operating system provides to a process is not necessarily identical to
that in the command line that the calling process gives to the
CreateProcess function. The operating system may prepend a fully
qualified path to an executable name that is provided without a fully
qualified path.
argv[0] contains the program name with path. Am I missing something here?
On windows..
#include <stdio.h> /* defines FILENAME_MAX */
#ifdef WINDOWS
#include <direct.h>
#define GetCurrentDir _getcwd
#else
#include <unistd.h>
#define GetCurrentDir getcwd
#endif
char cCurrentPath[FILENAME_MAX];
if (!GetCurrentDir(cCurrentPath, sizeof(cCurrentPath)))
{
return errno;
}
cCurrentPath[sizeof(cCurrentPath) - 1] = '/0'; /* not really required */
printf ("The current working directory is %s", cCurrentPath);
Linux
char szTmp[32];
sprintf(szTmp, "/proc/%d/exe", getpid());
int bytes = MIN(readlink(szTmp, pBuf, len), len - 1);
if(bytes >= 0)
pBuf[bytes] = '\0';
return bytes;
And you should look at this question..
How do I get the directory that a program is running from?
Related
This question already has answers here:
Cast to LPCWSTR?
(4 answers)
Closed 3 years ago.
I'm trying to load a DLL into C++ but was getting error code 126, which I think means the DLL couldn't be found. After some poking around I changed LoadLibrary to LoadLibraryA and suddendly it worked. However, I am at a complete loss as to why. I realise that I haven't provided the dll for this code to be runable but would be greatful if somebody could provide an explaination as to why this is happening? And prehaps an example of how to get LoadLibary working.
Broken version
#include <stdio.h>
#include <windows.h>
typedef char* (*gf_getCurrentLibraryVersion) ();
int main() {
gf_getCurrentLibraryVersion getVersion;
HINSTANCE hLib = LoadLibrary((LPCWSTR)"libsbnw.dll");
if (hLib) {
getVersion = (gf_getCurrentLibraryVersion)GetProcAddress(hLib, "gf_getCurrentLibraryVersion");
printf("Version = %s\n", getVersion());
}
else {
printf("Error loading dll: %d/n", GetLastError());
}
printf("Hit any key to continue\n");
getchar();
return 0;
}
Compiles and outputs
Error loading dll: 126/nHit any key to continue
to console
Working version
#include <stdio.h>
#include <windows.h>
typedef char* (*gf_getCurrentLibraryVersion) ();
int main() {
gf_getCurrentLibraryVersion getVersion;
HINSTANCE hLib = LoadLibraryA("libsbnw.dll");
if (hLib) {
getVersion = (gf_getCurrentLibraryVersion)GetProcAddress(hLib, "gf_getCurrentLibraryVersion");
printf("Version = %s\n", getVersion());
}
else {
printf("Error loading dll: %d/n", GetLastError());
}
printf("Hit any key to continue\n");
getchar();
return 0;
}
Compiles and outputs
version is: 1.3.4
The problem with your LoadLibrary((LPCWSTR)"libsbnw.dll") call is that your build environment converts that to a LoadLibraryW call, but the way you are trying to pass a wide-character string is wrong.
As you have it, you are simply casting a const char* pointer to a const wchar_t* pointer, which won't work (for example, it will interpret the initial "li" characters as a single 16-bit character).
What you need to do is specify the string literal as a wide character constant, using the L prefix:
HINSTANCE hLib = LoadLibrary(L"libsbnw.dll");
Or, alternatively, using the TEXT() macro (which will boil down to the same, when using the UNICODE build environment):
HINSTANCE hLib = LoadLibrary(TEXT("libsbnw.dll"));
Feel free to ask for further explanation and/or clarification.
Ordinarily the compiler will try to point out when you're making a mistake. But in this case you've told it not to by adding an explicit cast to the string.
HINSTANCE hLib = LoadLibrary((LPCWSTR)"libsbnw.dll");
//^^^^^^^^^
I'm assuming you've built your app with Unicode enabled, which defines a macro converting LoadLibrary to LoadLibraryW. The parameter must be a wide-character string.
HINSTANCE hLib = LoadLibraryW(L"libsbnw.dll");
There's another macro you can use when you're not sure if the app will be compiled with Unicode or not, TEXT() or the shorter form _T(). Not recommended for modern code since needing to turn Unicode on or off hasn't been a problem in many years, just use Unicode always.
HINSTANCE hLib = LoadLibrary(TEXT("libsbnw.dll"));
I'm trying to add a simple diagnostic output to a C++ UWP shared project akin to System.Diagnostics.Debug.WriteLine in C#. Following the documentation for OutputDebugString here and this solution here I've tried this:
char buf[1024];
sprintf(buf, "frequency = %f", (float)result);
OutputDebugString(buf);
but I get the compiler error
argument of type "char*" is incompatible with parameter of type "LPCWSTR"
How do I fix this?
A colleague advised me to add
#include "strsafe.h"
after any pre-compiled headers and then use this code instead
TCHAR buf[1024];
size_t cbDest = 1024 * sizeof(TCHAR);
StringCbPrintf(buf, cbDest, TEXT("frequency = %f"), (float)result);
OutputDebugString(buf);
I also needed to remember to swap the debugger to handle mixed code:
Here is what I use most of the time (notice the "L"):
#include <Windows.h>
OutputDebugString(L"Sarah Connor ?\n");
I am just porting a code to Mac OS X which is using _tspawnl on Windows.
Is there anything equivalent to _tspawnl on Mac OS X or Linux?
Or is there any posix equivalent to _tspawnl
You can use fork and execv system call together in the following way :
if (!fork()){ // create the new process
execl(path, *arg, ...); // execute the new program
}
The fork system call creates a new process, while the execv system call starts the execution of the application specify in path.
For example, you can use the following function spawn whose argument are the name of the application to be executed and the list of its arguments.
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <unistd.h>
int spawn (char* program, char** arg_list)
{
pid_t child_pid;
/* Duplicate this process. */
child_pid = fork ();
if (child_pid != 0)
/* This is the parent process. */
return child_pid;
else {
/* Now execute PROGRAM, searching for it in the path. */
execvp (program, arg_list);
/* The execvp function returns only if an error occurs. */
fprintf (stderr, “an error occurred in execvp\n”);
abort ();
}
}
int main ()
{
/* The argument list to pass to the “ls” command. */
char* arg_list[] = {
“ls”, /* argv[0], the name of the program. */
“-l”,
“/”,
NULL /* The argument list must end with a NULL. */
};
spawn (“ls”, arg_list);
printf (“done with main program\n”);
return 0;
}
This example has been taken from the chapter 3.2.2 of this book. (Really good reference for development in Linux).
You can use fork()/exec(), as already pointed out, however a closer system call is posix_spawn() (manpage).
It can be a bit of a pain to set-up, however, but there is some example code using it is here (note that this code also provides functionality for Windows using the CreateProcess() API, which is probably what you should be using under Windows anyway).
I have tried the following links, from StackOverflow and other sites,[I tried, but it didn't helped me, so i can't avoid duplicating]
StackWalk64 on Windows - Get symbol name
How do you make StackWalk64() work successfully on x64?
http://www.codeproject.com/KB/threads/StackWalker.aspx
http://jpassing.com/2008/03/12/walking-the-stack-of-the-current-thread/
How to Log Stack Frames with Windows x64
...
But none of the Code worked for me.I'm new to Windows C++ environment and i can't get any of the above code to work.
I'm looking for a call stack format like,
FUNCTION_NAME_DEPTH_1 : _LINE_NUM__
FUNCTION_NAME_DEPTH_1 : _LINE_NUM__
FUNCTION_NAME_DEPTH_1 : _LINE_NUM__ ...
Just function name and line numbers.
My Environment:
Visual Studio 2010
SDK : v7.1
Windows 7 Pro SP1
It would be a lot simple if anyone post a header file,[there seems to be few available,but not working] which we can include in our cpp file and print the call stack with a call like 'PrintFunctionCallStack();' . BTW in Linux/Mac, it was a whole lot easier,i was able to get the call stack from backtrace and it was so simple that i did it myself in few mins. In Windows i've have been trying past two days, but no surprise at all.
Linux/Mac Stack Trace Code, i haven't yet demangled the symbol names.
#ifndef _STACKTRACE_H_
#define _STACKTRACE_H_
#include <stdio.h>
#include <stdlib.h>
#include <execinfo.h>
#include <cxxabi.h>
#include <iostream>
static inline void PrintStackTrace()
{
cout<<"##############################################\n";
unsigned int maxStackCount = 63;
void* addressList[maxStackCount+1];
int addrLen = backtrace(addressList, sizeof(addressList) / sizeof(void*));
if (addrLen == 0) {
cout<<"Empty Stack, Probably Corrupted it seems ###\n";
return;
}
char** symbolList = backtrace_symbols(addressList, addrLen);
for (int i = 1; i < addrLen; i++) // Skipped First, 'i' begins with '1'
{
cout<<"###: "<<symbolList[i]<<":###\n";
}
free(symbolList);
cout<<"##############################################\n";
}
#endif
If your environment is Visual Studio, you can insert a Tracepoint and input
$CALLSTACK
in its edit box, after checking Print a message.
To do it, right-click on the line you want and select Breakpoint > Insert Breakpoint (or alternatively, insert a breakpoint clicking on the left of the editor line you want, then select When Hit).
Then you will see a detailed report in the Output window, having file name, line number and function name. It served me to successfully discovered some memory leaks.
i want to read a file.. but.. when i debug my program it runs but a pop up appears and says system programming has stopped working and in the console, it`s written that Press enter to close the program. my code is ::
// System Programming.cpp : Defines the entry point for the console application.
//
#include "stdafx.h"
#include "iostream"
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
HANDLE hin;
HANDLE hout;
TCHAR buff[20]= {'q','2','3'};
TCHAR buff2[20]={'a','v'};
hin = CreateFile(_T("Abid.txt"),GENERIC_WRITE,0,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0);
if(hin == INVALID_HANDLE_VALUE)
{
cout<<"error";
}
WriteFile(hin,buff,40,0,NULL);
CloseHandle(hin);
hout = CreateFile(_T("Abid.txt"),GENERIC_READ,0,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0);
if(hout == INVALID_HANDLE_VALUE)
{
cout<<"error";
}
ReadFile(hout,buff2,40,0,NULL);
CloseHandle(hout);
return 0;
}
According to MSDN, lpNumberOfBytesWritten paremeter can be NULL only when the lpOverlapped parameter is not NULL. So the calls should be
DWORD nWritten;
WriteFile(hin, buff, 40, &nWritten, NULL);
and
DWORD nRead;
ReadFile(hout, buff2, 40, &nRead, NULL);
Also, rename hin and hout.
Others have already answered your question. This is about the code.
// Your code:
// System Programming.cpp : Defines the entry point for the console application.
//
Just remove that comment. It isn't true. :-) The entry point for your program is where the machine code starts executing, and with the Microsoft toolchain it's specified by the /entry linker option.
Note that Microsoft's documentation is generally confused about entry points, e.g. it has always, one way or other, documented incorrect signature for entry point.
It's one of the most infamous Microsoft documentation errors, and, given that it's persisted, in various forms, for 15 years, I think it says something (not sure exactly what, though).
// Your code:
#include "stdafx.h"
You don't need this automatically generated header. Instead use <windows.h>. A minimal way to include <windows.h> for your program would be
#undef UNICODE
#define UNICODE
#include <windows.h>
For C++ in general you'll want to also make sure that STRICT and NOMINMAX are defined before including <windows.h>. With modern tools at least STRICT is defined by default, but it doesn't hurt to make sure. Without it some of declarations won't compile with a C++ compiler, at least not without reinterpret casts, e.g. dialog procedures.
// Your code:
#include "iostream"
using namespace std;
Almost OK.
Do this:
#include <iostream>
using namespace std;
The difference is where the compiler searches for headers. With quoted name it searches in some additional places first (and that's all that the standard has to say about it). With most compilers those additional places include the directory of the including file.
// Your code:
int _tmain(int argc, _TCHAR* argv[])
Oh no! Don't do this. It's a Microsoft "feature" that helps support Windows 9.x. And it's only relevant when you're using MFC linked dynamically and you're targeting Windows 9.x; without MFC in the picture you'd just use the Microsoft Unicode layer.
Area you really targeting Windows 9.x with an app using dynamically linked MFC?
Instead, do ...
int main()
... which is standard, or use the Microsoft language extension ...
int wMain( int argc, wchar_t* argv[] )
... if you want to handle command line arguments the "easy" way.
// Your code:
{
HANDLE hin;
HANDLE hout;
TCHAR buff[20]= {'q','2','3'};
TCHAR buff2[20]={'a','v'};
The TCHAR stuff is just more of that MFC in Windows 9.x support stuff.
Apart from being totally unnecessary (presumably, you're not really targeting Windows 9.x, are you?), it hides your intention and hurts the eyes.
Did you mean ...
char buff[20] = {'q', '2', '3'};
... perhaps?
// Your code:
hin = CreateFile(_T("Abid.txt"),GENERIC_WRITE,0,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0);
if(hin == INVALID_HANDLE_VALUE)
{
cout<<"error";
}
As others have mentioned, OPEN_EXISTING isn't logical when you're creating the file, and the count pointer argument can't be 0 for your usage.
When using <windows.h>, with UNICODE defined as it should be, the filename argument should be specifed as L"Abid.txt".
Cheers & hth.,
The problem is that you're passing a NULL pointer in for the lpNumberOfBytesWritten/lpNumberOfBytesread parameter. While this is an optional parameter, there's a condition:
This parameter can be NULL only when the lpOverlapped parameter is not NULL
Also, you may have the size of your buffers wrong:
WriteFile(hin,buff,40,0,NULL); // says that buff has 40 bytes
ReadFile(hout,buff2,40,0,NULL); // says that buff2 has 40 bytes
But if you're compiling for ANSI instead of UNICODE, these will only be 20 bytes in size.
You should probably use sizeof(buff) and sizeof(buff2) instead.
Assuming your initial code attempts to create the file as a new file, then you cannot use OPEN_EXISTING, you have to use OPEN_ALWAYS (or some other creational variant) on this call.
The OPEN_EXISTING usage for readback will be OK.
btw once this is fixed the WriteFile calls causes an access violation, as you are trying to write more bytes that your array contains.