I understand one should not just assume c:\windows\system32 is where system32 will be located but that there's a way to query Windows for it's location. My goal is to find the directory where I can copy a .scr (screensaver) to so that Windows finds it.
How do I do that? Specifically, how do I do that from an Electron app?
There are 2 system provided environment variables you can use. I have Windows 10
SystemRoot=C:\WINDOWS and
windir=C:\WINDOWS
So System32 would be
%SystemRoot%\System32 or
%windir%\System32
Related
DNVM installs a .dnx directory in C:\Users\myUsername\.dnx (in %USERPROFILE%).
Unfortunately, my user profile is limited to 30 MB by IT policies.
How can I move this directory to somewhere else, e.g. C:\.dnx?
I tried creating a symbolic link from C:\Users\myUsername\.dnx to C:\.dnx, but it seems like Visual Studio does not follow symlinks when building the solution, so I get build errors such as this:
Could not find a part of the path 'C:\Users\myUsername\.dnx\packages\System.IO\4.0.10-beta-22816\lib\contract\System.IO.dll'.
I'm using Visual Studio Community 2015 RC with .NET 4.6 under Windows 7 Professional.
I had an issue come up where my employer is blocking .exe files executing in user profile directories.
I moved the my C:\Users\%USERPROFILE%.dnx folder to C:\Program Files.dnx and created a symlink with the following command:
mklink /D C:\Users\%MYPROFILENAME%\.dnx "C:\Program Files\.dnx"
So far, this seems to be working and I am up and running.
I found a "temporary" workaround by making the .dnx directory non-roaming, via this registry key:
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\ExcludeProfileDirs
You can find more details about this workaround here.
Use junction tool by MS to create alias of the directory on other volume. Download junction.exe and read the usage.
If an application is built on a 32-bit machine, when run on a 64-bit machine, how does it know the .dll is in C:\Program Files (x86) instead of C:\Program Files or it doesn't?
ERROR SUMMARY
[SCRIPT]: File not found: C:\Program Files\Common Files...\abc.dll.
However, in my 64-bit machine, abc.dll is in C:\Program Files (x86)\Common Files...\abc.dll
If it doesn't, where do I adjust the path because apparently it's not in the application's code.
First of all, you can cross-compile in either direction so being built on a 32-bit machine doesn't necessarily mean anything. It is really an issue of running 32-bit code on a 64-bit machine. In this case, there is a 32-bit emulation layer on 64-bit installations called Wow64. Part of this is file system redirection, which redirects file system requests from 32-bit programs. In this case, trying to access "C:\Program Files" from 32-bit code will transparently redirect to "C:\Program Files (x86)".
it doesn't?
No part of the default search path checks anywhere in Program Files or Program Files (x86) unless it is because the directory of the application is under one of those folders.
If you are getting that error from a 32bit application then something is set up unusually (like overriding the default install location under Program Files (x86)).
I have an exe which depends on libeay32.dll. Both compiled for 32 bits.
I have copied the exe to C:\Program files (x86)\app\bin and the dll to C:\Program files (x86)\app\lib.
To ensure the correct working, i have added C:\Program files (x86)\app\lib to the path.
On Windows 7 64 bits, when i execute the exe, i got a libeay32.dll not found error.
Using dependency walker for 32 bits, the library is properly located at C:\Program files (x86)\app\lib.
Using sysinternal process explorer the app is executed properly.
Using cmd also works.
Using dependency walker for 64 bits, i can see the missing libraries.
Copying the two files toghether or dll to syswow64 also works perfectly.
If the application was compiled for 32 bits...
Why isnt windows looking for 32 bits libraries?
Why arent the libraries resolved if directory is already on path?
My guess is that w7 is ignoring the path, but according to this:
http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx
it shouldnt!.
Why i cant run my exe with dependencies located on path?
Should i register the library or something?
Any ideas will be much appreciated.
EDIT:
The program its correctly launched/executed when done from start menu->program, but not directly on the .exe...wtf?
Using procmon seems to be trying to open (note the lack of " "):
"C:\Program Files(x86)\myapp\Third-Party\openssl\LIBEAY32.dll"
but in the path its correct (rechecked: "C:\Program Files (x86)\myapp\Third-Party\openssl")
ANSWER?:
is there a know scenario/bug where setting "C:\Program Files (x86)" on path, lead windows try to load "C:\Program Files(x86)" instead????(see using procmon without ANY filter)
Windows 7 x64 bug?
You can mvoe the lib into the same directory, because there it always checks first. If its found, it is used.
On Windows 64 bit systems you can (not tried) also move the libs to the SystemWOW64 folder where the 32bit versions are stored, but I would recommend the first version.
I have an installer package, at the last step user can select launch application or not. the installed application is 32bit, during the installation we select the installation folder to "c:\Program Files", while it will always install application to "c:\Program Files(x86)" folder, then we meet problem, we can not launch the application, we have tested that if we choose the default installation folder(which means c:\program files") it works well. so I guess the problem is that windows launch 32bit application as 64bit, so it failed. how to solve it?
Your installer should know the path the application was installed to. You should use it, your EXE file key; for a WiX example see Well Done section of the tutorial.
If your installer package is MSI-based, then the installer is a 64 bit process, and it sees both Program Files (x86) and Program Files. I think it is the problem why you can't start your program. (A 32 bit executable will see only Program Files (x86) under the name of Program Files).
In x64 bit version of windows, i see that are also x86 bit directories. How do we get that using envirnoment variables ?
List of recognized System Environment Variables in Windows
For, say, Program Files (x86), it's PROGRAMFILES(X86)
Common Files under Program Files (x86) is COMMONPROGRAMFILES(X86)
Which directory are you looking to find, specifically?
PROGRAMFILES(X86) refers to the C:\Program Files (x86) folder on 64-bit systems.
See here: http://technet.microsoft.com/en-us/library/dd560744(WS.10).aspx