Micro$oft Biz'droid Lusers (was: OT email response format)

From: Sean 'Captain Napalm' Conner <spc_at_conman.org>
Date: Sun Apr 21 22:27:52 2002

It was thus said that the Great ajp166 once stated:
>
> > That doesn't make sense. UNIX you state as being easily ported, even
> >though as a kernel it has to hit the hardware pretty hard, yet you state
> >applications as not being portable at all, because of the underlying
> >hardware and processor (which the application shouldn't care about). If
> >anything, I would think the opposite would be true.
>
> You forget I guess. All cpus are from intel. At one time unix was on
> machines of different word size and instruction set. So an app while easily
> ported to a new platform, it was not without some problems. Like each
> version of unix was not always the same as another. Some of those were
> those little things like the apps programmer needed a target machine and OS
> to verify on. So "portable" is not the same as "ported to".

  No, I am aware of other CPU manufacturers than Intel. I've used computers
based upon the Motorola 68k (Amiga with a 68000, a Tandy-6000 with a 68000,
the Sun-3 series based upon 68020s or higher, some HPs), MIPS (SGI
machines), Sparc (Sun-4 series on up), PA-RISC (some other HPs), PowerPC
(IBM machines) and the ubiquitous x86 series (Linux, FreeBSD, OpenBSD,
MS-DOS, Windows, OS/2). All systems I've developed for (used, however, is a
slightly longer list).

  As for using non-8 bit byte based CPUs? Not really; I don't think I've
ever even come across any 9, 12, 18, 24, 36, 60 or 66 bit systems
*anywhere* and I'm one of the few programmers I know that's even *heard* of
such CPUs. Most programmers I suspect are only aware of the x86.

  And yes, there is a difference between ``portable'' and ``ported to.'' I
try to write what is ``portable'' code.

> I didn't say it wasn't possible only that saying the OS is unix meant it was
> not always a slam dunk and that compliation was often required.

  Um ... I thought compilation was *always* required (unless you are using
USCD Pascal, Java or C#).

> > Granted, on the 8-bit systems you often times had to code in Assembly,
> >both for speed and size reasons (and because compilers for such systems
> >weren't good enough) but when you get to UNIX the whole point was to avoid
> >assembly in the first place [1]. Therefore, you are writing in a higher
> >level, more portable language and then it becomes possible to write code
> >that will run across platforms. Heck, I've written a program that has
> >compiled across several different UNIX platforms (SGI, Linux on the x86,
> >Linux on the DEC Alpha, OpenBSD, FreeBSD) without problems [2] and you'll
> >notice that there is at least one 64-bit architecture listed there. The
> >same code was successfully compiled (with one line of code change, plus a
> >few other lines to get the correct header files loaded) under Microsoft
> >Windows. Okay, it may not have been optimum code under Windows, but it
> >still ran with minimum of changes or fuss.
>
> Thanks for the tutorial, I heard it back it 82 also. Experence however
> proved otherwise in practical terms.

  I was talking about my code. Yes, I've had experience where the porting
was painful (two weeks to ``port'' a Unix editor to QNX---God I wanted to
shoot the developer of that program, and another program I had to rewrite
for scratch because the original developer didn't care about programming at
all, and didn't want to support his mess).

> >[2] Okay, one problem---the DEC Alpha port crashed, but it was tracked
> > down to a bug in the C library call memchr().
>
> In the past 1983-1988 that was far more commonplace to have incompatable
> compilers libraries.

  I'm aware of that. I started coding in C in 1990, *after* the ANSI-C
standard was ratified so that did help (and it probably doesn't help much
that I refuse to work with anything written in K&R C)).

  -spc (Have compiler, will program)

[1] Footnote not found. Check original message.
[2] Footnote not found. (A)bort, (R)etry, (F)ail?
Received on Sun Apr 21 2002 - 22:27:52 BST