From owner-freebsd-current Sun May 31 09:30:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA10817 for freebsd-current-outgoing; Sun, 31 May 1998 09:30:16 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from shrimp.dataplex.net (shrimp.dataplex.net [208.2.87.3]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA10812 for ; Sun, 31 May 1998 09:30:11 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from [208.2.87.10] (user10.dataplex.net [208.2.87.10]) by shrimp.dataplex.net (8.8.8/8.8.5) with ESMTP id LAA02105; Sun, 31 May 1998 11:30:05 -0500 (CDT) Date: Sun, 31 May 1998 11:30:05 -0500 (CDT) X-Sender: rkw@mail.dataplex.net Message-Id: In-Reply-To: <199805311003.DAA20637@usr04.primenet.com> References: from "Richard Wackerbarth" at May 30, 98 04:15:40 pm Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" To: Terry Lambert From: Richard Wackerbarth Subject: Re: Fix for undefined "__error" and discussion of shared object Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG At 10:02 AM -0000 5/31/98, Terry Lambert wrote: >> As much as we might like to think otherwise, assumptions about the structure >> of the underlying OS and "hardcoded" into the source of the program. :-( > >The point is to make a port for FreeBSD 3.x work on FreeBSD 235.x, not >the reverse. In other words, "compile once, run anywhere". > >The binary compatability from FreeBSD 3.x to FreeBSD 235.x is a >problem for the XANDF processor during the install. And for it to be possible, there must be a "compatability library" of some kind. This, in turn means that you must emulate the archaic version of FreeBSD in its totality. What are you going to do when a concept entirely disappears? As an example, consider the impact of the eventual integration of devfs. By the time we get to FreeBSD 235.x, do you really expect to be able to support today's hack dejuor which relies on the present major/minor device numbers? I think not. As systems evolve, you are eventually forced to abandon the albatroses of legacy compatability. An even harder problem is related to timing assumptions that are hardcoded into programs. Many programs "work" only because they assume things about the hardware and/or compilers. Remember programs that "poked" an I/O register and controlled the timing with delay loops? They would never work today if a "decent" compiler were to get hold of them and optimize away the code that simply created delays. Where they were written, the languages never had the concept of optimization. As a result, the programmers never put the necessary hooks into the program to guide the compiler about which factors are important. All that I am saying is that I do not believe that it is possible to both maintain infinity compatability and allow for future innovation. At some point, the two concepts reach a point of unresolvable conflict. After that point, one of then will no longer apply. Richard Wackerbarth To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message