I wrote a BPL project and added output .bpi file to another EXE project. The EXE project compiles and links well. The EXE runs well if I put .bpl file in the same folder as .exe file. However, the EXE fails to run if I put .bpl file in other folders than .exe file, and it shows "The program can't start because XXX.bpl is missing...".
I also wrote a DLL version and put .dll file in other folders than .exe file. I added the .dll to the EXE project's "C++ Linker"->"Advanced"->"Delay load DLLs" list, and added SetDllDirectory() function call to my custom search path. The EXE runs well. It seems that .bpl can not work the same as .dll if delay-loaded with custom search path via SetDllDirectory(), am I right?
Test BPL code is like following:
"TestPackage.h"
class PACKAGE TestPackage
{
TestPackage( void );
int GetInt( void );
};
"TestPackage.cpp"
#include "TestPackage.h"
#pragma package(smart_init)
TestPackage::TestPackage( void ){}
int TestPackage::GetInt( void ){ return 1000; }
And the test form application code is like following:
"TestApp.cpp"
#include "TestPackage.h"
void __fastcall TForm1::Button1Click( TObject* Sender )
{
TestPackage* package = new TestPackage;
int ret = package->GetInt();
Application->MessageBoxA( IntToStr(ret).c_str(), L"test", 0 );
}
I disabled both "Build with runtime packages" and "Dynamic RTL" in application options. I put TestPackage.bpl in the folder as EXE and the EXE worked well. I could upgraded BPL separately from EXE, say to let TestPackage::GetInt() return other numbers. So the net result seems I can deploy my custom BPL with EXE, and other BPLs, like RTL and VCL, are still statically linked in EXE. The only limitation is that my custom BPL must be in the same folder as EXE, is there any way to overcome this?
Related
I have a project written in C. Currently it's using UNIX makefiles to compile itself for Linux, but recently I've been looking into CMake, to be more portable.
The executable, when running, needs to access some asset files that are part of the project. When using makefiles, I would just compile the project with:
make prefix=/usr
make prefix=/usr install
So while the project is compiled, it knows that it will end up in /usr, and when running, it searching for its own project files there (in something like /usr/share/my-project/).
I created a very basic CMakeLists.txt, that compiles the .exe file, and installs it together with one other asset file in the install directory. I then run the following commands to create an NSIS installer for Windows:
cmake.exe --build --config Release .
cpack.exe
Which succesfully gives me the NSIS installer. When run, it shows the user a few steps, one of them is to decide where the project will be installed, which the user can modify.
So my question is, at that point the project has already been compiled, so how can I pass to my project its own install location, so it can access files included in the project? How do other projects do this? I couldn't find much information online about it, which makes me think I might be taking the wrong approach.
For anyone stuck in a similar problem, I found one solution.
Upon looking online, this seems to be something not recommended for Unix systems, and setting the install location during compilation is pretty standard.
For windows, however, I found the function GetModuleFileNameW (GetModuleFileNameW function (libloaderapi.h)).
It returns the path to the current executable (something like C:\Program Files\<my-app>\bin\my-app.exe). I've confirmed it returns the right path, even when I install the project on different directories. It returns the result using wchar_t, so unicode directories are also supported.
Here is a small example of how it can be used:
// to keep the example simple, this is assuming maximum 1000 characters in the path
wchar_t dynamicProjectLocationW[1000];
GetModuleFileNameW(NULL, dynamicProjectLocationW, 999);
dynamicProjectLocationW[999] = L'\0';
// given a path like "C:\X\Y\bin\myapp.exe" find the second to last slash
// so we can get the path "C:\X\Y\"
wchar_t *pointer = dynamicProjectLocationW;
wchar_t *secondToLastSlash = 0;
wchar_t *lastSlash = 0;
while (pointer[0] != L'\0') {
if (pointer[0] == L'\\') {
secondToLastSlash = lastSlash;
lastSlash = pointer;
}
pointer++;
}
// cut the path short, so we can use the project path to find other files
if (secondToLastSlash) {
secondToLastSlash++;
secondToLastSlash[0] = L'\0';
}
This is solving my problem for now, so I'll be using this until a better solution is found.
This is a very easy question, but I'm struggling unreasonably hard to find answers online.
DeepMind just made MuJoCo free, so I decided to download it on my Windows computer and test it out. When I install, however, all I get is a folder.
I've created a different folder (not inside the downloaded folder), and copy pasted the hello.xml and hello.c files from the tutorial into this new folder. However, VSCode has underlined #include "mujoco.h" in red inside hello.c with the warning cannot open source file "mujoco.h".
I assume that I need to add some things to my path or somehow make my compiler able to find the header file. How should I go about doing this?
Overall, I want to be able to run hello.c.
(I have looked at many different links, which I can link here to prove I've researched elsewhere if needed, but most resources online seem to either 1. Assume things will just work / that you have experience with C and library importing 2. Are for Macs/Linux or 3. Are for mujoco-python)
TL;DR
Create empty visual C++ project
Copy the code
Add MuJoCo Header files via VCC++ Directories -> Include Directories (make sure the set the platform to x64)
Add Library Directories of Mujoco installation ("bin" directory) via Linker -> Input -> Additional Library Directories.
Add the library names (glfw3.lib, mujoco200.lib... etc.) via Linker -> General -> Additional Dependencies
Compile
Put the resulting exe into the bin dir of the MuJoCo installation
Create the project
Open Visual Studio File -> New -> Project -> Visual C++ -> Empty Project
Write the Code
stackoverflowMuJoCo -> Source Files -> Add New Item -> C++ File (I called it "main.cpp" but it shouldn't matter)
Copy the code from hello.c into main.cpp
#include "mujoco.h"
#include "stdio.h"
char error[1000];
mjModel* m;
mjData* d;
int main(void)
{
// activate MuJoCo
mj_activate("mjkey.txt");
// load model from file and check for errors
m = mj_loadXML("../model/hello.xml", NULL, error, 1000);
if( !m )
{
printf("%s\n", error);
return 1;
}
// make data corresponding to model
d = mj_makeData(m);
// run simulation for 10 seconds
while( d->time<10 )
mj_step(m, d);
// free model and data, deactivate
mj_deleteData(d);
mj_deleteModel(m);
mj_deactivate();
return 0;
}
*note i downloaded it before deepmind took over it so I still need to use the mj_activate call but you can just ignore it.
Also i change the path to hello.xml because later i am going to copy the executable into the bin dir of the MuJoCo installation(see below)
Add the header files
Right Click on the Project -> Properties
Change Configuration from whatever is selected (most likely Debug/x86) to "All Configurations" and set the Platform to x64*
VCC++ Directories -> Include Directories
Add the include directories of your MuJoCo installation "mujoco200_win64\mujoco200_win64\include" (should be a path like this)
*this makes sure you don't have to repeat the whole process for every configuration.
VSCode has underlined #include "mujoco.h" in red inside hello.c
This should now be gone.
Add the libraries
Right Click on the Project -> Properties
Configuration Properties -> Linker -> Input -> Additional Dependencies
Enter the names of the .lib files located in your "installation" of MuJoCo
Linker -> General -> Additonal Library Directories add the "mujoco200_win64\mujoco200_win64\bin" directory
The compilation should now succeed but the execution will probably fail
Execution and Debugging
At this stage the execution will probably fail with the following errors message.
To solve this you can just copy the outputed exe file stackoverflowMuJoCo\x64\Release\stackOverflowMuJoCo.exe into the bin directory of your MuJoCo installation.
This will make sure it can find the required dll's.
If you want to be able to debug: manually copy all the dll files into the "stackoverflowMuJoCo\x64\Debug" directory.
Warning
The code from the hello world example is passive simulation this means you won't see anything on the screen.
If you want to see something replace the code with this: https://github.com/atabakd/MuJoCo-Tutorials/blob/master/src/0_preliminaries/pd.cpp and add the invertedPendulum.xml to the models directory.
Some notes
There is probably a better/easier workflow but right now I just tried to get it to work. Also I used a different version of MuJoCo than you but it should basically work the same way (except for the activation stuff).
Installing the C version of MuJoCo 2.2.1 on windows and compiling/running code
(A) Installing MuJoCo and loading a model file
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
A1) Navigate to https://github.com/deepmind/mujoco/releases
and download the windows installation, mujoco-2.2.1-windows-x86_64.zip
Unzip this file and put it in a good location (e.g., Documents)
A2) Navigate to bin folder and double click “simulate”. This will open up a GUI.
A3) To load a model, go to the model folder and drop an xml, say humanoid.xml onto the open window. If everything worked fine, you should see a humanoid in the window
(B) Compiling the C programs provided by Deepmind
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
B1) Assuming you have done A1) above
B2) Download the Visual Studio Installer (select community version) here: https://visualstudio.microsoft.com/downloads/
Once the installer has downloaded, run it. When prompted to choose programs, choose the one that says “Desktop development with C++” (see screenshot below). Please restart your computer after installation.

B3) Now we will get some additional libraries to compile and create executables for mujoco on windows. Go to https://github.com/glfw/glfw/releases and download the latex version for Windows (usually glfw-3.x.x.bin.WIN64.zip). Unzip the file.
Now we will drag and drop some files from the glfw folder to mujoco
i) Copy the entire include/GLFW subdirectory to mujoco/include/GLFW.
ii) Copy glfw3dll.lib from the subdirectory corresponding into your compiler (here the compiler is lib-vc2022) to mujoco/lib/glfw3dll.lib.
iii) Copy glfw3.dll from the subdirectory corresponding into your compiler (here the compiler is lib-vc2022) to mujoco/bin/glfw3.dll.
B4) We will open the x64 shell to compile and run MuJoCo. Go to: Start (bottom left corner) —> Visual studio —> x64_Native Tools Command Prompt.
From this shell navigate to the sample folder. Then type make or nmake.
B5) Navigate to bin folder. (cd .. followed by cd bin). Then type simulate. Now you can do A3) above.
This video explains these steps: https://youtu.be/u6tNfvLXK-I
I'm quite new to python that I always use by writing script in spyder and running them in its Ipython console with python3.6.2 .
I'm trying to write a simple module from a "swig_example.c" file following a couple of swig tutorial (http://www.swig.org/tutorial.html, http://www.swig.org/Doc1.3/Python.html#Python_nn6).
My aim is to be able to run a script "main_python.py" which should look like:
import swig_test
print(swig_test.fact(4))
where fact is a function defined in the original c source.
The source file is "swig_example.c":
/* File: swig_example.c */
#include "swig_example.h"
int fact(int n) {
if (n == 0) {
return 1;
}
else {
return n * fact(n-1);
}
}
The header file is as simple as:
/* File: swig_example.h */
int fact(int n);
and the interface one:
/* File: swig_example.i */
%module swig_test
%{
#include "swig_example.h"
%}
%include "swig_example.h"
When in the terminal I run:
swig -python swig_example.i
a "swig_example_wrap.c" and a "swig_test.py" files are created.
How should I proceed to have my "main_python.py" working?
(It now returns a "No module named '_swig_test' error).
I would like to have some script (maybe using distutils?) so that each time I modify the .c source I can easily update the module without changing the "main_python.py" file.
If you have any solution which uses Xcode instead of spyder it would be well accepted.
I think that the question could be useful to many that are new to python (and Mac actually...) and try to use it while not throwing away their previous works...
EDIT:
I -partially- solved the problem. Now the main point remain Spyder.
I create the files ".c", ".h" and ".i" the way I described. Then, following this post (Python.h not found using swig and Anaconda Python) I create, in the same folder, my "setup.py" file:
from distutils.core import setup, Extension
example_module = Extension('_example', sources=['example.c','example.i'])
setup(name='example', ext_modules=[example_module], py_modules= .["example"])
Then, In anaconda navigator I open the terminal of the environment I'm working in, move to the right folder and run:
python setup.py build_ext --inplace
If now I open spyder everything works the desired way. But If I now want to modify my C source, say add a new function, problems arises. I modify the ".c", ".h" and ".i" files annd thenn re-run in the terminal the previous line. The "example.py" file result to e correctly modified (it innncludes the attribute of the new function), but when try to import the module in spyder (import example) changes are nnot registered and an error message "_example has no attribute "new function" is given in the Ipython console unless I restart Spyder itself.
Is there faster way to fix it? (maybe this is the interaction mentioned in the comments... )
Thank you all :-)
I use Clion 2016.1. For example, I run such code in the directory ~/CLionProjects/Tutorial:
#include <stdio.h>
int main() {
char * string;
string = "Hello, everyone";
printf(string);
}
Why does Clion go for this code to this directory?:
/home/ken/.CLion2016.1/system/cmake/generated/Tutorial-9a39f70/9a39f70/Debug/Tutorial
Hello, everyone
Process finished with exit code 15
How to make the programs running in "normal" directory ~/CLionProjects/Tutorial?
UPD
I want to read a "data.csv" file locates in the current directory (where main.c is). But CLion looks for it in /home/ken/.CLion2016.1/system/cmake/generated/Tutorial-9a39f70/9a39f70/Debug/Tutorial. How to make that CLion looks for data.csv in ~/CLionProjects/Tutorial?
If you want to appear your binaries in a folder you've specified, you need to tell it CLion by adjusting your CMakeLists.txt like this:
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${PROJECT_SOURCE_DIR}/bin)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${PROJECT_SOURCE_DIR}/lib)
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${PROJECT_SOURCE_DIR}/lib)
Edit:
Somehow it seems that these options are not respected in the current version of CLion (2016.2). Therefore one might has to change the desired output directory via: Build, Execution, Deployment | CMake settings and set it there.
For CLion v2016.1 and earlier
To change build output path, open CLion Settings and go to Build, Execution, Deployment | CMake settings and set it there.
This is more an answer for the UPD question than the original. But the answers are related. .EXE is built into a folder that depends on the build options (debug, release, etc). An exe's default working directory is the folder where the exe is found. That is the folder where the program will look for data files, etc, unless you tell it to look elsewhere.
You can change the working directory for the exe with a runtime option. I made a YouTube tutorial for my COSC1030 (Beginning C++) students but the solution is the same for everyone: https://youtu.be/dTtZEAfh_LM
I'm modifying an open-source GUI (written in c) to add a new menu item to the tray app. The new menu entry executes a file (update.exe) in the program root in c:\program files directory. Im using shellexec() and it works fine on x86, but since the path is different on x64 - c:\program files (x86), it fails to load. I'd like to use something to the effect of an environment variable like %programfiles%. What is an elegant solution to this?
Alternatively, I do have the ability to change where the update.exe file is stored. Putting it in 'program files' just seemed the most logical. For the problem above, should it go outside of program files? If so where?
You can use GetModuleFileName() to retrieve the full path to the executable. Then you'll just have to cut the filename from the end, and you'll have the complete directory path.
Something like this should to the trick:
TCHAR szPath[MAX_PATH];
LPTSTR szFileName;
GetModuleFileName(g_hInstance, szPath, sizeof(szPath)/sizeof(TCHAR));
szFileName = _tcsrchr(szPath, TEXT("\\"));
*szFileName = TEXT('\0');
// szPath now contains the path
(Warning! Untested!)