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