Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.mira.net.au!vic.news.telstra.net!act.news.telstra.net!imci3!imci2!news.internetMCI.com!newsfeed.internetmci.com!world1.bawave.com!news2.cais.net!news.cais.net!news.mathworks.com!fu-berlin.de!news.belwue.de!news.uni-stuttgart.de!news.rhrz.uni-bonn.de!saph2.physik.uni-bonn.de!juengst From: juengst@saph1.physik.uni-bonn.de (Henry G. Juengst) Newsgroups: comp.unix.misc,comp.unix.bsd.misc Subject: Re: How to delete files within C programs Date: 10 May 1996 09:38:47 GMT Organization: Institut fuer Strahlen- und Kernphysik Lines: 180 Sender: juengst@saph2.physik.uni-bonn.de (Henry G. Juengst) Distribution: world Message-ID: <4mv2r7$ld3@news.rhrz.uni-bonn.de> 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> <4mu7is$sro@web.nmti.com> Reply-To: juengst@saph1.physik.uni-bonn.de NNTP-Posting-Host: saph1.physik.uni-bonn.de Xref: euryale.cc.adfa.oz.au comp.unix.misc:22613 comp.unix.bsd.misc:986 In article <4mu7is$sro@web.nmti.com>, peter@nmti.com (Peter da Silva) writes: >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. Normally the number of bits is given by the width of the data bus. You can ignore that and redefine it, but you should write it clear. "Drop to 32-bit mode" means nothing (or everything, if one thinks about MSDOS). To extend the address space is no problem for programs based on source code. This is also true VMS and for most VMS application (depends on the author of the source code). The problem was the binary compatibility. This also a problem for unix. Anyway, you impute that 32-bit address space (in fact 31 for the applications) is a problem. 31-bit address space means 2 Gigabyte memory. If it is a problem for you, you should discuss that in comp.os.vms or alt.stupidity. > >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? Look at the design of the Alpha processor registers and compare it with the design of the VAX registers. You should see that the Alpha processor was not really designed for VMS (forget any arguments from marketing people). If you can not see that, you can discuss that in comp.os.vms. > >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. 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. > >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. I am not a Sun user, so it is possible that I missed something. Sorry. > >> 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. > >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. > >> 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. Sure, you can find examples like this one. You can also run Apple ][ binaries on a PC with an emulator. But you should not ignore the real problems between the unixes. There are too many different unixes which are not compatible at all. > >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* "UNIX runs on pure 16 bit systems (64K code space, what people call "8 bit" systems today)" >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). Endianness is also no problem. This does not depend on the operation system. > >-- >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 The start of this discussion was that I didn't agree that using unlink is not simple for beginners, because the name 'unlink' is meaningless for a beginner and 'remove' is unclear (remove what?). Nice examples for the design of unix. Please, discuss your experiences with VMS in comp.os.vms. Be happy with the unix compatibility. :-))) Henry -- juengst@saph1.physik.uni-bonn.de [131.220.161.1] (Internet) omni:.de.uni-bonn.physik.saph1::juengst (DECnet/OSI, phase V) saph1::juengst [26.358] (DECnet, phase IV) Any opinions in this mail are my own.