I am thinking of kicking off a JavaFX project on my 64-bit Windows 7 machine. What I am doing is designing a full-screen console application. It's not interactive aside from a barcode scanner.
I'm designing this for what I think would be an Ubuntu laptop or some other Linux variation, although a different Windows OS is a possibility too (as well as 32 bit). From what I understand Java FX version 2.x has made great advancements in portability from its predecessor, but I wanted to ask the community here what their experience was in deploying JavaFX apps.
Have you had success using them on a variety of different architectures? What are some problems you have encountered?
Checkout EstiMate for an example of an all-in-one jar which is runnable via double click.
https://bitbucket.org/atill/estimate/downloads
It requires Java7u10 installed. I plan to make a proper installer for it later on, using the javafx maven plugin. https://github.com/zonski/javafx-maven-plugin. I haven't tested it on Linux or Mac but it does work across winXP 32bit and 64bit windows7.
As long as your barcode scanner works the same on ubuntu as on win and you are not using any external libraries, you won't notice the difference between those systems from your app.
I found installing oracle JRE on ubuntu the most difficult task. (with JRE_HOME, etc.) Even on Archlinux was easier than ubuntu.
Nevertheless, once the JRE is set, your app will run even on Raspberry Pi (which is ARM not x86)
Remember about file system differences between systems.
Related
I am not sure if this is a Programming or Linux question so please forgive me! Here is my situation:
I have my own PC (running Lubuntu 64 19.04) which I use as my work desktop. I have installed qt creator and qt 5.13 and everything works fine.
Now I have a mini-pc (intel nuc) which is luckily the same CPU architecture (intel x86-64). So the program will be binary compatible for both machines and allows me to develope and compile on my main machine and then remotely deploy or debug on the mini-pc using something like ssh and scp.
I want to develope some sort of "kiosk" application for this mini-pc. The problem is that it has very little storage (32GB). This kiosk application will save some data so it needs a lot of free space.
Now back to the question: For the mini-pc, I can go with qt-installer and install qt just like how I did it on my desktop. But I want to avoid this and I want only to copy the libraries that my application needs to have as small as footprint possible. So:
Is there a qt 5.13 libraries only package that I can install using
apt-get?
Can I get away with only copying (.so or .a) files to my remote pc
in the application binary folder?
What would be the must professional way?
You can copy only the relevant dependencies. There is a existing project for this purpose, called linuxdeployqt.
According to the official docs:
This Linux Deployment Tool, linuxdeployqt, takes an application as input and makes it self-contained by copying in the resources that the application uses (like libraries, graphics, and plugins) into a bundle.
And more specific:
When used on Qt-based applications, it can bundle a specific minimal subset of Qt required to run the application.
The project is based in the official tool macdeployqt.
I started developing Delphi, but I do not know how to use Delphi in Linux.
You can't use Delphi itself in Linux directly, as the Delphi IDE and compilers are all Windows-only executables. So, to run Delphi on a Linux system, you would have to run it inside of a Windows-based virtual machine running on Linux.
However, Delphi 10.2 Tokyo and later include a compiler that can create executables that run natively on Linux.
Unfortantley you cannot run Delphi in Linux. But there is an amazing alternative. It is called Lazarus! It will run on Linux, Mac or Windows. Get it at https://www.lazarus-ide.org/
I am actually surprised Lazarus isn't one of the most popular desktop development tools. If you find it useful and you are capable you should also contibute to the project. It has come a long ways in the past 10 years and with it I don't think you will need to even consider running Delphi on Linux. Lazarus with FreePascal is sufficient!
Also maXbox runs on Linux with a lot of scripts and also python for delphi.
we need Wine to run the scripting engine on debian linux.
maXbox is a script tool engine, compiler and source lib all in one exe to design and code your scripts in a shellbook! Pure Code for Object Scripting. Principle is simplicity and reduce to the max.
The App is “out of the box” (self containment) and needs no installation nor registration.
Release Notes maXbox 4.7.5.90 October 2021 mX47
Add 14 Units + 2 Tutorials
https://sourceforge.net/projects/maxbox/
What is the situation with JavaFX on Linux (x86 and x64)?
Can a JavaFX app be executed without problems on Linux OS?
I have found some questions from years 2011 and 2012, when apps were not stable!
The current version of JFX released is 2.2.4 and it is quite stable on Linux. However, it will become very much better when Java 8 would be released as it would contain JFX 8 distibution. You can try it yourself now using java 8 early access builds.
JavaFX 8 runs fine on Linux in my experience, the only requirement appears to be libgtk 2.18+. There are full details on Oracle JDK 8 and JRE 8 Certified System Configurations. Working Linux versions include:
Ubuntu 10.04 (and possibly earlier, 10.04 had libgtk 2.20)
Redhat 6
Possible problems you may encounter
3D scene support - requires specific modern GPUs + recent drivers, note there is no software rendering fallback for this, and no plans to - see mailing list question
Video playback requires certain version of libavcodec
OpenJDK does not yet include javafx, only the oracle distribution. Update July 2016 - openjfx package now available .on Ubuntu 16.04...
Javafx runs on JVM(Java Virtual Machine) like all other java applications. It doesn't matter whether you run the javafx application on windows or linux or mac there is no doubt that it will not run. That's why java is called platform independent language. Now stable version of javafx 8 has been released with more features.
I have developed a small application in Qt Creator on Ubuntu 12.04 which I want should run on any other linux distro (mostly different versions of CentOS and ubuntu), just like any portable application on windows does.
I want to be able to simply share the binary file of the Application, and run the application.
I am able to successfully do this in windows, by just building the project in QT Creator and then putting the required libraries in the Application directory and then transfering them to other windows systems.
I searched all over and found out that I should be trying to build the project using LSB(Linux Standard Base) Compatibility, so that it runs on other linux distros. Is that the right way to do this?
I am very new to Qt and also to Linux (dont know much of Shell Scripting).
Thus, I dont know how I should proceed to make the Application LSB Compliant.
I have refered to, the following links:
Distributing Qt-based binaries on Linux and
Deploying Qt applications on Linux but have not beem able to understand what I am suposed to do.
I also found this question here which states a very similar situation as mine, but because I am a novice, I dont know how I should do this.
Moreover, considering that the first two articles were written 6 years back, shouldn't there be a simpler way to deploy Qt apps on the linux platform now?
I also saw something about static linking, is that the way to go?
Isn't there a way by which all of this can be done through Qt Creator itself?
If there is no hope of creating a portable Qt Application for Linux, then is there a way, say a shell script or something that would combine all the steps required to compile the Qt project on another computer and run it. Say, download Qt-SDK if not present, run qmake and make and then the newly compiled application, if not already there, so that the user can run the program just by running one script.
Your problem here is not the Linux Standard Base, but rather the presence or not of the specific version of Qt you need (or a later one).
Exactly like on a Windows machine, a user may have any of Qt installed, or they may not have it at all. On Windows it is easier to check for the presence of a certain version of Qt than it is on Linux, thus it is easier to write install tools that automate the experience.
To solve your problem there are a few ways:
Inform the user that your program requires a certain version of Qt or higher, and let the user handle the problem
Learn how to create packages for every distribution you want to target and create specific packages
Use a program like 0Install or Elf Statifier to create a package/executable containing all the necessary libraries.
The latter is similar to what many Windows and Mac programs do (they include every library they need within the installer), but it is not the preferred way on Linux, which relies heavily on shared libraries.
Making a binary application compatible with any other Linux distro is practically impossible since you will never know in advance which libraries are available in distro X, or what version of that library is available. Even among a single distro (e.g. Ubuntu), binary application are almost never backward-compatible, since anything built on Ubuntu 12.04 will have dependencies on versions libraries which are installed on that version of Ubuntu, and trying to run that binary on Ubuntu 10.04 will most probably fail simply because it doesn't have a recent enough version of glibc or some other necessary library.
However, the idea can be much more implementable if you limit yourself to a finite list of distros and versions of those distros. You can then know which libraries are available for those distros, and aim for the lowest common denominator. I used to maintain a binary application which had to support several distros (Ubuntu, Fedora, OpenSUSE, SLED, Mandriva), and the way I would do it is install the oldest distro I was targeting on my build machine. That way, the binary application would be linked to the oldest versions of the libraries available on those distros. Unless there's a new major version of such a library (which happens quite rarely, and even then, distros usually distribute the previous major version for a while for compatibility purposes), your compiled binary will then be compatible with all your targeted distros.
Therefore, the quick piece of advice I would give for your situation, use the oldest LTS version of Ubuntu which is still supported (10.04 at the moment) for your development, and you should be pretty safe for most recent popular distros. For the application you already developped on Ubuntu 12.04, you should have no problem simply recompiling the same source on 10.04. Understand that you will never however achieve 100% compatibility with a compiled C++ Qt application.
If Qt is not all that important to you, you could use a higher-level or interpreted language such as Python, Java, Perl or Ruby. With such languages, you can usually count on the language implementation already being installed on the target distro.
Deploy an application in Linux is a nightmare, luckily there are some solutions. Check this projects to build a portable binary with all their dependencies bundled:
http://statifier.sourceforge.net/statifier/main.html
http://www.magicermine.com/index.html
http://www.pgbovine.net/cde.html
Another solution is make a portable 0install package:
http://0install.net/
I recomend this solution. Personally I have been problems with the 3 first packagers.
We are getting new dev machines and moving up to Vista 64 Ultimate to take advantage of our 8gb ram. Our manager wants us to do all dev in 32bit virtual machines to make sure there will be no problems with our code moving into production.
Is there any way to guarantee the resultant programs will work on 32bit os's?
I don't mind using virtual machines, but I don't like how they force you back into a "Single" monitor type view. I like moving my VS toolbars off to my other monitor.
EDIT: We are using Visual Studio 2005 and 2008, VB.NET and/or C#
EDIT: Using Harpreet's answer, these are the steps I used to set my Visual Studio IDE to compile x86 / 32bit:
Click Build and open Configuration Manager
Select Active Solution Platform drop down list
Select x86 if it is in the list and skip to step 5, if not Select <New...>
In the New Solution Platform dialog, select x86 and press OK
Verify the selected platform for all of your projects is x86
Click Close.
Enjoy.
Thank you,
Keith
I do development on 64 bit machines for 32 bit Windows. It's not a problem. You should make sure that your projects are set to compile in x86 mode in order to be conservative. You'll want to go through each project in the solution and double check this. You could also use the AnyCPU setting but that's a little riskier since it will run differently on your dev machine than a 32 bit machine. You want to avoid the 64bit mode, of course.
The problems I've run into are drivers that don't work when the app is compiled for 64 bit (explicitly 64 bit or AnyCPU compiled and running on 64 bit Windows). Those problems are completely avoidable by sticking with x86 compilation. That should reveal all flaws on your dev machines.
Ideally, you could set up a build and test environment that could be executed against frequently on a 32 bit machine. That should reassure your management and let you avoid the VM as your desktop.
As long as you compile your executables as 32 bit, they will run on both 32 bit and 64 Windows machines (guaranteed). Using 64 dev machines has the advantage that you can start testing your code with 64 bit compilation (to check for things like pointers casted to 32 bit integers), this way making the transition to 64 bit easier in the future (should you your company choose to do a 64 bit version).
Compiling for a 64bit OS is an option in the compiler. You can absolutely compile to a 32bit exe from within Vista 64 bit. When you run the app, you can then see in the TaskManager that there is a "*32" next to the process...this means it's 32bit ;)
I believe your managers need some more education on what 64bit OS really means :)
Not an answer to your question, but possibly a solution to your problem: VirtualBox (and probably others) supports "seamless integration" mode, which just gives you a second start bar and lets you drag windows around freely.
Also, and this is an answer to your question, it depends on your compile settings. You can compile for different environments, and you can perfectly compile 32-bit programs on a 64-bit system with Visual Studio. Can't tell you how, but I'm sure some Visual Studio guru could help you out.
We develop a 32-bit application using VS 2005 (2008 soon) and have just purchased some new machines with XP Pro x64 or Vista Business 64-bit on them so that we can take advantage of the extra RAM whilst holding a watching brief on the possibility of doing a 64-bit port if it becomes commercially necessary to do so. We haven't had any problems with doing this other than tweaking some scripts in our development environment etc.
Those developers who weren't included in this upgrade cycle still use 32-bit machines, so these should pick up problems when the unit tests and the application test suite are run as a matter of course before a check-in.
What we also do is to make sure that we have a set of "test build" machines made up of "typical" configurations (XP/Vista, 2/4/8 cores, etc.) that build and test sets of check-ins - we have various different test suites for stability, performance, etc. - before they are added to the integration area proper. Again, these haven't picked up any problems with running a 32-bit application built on a 64-bit OS.
Anyway, as others have already said, I wouldn't expect it to be a problem because it's the compiler that generates the appropriate code for the target OS regardless of the OS that the compiler is actually running on.
yeah, like adam was saying. There's 3 options: MSIL (default), x64, and x86. You can target x64 and it will generate dll's specifically for 64-bit systems, or you can do x86 which will run on 32-bit and 64-bit, but will have the same restrictions as 32-bit on a 64-bit system.
MSIL will basically let the JITer issue the platform specific instruction (at a slight performance penalty compared to a native image)
EDIT: no language, so i'm talking about .net framework languages like vb.net and c#, c++ is a completely different animal.
Found this today:
http://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with-net.aspx
x64 Development with .NET
Earlier this year I made the switch to a 64-bit operating system - Vista Ultimate x64 to be exact. For the most part, this process has been relatively painless, but there have been a few hiccups along the way (x64 compatible drivers, mainly, but that's not the point of this discussion).
In the world of x64 development, there have been a few struggling points that I thought I'd outline here. This list will likely grow, so expect future posts on the matter.
In the wonderful world of .NET development, applications and assemblies can be compiled to target various platforms. By default, applications and assemblies are compiled as Any CPU in Visual Studio. In this scenario, the CLR will load the assembly as whatever the default target is for the machine it is being executed on. For example, when running an executable on an x64 machine, it will be run as a 64-bit process.
Visual Studio also provides for 3 specific platform targets: x86, x64 and Itanium (IA-64). When building an executable as a specific target, it will be loaded as a process of that type. For example, an x86-targeted executable run on an x64 machine will run as a 32-bit process using the 32-bit CLR and WOW64 layer. When assemblies are loaded at runtime, they can only be loaded by a process if their target matches that of the hosting process, or it is compiled as Any CPU. For example, if x64 were set as the target for an assembly, it can only be loaded by an x64 process.
This has come into play in a few scenarios for me:
XNA - XNA is available as a set of 32-bit assemblies only. Therefore, when referencing the XNA assemblies, the executable/assembly using them must be targeted to the x86 platform. If it is targeted as x64 (or as Any CPU and run on a 64-bit machine), an error will be thrown when trying to load the XNA assemblies.
Microsoft Robotics Studio - The XInputGamepadService uses XNA internally to talk to the Xbox 360 controller. See above.
Managed DirectX - While this is already deprecated and being replaced with XNA, it still has its uses. The assemblies are not marked for a specific target, however I had difficulty with memory exceptions, especially with the Microsoft.DirectX.AudioVideoPlayback assembly.
Phidgets - Depending on what library you download and when, it may or may not be marked as 32-bit only. The current version (11/8/07) is marked as such, and so requires a 32-bit process to host it.
The easiest way to determine if an executable or assembly is targeted to a specific platform is to use the corflags application. To use this, open a Visual Studio Command Prompt from your Start menu and run it against the assembly you wish to check.
The easiest way to determine if an executable or assembly is targeted to a specific platform is to use the corflags application. To use this, open a Visual Studio Command Prompt from your Start menu and run it against the assembly you wish to check.