Re: Cross Platform Development

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Bell <ruffrecords@xxxxxxxxx> writes:

I am looking for suggestions for open source cross platform
(Linux/Windows) development tools/languages.

"Linux/Windows" is not exactly cross-platform; it's just two
particular platforms, presumably for a single arch (i386).

Your requirements are somewhat unrealistic. You may need to
compromise on what you want over what is practical. "Stand-alone"
applications are not common, nor a recommended way of doing things;
modern systems are too modular to allow for monolithic applications of
any appreciable complexity. On GNU/Linux, applications can and do
depend upon a multitude of interdependent packages, and you should do
this if at all possible.

I want to be able to provide statically linked stand alone executables for
each platform.

Statically linked executables are not portable. libc cannot be
statically linked, though other libraries may be possible to link
statically.

Static linking has implications for security and bug-fixing; unlike
shared libraries, you need to re-link to every new version of the
library, which is inconvenient, and can leave your users open to
security vulnerabilities they cannot be aware of. For example,
consider the consequences of linking libz, libpng or libgtk2.0
statically.

GNU/Linux users can reasonably expect for a libz or libpng bug or
vulnerability to be fixed by their distribution's security team.
static linking would mean your application would remain unfixed and at
risk.

I can't stand C++ so anything that uses that is out.

C and C++ are well supported on GNU/Linux, and are the most
widely-used languages on the platform. What are your particular
objections?

gtk widgets are too clunky.

In what way? They are themable, so the user can choose a less
"square" appearance, if that's what you are referring to (there are
other clunky aspects to GTK+ which are rather more fundamental).

There are plenty of other widget sets to choose from (Qt, Tk, FLTK,
Motif and Athena spring to mind, but there are many others).

Kylix cannot make standalone executables but would otherwise be
perfect.

It's a closed-source development environment only supported by a
single company. Would you really be happy to be completely dependent
upon Borland continuing development for the foreseeable future. They
could cancel it next year, and you would be rather stuck.

(I've seen the problems caused by total dependence on a single tool
vendor once too often, and Kylix is no different to those that have
gone before in this respect. It's convenient, but that convenience
Comes at a high price.)

Tcl/Tk, Python, Ruby etc are all interpreted and are not standalone
anyway.

Tcl, Python, Perl and Ruby may be interpreted, but you won't find many
systems without them. They are also relatively self-contained, so
depending on one of them also means you'll have all the standard
modules included and available to use.

What is the problem with them being interpreted? Unless you are
writing very computationally-intensive code, their relative slowness
is a non-issue (and if it is, you should be using an appropriate
language, such as C, C++ or hand-optimised assembly). GUI client code
is ideal for an interpreted language, because it's largely waiting on
user events, so it's not perceived as being slower.

Python and GTK+ go very well together (PyGTK). I can recommend it.

If the problem is that you want to write closed-source code, that's
the price you pay for writing closed code.

I have looked at a few (visual) basics (heave) but so far I have not
found a cross platform open source compiled one that is stable
enough to run on my PC.

I doubt there is such a beast (that's mature and usable). You still
run into the problems of future availability that plague Kylix and its
ilk.


Regards,
Roger


- --
Roger Leigh
Printing on GNU/Linux? http://gutenprint.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8+ <http://mailcrypt.sourceforge.net/>

iD8DBQFERUKhVcFcaSW/uEgRAjIhAJ9n07NvbNv/Rz0PXv7moKJW/Hnd0gCdF4tr
J+U+9S4pG1J7jbNgSlOLLX8=
=EV5z
-----END PGP SIGNATURE-----
.

Relevant Pages

  • Re: VBA and VSTO
    ... so I am not dependent to what the user have installed of ... Is my code in VBA in a high level portable to the new ...
    (microsoft.public.excel.programming)
  • Re: Wide character support
    ... > adequately translated for the new platform. ... I've printed a wide string to a narrow stream and ... Printing on GNU/Linux? ...
    (comp.lang.c)
  • Re: CETK - Rebuilding the Touch Screen test in Kernel mode
    ... **Am launcing the touchtest from CETK where we have changed the ... so in the blogs it was written that to run the touchtest in kernel ... PB Debugger Loaded symbols for 'C:\PROGRAM FILES\MICROSOFT PLATFORM ... dependent module could not be found. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Comdlg32.ocx
    ... sure the binary is stored at the specified path or debug it to check for ... problems with the binary or dependent .DLL files. ... The specified module ... comdlg32.ocx is dependant upon some other DLLthat are not on the 64 bit platform that are on the 32 bit platform. ...
    (microsoft.public.windows.vista.general)
  • How many active Threads is possible?
    ... not a language question: ... How many active threads can I create? ... Of course, it is dependent on the platform and the VM implementation, ...
    (comp.lang.java.programmer)