*BSD News Article 68192


Return to BSD News archive

Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!news.vbc.net!samba.rahul.net!rahul.net!a2i!bug.rahul.net!rahul.net!a2i!genmagic!sgigate.sgi.com!swrinde!newsfeed.internetmci.com!uuneo.neosoft.com!web.nmti.com!peter
From: peter@nmti.com (Peter da Silva)
Newsgroups: comp.unix.misc,comp.unix.bsd.misc
Subject: Re: How to delete files within C programs
Date: 10 May 1996 16:58:33 GMT
Organization: Network/development platform support, NMTI
Lines: 113
Message-ID: <4mvsjp$nhn@web.nmti.com>
References: <Oum-El-Kheir.Benkahla-3004961724540001@mac-ugm-3.imag.fr> <4mr76q$t8i@news.rhrz.uni-bonn.de> <4mu7is$sro@web.nmti.com> <4mv2r7$ld3@news.rhrz.uni-bonn.de>
NNTP-Posting-Host: sonic.nmti.com
Xref: euryale.cc.adfa.oz.au comp.unix.misc:22621 comp.unix.bsd.misc:992

In article <4mv2r7$ld3@news.rhrz.uni-bonn.de>,
Henry G. Juengst <juengst@saph1.physik.uni-bonn.de> wrote:
> Normally the number of bits is given by the width of the data bus.

For an operating system, which is a piece of software, the number of
bits is given by the programming model. Since there are fast and
efficient algorithms for extended length integer arithmetic, the
only important restriction for an operating system is the address
space, and how the address space is managed.

It's not simply that VMS requires a 32 bit address space. If that was
the only restriction it would have been no problem for DEC to port
it to their MIPS-based boxes and take an immediate performance boost
in the mid-late '80s when the VAX started seriously lagging. Instead,
they had to produce their own RISC chip with a memory management
model clearly based on the features of the VAX MMU that VMS depended
on. (MMU, Henry. Not processor registers. The Alpha MMU is very nice,
by the way. I like it. But it's sure got VMS requirements in it)

(lots of stuff about portability of application code which is pretty
much irrelevant to the issue of O/S portability and the level of the
underlying hardware that's exposed by the API, and which I've already
spent three messages responding to. Sorry, but if that's all you have
to say about it I'll be toddling off now...)

> I do not see any technical reason why VMS could not run on a MIPS.
> Or any RISC processor. Or Intel (don't beat me:-) processors. There are
> just marketing reasons.

Oh! Cute! Now you're talking marketing reasons. You blew me off when I did
that. Want to go back and eat those words, now?

> >> Many of them are fighting with the great unix source code compatibility,
> >> which is in reality only a dream.

> >Only if you wrote bad code to begin with. I've got code that was written on
> >Xenix-286, and runs unchanged on the Alpha, leaping right over the 32-bit
> >generation... from 16- to 64- bit. No porting. Just a recompile.

> Recompilation is possible with any operation system. The compiler does
> the porting for you, if your source code allows it.

Right. Well written source code is portable. Badly written source code...
well... I've run into plenty of code that woudn't port from one compiler
to another on the same O/S. C code, Fortran code, Modula code, PL/I code.

> >On VMS you get "code portability" by emulating the old environment, warts
> >and all, and cripping your 64-bit CPU with a 32-bit O/S.

> Stupid statement without any argument and disproved by running programs
> without any change.

How does running programs on a 32-bit O/S on a 64-bit platform prove that
you don't have to use a 32-bit O/S to run 32-bit VMS programs on a 64-bit
platform? *blink*

> But you should not ignore the real
> problems between the unixes. There are too many different unixes
> which are not compatible at all.

It's the code, not the O/S.

My Xenix code was written on a pure-AT&T System III based system, and run
on System III and System V for many years (System V, 16-bit, little-endian).
I transferred it to SunOS (early BSD, 32-bit, big-endian) and Digtal UNIX
(recent BSD, 64-bit, little-endian). That pretty much covers the extremes of
the "UNIX envelope", Henry. There's damn few variances in the UNIX family
that don't fall under one or the other of those alternatives.

> >No, I deliberately *didn't* confound them. The memory model is the *biggest*

> "UNIX runs on pure 16 bit systems (64K code space, what people
> call "8 bit" systems today)"

Right. 16-bit systems. 64K code space. And I noted, for clarification, that
people call that 8-bit these days, even though it isn't, to make sure you
understood that I *wasn't* claiming UNIX ran on *real* 8-bit CPUs like the
6502.

> >porting obstacle there is, followed by endianness. NT does the same thing...
> >buying compatibility now in exchange for porting nightmares tomorrow. They
> >both make the world look like, well, a VAX. The problems UNIX programmers
> >have fought with and the good ones have solved are still ahead for you.

> I do not see any reason to make a program memory dependent (ignoring MS
> world).

Neither do I, but in my experience that's one of the biggest porting obstacles
in real-world all-the-world's-a-VAX code.

> Endianness is also no problem.

That's why people write code with ifdefs for endianness all over the place.

> The start of this discussion was that ...

The start of this discussion was that you decided to take some random
message and start bashing UNIX in comp.unix. If you don't want to get as
good as you deal out, then don't come in and stir up trouble.

As for DEC, it's intuitively obvious that you write to a serial port
with QIOW$? That string manipulation is in a library called "edit"?
Or let's look at VMS. How to you remove a print job again? I can't
keep track of whether it's DELETE QUEUE/JOB or DELETE /QUEUE or DELETE
JOB. It wouldn't surprise me to find it's now SET JOB/NOPRINT. Half the
commands in VMS are hidden under SET somewhere, including their remote
terminal program (SET HOST).

-- 
Peter da Silva    (NIC: PJD2)      `-_-'             1601 Industrial Boulevard
Bailey Network Management           'U`             Sugar Land, TX  77487-5013
+1 713 274 5180         "Har du kramat din varg idag?"                     USA
Bailey pays for my technical expertise.        My opinions probably scare them