I'm using SDL in VS2013 and I'm trying to load an image from the folder that my working directory should be using a relative path. Which is where the .vcxproj files are. However I discovered that the working directory is not the folder it should be, it is actually in C:\Windows\System32. I have realised that this is only the case when I go to linker, system and then change the subsystem to CONSOLE. In a WINDOWS subsystem it uses the correct working directory. Why is this happening and how do I fix it?
I think it may have something to do with VS2013 using cmd.exe which is in the system32 folder but I cannot be certain and would not know how to fix it even if that is the case.
Hmm...I don't think I've ever had that problem, and I always write with the console window. Have you tried just making a new project to see if maybe something got set in your properties by accident or something? I would give that a try, or maybe re-install SDL..? That's weird, sorry I don't have better advice!
Related
I have written my own screensaver, which makes use of additional files located at the same directory as the screensaver executable (.scr file).
If I right-click on the screensaver and select 'Test', all is well, those extra files are found.
But if I right-click and click on 'Install' to install the screensaver, it seems to not be able to find those files anymore.
Does the installation process make another copy of screensaver, or maybe change the working directory? If so, what directory is it in?
It's a Windows 7 desktop.
So far I have searched in Windows folder, Program Files, Program Files (x86).
UPDATE:
So, I added the following bit of code to determine the executable's location.
System.Diagnostics.Process.GetCurrentProcess().MainModule.FileName
It appears that the screensaver is running from the directory where I put it, from the original file. However, after installing it, the only way I can reach files in the same folder from the executable is if I use full paths. If I run it as Test, I can simply use filenames only.
This should be a clue as to what is going on, I think. The above function, if I run it as Test, returns long file names, but if I run it as Installed, it returns short file names. I think that when Installed, it runs as some kind of a special process, or maybe a child process, which also interferes with file access.
What is going on?
I added a piece of code to determine the current working directory, and found that when running the screensaver in Installed mode, the current working directory becomes C:\Windows\system32, which would of course explain how files are referenced.
Environment.CurrentDirectory
So I have been trying to build an installer for my game with NSIS. For the most part it works fine but just noticed that it seems to be skipping certain files for no reason. Or no reason I can figure out.
At first I was using this line to gather up all the files in the source folder:
File /r "${NSISDIR}\game\source\*.*"
However, I noticed that this didn't get everything. Granted it found all sub-folders and kept the hierarchy correct. There didn't seem to be any rhyme or reason to what it skipped. Then I tried listing all files and directories separately and found out why. Example:
File "${NSISDIR}\OWTD-DE\source\pygame.math.pyd"
This produces the following error:
File: "C:\Program Files (x86)\NSIS\game\source\pygame.math.pyd" -> no files found.
But that file exists, I can see it in the source folder. This was the case for all missing files. At first I thought it may be the two periods in the name, but various files have that naming convention and they are added fine. I cannot figure out how to get it to recognize these files. Any ideas?
${NSISDIR} is a define used to access the UI resources in the Contrib subfolder, you are not supposed to put your files there. Your source files should not be in Program Files, only installed files should be located there. Also, on 64-bit systems there are two Program Files folders and there are some compatibility hacks in Windows related to %ProgramFiles% so putting your source files there is not optimal. Just because you see that file there does not mean it is actually in Program Files, it could be UAC Virtualization/VirtualStore tricking you...
Normally you would keep your .nsi somewhere in the same directory tree as the rest of your files so you can use relative paths but you can also use a define if you really want to:
!define MYSOURCE "c:\foo\bar"
...
Section
File /r "${MYSOURCE}\*.*"
SectionEnd
If it still misses some files I would suggest trying Process Monitor so you can see the low-level details...
Weirdly enough, this process did not work very well on Windows Home 64-Bit but did on Windows Professional 64-Bit. I'm not sure if this an issue with NSIS itself or what, but nothing was different between the two except the OS. And there really isn't much difference between those two operating systems. However, perhaps some configuration differences between the two was the real issue.
While marked solved, I'm not really sure what the actual issue and solution could be.
I'm debugging test.exe which reads a file "data.txt" that is present in the same directory as that of the exe. The program works fine when run directly. But when being debugged under winDBG, the CreateFile WinAPI in the code fails with err#2 (Unable to find file). I saw a related thread about a similar issue when debugging with VS - there the solution was to place the data file along with the source/headers. That solves the VS issue, but does not help this WinDBG issue.
Has anyone faced this issue before? Please let me know if you are aware of a solution.
If you use relative file paths, then the working directory of your process will affect how they are converted to absolute paths.
When test.exe is launched in Windows Explorer, its working directory is the folder that contains it. In that case the data file in the same folder can be found correctly.
When you use WinDbg to launch test.exe, unless you explicitly set working directory to the one you want, WinDbg will use its own folder. No doubt that leads to the issue you meet.
http://en.wikipedia.org/wiki/Working_directory
can someone help me with this error!
"The PROGRAM CANT START because OPENGL.DLL is missing from your system."
I already put the h. and .dll files in the specific directories. i'm working on a 64 bit window 7. microsoft visual c++.
Most systems already have OPENGL.DLL in the Windows System directory.
The way to diagnose this error is to run Dependency Walker (download here).
Run it and open up your .EXE file - and it will tell you specifically what DLL it can't locate, or which is loaded but is not compatible.
OPENGL.DLL
You are sure about that name. Wasn't it opengl32.dll?
I already put the h. and .dll files in the specific directories
Never(!) do this with opengl32.dll. This is a system DLL and must not be overridden by shipping one own's with the program. If you do this, you may very likely end up with not getting HW acceleration.
I had a similar issue and discovered that I had deleted the following line before pasting the test code:
#include "stdafx.h"
Make sure you have the line as above before pasting the test code.
Maybe you could go to one of your friends , and copy this .dll file from his system dictionary
We're finally getting around to moving our software's documents out of the program's own directory and into "My Documents". We're also adding a "requestedPrivileges" line to the manifest to prevent further trouble with virtualization.
However if we only did that then anyone who had been running the old versions in Vista/7 is likely to lose their work somewhere within the hidden VirtualStore directory after updating. So what's the preferred way of migrating into the 21st century?
Frankly I'm a little wary of copying files around, especially as I can't seem to find a programmatic way of getting at the shadow directory, but presumably plenty of other people must have had the same problem before us.
Don't add requestedPrivileges unless you legitimately need administrative rights in order for your program to work - nothing in your description suggests that you do. That should also let you simply copy the files on the first boot as if they were still in your program directory, because any virtualization would still be in effect.
However, if you absolutely must do the migration without UAC enabled, you can find your files in %LOCALAPPDATA%\VirtualStore\path\to\file. For example, if your file would have been stored in C:\Program Files\OurApp\, you'll find it in %LOCALAPPDATA%\VirtualStore\Program Files\OurApp\.
To get the path to %LOCALAPPDATA%, you can use SHGetSpecialFolderPath with CSIDL_LOCAL_APPDATA as the CSIDL parameter.