How to prevent local msmpi installation from loading system wide msmpi.dll - environment-variables

I'm writing a console app for windows that sets up an environment and launches (popen) various hpc-apps using msmpi mpiexec.exe.
I have an msmpi installation installed locally to the application I'm writing. All works fine and parallel processing is OK.
However, as soon as I happen to have a system installation of msmpi as well (as installed by e.g. msmpisetup.exe), my applications stubbornly loads the Windows/system32/msmpi.dll instead of the msmpi.dll that I point at using PATH. Since the system msmpi.dll is of a different version, my apps does not run.
The PATH env.var. is set within my app, and it is apparently inherited correctly by the child processes, including mpiexec.
The only remedy I've found is to either (1) Rename system32/msmpi.dll or (2) place a copy of "my" msmpi.dll into every folder in which I have a parallel executable. Both remedies are... not nice.
How can I prevent my apps from selecting the system32/msmpi.dll and use the instance that's in the PATH instead??
Thank you for any advice.
N

The standard DLL search order in Windows is documented to be
The directory from which the application loaded.
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.
If you want your application to check a specific location first before using the system locations, you can call SetDllDirectory in the parent application before letting it execute other binaries that require a particular DLL.

Related

Unrecognized property 'CommType' in connection string using Advantage Data Provider with Entity Framework

I'm trying to set CommType in connection string for Advantage DataBase Server using Entity Framework 5 and Advantage Data Provider in a .NET Web Application.
Connection string is in properties.config file.
I trie to use ads.ini but I don't know where to put it (I try in wwwroot/site/bin but nothing happened)
I need to set this parameters:
RETRY_ADS_CONNECTS = 5
PACKET_SIZE=512
USE_TCP_IP = 1
I can do this whiteout errors, but not using properties.config file.
AdsConnection conn = new AdsConnection("data source=\\\\SERVER1\\DATA; ServerType=remote;TableType=CDX;CommType = TCP_IP");
Any clue about how to solve this? Using ADS.INI or properties.config file, same for me.
Thank you!
Gaston Brave.
You can use the ADS.INI file for this purpose. Where it needs to be located (or how to tell Advantage where to find it) depends on the OS you're using.
From the Advantage Help file topic ADS.INI:
Windows
In order for the ads.ini file to be used, it must be located in the application directory, the Windows directory, the Windows System directory, or the client's search path.
In addition, if an environment variable exists with the name adsini_path, that path will be used to locate the ads.ini file. This can be helpful when you do not want to modify the application’s search path, but still need the ads.ini file to exist in a directory multiple users have rights to (for example on Windows Vista installations). An application can often set the environment variable at run-time before calling any Advantage functions, which avoids the need to set a per-workstation environment variable.
Linux
In order for the ads.ini file to be used, it must be located in the application directory, a directory specified in an environment variable named ADSPATH, in the users home directory, or in the /etc directory. If located in the users home directory the ads.ini file should be named .ads.ini (note the initial "dot").

having external files in an electron application

I have an electron app, and when I make it, it packages and compiles everything.
Sounds like it works perfectly right?
Well, problem is I want one of the folders to not be compiled, but still be accessible by my static files, so the users can add or remove content from the folders.
I've tried making it in a seperate folder, but then it can't find the files even when it's placed in the correct relative path.
Overall, I want my app to exist next to a folder and my <script src="./folder/script.js"></script> to actually be able to access it.
I'm new to basically anything node or electron so i'm probably making some dumb mistake.
Thanks in advance.
Having your user touching files close to your Electron application may be fraught with danger. If they accidently overwrite an important file or accidently delete an important file then your application may stop working and require the user to perform a re-install.
Instead, have any default files the user may need to "touch" packaged up with your application and then upon your applications first run, copy these files (and any necessary folder structure) over to the users home, desktop, documents, downloads or even userData directory.
That way, your application will always know where to find them and the directory is a directory your user will already be comfortable adding files to and removing files from.
You can always let the use choose where these files are stored as a settings option which persists in an application setting file, using something similar to path.join(app.getPath('userData'), 'settings.json');
See Electron's app.getPath(name) for more information.

Show Content of app file after unzipping the iPA, and opening exec shows my local path

I've developed an application and I need to remove my computer local path from the generated iPA file.
I did the following:
unzipping iPA file.
click on show package content.
open exec(appname.exec) file with text editor.
Now I can see some binary stuff, and strings with my computer local path (with my mac name).
I have to remove these paths from the exec file, due to security issues. How can I do so?
As Accessing Files and Directories says:
Although you can open any file and read its contents as a stream of bytes, doing so is not always the right choice. OS X and iOS provide built-in support that makes opening many types of standard file formats (such as text files, images, sounds, and property lists) much easier. For these standard file formats, you should use the higher-level options for reading and writing the file contents. Table 2-1 lists the common file types supported by the system along with information about how you access them.
You have many ways to save your data:
Specifying the Path to a File or Directory
Locating Items in Your App Bundle
Locating Items in the Standard Directories
Locating Files Using Bookmarks
You have chosen to Specifying the Path to a File or Directory,as #Droppy says
Firstly it will break the code signature and secondly it's time consuming and error prone.
You'd better choose to Locating Items in the Standard Directories
Here is why you should choose the way:
Locating Items in the Standard Directories
When you need to locate a file in one of the standard directories, use the system frameworks to locate the directory first and then use the resulting URL to build a path to the file. The Foundation framework includes several options for locating the standard system directories. By using these methods, the paths will be correct whether your app is sandboxed or not:
The URLsForDirectory:inDomains: method of the NSFileManager class returns a directory’s location packaged in an NSURL object. The directory to search for is an NSSearchPathDirectory constant. These constants provide URLs for the user’s home directory, as well as most of the standard directories.
The NSSearchPathForDirectoriesInDomains function behaves like the URLsForDirectory:inDomains: method but returns the directory’s location as a string-based path. You should use the URLsForDirectory:inDomains: method instead.
The NSHomeDirectory function returns the path to either the user’s or app’s home directory. (Which home directory is returned depends on the platform and whether the app is in a sandbox.) When an app is sandboxed the home directory points to the app’s sandbox, otherwise it points to the User’s home directory on the file system. If constructing a file to a subdirectory of a user’s home directory, you should instead consider using the URLsForDirectory:inDomains: method instead.
You can use the URL or path-based string you receive from the preceding routines to build new objects with the locations of the files you want. Both the NSURL and NSString classes provide path-related methods for adding and removing path components and making changes to the path in general. Listing 2-1 shows an example that searches for the standard Application Support directory and creates a new URL for a directory containing the app’s data files.
You cannot do it this way. Firstly it will break the code signature and secondly it's time consuming and error prone.
The correct approach is to not use the complete path in your code and instead use methods like NSSearchPathForDirectoriesInDomains to get the Documents folder, or whatever directory you want to use.

How to find out the name of the common documents folder on a network machine

Given that I am executing an EXE file (D2006 app) on a machine across the network, how can I get the pathname to the commondocs folder on that machine, given that the EXE might have been invoked from a UNC shortcut or a mapped drive letter shortcut, and the platform of the remote machine is not necessarily known (but will be >= WinXP)?
The situation is where the client has a large number of dispersed machines, and they can't be bothered installing my app on all the PC's. So what they do is install the executable somewhere on the network and give everybody a shortcut to that. This already seems to suit them fine and there are no issues there.
At their request, I made the app read the settings from an INI file placed in the same folder as the executable. I can only assume they have configured things so that all the users can write to that folder so that the INI file can be saved back.
However, I want to change it so that the INI file is read and saved to somewhere in the commondocs folder tree on the remote machine, so that they don't need to provide write access to a Program files folder.
The machine that's running your program is the only machine you have access to. The machine where your program is stored is irrelevant. It's just a disk drive. It might not be running Windows. It might even be a NAS that's hardly running anything at all.
If the customer wants the common-documents folder of the file server to act as the common-documents folder for everyone on all the client systems, then get the sysadmin to configure a shared folder on the server and then configure the clients to use that remote folder as their common-documents folder. There is no special programming required on your part for that.
To get the common-documents folder of the machine your program is running on, you can call any of various API functions, including ShGetFolderPath. The CSIDL value you need is CSIDL_COMMON_DOCUMENTS. If you call SHGetKnownFolderPath instead, use FOLDERID_PublicDocuments.

Erlang - Standard location of mnesia database

Is there a standard place to put the mnesia database within erlang? At the moment I am putting it in the priv directory.
By default, Mnesia will create the schema in a subdirectory called Mnesia.<node name> of the current directory of the emulator process.
If that's not what you want, all you need to do is set Mnesia's dir application variable with something like
application:set_env(mnesia, dir, "/path/to/db").
As for where to place the database: that depends on your deployment scenario. Since application
variables can also be set using release config files or command line arguments, you can delay that
decision until you ship (or install on your own servers). For use in production, a standard directory like /var/lib/<your application>/mnesia-<node name>(on unix) should do.
For playing around, i'd recommend using a dedicated directory under the code root (NOT the priv directory) and setting that location within your application's startup section.
In my pet projects, i often use code such as
Root = filename:absname_join(filename:dirname(?FILE), ".."),
application:set_env(mnesia, dir, filename:join(Root, "db")).
for exactly that purpose.
As far as I know, when you create the schema every node creates a schema directory in its root directory.
Therefore, I guess that can be considered the default location.
If, for some reason, you have to include a schema together with your application, well, I guess the priv folder should be fine, since it is supposed to be used for application specific files and it's easily accessible via the code:priv_dir/1 function.

Resources