Related
In writing an install script, I quickly found that I'd have cross-platform issues, and bash scripts are hard to maintain. I decided to look for a cleaner solution that's more cross-platform.
The goal is to have an intelligent script sniff out components of the user's system and have as little user interaction as possible. That being stated, I thought about these languages:
Python- cross-platform, and many other programs rely on it, so it may already be present
Javascript- nodejs is required by part of my application, but it's a little clunky for exec calls
Are there any languages that would be a better fit for this application?
Requirements:
Available on all platforms
May be distributed as part of my application if small enough
Little to no version variation, so Ruby is out
*nix only for now, but eventually will be run on Windows
Maintainable
Clear syntax (Perl is out)
Modular (if I sniff the OS, I can include separate OS-specific code)
Capable of downloading files (unmet dependencies)
Capable of relatively complex scripting tasks
Testing for used HTTP ports
Reading and parsing files for configuration data
Checking for permissions and changing directories of insufficient privileges
Open source
Python can do all of those things:
Available on all platforms (Mac, Linux, Windows, and more)
May be distributed as part of my application if small enough (You can make binaries with cx_freeze, if needed)
Little to no version variation, so Ruby is out (Python is pretty static when it comes to version changes)
*nix only for now, but eventually will be run on Windows (It comes pre-installed on Mac, and ships with just about any Linux distro. Binaries don't need the interpreter to run)
Maintainable
Clear syntax (Perl is out) (Python is very easy to read, but that's up to you to decide)
Modular (if I sniff the OS, I can include separate OS-specific code) (Modules are just files in Python)
Capable of downloading files (unmet dependencies) (Urllib2 takes care of that, and it's pre-installed)
Open source (Yep)
Ant will do what you need. It is OS independent and will allow compiles and installs.
Are there any differences between the original CruiseControl and the .NET port? I've compared the 2, but can't find any big differences except the language it has been developed in. I want to use either one of them for (automated) testing of web applications, using Selenium and Subversion, perhaps even Groovy but don't know which to choose.
[edit]
After looking at CC and Hudson, I've chosen Hudson for it's simplicity, it already has plugins to run Groovy scripts and Selenium as well
Choose me, choose me! (I work on the original CruiseControl.)
I've never used CC.NET but from what I know I agree that they are pretty comparable. Probably the most important difference is cross-platform vs. Windows only.
Now I wonder how long until someone comes by and says their both crap and you should try Hudson? ;)
(And of course there are lots of other choices...)
CruiseControl.NET (cc.net henceforth) has build queues (http://confluence.public.thoughtworks.org/display/CCNET/Project+Configuration+Block), which allows you to serialize builds that depends on a certain build order. I'm in the process of emulating this behavior in the java version of cruisecontrol but the functionality doesn't map one to one. The reason however, that I'm at all moving from the .net to the java version is that the .net version core dumps with mono (cc.net nightly build and mono nightly build as of two months ago). The fault lies with monos thread handling but voids attempts to get cc.net up and running.
The documentation on this can be tricky to find, if you don't notice the version numbers that the configuration examples/documentation adhere to (confluence.public.thoughtworks.org has the updated configuration documentation whereas ccnet.sourceforge.net has not. I know that the ccnet is most likely a dead site, but if your're not carefully reading the datestamps on every page you're visiting, this may bite you).
Furthermore, the sourcecontrol blocks for cvs and svn in cc.net are more granular and featurerich than their counterpart in the java version, but this has not been a problem in my work. The java version is also easy to extend/modify re: plugin behavior, but you would really just like to see this kind of work going upstream instead of forking.
I'm fairly impressed with both the java version and the fork in .net (modulo mono runtime behavior), but you really do not want to try any of the other forks of cruisecontrol. I've had peripheral experience with hudson, and the features were just not compelling enough to veer me from cruisecontrol. Hudson has a (somewhat coloured) comparison map of Hudson and CruiseControl (java) at http://hudson.gotdns.com/wiki/display/HUDSON/Home
A viable alternative is the python implemented buildbot (http://buildbot.net/trac). It does not have fancy gui dashboards and the setup is somewhat more commandline-bound, but if you're doing distributed builds, it's very easy to set up and get running.
I think for you it will come down to operating system, original can run on nix, and .net version runs on windows.
There are other automated build utilities that can do this as well, such as TeamCity in the windows space, and cruisecontrol.rb in the ruby world.
Also there is a PowerShell based build utility called pSake that can poll subversion and perform tasks.
We need to interface to 3rd party app, but company behind the app doesn't disclose message protocol and provides only Windows DLL to interface to.
Our application is Linux-based so I cannot directly communicate with DLL. I couldn't find any existing solution so I'm considering writing socket-based bridge between Linux and Windows, however I'm sure it is not such a unique problem and somebody should have done it before.
Are you aware of any solution that allows to call Windows DDL functions from C app on Linux? It can use Wine or separate Windows PC - doesn't matter.
Many thanks in advance.
I wrote a small Python module for calling into Windows DLLs from Python on Linux. It is based on IPC between a regular Linux/Unix Python process and a Wine-based Python process. Because I have needed it in too many different use-cases / scenarios myself, I designed it as a "generic" ctypes module drop-in replacement, which does most of the required plumbing automatically in the background.
Example: Assume you're in Python on Linux, you have Wine installed, and you want to call into msvcrt.dll (the Microsoft C runtime library). You can do the following:
from zugbruecke import ctypes
dll_pow = ctypes.cdll.msvcrt.pow
dll_pow.argtypes = (ctypes.c_double, ctypes.c_double)
dll_pow.restype = ctypes.c_double
print('You should expect "1024.0" to show up here: "%.1f".' % dll_pow(2.0, 10.0))
Source code (LGPL), PyPI package & documentation.
It's still a bit rough around the edges (i.e. alpha and insecure), but it does handle most types of parameters (including pointers).
Any solution is going to need a TCP/IP-based "remoting" layer between the DLL which is running in a "windows-like" environment, and your linux app.
You'll need to write a simple PC app to expose the DLL functions, either using a homebrew protocol, or maybe XML-RPC, SOAP or JSON protocols. The RemObjects SDK might help you - but could be overkill.
I'd stick with a 'real' or virtualized PC. If you use Wine, the DLL developers are unlikely to offer any support.
MONO is also unlikely to be any help, because your DLL is probably NOT a .NET assembly.
This is a common problem. Fortunately, it now has a solution. Meet LoadLibrary, developed by Tavis Ormandy:
https://github.com/taviso/loadlibrary
I first stumbled across LoadLibrary in an article on Phoronix by Michael Larabel:
A Google researcher has been developing "LoadLibrary" as a means of
being able to load Windows Dynamic Link Libraries (DLLs) that in turn
can be used by native Linux code.
LoadLibrary isn't a replacement for Wine or the like but is intended
to allow Windows DLL libraries to be loaded that can then be accessed
by native Linux code, not trying to run Windows programs and the like
on Linux but simply loading the libraries.
This project is being developed by Tavis Ormandy, a well known Google
employee focused on vulnerability research. He worked on a custom
PE/COFF loader based on old ndiswrapper code, the project that was
about allowing Windows networking drivers to function on Linux.
LoadLibrary will handle relocations and imports and offers an API
inspired by dlopen. LoadLibrary at this stage appears to be working
well with self-contained Windows libraries and Tavis is using the
project in part for fuzzing Windows libraries on Linux.
Tavis noted, "Distributed, scalable fuzzing on Windows can be
challenging and inefficient. This is especially true for endpoint
security products, which use complex interconnected components that
span across kernel and user space. This often requires spinning up an
entire virtualized Windows environment to fuzz them or collect
coverage data. This is less of a problem on Linux, and I've found that
porting components of Windows Antivirus products to Linux is often
possible. This allows me to run the code I’m testing in minimal
containers with very little overhead, and easily scale up testing."
More details on LoadLibrary for loading Windows DLLs on Linux via
GitHub where he also demonstrated porting Windows Defender libraries
to Linux.
Sometimes it is better to pick a small vendor over a large vendor because the size of your business will give you more weight for them. We have certainly found this with AV engine vendors.
If you are sufficiently important to them, they should provide either a documented, supported protocol, a Linux build of the library, or the source code to the library.
Otherwise you'll have to run a Windows box in the loop using RPC as others have noted, which is likely to be very inconvenient, especially if the whole of the rest of your infrastructure runs Linux.
Will the vendor support the use of their library within a Windows VM? If performance is not critical, you might be able to do that.
Calling the DLL's functions themselves is of course only the tip of the iceberg. What if the DLL calls Win32, then you'd have a rather massive linking problem. I guess Wine could help you out there, not sure if they provide a solution.
IMO, the best bet is to use Sockets. I have done this previously and it works like a charm.
An alternate approach is to use objdump -d to disassemble the DLL, and then recompile/reassemble it. Don't expect to be able to recompile the code unedited. You might get pure, unadulterated rubbish, or code full of Windows calls, or both. Look for individual functions. Functions are often delimited by a series of push instructions and end with a ret instruction.
As good developers we keep our code as standard compliant as possible to help in porting between platforms. But what tools are available that help us build the code in a uniform way across multiple platforms.
*nix family has make but Windows needs nmake.
I have read about SCons but never used it in anger. What is your favorite build tool, why do you find it effective and are there any limitations (i.e. platforms with bad support etc).
Cross platform IDEs as well.
cmake for c/c++ environments is good. http://www.cmake.org/
I personally use ant, rake, and maven2. I have used ant the most and find it great for several reasons:
Because it is java it works on lots of platforms (without changing any scripts)
The build files are written in XML and fairly easy to write
There are lots of 3rd party extensions available for it and it is easy to write plugins for
we do extreme cross development, and our code runs on linux, windows ce, windows 2K, nucleus and uCOS-II.
since each environment uses different 'make' methodology (out nucleus customer, for example, require us to compile via code-warrior GUI).
i used ANT combined with perl for about 2 years, but this lead the build script to total non-maintainability.
now we moved to use python, which increase the maintainability of the scripts.
bottom line, i did not find a ready-made tool, and had to build my own. maybe, when i have some time (2017 ?) i will pack my scripts and distribute them ....
If you're in the Java world, there are quite a few tools which are cross-platform. Apache Ant and Maven are both build tools which will run on any platform which has Java available for it.
Cruise Control (continuous integration tool) also works on Windows and Linux (it's written in Java as well).
I haven't had any real issues with the core tools, the only problems I've sometimes had have come from things external to the build process, i.e. publishing artifacts - this will vary between systems so I've found there's no single way of setting it up.
For C/C++ development, I've found that bakefile works well. The fairly large wxWidgets project, a cross-platform cross-platform utility and UI library, uses it for their build file generation.
Bakefile is cross-platform, cross-compiler native makefiles generator. It takes compiler-independent description of build tasks as input and generates native makefile (autoconf's Makefile.in, Visual C++ project, bcc makefile etc.).
Bakefile's task is to generate native makefiles, so that people can keep using their favorite tools. There are other cross-platform make solutions, but they either aren't native and require the user to use unfamiliar tools (Boost.Build) or they are too limited (qmake).
You can use gmake on Windows as well with cygwin/minGW or build your windows stuff on Linux.
http://cdtdoug.blogspot.com/2009/05/mingw-cross-for-linux.html
There are tools like Opus Make or MKS Toolkit that offers multiplatform and support. If you have an existing codebase of make script, could be easier migrate to one of there. I suspect you may hunt for similar tools in advertising of DDJ magazine.
We've been running a Java environment for Linux, Windows and the Mac for the last 18 months.
Maven 2 drives our builds, it's pretty easy to get things consistent here. Where M2 plugins don't dare to tread, we use small Ant scripts.
IDE-wise we're using Eclipse & IDEA - both, of course, multi-platform.
Testing - JUnit, Fitnesse, Fest - all nicely multi-platform.
Release scripts are written in Ruby. There's a bit more trouble with Windows here, but a function to convert paths as necessary generally does the trick.
TeamCity does CI. We've actually migrated this from Windows to Linux and encountered no errors at all, very nice package.
We did use GWT for a while and this did cause us large amounts of pain. Be careful if you swing that way.
Greetings,
I want to write a small cross-platform utility program with GUI in it. What language/GUI-library should I stick to? Is it possible whatsoever?
This is gonna be a small program, so I don't want to make people download JVM or .NET Framework. Is it possible to develop it natively?
Update 1.
By "natively" I mean that the end result will be native code without intermediate layers like Java Virtual Machine or .NET Common Language Runtime
Update 2.
A FREE solution is preferable ;)
If you know C or C++ the first cross platform GUI framework I can think of are:
QT (C++, proprietary but free with the LGPL licensing)
wxWidgets (C++, the most complete and stable but also huge)
FLTK (C++)
FOX (C++)
IUP (C, simpler and cleaner than the ones above)
If you know Pascal, you can try freepascal+Lazarus. I've never used it, though.
The problem is: If you do not want to have a GUI but you do not want to ask the user to download an eternal API, Framework or virtual machine to run it in, be it TCL/TK, Java or QT etc. then you get lost pretty fast.
The reason is: You would have to rebuild all the (GUI) functionality those APIs, frameworks and virtual machines provide you with to be platform independent. And that's a whole lot of work to do... .
On the other side: The Java virtual machine is installed on nearly any operating system from scratch, why not give this one a shot?
You want to develop a cross-platform program natively? Uh...I don't think that'll work, mainly because that phrase is a paradox. If you write native code, it by its very nature will only run on the platform you programmed it for. ;-) That's what the Frameworks are all about.
So what you should do instead is use a very slim framework if your program is going to be so small. itsmatt's idea of Qt is a possibility.
WxWindows? Oh, it's called WxWidgets now: http://www.wxwidgets.org/
wxWidgets has bindings to all sorts of languages - python for instance, if your app is small enough.
Lazarus is great. GTK2 on Linux, win32/64 on Windows, WINCE on euh, Wince. It even uses Carbon on Mac (working on COCOA). Also easy to sell to your boss (the code is Delphi compatible)
How about Python using Qt or Wx and then using PythonToExe to make a 'distributable'
Thought will have to giving to the development to ensure that no native functionality is used (i.e. registry etc.) Also things like line breaks in text files will have different escape characters so will need to be handled
Which OS's do you have in mind when you say cross-platform?
As Epaga correctly points out, native and cross-platform are mutually exclusive. You can either write multiple versions that run natively on multiple platforms, or you need to use some cross-platform framework.
In the case of the cross-platform framework approach, there will always be extra installs required. For example, many here suggest using Python and one of its frameworks. This would necessitate instructing people to install python - and potentially the framework - first.
If you are aiming at Windows and OS X (and are prepared to experiment with alpha-release code for Linux if support for that OS is required), I'd highly recommend you take a look at using Adobe AIR for cross-platform GUI applications.
I agree with Georgi, Java is the way to go. With a bit of work, you can make your desktop application work as a Java applet too (so that users do not need to actively download anything at all). See http://www.geogebra.org as an example of an application with runs smoothly as a cross-platform Java application AND has a simple port to a web applet.
Two other advantages to using Java are:
They have extensive libraries for building the UI, including UI component builders.
The Java runtime framework is generally updated automatically for the user.
One disadvantage:
The version of Java installed on your end users computer may not be totally compatible with your application, requiring you to code to the lowest likely denominator.
Try RealBasic. Visual Basic-like syntax, targets Win32, OS X and Linux. I don't know any details about targetting Linux, but for any cross-platform development I've done between Win32 and OS X its been a dream.
http://www.realbasic.com
Edit: Generates native executables. There is a small cost - $100.
Have you looked at Qt?
Flash? It's installed pretty much everywhere.
If it "HAS" to be Desktop use Qt. Nothing beats it right now.
However personally I gave up on desktop and any UI based project I do is normally Browser/Server based. You can easily write a little custom server that listens to some port so the program can run locally with no need for your users to install Apache or have access to the net. I have a small Lua, Python and C++ framework I made for that purpose (Want to add Javascript for the backend with V8 :)
If you're going to look at Qt and WxWidgets, don't forget to also check out GTK+ !
I agree with David Wees and Georgi,
Java is cross-platformness par excellence. You literally write once and run everywhere. With no need of compiling your code for each target OS or bitness, no worries about linking against anything, etc.
Only thing is, as you pointed out, that a JRE must be installed, but it's quick and straightforward to do even for novice end-users (it's a matter of clicking "Next>" a few times in the installer).
And with Java Web Start deployment gets even easier: the user just clicks the launch button on a webpage and the application runs (if the proper JVM is installed according to what specified in the JNLP descriptor) or the user gets redirected to the Java download page (if no suitable JVM is found).