I am porting existing C++ app (game engine) to support Windows Store 8 and Windows Phone 8.1 Apps and I am having problem with the _wfindfirst function. On regular Win32 it returns a handle to the first found element matching the pattern. we use it mainly to get information about directory or file.
The function I am trying to get working on WindowsPhone/Windows Store App is like this:
bool sys_GetFileInfo(const std::string& path, FileInfo* info) {
...
long handle = _wfindfirst(p.c_str(), &item); // path gets converted to wstring
if (handle != -1L) {
info->size = (item.attrib & _A_SUBDIR) ? -1 : item.size;
info->modifiedAt = item.time_write;
_findclose(handle);
return true;
}
...
}
So it was used to retrieve file size and modification date (and if it happened to be directory the size was set to -1)
The first usage was to get info about working directory of an exe so in case of the WinRT/WP/WS I am using it with the path provided by
std::wstring wpath = Windows::ApplicationModel::Package::Current->InstalledLocation->Path->Data();
The path in this case is:
wpath = L"C:\\foo\\winrt\\winrt\\Debug\\foo_winrt.Windows\\AppX"
The problem is that it always returns -1, when I check the error string with GetLastError() code I get the access denied error. This is confusing as in my understanding application should have read access to this location so _wfindfirst is a read operation right? On Win32 it worked given a regular directory path.
Why this function fails? Is there any other viable option to achieve the same result for WinRT ?
If still relevant, it seems you are not able to use standard C++ functions to access file system outside your app's sandbox (installed location and local app folder). They will fail with Access denied error. I think they behave pretty much the way CreateFile2 behaves, and according to MSDN:
When called from a Windows Store app, CreateFile2 is simplified. You can open only files or directories inside the ApplicationData.LocalFolder or Package.InstalledLocation directories.
In your case, as I can see, the installed location points to a development folder, and I think the system decides that this location isn't inside your app's sandbox.
Consider using Windows Runtime APIs from Windows.Storage namespace. These APIs can be used to access any file in the file system.
Related
I want to use spawnl to restore a DOS terminal session after my application has completed, I'm doing the following:
static char* pszMode = "mode.com";
int intRC = spawnl(P_WAIT, pszMode, pszMode, "co80", NULL);
char szCOM2setup[80];
sprintf(szCOM2setup, "%s:9600,n,8,1", clsPort::mpcszCOM2);
intRC = spawnl(P_WAIT, pszMode, pszMode, szCOM2setup, NULL);
mpcszCOM contains COM2
In both cases intRC contains -1, I've single stepped execution and it doesn't look like these commands are being properly executed, what haven't I done?
I'm using ROM-DOS version 6.22 on an embedded PC104 platform.
I've checking with perrror and using strError, the actual error is:
No such file or directory
But why? The path is set-up before the application is launched and mode.com is accessible from the command line in the same folder as the application.
Tried using spawnlp instead of spawnl, no better same error.
For a reason I don't understand even though the path is set-up correctly, the application was returning "No such file or directory" so I modified the application to include the path and this resolved the issue.
I've written a very simple service application based on this code example.
The application as part of its normal running assumes there exists a file in the directory it is found, or in its execution path.
When I 'install' the service and then subsequently 'start' the service from the service manager in control panel. The application fails because it can't find the file to open and read from (even though the file is in the same directory as the installed executable).
My question is when a windows service is run, which is the expected running path supposed to be?
When calling 'CreateService' there only seems to be a path parameter for the binary, not for execution. Is there someway to indicate where the binary should be executed from?
I've tried this on windows vista and windows 7. Getting the same issues.
Since Windows services are run from a different context than normal user-mode applications, it's best if you don't make any assumptions about working directories or relative paths. Aside from differences in working directories, a service could run using a completely different set of permissions, etc.
Using an absolute path to the file that your service needs should avoid this problem entirely. Absolute paths will be interpreted the same regardless of the working directory, so this should make the working directory of your service irrelevant. There are several ways to go about this:
Hard-code the absolute path - This is perhaps the easiest way to avoid the problem, however it's also the least flexible. This method is probably fine for basic development and testing work, but you probably want something a bit more sophisticated before other people start using your program.
Store the absolute path in an environment variable - This gives you an extra layer of flexibility since the path can now be set to any arbitrary value and changed as needed. Since a service can run as a different user with a different set of environment variables, there are still some gotchas with this approach.
Store an absolute path in the registry - This is probably the most fool-proof method. Retrieving the path from the registry will give you the same result for all user accounts, plus this is relatively easy to set up at install time.
By default, the current directory for your Windows service is the System32 folder.
A promising solution is creating an environment variable that keeps the full path of your input location and retrieving the path from this variable at runtime.
If you use the same path as binary, you could just read binary path and modify it accordingly. But this is rather quick-fix rather than designed-solution. If I were you, I would either create system-wide environment variable and store value there, or (even better) use windows registry to store service configuration.
Note:
You will need to add Yourself some privileges using AdjustTokenPrivileges function, you can see an example here in ModifyPrivilege function.
Also be sure to use HKEY_LOCAL_MACHINE and not HKEY_CURRENT_USER. Services ar running under different user account so it's HKCU's will be different than what you can see in your registry editor.
Today I solved this problem as it was needed for some software I was developing.
As people above have said; you can hardcode the directory to a specific file - but that would mean whatever config files are needed to load would have to be placed there.
For me, this service was being installed on > 50,000 computers.
We designed it to load from directory in which the service executable is running from.
Now, this is easy enough to set up and achieve as a non-system process (I did most of my testing as a non-system process). But the thing is that the system wrapper that you used (and I used as well) uses Unicode formatting (and depends on it) so traditional ways of doing it doesn't work as well.
Commented parts of the code should explain this. There are some redundancies, I know, but I just wanted a working version when I wrote this.
Fortunately, you can just use GetModuleFileNameA to process it in ASCII format
The code I used is:
char buffer[MAX_PATH]; // create buffer
DWORD size = GetModuleFileNameA(NULL, buffer, MAX_PATH); // Get file path in ASCII
std::string configLoc; // make string
for (int i = 0; i < strlen(buffer); i++) // iterate through characters of buffer
{
if (buffer[i] == '\\') // if buffer has a '\' in it, replace with doubles
{
configLoc = configLoc + "\\\\"; // doubles needed for parsing. 4 = 2(str)
}
else
{
configLoc = configLoc + buffer[i]; // else just add char as normal
}
}
// Complete location
configLoc = configLoc.substr(0, configLoc.length() - 17); //cut the .exe off the end
//(change this to fit needs)
configLoc += "\\\\login.cfg"; // add config file to end of string
From here on, you can simple parse configLoc into a new ifsteam - and then process the contents.
Use this function to adjust the working directory of the service to be the same as the working directory of the exe it's running.
void AdjustCurrentWorkingDir() {
TCHAR szBuff[1024];
DWORD dwRet = 0;
dwRet = GetModuleFileName(NULL, szBuff, 1024); //gets path of exe
if (dwRet != 0 && GetLastError() != ERROR_INSUFFICIENT_BUFFER) {
*(_tcsrchr(szBuff, '\\') + 1) = 0; //get parent directory of exe
if (SetCurrentDirectory(szBuff) == 0) {
//Error
}
}
}
Hoping for some help here, as I am tearing my hair out!I'm using Visual Studio 2010.
I have an MFC C++ application to deploy. I have a config.ini file that I'd like referenced when the exe starts. At the moment the user cannot double click on a *.myfile and it open, because the application does not "start in" the application folder (where I am installing the ini file to), and so cannot find the ini. I've tried the following
I tried finding info on setting the "start in" folder for the &Open action, but cannot find anything.
I can't find any info on setting a registry value of the ini file at installation, since this would be a relative reference depending on the user's choice, and so this doesn't apply.
It is unmanaged so the C++/CLI app.config solution doesn't apply.
Using the Application Data folder, but this gives me the wrong path - I'm using Windows 7, this is probably why, but I want my deployment to work on Windows XP ++.
Reading the app path at start up (from here) (put this in CMyApp::InitInstance().
Code:
CString strPath;
TCHAR* pstrExePath = strPath.GetBuffer (MAX_PATH);
::GetModuleFileName (0, pstrExePath, MAX_PATH);
strPath.ReleaseBuffer();
int pos = strPath.ReverseFind('\\');
strPath = strPath.Left(pos);
strPath += "\\config.ini";
This is the closest, but in debug mode there is a weird "\.\" in the path invalidating it. I could use a #ifdebug but this is messy surely?
Really appreciate any help - thanks!
EDIT:
Using this:
TCHAR szPath[MAX_PATH];
if (SUCCEEDED(SHGetFolderPath(NULL, CSIDL_COMMON_APPDATA, NULL, 0, szPath)))
{
MessageBox(NULL,szPath, "MyApp", MB_OK|MB_ICONWARNING);
}
I get: "C:\ProgramData" as the szPath. Maybe this is right for debug mode? Or the development machine?
Thanks for all the input and prompts. It helped me get to this solution. Hopefully it helps some others to have the info in one place. This solution is a very simple one and probably not for full commercial deployment!
In VS2010 in the FileSystem (Setup)
put the config file in the User's
Application Data Folder \ Productname
Set InstallAllUsers to false, so that
you don't need conditionals on where
your config file is located, based on
the user's installation choice
In the InitInstance() function add
something like the following:
[listbreaker]
TCHAR szPath[MAX_PATH] = {0};
if(SUCCEEDED(SHGetFolderPath(NULL, CSIDL_APPDATA|CSIDL_FLAG_CREATE,NULL,SHGFP_TYPE_CURRENT,szPath)))
{
PathAppend(szPath, "\\MyApp\\");
// Can check to create the directory here
//if (!PathFileExists(szPath))
// CreateDirectory(szPath, NULL);
PathAppend(szPath, TEXT("MyApp.ini"));
// can check to create default file here if removed by user
//if (!PathFileExists(szPath))
//g_ConfigData.write_default() // be nice if it could write itself
//MessageBox(NULL,szPath, "MyApp", MB_OK|MB_ICONWARNING);
}
if (!g_ConfigData.ReadData( szPath ) )
MessageBox(NULL,"Configuration file cannot be read", "MyApp", MB_OK|MB_ICONWARNING);
Some useful links that really helped me on this are:
How to get the %AppData% folder in C?
http://msdn.microsoft.com/en-us/library/206sadcd.aspx
http://www.vbforums.com/showthread.php?t=491920
http://jedej.com/2011/02/22/constant-special-item-id-list-windows-special-folders/
http://www.codeproject.com/Messages/2623871/using-CSIDL_APPDATA-or-CSIDL_COMMON_APPDATA.aspx
I'd appreciate any further help on this, as I'm sure there are more refined and flexible solutions (e.g. handling "All Users" choice on installation).
I'm trying to use a dialog box to open a file in my program. This works perfectly on a 32 bit system, but when I try to use it on 64 bit it is unable to open the file. I've figured out that if the file trying to be opened is in the same directory as my program, it works fine. Trying to open a file from another folder, however, doesn't work at all.
So, I tried to copy the file to the program folder. This also works fine on 32 bit but doesn't work at all on a 64 system. Any thoughts why?
char cwdl[500];
getcwd(cwdl,500);
string mystring = string(cwdl);
CFileDialog fileDlg(TRUE, NULL, NULL, OFN_FILEMUSTEXIST | OFN_HIDEREADONLY, "All Files (*.*)|*.*||", this);
fileDlg.m_ofn.lpstrTitle = "Select New File";
if( fileDlg.DoModal() == IDOK)
{
CString newFile= fileDlg.GetFileName();
mystring+="\\"+newFile;
const char * newLoc = mystring.c_str();
CopyFile(newFile,newLoc,true);
this is just a snippet of the code.
UAC and file system redirection are related yet different.
User account control is a permissions based security to prevent unauthorized users from changing your file system or executing applications which may affect other users. The prompt allows you to override the security by providing administrator privileges temporarily if that was your intent.
File system redirection is to allow backwards compatibility with 32bit applications by having a mirrored 32bit system folders and registry. In fact if the action causes UAC to kick in redirection does not occur it will always try to use the 64bit version of the file in that case. Unless you specify the redirection directory explicitly or run the 32bit application with administrator privileges to bypass UAC.
Ok that said you are using a relative path so it will look for the file in the current directory for the process. If it's compiled as 32 bit process running it on systems with different architectures may not behave as expected due to aforementioned redirection.
You can use GetCurrentDirectory windows API to see what directory the current process is using and verify it is what you expected. If not you have a few options.
The easiest would be to use fully qualified file paths.
You could also have two builds one targeted for each architecture you intend to deploy on. After all if you're on a 64bit system you might as well deploy 64bit applications.
A more involved option would be to subclass CFileDialog and disable redirection by calling Wow64DisableWow64FsRedirection in the constructor and Wow64RevertWow64FsRedirection in the desctructor. However this is meant to be a system setting so you may get new problems by forcing your 32bit application on 64bit windows.
There are probably plenty of other options as well since there is usually many ways to skin a cat. However the first step is to put some debug code in place and verify or eliminate redirection as a culprit with GetCurrentDirectory
Maybe it's just me, but I'm seeing a strange result: in 64-bit mode, the first four bytes of the buffer used to store the location of the path, are filled with zeros.
char wk[_MAX_PATH];
char *ret = _getcwd(wk, _MAX_PATH); // wk = "\0\0\0\0C:\\MyFolder\\..."
// ret = "C:\\MyFolder\\..."
The return value OTOH is correct. "ret" points to wk + 4;
In 32-bit mode, there are no leading zeros, the path starts at the first byte. Note: this is a Multi-byte app, not Unicode.
I'm using Visual Studio 2010 (10.0.40219.1 SP1Rel).
Anyway, if you're getting the same result, that would explain why your example doesn't work. You would have to say (in 64-bit mode only):
string mystring = string(cwdl + 4); // 64-bit only
Weird or What?
Edit: Seems to be an alignment problem. Works OK if the _getcwd is in a separate function.
I created a .properties file that contains a few simple key = value pairs.
I tried it out from a sample c++ console application, using imported java classes, and I was able to access it, no problem.
Now, I am trying to use it in the same way, from a C++ dll, which is being called by another (unmanaged) c++ project.
For some reason, the file is not being accessed.
Maybe my file location is wrong. Where should I be storing it?
What else might be the issue?
TIA
As you are mentioning "DLL" i guess, that you are using MS Windows. Finding a file there from a DLL, and independently from the logged on user is a restricted item. The best way is to store the file in a path assembled from the environment variable ALLUSERSPROFILE. This is the only location that is equal to all users and where all users usually have write access. Your applications data should reside in a private subdirectory named like < MyCompany > or < MyApplicationsName >. Type
echo %ALLUSERSPROFILE%
on a windows command line prompt to find out the actual location on a machine.
Store your data in i.e.:
%ALLUSERSPROFILE%\MyApp\
Your dll can then query the location of ALLUSERSPROFILE using getenv:
char *allUsersData = getenv("ALLUSERSPROFILE");