On linux, we have LIBRARY_PATH and LD_LIBRARY_PATH environment variables in order for programs to search for libraries. Do we have similar thing on windows? Particularly Windows 7?
Also, I would like to know best practices for DLL use (where to put them, use envs or not, etc.), since I want to work on windows like everyone does, and not to sloth myself on workarounds :)
Edit: As explained by Bob, this answer describes the Alternate Search Order, which is not what most applications would see. The full rules are quite complex. I don't think I can summarize them here. Instead, read the Microsoft docs - https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order
My original answer was:
This MSDN article explains the default search order. I quote:
The directory specified by lpFileName.
The system directory. Use the GetSystemDirectory function to get the path of this directory.
The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched.
The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
The current directory.
The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the App Paths registry key. The App Paths key is not used when computing the DLL search path.
In (1), if you statically linked against the DLL's stub library, I think "the directory specified by lpFileName" is the process's exe's path.
Take a look at the help for the LoadLibrary and CreateProcess functions. These describe the paths used to locate DLLs, and how you can modify them.
It looks on currentDir first then WinDir and SystemDir also in your path
According to what #andrew has mentioned in his answer, the order of folders that are used on Windows to search a DLL may be different from one configuration to another. I think the simplest way to check this order on Windows is to use the Dependency Walker tool. After opening the tool, and pressing the "Configure Module Search Order" button on the toolbar, you will see a window like this:
This window shows you the current search order on your machine. The interesting part is that by pressing "Expand", you can see the whole folders in the search path one by one. You may also change the order if you want, to be used for loading an specific module.
Related
We are using an earlier version of a commercial application, doors.exe. The latest Windows 10 update broke it. Using msftedit.dll from Windows 7 restores it. Below are three scenarios I have tried. I don't understand why the first and last function the way they do rather than the way the documentation seems to say they should. Questions are in the first and last bullet.
If I create a directory doors.exe.local in the same location as the doors.exe executable and put the win7 dll into that directory, it is ignored and the one in SysWOW64 is used. Why isn't it using the .local directory?
If I put the win7 dll in the same directory as doors.exe, the win7 is used, whether or not I have an empty file named doors.exe.local.
If I put win7 dll into the doors.exe directory but don't create doors.exe.local redirect file, I expect that doors.exe would use whatever dll is loaded and only use the win7 dll if nothing was loaded. If I first start WordPad, which also uses msftedit.dll, and then start doors.exe, doors.exe still uses the local msftedit.dll. Why isn't it using the same dll as wordpad?
I am using Process Explorer to see exactly which dll is used by which process.
The above behavior seems contrary to what I have read in the MSDN documentation. https://learn.microsoft.com/en-us/windows/desktop/dlls/dynamic-link-library-redirection
What am I missing/not understanding?
Thanks,
Daniel
Do you know if the msftedit.dll is loaded with relative path? Or simpler, just by name? What you describe matches the standard LoadLibrary search order. First is the current working directory.
I am struggling with local redirection too. I have 3 PC where it works and 1 where doesn't.
I found how Dynamic-Link Library Redirection/Dot Local works. It uses some sort of caching per .exe instance to mark if redirection is used or not.
When you have an app.exe, first time when you run it on your PC it marks if it will use Redirection or not. Later this decision remains regardless if you put or remove the app.exe.local file/folder. I do not know yet where the cache value is stores. I searched the registry for the cache but haven't fount it.
Example 1: If you have app.exe and you do not have app.exe.local next to it and you run it first time, later never will use redirection. If you add app.exe.local redirection will not work.
Exsmple 2: If you have app.exe and you do have the app.exe.local next to it and you run it first time, later always will apply redirection. If you remove app.exe.local it still applies redirection.
I do not see the motivation for this confusing behavior.
Useful: if you want to reset the cache for an exe to use redirection or not, you can run in cmd:
touch app.exe
we working on a C++/CMake project, that needs to run in both Windows and Linux. On Windows, we have to work with a number Visual Studio versions, both in 32- and 64 bit. In order to alleviate dependency issues in our team, we have manually compiled a number of dependencies for each configuration(vs2013_x64, vs2013_x86, vs2012_x64, vs2013_x86...) and installed them (using make install or similar commands) to a common folder for each configuration. Now we have a folder called "vs2013_x64" for example, that contains similar folders as /usr would on linux: CMake, include, lib, share, ...
Now my question is: How do I have to set up CMake, so that it treats this vs2013_x64 folder just like it does /usr on Linux?
I found a number of variables that seem related, for example
CMAKE_FIND_ROOT_PATH and CMAKE_SYSROOT. However, setting them to my vs2013_x64 folder for example does not work: FindXXX.cmake files in the vs2013_x64/CMake folder are not found, and even when I manually set the CMAKE_MODULE_PATH to that CMake folder, the Find* scripts are unable to find the include they are looking for, because the vs2013_x64/include folder does not appear to be searched.
A solution that did work was to set the CMAKE_PREFIX_PATH. This is nice and almost what I need, but lets say that on Linux, I would not want it to look at /usr at all under any circumstances. This would not be possible using the PREFIX_PATH solution if I understand it correctly.
From what I understood from the documentation,
CMAKE_FIND_ROOT_PATH is more configurable and has a number of additional variables such as CMAKE_FIND_ROOT_PATH_MODE_PROGRAM, CMAKE_FIND_ROOT_PATH_MODE_LIBRARY and CMAKE_FIND_ROOT_PATH_MODE_INCLUDE. This makes me believe that FIND_ROOT_PATH is what I actually SHOULD be doing - yet I am unable to make it work
Does what I am trying to do make sense? Can anyone clarify when and how to use what? Ideally, I would like a solution that allows me to set the search path to my vs2013_x64 folder on Windows, that defaults to /usr on Linux, but can optionally also be set to another directory containing lib/include/cmake folders. In addition, it would be nice if searching ONLY occurred in the configured path and nowhere else (to avoid mistakenly picking a library that was installed system-wide).
Thanks!
I have a few sketches I'd like to distribute together. All of them use a custom library which resides in the same folder. The current directory structure is totally flat. All .ino files are in a single folder, right next to the .cpp and .h files for the library. This makes it easy to distribute and update.
This would work perfectly, except that each time I open one of the sketches to upload, the Arduino IDE forces me to move it into a subfolder, then it can't find the custom library. Is there any way to disable this behavior, or can anyone suggest a workaround? Thanks!
I tried at first to do all flat and found it never ending battle. Rather than always working around that, I work with it. My example.
Where I have my local repo in some arbitrary location, then have symbolic links in the ./arduino/library/. directory pointing to them appropriate directories in the repo. In the example I have symbolic links for both SdFat and SFEMP3shield in the ./library/. directory. I use windows so rather than links (or the ln -s command) I use "hard junctions".
Note the libraries use a directory structure of ./ardunio/library/foo/example/bar/bar.ino. So I actually do all my projects in the ./example/bar/bar.ino sketch. Also its worth noting that I use an external editor (like notepad++).
This way my repo can have more or less of what I specify it to.
I'm working on a cross-platform Qt application and the paths are different on Mac OS X and Windows. Since the project is on an external hard-drive, the drive letter also occasionally changes on Windows.
For that reason, I would like to refer to the project directory using a variable, preferably a built-in one. In particular, is there such a variable usable in:
The .pro file?
The build settings (in the Projects tab)?
To complete, #Bill's answer, the way to refer to the source path in the Build Settings is to use %{sourceDir}.
%{buildDir} is also available.
Since I struggled a bit to find it, I'm adding it here.
In addition to %{sourceDir} and %{buildDir}, you could use %{CurrentDocument:Path}, %{CurrentDocument:FilePath} and %{CurrentProject:Path} to refer to specific files and folders in the project directory.
The built-in _PRO_FILE_PWD_ variable contains the path to the directory containing the project file in use. That variable may be useful for you.
There are problems with $$_PRO_FILE_PWD_ on windows, because it contains forward slash allways. You need to fix slash using shell_path.
$$shell_path($$_PRO_FILE_PWD_)
I'm having an issue with linked Resources in Flash Builder. I work in a team environment where we use Linked Resources extensively. We just started developing ANEs and noticed that while linkedResources are used in the libraryPathEntry, in the buildTargets like anePathEntry and airCertificatePath, the absolute path is stored. I tried editing the .actionScriptProperties files directly, modifying the buildtarget absolute paths to linked resource equivalents using the libraryPathEntry as a guide but FlashBuilder complained when loading the project.
Is there a way to get the buildTargets to respect linkedResources and not save the absolute path? I'm trying to avoid the draconian way where all developers must have the exact same directory structure.
Thanks!
Randy
My team had this exact problem and all attempts to fix it with relative paths or workspace macros (i.e. ${PROJECT_LOC}) failed. It seems as if the team in charge of Flash Builder neglected to support relative paths in these particular dialogs, despite them being supported elsewhere.
Here is what we have done to fix this problem. I am assuming you are on a Mac/Linux or the like. If not, the concept here can still be applied.
Most of our projects already have a "set up" bash script that contributors run when they get code. Inside of that script, we simply set up a couple of symbolic links from the user specific absolute path, to a new absolute path with a "common" user. The script first creates the directory if it does not exist, and then creates the symlinks.
sudo mkdir -p /Users/common/<project>/
sudo ln -f -h -s ~/path/to/certificate/dir /Users/common/<project>/certificates
Obviously you can use whatever you like and whatever makes sense for the common path.
Now, in your .actionScriptProperties file you can change the location pointed to by the provisingFile and airCertificatePath to this new common absolute path.
<buildTarget ... provisioningFile="/Users/common/<project>/certificates/provisionfile.mobileprovision" ... >
<airSettings airCertificatePath="/Users/common/<project>/certificates/cert.p12" ... >
We actually take this a step further (and I suspect you will need to also) and create common symlink paths for the ANE files themselves. This ends up changing the anePathEntry to the common path as well.
<anePathEntry path="/Users/common/<project>/anes/some.ane"/>
You will need to make sure that you either hand edit the .actionScriptProperties file directly, or type in the fully qualified symlink path into the dialogs directly. Any attempt at using the Finder dialog launched by Flash Builder to navigate to the files in the common location resulted in the symlinks being auto-resolved to their actual locations.
The script requires sudo, which as I'm sure you know, will require that the users of it know their root password. Maybe some more bash savvy folks can suggest a way around sudo if this is not an option for you.
This will work for android stuff as well I believe. I don't know if that matters to you or not.
Hope this helps!
It looks like this issue was called out in the Flash Builder 4.6 known issues:
http://helpx.adobe.com/flash-builder/kb/flash-builder-4-6-known.html
https://bugs.adobe.com/jira/browse/FB-32955
The bug is apparently fixed but I haven't been able to check the new Flash Builder 4.7 beta yet:
http://blogs.adobe.com/flex/2012/08/flash-builder-4-7-beta-is-here.html