Bottom line is that except for apps that use native GUI code* or apps that perform system management functions**, _IF_ the original programmer takes due care to use only standards compliant interfaces and widely available dependencies as much as possible, and to use build mechanisms(s) that can choose between alternative platform dependent code when that's NOT possible (and tries to isolate and encapsulate that as possible), then the application can be quite portable, building on all platforms for which the support is included and dependencies are satisfied, and taking no more than the necessary amount of effort to add support for other platforms that do (or can) support the needed standards. So you can write something that's POSIX+X11 (and layered libraries) only, and IF the native environment implements the needed standards and has the needed extra goodies, it will probably work on anything from a Raspberry Pi to a mainframe or supercomputer.
But there are other gotchas to doing it right. Word size, byte order, version of standards supported (or of OS-dependent features available), etc; all of which can be overcome by careful aware coding, but are easy enough to miss. There is a significant level of discipline and skill required to make a large program (esp. one with GUI or system management aspects) as portable as possible. There are tools to help, but it works best if they were used from the beginning; retrofitting them and good design may indeed involve a lot of rewriting. Writers of apps for multiple versions/distros of Linux, or to a lesser degree the BSDs already have to deal with SOME of that because those OSs themselves have been ported to multiple CPU architectures, etc; and have multiple options for "native" GUI (different toolkits layered on top of X11, or even Wayland rather than X11 as the lower layer of graphics, although X11 can be implemented on top of Wayland for compatibility). So to build on more than one particular distro and architecture, code for those OSs already has to take into account CPU architecture differences, dependency availability (which might be as little as DOCUMENTING what the prerequisites are and how to find them), etc, whereas strictly native code for Windows or macOS mostly just deals with version compatibility issues (although even Windows and macOS have at various times in their histories run on different CPU architectures etc, so code for them should also take that into account). Programmers who have mostly not had to worry about portability issues should perhaps study the available standards for platforms they desire to support, and work upward starting with simple programs that deal just with SOME problematic areas, and look at existing examples that do it well. Usually one does NOT want to reinvent one's own build mechanisms from scratch, but pick something that's widely enough supported and good enough to do the job; otherwise additional build-time dependencies (and maintenance of the extra tools!) are required. I never needed to go much beyond the simple phase myself; but it wasn't hard for me because I've always been compulsive about reading the man page for every library or system call while I was coding a call to it; typically even if I'd called that one hundreds of times before, because there might be something like a USUALLY uncommon flag value or error condition that might be more relevant in a particular situation, and need to be used or handled differently. GOOD man pages (Solaris and derivatives are pretty good in this regard) try to mention which features of what they document are standards-compliant, and which are non-standard extensions, helping one to avoid needless use of the latter. Mostly, if you want to blame someone, do NOT blame the OS developers (as long as their documentation is decent) so much as the application developers. Yes, a less common OS will not be as widely supported, but most apps meant to be portable and already supporting some not too similar platforms, should be easily (added code and platform recognition, but not a major rewrite) extensible to a platform not originally supported. *for which Windows, most Unix/Linux except macOS (macOS _can_ run X11, but it's not as nice there as the native GUI), and macOS have very different interfaces and capabilities. ** as I recall, attempts to standardize some minimum portion of system management interfaces pretty much failed, as along with (in some cases) native GUIs, those were major differentiating (and backwards compatibility!) factors that no vendor wanted to compromise on. > On Feb 11, 2021, at 13:13, Alan Coopersmith <[email protected]> > wrote: > > On 2/11/21 8:59 AM, Jason Long via openindiana-discuss wrote: >> Hello, >> If someone wants to porting an application from an operating system to >> another operating system, then he\she must rewrite that program from scratch? > > No - most applications have a large amount of code that's specific to the > application itself which is operating system independent - for instance a > stock market application is going to have code for tracking changes in > stock prices or figuring out gains and losses that doesn't depend on the > OS in use; while a database is going to have things like SQL handling code > that doesn't change between platforms. > > But applications also have a fair amount of code to interact with platform > interfaces to do things like network communications, read & write to disk > or other storage, display output, etc. If they're written in something > like Java or Python that provides it's own platform routines for that, to > hide the underlying OS details, then there may be very little work to port > to a new OS, unless they need functionality not provided by the platform. > > If they're written in something else, without those platform routines, > such as C or C++, then the work may increase and how much depends on > the OS'es you are porting between. Porting from another platform in > the Unix family - Linux, BSD, AIX, etc. - will be much easier than > porting from Windows or MacOS, since a large amount of the OS > interfaces are the same between the Unixes - especially for the subset > defined in the POSIX standard. You can see this in the large amount of > open source software shipping already in OpenIndiana, where the same > source code for things such as vim, emacs, nano, Firefox, perl, python, > etc. is used on OpenIndiana as on BSD & Linux, with just some small > sections of the code which check for the OS and call the OS-specific > interfaces for that. > > -- > -Alan Coopersmith- [email protected] > Oracle Solaris Engineering - https://blogs.oracle.com/alanc > > _______________________________________________ > openindiana-discuss mailing list > [email protected] > https://openindiana.org/mailman/listinfo/openindiana-discuss >
_______________________________________________ openindiana-discuss mailing list [email protected] https://openindiana.org/mailman/listinfo/openindiana-discuss
