How to generate executable across platforms - installation

in case i have a source code and an api to generate windows executable version, is there any possibility or any easy approach to convert it into something that can be executed across Linux /mac or Solaris platforms?

If your code is in a .NET language, there are online and offline translators that can convert the code to Java.
This is just language translation, and doesn't convert the API calls, but it would be a first step in the process.
Another way to handle the problem would be to choose a cloud-based web service or bridge solution. If you have a significant amount of program logic, exposing APIs in this way would allow you to maintain much of the code in its existing language, while making it invocable on other platforms.

Related

Writing a GUI for a Forth application

I was asked by a friend to write a simple GUI containing some charts and selections of common commands for an application he wrote in Forth. However, I have basically zero knowledge about Forth, only that you can't write a GUI in this language (at least that's what he told me).
Now I've been wondering what other programming languages you would suggest which do interact well with Forth and provide libraries (e.g. Java Swing) for interface programming?
Note: I'm still a beginner in programming, and my experiences so far are limited to Java, HTML, CSS, JavaScript, and some C#.
Win32Forth comes with complete Windows GUI and words to use all user32.dll and gdi32.dll functions. It also has a great development environment and windows form creator and editor. Very easy to create user interfaces with it.
SP-Forth allow developing applications with GUI and library WinLib: http://spf.sourceforge.net/ UI libs: http://spf.sourceforge.net/docs/devel.en.html#ui
I would suggest XHTML and Co. (i.e. CSS, JavaScript, XSLT, HTTP) to create user interface (GUI) and interact with Forth. In most general case you include an http-server into Forth system. In some special cases a Web browser object can be embedded into Forth application (for example, using COM on Windows).
Also on Windows you can use HTA (HTML Application) — quite simple solution. HTA can be started from Forth as well as Forth from HTA.
Another way is to use Qt framework (some Forth systems can have bindings).
Yet another way — just use API to underlying system (like user32.dll and gdi32.dll on Windows). Some Forth systems contain GUI-libraries that are based on underlying system API.
Also as edge case, user interface can be implemented in any language as shared library or as separate process with IPC (inter process communication) to Forth system.
In any case, usually GUI is created using special languages, libraries or APIs. GUI is not a subject of Forth as general-purpose programming language.
Bernd Paysan's MINOS may be a way to write GUI code in Forth:
https://bernd-paysan.de/theseus/minos-1.html
Adding a GUI to a program written in Forth is no different from the same problem in any language. You either have to write graphic code yourself or be able to call graphic libraries. In both cases on e.g. MS-windows you have to call functions present in DLL's and you need the documentation of those functions. Most serious Forth's allow to call DLL's. Of course libraries that are internal to a different language are less easily used, but why would you want to? You then commit to that language and are better off using that language from the get-go.
Forth being an interpreter you can couple a plot program easily via a pipe, but that is a one way street. It may be viable if the plot program has the interaction ( such as enlarge, change scale, crop, print etc.) you need.

Functionality unique to Win32 API?

It seems that the Win32 API (the C API for native Windows applications) is becoming more and more overtaken by more modern frameworks and toolkits, including Microsoft's own WPF and Qt.
If the programming language is not a concern -- if you're not set on a managed environment, or a functional programming style, etc. -- does Win32 API bring anything to the table? Is there any functionality that one can implement with Win32 API that's not available with WPF or other frameworks?
I know it's possible to mix Win32 code into WPF/managed software, so one doesn't have to choose one or the other. But what are some examples of needing to break out Win32 API when developing a program in a higher-level language/framework?
Another more specific example is "windows hooks".
I needed to hook some socket programs at some point and the only possible way was windows api.
To elaborate i wanted to receive all communication received on some listening socket on a different one. Doing this requires hooks
Certainly.
All the frameworks are written in terms of the Win32 API. The frameworks cover 80-95% of what programmers need to do, but if you need really low-level control over something, you'll need to drop to the underlying Win32 API. Some examples would be:
precise control over text rendering (via DirectWrite),
detailed control over speech recognition using SAPI (there are literally dozens of interfaces not exposed through System.Speech),
low-level networking code (i.e., anything not HTTP related),
Practically anything audio related, if you're interested in performance.
... and don't forget about direct hardware access like "WinUSB" and debugging functionality (writing programs that act as debuggers).
The Win32 API is nowhere close to be taken over by any framework at the moment.
If that was the case, most of the API would not be updated by Microsoft. Instead, lots of new interfaces are added and updated.
There are framekorks like Qt, but, unless what you need to create is trivial, you will eventually use the API, especially for new graphics libraries, audio, video, usb, ribbon, sockets, network, COM automation, biometrics, encryption, digital signatures, security, scripting, etc.
Actually, most libraries are quite outdated and, while you can create an application that relies mostly on worker threads and not on the interface, building a nice, modern and useful application today certainly requires the API. So investing on a framework that would only cover a minimum part of your application is not worth the learning curve, these frameworks mostly target really new and unexperienced windows developers.

Programming language without additional requirements

Soon I will be coding the file patcher for my application (check if the files are up-to-date and download newest if not) so its not much to code.
The problem is that I don't want the application users to be forced to use additional libraries like .NET (even though I like to code in vb.net or C#). I keep in mind that the .NET framework is installing together with the Windows but still there are plenty people who somehow doesn't have this framework installed, and thats why I'm looking for the programming language that wont require an additional libraries to run the application.
I haven't got much knowledge about programming in C++/Java but I have some experience with the AutoIT, vb.net, C#.
So the question is, what programming language will be the best for this purpose?
This answer is for "what language is available on any version of Windows without additional requirements". There are many other options for "what I can use to create application that can be xcopy deployed on any version of Windows".
JavaScript is probably your best bet - it is supported on most recent versions of Windows (according to Wikipedia article - Windows Script Host JavaScript available for scripting starting with Windows 98). Allows basic operation with files and HTTP communication - maybe enough for simple patching application.
Next would be native Win32 application, but lack of C++ experience will make it hard.
Freepascal, D and Go — to name a few — are much easier to program than C++ and could be told to produce statically-compiled binaries (not dependent on anything but certain system DLLs).
I, personally, would use the latter as it has all the necessary tools (including HTTP and binary I/O) in its standard library and is super-easy to get started with.

Why is it that we can't write a program that will run on both mac and pc?

Programming languages are platform independent, so why is it that we can't write a program that will run on both a PC and a Mac?
I want to develop a software and I'm on a mac, but I want it to run on a PC also, is it possible to develop such a software without having to require the user to download a special program that will make my program compatible with their computer?
The problem with this is that most software is dependent on the OS to handle some tasks. Yes, most programming languages are compatible with many platforms, but the OS provides a lot of support. When software uses the OS, it is sometimes called making a system call. If you want here is some more information.
Theoretically if you write your program in a 'high level language' it should be portable between two operating systems.
Practically however, the differences start from the very beginning - the API of choice, which works on one and does not on another(Such as, Mac's BSD API is incompatible with Win32 API) and boils down to the very last, which is, executable format, linker and loader. Each operating system has its own quirks.
Then comes the difference between the underlying architecture. Previously Macs ran on PowerPC architecture and Motorola architectures, while PCs used Intel. Since Macs have switched to Intel, there have been attempts at making cross platform executables inside Apple. Most attempts have failed.
There is however a way around your problem. You can use a very high level language such as Python to code and then distribute your python code to your PC friends.(But remember remember, you need a Python interpreter in your PC friends' computers for your program to run). I have successfully ported Python programs from Mac to PC with 0 code changes, and sometimes requiring only 2-4% code changes.
Simple answer: because language per se is not enough to make an application cross-platform. Also the framework it uses must be cross-platform too, frameworks are required for everything: handling data, displaying things, communicate with the hardware, multi threading, etc
This can usually be done:
by choosing a complete solution like Java, which will actually run on both platforms seamlessly and even with the same binary
by using C/C++ and cross platform libraries so that the same program can be compiled for both platforms (keep in mind that you can't distribute the real same binary, you need to compile two in any case)
by writing the logic of your program just using standard libraries and a standard language and then attach whatever you need for a specific platform just to build two different libraries. Of course you will have to wrap as much as you need so that the cross-platform part of your program doesn't know it
Mind that developing cross-platform applications which are not trivial examples like a game (for which there are plenty of cross-platform APIs) without using a complete solution like Java is not an easy task at all. Especially because most of the GUI you can build are strictly platform specific and relies on their own frameworks.
If you want an application to run "anywhere" your best option is a JIT type language which means that it compiles as it runs (Just In Time) for the platform that it's on. Really the language that stands out in my mind is Java (there's others and personally I don't like java). However, it's not quite that simple. For example a Window on a Mac computer has pieces and functions that a Window on a PC doesn't have and vice versa. And other operating systems don't even have windows or anything equivilant yet still run Java like Android or iOS for example or countless Linux Distros. And that's just a very basic example it gets MUCH MUCH harrier. Really the best way to build an application that can be used by anyone on just about any device is going web based.
The lesson is that if it was that simple a lot of people wouldn't have jobs and it never will be that simple, things will always progress and change and not everyone is going to want to do the same thing with their OS as someone else. There's a million ways to skin a cat and there's many more ways to implement something in an OS.
Yes, it is possible. But it is quite tricky. You need to:
Use a cross platform language (this is the easy part, many languages run on different plaftforms)
Avoid using any platform-specific features (usually not too hard, but needs testing)
Ensure you have cross platform libraries for all your dependencies (hard!)
Because of the library issue in particular, there are very few options that work across platforms. Your best options are probably:
A JVM language (like Java, Scala or Clojure) - because the JVM abstracts away from platform specific features, pure Java applications and libraries will run on any platform. Java probably has the best ecosystem of cross platform libraries and tools as a result.
JavaScript - quite a good option if you don't mind running in a browser. There are lots of quirks to deal with, but JavaScript is one of the best cross-platform options because of it's ubiquity.

Is there a Linux equivalent of Windows' "resource files"?

I have a C library, which I build as a shared object for Linux and a DLL for Windows with MinGW32. The API depends on a couple of data files (statistical models) which I'd really like to roll in with the SO/DLL so that deployment is just one file.
It looks like I can achieve this for Windows with a "resource file" compiled with windres, but then I've got to write a bunch of resource-handling code for Windows, and I'm still stuck with the files on Linux.
Is there a way to achieve the same functionality on Linux?
Even better, is there a portable solution?
It's actually quite simple on Linux and other ELF systems: http://www.linuxjournal.com/content/embedding-file-executable-aka-hello-world-version-5967
OS X has bundles, so you just build your library as a framework and put the file in the bundle.
Two potential solutions:
Phong Vo's sfio library, which is part of the AT&T Advanced Software Technology toolset, is a wonderful replacement for C stdio.h, and it will allow you to open either files or memory blocks using a single API. So you can easily convert your existing files to C initialized data to include in your DLL or SO file.
This is a good cross-platform solution, but the penalty is that the learning curve to get started is pretty high. They don't make it easy to figure out how stuff works or to take one part of their toolset and split it out for use independent of the other parts. But the good news is that if you want to adopt their U/Win system for running Unix codes on windows (all part of the same toolset), you can create DLLs and SOs using the same system.
For this kind of problem I often fall back on Lua; I can stored Lua data either in external files or within C as initialized data. This is great for distributing everything in one .so file; I do this for my students.
Again the downside is that you have to master and incorporate a new technology.
In my own work I use Lua over the AT&T stuff for these reasons:
Lua has a much smaller footprint and is designed to play well with others; with AST you really have do adopt their way of doing things.
The learning curve with Lua is much less steep; you can be productive very quickly.
Lua is dead easy to install and it's easy to get information about it. AST has its own quirky installation process shared by nobody else in the world; it's often hard to make the installation work; and it's harder to get information about it.
Using Lua has a lot of other payoffs, so the effort spent learning Lua and learning how to incorporate Lua into C codes is easy to amortize over multiple projects.

Resources