For Wine, I have a custom-built imm32.dll.so file that I would like to override with a certain application. Replacing the built-in DLL under /usr/lib32/wine/ works, but I don't want to override the DLL for all my Wine programs. I only want to override one application that's in it's own WINEPREFIX.
The winecfg is set to override imm32 with builtin only. I've tried placing the DLL under the system32 and in the same directory as the application without any success. I've also tried setting the WINEDLLPATH path with no success. Nothing seems to work other than copying the imm32.dll.so file to /usr/lib32/wine.
Related
There is a ncurses6 originally installed in a user home dir, let's say "/home/test", so a test environment was built over this ncurses path, a lot of (in development) apps were compiled and is working now, depending only of the current HOME env variable.
But, because of a purpose beyond our control, we have to change the user home dir. And now it's anything different from "/home/test".
The external apps and ncurses tools still working, we need just point the libraries with LD_LIBRARY_PATH and use a more specific path like we used before for ncurses tools:
LD_LIBRARY_PATH=~/bin/ncurses-6.0/lib ~/bin/ncurses-6.0/bin/tic
But now, after changing the user home dir, we need to point also the terminfo database:
TERMINFO=~/bin/ncurses-6.0/share/terminfo LD_LIBRARY_PATH=~/bin/ncurses-6.0/lib ~/bin/ncurses-6.0/bin/tic
But, is there any way to make the TERMINFO database path permanent without recompiling and reinstalling the ncurses ? Is it hard code in ncurses during compilation ?
The default values are compiled-in. You can override those with environment variables (TERMINFO is standard, TERMINFO_DIRS is an extension). That's not new with ncurses6 (it predates ncurses4, twenty years ago).
The most practical "permanent" change would be to put the overrides in your shell initialization.
It's possible to modify an ELF binary (there's no checksums), but the resulting path couldn't be longer. It could be shorter, since the strings are null-terminated. Since your example adds to the path, that wouldn't work for you, anyway.
I want to include a library - I've downloaded it and found exactly four files inside:
.h
.lib
.dll
.def
I've put the header file inside of my project. That's the only thing I did - and the visual throws an error that it cannot open the .lib file.
So I immediately wanted to beg for help on stackoverflow, but I've decided to do a little research first. I've found out that the .dll file should be placed inside of the windows/SYSWOW64 location (for my 64-bit windows 7), I placed it there but VS still displays the same error.
How should I deal with that? Did I missed some step during the "installation"? If so, which ones?
You have to specify the path to the library (*.lib) in your project settings.
(You can put it also into your directory with sources)
The presence of DLL file during build is not required.
In VS2010 the VC++ Directories editing in Tools > Options has been deprecated. VC++ Directories are now available as a user property sheet， which is very convenient to keep the include/lib directories depending on different projects. Is there any way to do the similar thing in VS2008?
After digging around, I figured out a way to partially do it: still with the property sheet.
we can create a new property sheet and set following items:
C/C++->additional include directories
linker->additional lib directories
linker->additional dependencies
...
This will do most of the VC++ directories.
However, the executable directories is still missing. There are two parts need to be done.
the executable path while building, this can be set via add user macros:PATH (for example: c:\sss;%PATH%), then check the box on the bottom to expose this variable to the building environment.
However, while debugging the DLL directories may still missing. We can then set this in project properties->debugging->environment:PATH=%DLLPATH%;%PATH% which will allow the debugger add the DLLPATH to the environment PATH.
I built an application based on QuickFIX Engine in Qt, named fixapp; it works fine. My broker asked me to specify a local port to connect to them. Then I couldn't find such configuration file, so I modified the source code of QuickFix.
I used the examples of tradeclient and executor brought by QuickFIX source code to test. This works. tradeclient binds to a local port I specified in configuration file.
However, when I turn to fixapp, using the library built by the modified QuickFIX source code, it doesn't bind to the local port I specified. It seems that the part I modified didn't change the behavior of the program.
What are the potential problems here?
Update:
I tried to set some breakpoints in QuickFix source code. In one cpp file I modified, my breakpoint is ignored. It is Debug Mode, not release mode. I feel like that it is running the old cpp file and showing the new cpp file.
The asker found that quickfix library path is .../quickfix/lib, and the path I reference to the external lib in fixapp is also .../quickfix/lib. However when he checked the library path in /usr/lib, the library is still the old one. Once he replaced the one in /usr/lib, the fixapp started to work. He doesn't know why the path he referenced in Qt doesn't work but the /usr/lib works.
I'm having trouble using macros in my .inf file that I'm using to create my cab, specifically when setting the InstallDir string. If I do something like this:
InstallDir=\<PathToProgramFiles>\MyAppName
then everything works fine. However, if I do this:
InstallDir=%CE1%\MyAppName
then I get the following error when trying to install the cab (double tapping it on my device): "MyAppName was not installed successfully. Please run Setup again."
This only seems to apply to the built-in macro strings. I can use %AppName% without any problems. Maybe there is some registry setting that isn't properly set that would normally resolve the %CE1% macro?
Any ideas about what is going on?
Edit: My device doesn't have a \Program Files directory. It seems the %CE1% macro always resolves to that path and if the InstallDir specified in the inf file doesn't exist (with the exception of the last directory portion then the install fails. Manually creating \Program Files fixed the issue. Since a lot of the devices I'm working with have different paths for their Program Files directory, is there a generic way to get the installer to default to the actual Program Files dir? I guess my only other option is to not specify a path and force the user to choose one?
First, in this link you can find the shortcuts and their meaning (the %C..%), goto appendix B. The Windows CE5 MSDN link.
You can add a Setup Dll to your CAB installaer that will check the directory structure and will create a folder in case it does not exist. You may find this SO question useful.
A warning: If you are targeting regular Windows CE devices, beware where you place the files as it can be to a RAM based file system and then the files will disappear after reboot.