Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.mel.connect.com.au!news.mira.net.au!inquo!in-news.erinet.com!imci5!pull-feed.internetmci.com!news.internetMCI.com!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 01:53:32 GMT Organization: Network/development platform support, NMTI Lines: 109 Message-ID: <4mu7is$sro@web.nmti.com> References: <Oum-El-Kheir.Benkahla-3004961724540001@mac-ugm-3.imag.fr> <4mq4o3$qkh@news.rhrz.uni-bonn.de> <4mqr1s$5ou@web.nmti.com> <4mr76q$t8i@news.rhrz.uni-bonn.de> NNTP-Posting-Host: sonic.nmti.com Xref: euryale.cc.adfa.oz.au comp.unix.misc:22601 comp.unix.bsd.misc:973 So this is the article you flamed me for ignoring. I can't see why... there's nothing in there that changes my comments in the slightest. In article <4mr76q$t8i@news.rhrz.uni-bonn.de>, Henry G. Juengst <juengst@saph1.physik.uni-bonn.de> wrote: > In article <4mqr1s$5ou@web.nmti.com>, peter@nmti.com (Peter da Silva) writes: > >In article <4mq4o3$qkh@news.rhrz.uni-bonn.de>, > >Henry G. Juengst <juengst@saph1.physik.uni-bonn.de> wrote: > >> Nice to see that you compare unix with MSDOS. Please, more! :-))) > >OK, let's compare it with VMS, which is several years younger than UNIX, > >and so tied into specific details of the VAX memory management model that > >to run it on an Alpha they have to drop to 32-bit mode... and the Alpha > >was designed with running VMS as one of its goals! > >I undertand they're finally getting VMS to 64 bits. Reminds me of how > >long it took RSX-11 to make use of the split I&D model on the PDP-11, > >after UNIX had been using it for years. > Nonsense. You don't know what you are talking about. And your statements > are not clear. They're quite clear. The VMS memory model was 100% tied to the VAX hardware memory management. Whether you could do 64 bit calculations on the processor is irrelevant. You can do 64 bit calculations on the extended Sparcs under Solaris, but it's still a 32-bit operating system. Here I am talking about memory management, and you start going on about integer calculations. Why? I can only speculate that you know I'm right so you're bringing in irrelevancies. > The Alpha processor has been used as 64-bit processor since its first > days running VMS. 64-bit means calculations with 64 bits. Only the > virtual address space was (OpenVMS 6.x) limited to 32 bits. Which means that, like Solaris (regular Solaris, not the HaL version), it's a 32-bit operating system. > You did not mention that DEC did include a migration tool for VAX (CISC > architecture) binaries to make them running as binaries on the Alpha (RISC > architecture). Additionally they added an assembler for VAX assembler code > running on the Alpha processor. Why should I? The Alpha was *designed* with VMS support as a goal. What does that have to do with the issue of the way VMS' VAX-centered design has so badly hurt DEC's ability to compete, by tying the operating system to the limitations of a dying CPU... the last great CISC? Unlike UNIX, they couldn't just port VMS to RISC... otherwise they would have done it for their MIPS-based boxes. No, they had to design a RISC from thr ground up to get it off the VAX, and the lack of ability to get out from under the fading performance curve of the VAX has cost them customers. They just barely kept us, and we only stayed because we didn't have to stay with VMS. Oh, and they also have a migration tool that lets you translate SunOS binaries to run under OSF/1. So that argument's a wash. > I have used the binary migration tool (VEST) sometimes now and even an old > image from 1989 works. Now, ask DEC's unix users. You will find enough > ultrix users who would like to do this on their new DEC unix Alpha machines. I'm one of DEC's UNIX users. Of course I'm migrating from Sun to Digital UNIX, so I get Freeport Express. > 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. 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. > All those "ports" of applications for > different unixes are speaking for themself. Perhaps you should just try to > start an image which needs an old shared library on your unix chest. We've got customers running our old Xenix-286 binaries on Unixware right now. That's 1984 code, not 1989 code. We can run our old SunOS binaries on Digital UNIX, too... though we prefer to recompile. > Unix magazines are full of "64 bit unix" advertisements now. Why did > it take so long? I've already answered *that*, and that answer stands just as well now as it did when you refused to answer it the first time. > >All other things being equal, a simple high-level O/S design is inherently > >more flexible. UNIX runs on pure 16 bit systems (64K code space, what people > >call "8 bit" systems today) all the way up to the latest 64-bit monsters. > You confound the width of address space with the width of the data bus. No, I deliberately *didn't* confound them. The memory model is the *biggest* 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. -- 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