Date: Fri, 10 Mar 1995 10:18:59 MST From: Warner Losh <imp@boulder.openware.com> To: patriot3!cchou@phi.com (Carol Chou) Cc: oi-users@freefall.cdrom.com Subject: Re: OI on solaris Message-ID: <199503101719.KAA25313@marvin.boulder.openware.com> In-Reply-To: Your message of Fri, 10 Mar 1995 08:32:43 CST
next in thread | raw e-mail | index | archive | help
: Have anyone ported OI applications from SunOS4.1 to Solaris 2.4 (or Solaris 2.3)? I have :-). I've also ported OI to a bunch of different platforms, in addition to all of its demos and the like. : We also use NIH library as our class library. Is it a lot of efforts involved in : porting it? If you have any ideas about it, could you give me an estimate : on how big the effort would be, such as time, code change,..etc? Sun has a tool : call STT which should automatically convert the code to solaris 2. How helpful : it is? STT is marginally useful. When we used it (back in the Solaris pre alpha days), it was C++ stupid. So, if you had a class that had a member function open or ioctl or some other system name, it would whine at you, so you had to take its complaints with a big grain of salt. Your best bet: get a source tree on the Solaris machine, type make and look at the amount of output that it gives you. This will likely give you some idea the scope of the build process. Don't worry, for now, if you don't have an OI library, as the headers will do just fine to find out how big the task is. If this project has never been ported to another system, I'd allow for at least 1 month / 20,000 lines of code, if not more. You might get lucky and not need this large amount of time, but on the other hand, you may have your code riddled with SunOSisms that need to be converted to Solarisisms. If you've ported this to a lot of systems, then it will likely take about 1 wk/200,000 lines (that's about what OI/OB takes for most ports that are basically POSIX.1 systems, give or take for Xisms). NIH, can't tell you on that, since I've not used it. Things OI uses to get its portibility (in a nutshell): 1) Code to the POSIX.1 and ANSI C APIs. Provide them when they aren't in the target environment. (Well, we also use strdup(3) which isn't in either, but most systems have it). 2) Don't use sysent.h, osfcn.h to get your prototypes. Instead use unistd.h. Alas, this isn't a hard and fast rule, as sometimes on Sparc you'll need sysent.h for some things. 3) Use memmove and memcopy as opposed to bcopy. Ditto memset and memcpm. 4) Use strchr and strrchr rather than index and rindex 5) include string.h, not strings.h 6) Try not to use the exotic parts of C++ (templates, exceptions, etc) as many compilers have conflicting implementations for some of these and some don't implement them at all. 7) Don't write code that depends on byte ordering. Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503101719.KAA25313>