Date: Tue, 26 Sep 1995 14:15:29 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: terry@lambert.org, kelly@fsl.noaa.gov, gryphon@healer.com, freebsd-hackers@FreeBSD.ORG, freebsd-ports@freebs.org Subject: Re: ports startup scripts Message-ID: <199509262115.OAA08299@phaeton.artisoft.com> In-Reply-To: <21914.812109715@time.cdrom.com> from "Jordan K. Hubbard" at Sep 26, 95 03:01:55 am
next in thread | previous in thread | raw e-mail | index | archive | help
[ ... the UNIX destop "battle" ... ] > You know how I like to compare the UNIX world to the Three Stooges > trying to fix a leaky faucet? Nobody actually works on the faucet > throughout the entire episode - they're too wrapped up in seeing who > can poke the other the most times in the eye. Well, that's how the > UNIX world has looked from an ISV's perspective for a LONG time! Who > do you think *writes* the bloody desktop apps? The ISVs. Do you > think that we at Lotus, for example, were overjoyed at the prospect of > doing entirely separate and laborious ports of NOTES, 1-2-3 and AmiPro > to everthing from SunOS to HP/UX? No, we weren't. We were stuck > doing 6 different platforms, in fact, all of which were majorly > different from one another! It was the polar opposite of fun! And we > were the bloody UNIX *experts* of the company! You can only imagine > how it looked from everyone else's perspective. The occasional VP > would stroll through and see this workgroup filled with literally > several million dollars worth of top end HP, IBM and Sun hardware and > they'd look at this little engineering group full of very highly paid > engineers (we were rare!) and they'd sort of shake their heads and say > "you need ALL this stuff to service a market 1/10th the size of OS/2 > or Windows?" And we'd say "yup! pretty #%&@*! stupid, ain't it!" With respect, the porting time required is proportional to the portability of the code. The overhead is realtive to how clean the code base is in the first place. People have complained about obvious aspects of my coding style on points other than the inane "goto" argument. My coding style evolved from 1984 to the present, supporting compiler and system incompatabilities and bugs in C libraries. The point is, that code written in that style compiled and ran on 142 platforms, 121 of them UNIX systems of one bent or another. Without modification. Probably why our async communications software beat out UUCP (which came with UNIX for *free*) by 2:1 in a UNIX World survey. The point here is that it is possible to code portably without worrying about porting issues by adopting code and software architectural styles that are sensitive *by design* to architectural differences (or compiler vagries, like improper handling of bitfields or comma operators or parenthisis or brace placement or inferior preprocessors, etc.). As a small software house, Century Software was able to go in and "port" to a new "UNIX box" in about a day, including running validation suites on product components and cutting two masters with any minor source changes that were necessary for reintegration into the code base. Let me repeat that: one day. In general, this is because system dependencies were limited to reliably present library routines (like tgetent/tgetstr/tgetnum) or encapsulated in a single module common to system types of that derivation (there were 5 sio.c modules for doing serial I/O on BSD+Xenix, SVR3+SVR4, VMS, DOS, and Macintosh, and 4 for handling terminal I/O). The software in question was a terminal emulation package capable of emulating 12 different base terminal types on any UNIX terminal, such that you could hook into a remote system expecting, for instance, a block mode IBM 3101 with your Wyse-50 attached to your UNIX box. It was enough to let you use VMS EDT/LSE/TPU on a Televideo 910. The problems faced by an application program, whose only real system dependency issue is the ability to interact with a tty, are really nothing compared to what was, in effect, system level software (the SVR4 code had to have the capability of pushing and popping the cannonical processing module of the streams stack, and the issues in allocating and deallocating modems, patial open hacks, etc., are really, really complex). Now I agree that Lotus was probably architecturally handicapped because of its DOS origins. Wordperfect was similarly handicapped. The reality of the situation is that these handicaps are entrenched only if it's not possible to roll portability changes back into the mainline code tree. And that problem's political, not technical. But it doesn't take a genius to write portable software. The support issues really boil down to release synchronization, and little else, once you have the portability concerns addressed. That's why I always harp on portability to old compilers: a small shop must borrow machines. > Bitter? Oh, not us. We wanted MORE versions of UNIX. Binary > compatibility? Heck no! Crazy ideas like that only let us stay home > with our families on the weekends! Needless to say, this was not an > unusual attitude among the other ISVs who provided you with everything > from Framemaker to Adobe Photoshop and THAT is why UNIX lost, yes > lost, the desktop market. UNIX was a highly dysfunctional family that > fought so long and hard that the children were finally taken away by > social services. Little help, when social services idea of a functional family unit is 1.6 kids, so they start oiling up their chainsaws. Code developed with restraint on Altos Xenix would run on SCO Xenix, SCO UNIX, ISC UNIX, Cubix and Microport. Code developed with restraint on a DG Aviion would run on DG, ICO, Sanyo, and other 88'open boxes. Code developed with restrain on an NCR Tower XP would run on a Tower 16, a Tower 32, a Sperry 5040, 5050, and 5060 (OEM NCR hardware with a Sperry (later Unisys) UNIX port. Binary compatability isn't nearly as big an issue as other ISV's were complaining about. And it's less of one today, now that Intel is the common hardware platform. And Century Software's products aren't the only ones who followed this model successfully. BBX, a "Business Basic" did the same thing. So did a lot of other vendors. So did Lone Star Software. I have no patience for ISV's whose complaints boil down to a political inability to achieve the correct technical soloution. If they had their way, the common ABI would be Windows .EXE programs and they would never have to port anything anywhere. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509262115.OAA08299>