Results 1 to 6 of 6
Enjoy an ad free experience by logging in. Not a member yet? Register.
- Join Date
- Oct 2008
Porting software amongst operating systems
drivers are for hardware, so that has nothing to do with porting an application between OS
depending on the language you may or may not have to do anything to port it
ansi c/c++ should compile on any compilers long as you don't do anything outside of STL
java is by nature cross platform, as is python and many other scripting languages
- Join Date
- Apr 2009
- I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
As coopstah13 said, it depends. Interpreted languages such as Java, Python, .NET may only need the correct support libraries and packages, if they are available on the other OS. Shell scripts may or may not require changes, depending upon a number of issues. Compiled binary executables and libraries will at the very least need to be recompiled and relinked to work. However, in 30+ years of cross-platform development and many, many system porting processes there is one area that never changes - testing. The more, the better, and the more reliable the results will be.
So, what is the basis of your question? Do you have a major application that needs to be ported to another OS? Is it personal, or a company application?Sometimes, real fast is almost as good as real time.
Just remember, Semper Gumbi - always be flexible!
It is a matter of libraries.
Many high-level languages are system-independent, as are their libraries. For instance, if you have a script in Perl, it will generally run on any system that can run Perl (and this includes Linux, Mac OS X, and Windows) with no modification at all. It is possible that some module used by the Perl process was written in C and is not system-independent, but this usually doesn't happen.
So most of these higher-level languages are system-independent.
Then you have Java, for instance. Java code compiles to Java bytecode, which is not true machine code. Java bytecode runs on a theoretical machine called the Java virtual machine, and implementations of the Java virtual machine exist for most modern operating systems (including, again, Linux, Mac OS X, and Windows). Therefore, a Java program will run on any of these systems without modification. Again, there are techniques to write Java code that uses non-Java code, so there are cases where Java is not cross-platform, but it usually is system-independent.
Finally, we have languages like C and C++. Programs in these languages compile directly to machine code, which differs between different types of processors and different operating systems. Therefore, a program written in C or C++ must be recompiled depending on what platform it will run on.
If you only use the standard library for C and C++, the program is supposed to be able to run on any system. However, most people do not only use the standard library (and this includes any graphics or media), which means that most C programs do need to be changed in order to run on a different system.
If you have a specific example in mind, that would be helpful. Otherwise, I hope that this helps.
Last edited by Cabhan; 02-07-2010 at 05:31 PM.
- Join Date
- Oct 2008
Thanks everyone. There was no specific need. The subject came up on a cycling forum, another member's software for his bike computer, aka odometer, is supposed to not work with windows 7 (his OS). I suggested that he contact the manufacturer and suggest they consider an open source license, and that the software could then be ported to other OSs much more easily. Another member wrote that this would not be easy. So I thought I'd find out what is involved. Again, thanks to all posters, Kurt
in that case, it would likely not happen, companies wouldnt want to open up their code, and often they will use external libraries they liscense form otehr companies, so releasing their code under gpl or such would require either releasing an incomplete program or the external library owners would have to agree to release their code in the same way. those is one argument that nvidia uses to explain why they cant open source their drivers.nVidia G-Force 6600GT (bfg) pci-e: amd 64 2000+ (939): 1024 corsair ram: 2X 80gb seagate harddisk SATA: plextor cd/dvd-read/write cdrom SATA