I need to install a DLL on Windows and OSX, it will be used by several apps and dlls placed allover the system, but I'm 100% sure it will always be my apps and I don't need any kind of versioning, meaning that if the DLL is replaced by a newer version (or older for that matter), it will work just fine. I also need 32-bit and 64-bit versions.
It looks like these are the proper paths:
OSX : /usr/lib (merged binary for 32 & 64)
Windows: C:\Windows\System32 (here the sources vary)
On OSX it seems working fine. On Windows however it doesn't. I need to support Windows XP,7,8... And on Windows 8.1 it sometimes just didn't work - the file was clearly there, but systém said the DLL is missing. It also seems like the folder for 32-bit (SysWOW64) and 64-bit (system32) are actually pointing to the same location, so I assume Microsoft has been "fixing" the naming mess.
Anyway one location it always worked is here:
C:\Windows
but it doesn't seem to be designed for that. So how is it?
Related
I noticed that deployed on windows Qt applications are always including the dlls they needed.
Why did they made it that way?
Why can't they do it like on linux? - You install needed Qt version to system, and then every application that need it - can use it, e.g. only one instance of libraries(excluding different versions like qt4/qt5).
Wouldn't it be better to make it like Java/.Net, e.g. you install Java/.Net then you run/develop applications using only one instance of libraries(dlls).
I find it kinda "unconservating": I have 7 applications that use Qt5, and all of them have Qt5Core.dll, Qt5GUI.dll, etc. and every of them takes some space. Feels like I have 7 packs of Qt5 libraries... x_x
While on linux these same applications use only "one" Qt library.
I noticed that deployed on windows Qt applications are always including the dlls they needed.
This is called "local deployment".
Why did they made it that way?
I can think of a few reasons.
To avoid DLL Hell.
It is sanctioned by Microsoft. They wrote, "You can use this deployment method to enable installation by users who don't have administrator rights, or for applications that can be run from a network share." (see https://learn.microsoft.com/en-us/cpp/windows/choosing-a-deployment-method?view=vs-2019)
You install needed Qt version to system, and then every application that need it - can use it, e.g. only one instance of libraries(excluding different versions like qt4/qt5)
Qt is a C++ library. C++ DLLs can differ by more than just a major version number. The DLLs could be built with MinGW, or they could be built with MSVC; They could be 32-bit, or they could be 64-bit. The different variants are incompatible with each other.
Example: if you force a PC to have one global copy of Qt 5.14.1 MSVC 32-bit and put that in your PATH, then:
Other Qt apps on that PC that are built with MinGW cannot run.
Other Qt apps on that PC that are 64-bit cannot run.
Apps that must use Qt 5.13 might be broken. (For example, if a critical bug exists in Qt 5.14)
Why can't they do it like on linux? .... on linux these same applications use only "one" Qt library.
I listed a few disadvantages of this approach above. In addition, the version of Qt in Linux distros are usually a few versions behind so applications in the distro repository cannot make use the latest features, bugfixes, or improvements.
That's part of the reason why systems like AppImage and Snapcraft were invented. Sometimes, Linux users also want an app to contain a copy of its libraries, instead of having a single global copy of the libraries.
I have two machines, one running Vista Ultimate 32, the other one running XP SP3. both machines have the same VS2008 version installed.
I built boost 1.50.0 on the first machine (vista), and subsequently libtorrent library, that relies on boost.
I saw in some libtorrent build instructions that the win version is specified within preprocessor, so I did what seemed to make sense at the moment:
#define _WIN32_WINNT=0x0600 // being that the current OS is Vista
The build went successfully, and I was able to run the application on that machine. However, when I tried to run it on the other one (XP), it failed with the message, something like:
Procedure entry point SetFileInformationByHandle could not be located in the dynamic link library KERNEL32.dll
Now, logically, I'm guessing that this has something to do with incompatible versions, and probably different windows headers are included when this variable exists with different values.
The requirement: I'd like to build this on Vista or 7, and still be able to run it on XPs.
The question: Do I need this directive at all, and if I do, what should be the value? What else should I specify, if I'm missing something?
Try to build your program on XP or set _WIN32_WINNT to 0x0501 (as in your comment). The kernel32.dll library is backward binary compatible according to this report, so you can build your program with old version of this library (5.0) and run it with a new one (6.0) without the need to recompile. Vice versa is not possible due to a bunch of added symbols (SetFileInformationByHandle is one of them).
I need to redistribute gdiplus.dll v.1.1 with my app and be sure that this particular version is used. E.g. Windows XP has system version of gdiplus.dll but it can be not upgraded (v.1.0). But if I put my gdiplus.dll into application folder, the system one is still used. Why? How to resolve this?
MSDN says:
If you are redistributing GDI+ to a
downlevel platform or a platform that
does not ship with that version of
GDI+ natively, install Gdiplus.dll in
your application directory. This puts
it in your address space, but you
should use the linker's /BASE option
to rebase the Gdiplus.dll to prevent
address space conflict.
But I have no clue how to rebase gdiplus.dll and for what, anybody can explain this?
[EDIT]
Seems Microsoft decided not to ship GDI+ 1.1 for Windows XP, only Vista and so on. Nice move. Thank you all
You don't actually need to rebase it. If you don't then the DLL will be rebased automatically whenever it is loaded. This will have a mild impact on start-up speed but I would guess that it won't even be detectable.
However, it seems that you cannot redistibute GDI+ 1.1 to XP: How do I install GDI+ version 1.1 on Windows XP?
Put gdiplus.dll in the same folder as your exe, link your exe with the .lib for GDI+ 1.1 and that will be the one that loads.
First line of code in your app will need to register it. Shell "regsvr32 /s gdiplus.dll"
I had previously installed PyQt4 on my Windows XP machine and was successful in getting everything to run. This evening, I downloaded the full Qt4 SDK (open source version) and installed it as well. After adding the path to the bin directory to my system environment path I was able to build a few small programs I'd written in C++. Without changing my environment, I started up python and tried to import PyQt4.QtCore and got an error that it couldn't load the DLL. I removed from my environment path, the path to the Qt4 SDK bin directory and was now able to run my python PyQt4 programs but I could no longer build my C++ programs.
First off, I'm not sure why the presence of the C++ SDK should impact the python version because they're in different directories. I assume the issue is that, when python attempts to load the PyQt4 DLL, it thinks its using an executable from the python path but, because the SDK path is first, that (incompatible) version is what is actually invoked.
Is there a way that these two environments can leave peacefully with each other such that I can build and run either type of program?
The issue, as you correctly suggest, tends to be that the versions of the various DLLs (QtCore4.dll, QtGui4.dll etc) are different. I've tended to find that the problem occurs for the one expecting a newer version (so if the Qt SDK is installed second, but PyQt4 is in the path first, the Qt SDK would complain), but it sounds like you've got a different problem.
There are two solutions that I've found to this:
Change your path for the different build/run environments (not very nice).
Make sure both PyQt4 and Qt/C++ are at the same Qt version so that either DLL will work (generally much easier).
Since I have started installing both PyQt4 and Qt/C++ on a computer when I first start using it (and therefore they are at equivalent release versions), I have rarely had any problems with them coexisting.
Regarding my earlier question about the Point of Mono on Windows, let's say that I develop an app against the windows mono runtime so that it will also run on Linux, OSX, etc.. and to make it more complicated, I use GTK# so that I don't have to deal with WinForms. Is there then an easy way to bundle the Windows Mono runtimes with my Windows version of the application so that it can all be installed at once? Or, is there no point to this? Once I develop against the Windows Mono runtime, would it still run fine against the MS .NET runtime? (I assume I would still need GTK# installed though).
The short answer is Yes.
The things you should take care about while programming are
Not to use platform API
Don't hardcode directory & file name separators, i.e. don't hardcode file paths, but use appropraite class to obtain path separator then concat the names.
Keep in mind that file names on *nx are case sensitve and on Windows are not. While programming don't refer to the same file as log.txt and Log.txt but keep it all small.
Other then that, if you created GTK# application on *nx system, you will be able to run it on Windows if you installed GTK# assembly, and vice-versa.
I did this myself, and it worked like expected. I had a problem to find specific assembly dll version of GTK# on Windows and that took me few hours.
In general, you probably would just use the .Net runtime on Windows. The installer for GTK# for .Net is available from Mono's download page. Your users would need this installed, and then could run you app using the regular .Net runtime.