In message <[EMAIL PROTECTED]>, Chris Zakelj writes: >That is, how >does one figure out what needs to be changed in order to make OpenNTPD >work on Linux?
If you know what is available on Linux and what is used on the code, you can do this manually, but usually it involves trying to compile it on the new platform and seeing what breaks. This works most of the time but can introduce subtle bugs. For example, the preferred way of dropping root privileges used to be setuid(2) - I assume it still is. But what if setuid() on the new/target platform doesn't drop root privs permanently, but instead they can be recovered via a setreuid() or equivalent? Then you have a potential security problem. This is unfortunate, but happens a lot with certain domains like cryptography... I think Bruce Schneier said something like "weak crypto looks like strong crypto". Your application may work, but be weak/broken in some subtle way. You won't know there's a problem until someone brings it to your attention if you use this method for porting code. Also, if two functions have the same "signature" (name and type of args and return value), it will compile, but unless they have the same semantics, you will have problems. Standards help here by specifying the signature and often the implementation semantics. Some programming languages have something called "interfaces" which embody some semantics (e.g., "this is a singly-linked-list class") without tying you down to an implementation. An interface is like a contractual agreement between the caller and callee. Inheritance is like an interface plus a "default" implementation, and is where most of your code re-use happens. >Is it generally easier to move a program from $some_bsd >to $some_other_os, or from $some_other_os to $some_bsd? It's usually easier to move to a platform that is well documented and with which you are familiar (note that the former assists in the latter). >How would you >even begin to port something like OpenSSH to a non-Unix system like >Windows? MS-Windows has, if I understand correctly, a POSIX API. POSIX was supposed to be a common API for Unices, and enough momentum was gathered that MS-Win added support to it in their NT line so they could claim POSIX compatibility. So if you use things in the POSIX way, and don't have non-POSIX constructs, it should theoretically be easy. In reality I heard it's a bit more difficult. In practice, I think MS-Windows's POSIX emulation merely maps the POSIX stuff onto the native Win32 calls and so there may be performance issues. Also IIUC, you cannot do things like make your application dock in the system tray when using POSIX API. I heard it is either Win32 or POSIX, but not both. However, this is second-hand information and from a while back, as well. >Does the chosen language (C, C++, Java, etc) make a difference >in difficulty? Absolutely. In general, the higher level the language, the easier porting is. It is possible to write very portably in C, but this is a learned skill and not usually covered in introductory texts. It requires knowledge above and beyond just being able to program in C. It usually requires implementing an API (of sorts) on top of the language; for example, you use "u_int32_t" instead of "unsigned int", since the language doesn't specify that "int"s are supposed to be 32 bits. Then you need to create that type if it doesn't exist on the target platform. C leaves a lot up to be implementation-defined. It is said that "C combines the power of assembly language with the convenience, ease of use and portability of assembly language". IMHO C is a great language for low-level system programming, and the frameworks erected on it (/usr/include, autoconf), can, when used properly, give you a lot of portability. However, there are a lot of "gotchas" in it and for ordinary user-level "application" programming, it is probably best avoided in preference to something more modern and higher-level (like python or PERL). Incidentally, I don't know of many recent attempts to make low-level languages that are an improvement upon C. Maybe I just don't pay much attention to them. For a good laugh, go read the "C Infrequently Asked Questions": http://www.plethora.net/~seebs/faqs/c-iaq.html If you don't "get it", here's a spoiler: The answers are often correct, but not for the reasons specified. Anyway, the same thing applies with APIs. In general, the higher level the API, the more portable it will be. In fact, portability is generally the point of having APIs. Note that when you work at a high level, you may not have access to certain facilities that are present at lower layers. For example, to my understanding java does not have anything resembling a setuid(2) call. This is because it is very hard to make an abstraction (API) that deals with user identities that is also platform-independent. Trying to include one in java would probably have meant that java programs using it would only work on Unix-like platforms, something that Sun studiously avoided ("write once, run anywhere"). So portability has its costs, not only in efficiency, but also in potency. To be portable, you often have to give up some functionality. IIRC, it used to be the case that the GNU coding standards* had a ton of information about portability. It appears that most of that has been removed. For example, I recall them mentioning that Dynix used a four-byte magic number, so that portable scripts should begin with "#! /" and not "#!/". [*] http://www.gnu.org/prep/standards/html_node/System-Portability.html Note that portability comes in several flavors. OS facilities, processor word size, endian-ness and "The NUXI problem", etc. etc. I bet that the GNU autoconf manual has tons of great information about portability; here is the link (note: no browsable HTML versions): http://www.gnu.org/software/autoconf/manual/index.html Another good source is the comp.lang.c FAQ, especially this section: http://www.eskimo.com/~scs/C-faq/s19.html An amusing portability anecdote is referred to here: http://www.clueless.com/jargon3.0.0/elevator_controller.html Well, my espresso buzz is wearing out. -- VaX#n8
