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).
Related
I'd like to use some functions that are only available in Windows 7 or higher in my application but I also want my app to remain compatible with Windows XP. The app should check at runtime if at least Windows 7 is available and offer some advanced features (like Media Foundation support) in that case.
Is the only way to do this to manually check for Windows 7-only DLLs using LoadLibrary and then importing all the functions I need using GetProcAddress()? This would be very inconvenient but I don't see any other way. Statically linking against Windows 7+ DLLs will cause the application to refuse to start on XP because of missing DLLs so this won't work. But doesn't the Windows SDK offer some more convenient technique for programmers who want to remain compatible with older Windows versions and optionally use features of newer Windows versions?
Note that my application is written in plain C so I'm looking for a solution in C.
Don't ever check for OS versions. Check for available features instead.
The most convenient way to keep your code compatible with earlier versions of Windows while still allowing it to opt-in to newer features is to use delay-loading of modules (see Linker Support for Delay-Loaded DLLs). This allows you to benefit from import resolution as you would with compile-time dynamic linking, yet allows you to respond to import failures at runtime.
There are 2 options:
LoadLibrary / GetProcAddress. It is not so inconvenient - you can define and assign function pointers and use them like normal functions.
Compile 2 versions for XP and 7. The installer chooses the right executable or XP version is started by default and it runs second executable if OS is Win7.
I could find that vs2015 comes with mussel library which is more like to use POSIX calls. I went through the installation guide provided and through the official link, came to know that I need to run configuration file followed by make.
But the configuration file has not been provided with vs2015.
I request you to let me know the procedure if someone has done this before.
musl doesn't support Windows; from the FAQ page:
What are musl’s dependencies?
Linux 2.6 or later. Earlier versions will suffice for running most simple single-threaded programs, but due to bugs and conformance issues at the kernel level, musl is not offically supported on earlier kernels.
(now, Windows 10 does support running Linux binaries through WSL, but in that case you would be building musl through gcc inside the Linux "container" and it would be another kind of game entirely)
As it comes as VS2015 along with third party license I thought there should be a way to get it done. The folder location is Microsoft Visual Studio 14.0\VC\vcpackages\IntelliSense\iOS\OSS\musl-1.1.10
As said in the comment, from the folder name it seems that it's there just to aid IntelliSense when editing code for iOS targets.
I use a 64-bit OS to develop a JavaFX application and use Maven to build my application with javafx-maven-plugin to generate an installation package. The resulting package contains only a 64-bit application. So, is there a way to create a multiarch installator or create a pair of x86 / x64 installators in one pass?
UPD
Could you provide an example of a targeted build-system based on maven? Is it needed to use differents OS or just differents JRE on OS x64? In last case how to build the pair of installers per one run? How to automatically add a suffix to application name to noting the architecture? Is it needed to use e.g. Jenkins, or it can be done with maven alone? Is there a some "classic" configuration of the targeted build-system? And more, is there some drawbacks to use 32-bit application on 64-bit OS? From my tests follows that 32-bit app (for my case) is slower on 32-bit OS than on 64-bit OS. But 32-bit and 64-bit application on 64-bit OS work equally.
this is indended, because the underlying installers contain that information. There is no future where this can be provided, this was a JDK-bug once, but closed as "wont fix". As the javafx-maven-plugin uses the official javapackager-tooling, all benefits/drawbacks of that tooling is valid here too. This is even in the official documentation: https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html#A1307236
You need a build-system per targeted architecture.
EDIT: regarding your updated question: you can only create windows-launchers/installers on windows-systems, you can only create linux-launchers/installers on linux-systems, and the same form mac. This means in order to get launchers/installers from the one project, you have to run the build on every platform, and two times each. One time you have to call it with 32bit JDK being installed, and the other time with 64bit JDK installed (might work on Windows to only have JAVA_HOME being set, as maven picks this up), it does not need any tool like Jenkins, but if you have it, just use it.
About the performance I can't say anything, this is out of scope and is bound to the JRE itself.
Disclaimer: I'm the maintainer of that maven-plugin.
Environment:
Visual Studio 2015/Visual C++
OS: Windows 10 TH2 10586 / Corresponding Windows SDK
Since GetVersionEx is deprecated in Windows 8 and later, I wanted to use version helper APIs (IsWindows10OrGreater) to detect the OS in my DLL to decide the flow. However, as per the MSDN documentation, I will need to have a manifest (with compatibility section for supported OS versions) without which this API (IsWindows10OrGreater) will return false even if running in Windows 10.
I have added a manifest with the required compatibility sections but I could not still get it to work. It always returns false. (I have defined manifest ID as 2 in my resource.h as it is DLL)
To cross check, I implemented a sample standalone application with same manifest which works perfectly for this version helper API.
I need your help to understand what am I missing here in the DLL? Unfortunately, none of the discussions available online talk about DLL manifests for compatibility.
Thanks,
The answer comes a bit late, but I had a similar problem, see my question here.
The problem is that the compatibility section of a manifest is ignored when applied to a DLL, it only works when applied to an EXE.
So if you don't control the EXE that will use your DLL and can't be sure that it has the correct manifest, the way to get around it is to get the ProductVersion from the kernel32.dll file. This neatly corresponds with the Windows version and seems pretty reliable (it is also recommended on MSDN).
I am compiling a DLL that uses ATL to house a com object and targeting X64. Everything seems to be fine but the DLL wont run on the 64 bit machine. I ran depends on it on the target machine and it seems to be dependant on the x86 versions of countless system libraries (kernel32 etc.). Anyone know what i am missing?
I am guessing you are running the x86 version of Dependency Walker, which when analyzing a 64 bit DLL will show that it depends upon several x86 system libraries. You need to download and run the x64 version of Dependency Walker to see what is really causing the problem with your DLL.
http://www.dependencywalker.com
Need more details to be able to help, What are the errors you are getting?
The name of a DLL does not indicate if it's 64 bit or not, in windows there are versions of most system dlls on both 32 & 64 bits and they are named the same but placed in different folders.
The results you got from depends are troubling. Are you sure your DLL is indeed 64 bit? If it is, and it is linked to 32 bit DLLs, it will never work. Go back to your dev env and change those dependencies. If your DLL happens to actually be 32 bit, look for the 64 bit one...
You don't specify how exactly the DLL won't run (does regsvr32 work? if so, what error does creating an instance return?). In case you can indeed register it and you're trying to use it from a 32 bit client, make sure you specify the activation bitness correctly (see CLSCTX_ACTIVATE_32_BIT_SERVER and CLSCTX_ACTIVATE_64_BIT_SERVER). If this is the case, the dependency thing was a red herring, of course.