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.
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 like to use command line to install Tomcat as a Windows service. There should be the service.bat file for this purpose. But it is missing from Tomcat 7.0.37 and 7.0.39.
We can not use Windows installer for embedded, so this is not an option.
Thanks for help.
Are you sure you have downloaded the right package?
From the download page for the latest Tomcat 7 version (7.0.39 at the moment of writing this) choose depending on your needs:
32-bit Windows zip
64-bit Windows zip
Both packages have service.bat in the bin directory.
Also on the download page read the README file for packaging information. It explains what every distribution contains.
UPDATE
From the README file for packaging information (emphasis mine):
apache-tomcat-[version].zip or .tar.gz
Base distribution. These distributions do not include the Windows service wrapper nor the compiled APR/native library for Windows.
apache-tomcat-[version]-windows-x86.zip
32-bit Windows specific distribution that includes the Windows service wrapper and the compiled APR/native library for use with
32-bit JVMs on both 32 and 64 bit Windows platforms.
apache-tomcat-[version]-windows-x64.zip
64-bit Windows specific distribution that includes the Windows service wrapper and the compiled APR/native library for use with
64-bit JVMs on x64 Windows platforms.
You may also find it useful reading the RUNNING.txt file, which is available in every distribution. It contains important details about installing/configuring/running Apache Tomcat and also Windows and *nix specific instructions.
Tomcat is a Java application. So it is cross-platform. But if you want/need to utilize Windows specific features, like Windows services in your case, then you should download the Windows specific distribution.
Other thoughts
I myself on my Windows machine use "Base distribution" (i.e. not Windows specific, but an ordinary ZIP file available on the download page under Binary Distributions => Core) without any problem whatsoever, because I prefer not to bother with installations (i.e. running the installer), but just to simply unpack the distribution to the desired directory and manually configure it using the related config files. It's so much easier and convenient both to install (just unpack) and delete the installation (just delete without running any uninstaller), and it's more portable. Plus this way you can install multiple versions of Tomcat on the same machine (in case you need this for some development/testing reasons).
Here is a very useful step-by-step tutorial with some nice illustrations and explanations:
How to Install Apache Tomcat 7/8 (on Windows, Mac, Ubuntu) and Get
Started with Java Servlet
Programming
In the official web site, under core. Don't download the version tagged zip. Download the version tagged 32-bit Windows zip or 64-bit Windows zip. You will find Service.bat under Bin
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 am looking for a recommendation on an installer program. The installer needs to support mulitple OS's - Solaris, Linux and Windows. I have three build machines each running one of the OS's. Currently using the same code base - JAVA and C/C++ for all three.
InstallAnywhere seems to be the dominant player.
IzPack is a an open source software installer generator. All you need is a JRE on the target platform.
Maybe is my personal opinion but I think that the installer is probably the only thing that you may want to keep platform specific and here is why:
it is good to integrate with platform specific deployment systems like: RPM or DEB on Linux, DMG on OS X or MSI under Windows. By using them and allowing both UI and silent installation you will easy the installation of the product for individuals and also for enterprise environments - where it's common to push the installations to the clients.
you can add move the configuration screens outside the installer and trigger them first time when the user runs your application
also do not forget to minimize installer complexity - each "feature" you add will cost you more specially on QA.
You can take a look at BitRock InstallBuilder It supports all the platforms you mention, and it does not depend on Java (though you can use it to install Java programs, in fact many of our customers use it for that, including Sun Microsystems :)
Does it need to be a client-based installer for wide distribution, or just intranet?
For corporate LANs, sometimes setting up a Java Webstart page is the best solution; the customers always have access, they can make desktop shortcuts to the launcher to run just like a standard application, and you have absolute control for pushing updates.
We have an application we're trying to deploy on both 64 bit and 32 bit platforms. Is there a way to put both compiled versions of the code in the same binary, a la Apple and NeXT's fat binaries?
Ideally we could ship one .exe that decides upon execution which version of the code to execute. We're targeting Windows XP and later.
Process Explorer (was sysinternals, now owned by Microsoft) does this. It is a 32-bit application that detects a 64-bit environment, writes out another binary and deletes it on exit. http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
One approach is perhaps to supply a bootstrapping application that determines the architecture and chooses the appropriate executable to run. So basically the shortcut or what have you to your application simply starts the bootstrapper which in turn starts the appropriate application. This can be a little more tricky if your application is a Windows service.
The simplest approach would be to handle this by the installer - it would have two versions of each binary and copy necessary versions depending on which system bit-ness is at the target machine.