From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 18978 invoked from network); 23 Feb 2023 16:49:46 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 23 Feb 2023 16:49:46 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 7E01E42278; Fri, 24 Feb 2023 02:49:40 +1000 (AEST) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by minnie.tuhs.org (Postfix) with ESMTPS id B137A42275 for ; Fri, 24 Feb 2023 02:49:31 +1000 (AEST) Received: by mail-pj1-x102e.google.com with SMTP id qa18-20020a17090b4fd200b0023750b675f5so5570912pjb.3 for ; Thu, 23 Feb 2023 08:49:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=lwzwje3BsAc0Edv9DFpusEg+vmjmbNo8jiFql+SL1NM=; b=RTSrcZxiQM5nSbtbS954Z5D+Z0c2yAfh6+Lb5tqKyWlikWC63ZzUF5lWyfiR3rexBz Fp8NXoFuMHMt0n3UetDcbVrm8dAqMdRtkjKpynG0ze/Csi/e5zqQjhwu597jrQFRlsgp Gpj6+7zdr3KUPkINU8BXVfvNrDL7eV9tWuDWZFzmRgclcG/eWW6jPsw5fiJpT+FbZoTy Hk6TC43l2q/pFVMgOyXIfEtwHQqGWrzmwZjI7p95dCbtUlnBSVNYMM2B/SRfXi0fBVGX vUakjB5k1hH5aE5TCVfk6A7KO6c49+wfSSDvvN/SpGihMVmhTKbP/Iuw6OpvZB3BlEEY SFnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=lwzwje3BsAc0Edv9DFpusEg+vmjmbNo8jiFql+SL1NM=; b=xSyMk4RSV9JwleV44pqBSbvyz6xtvfmVEPvADGAs2PAKOGn63hQeRwIWrtrfCLycH2 sQP5SWgICpeE9xMLzQ9ic7DvRUCGOST2ucpQxek72Mtn0is4Y4qEDG+qFbBrgz1Db19x bt/N/Hy1XPQsEVR+vuNLaBxPNWNpLh8C4Fykj/0vD/irGARSRu3vk8aUEDOKPsX5+ulz t6zi9mvegK7+FP439TeVMBtzcsC95FM/Pkj9AflDWDOUjgMzFIkraquV1IgNjWBH/c7T jW8l33zWsECqHGvB5RLHFDrxxp1BcD0AZkThNyZH/ZdVTzs/PVv8PuFt1WWGWJyrT6jr /iRw== X-Gm-Message-State: AO0yUKXOyGUr8dwCr+zKkhz1fOkq0DqT982fp3A1j23PhtUWkxab+daT /kuXp6/8u/RrU4gUhV7LPD3fYWOC+LXqhFjMlaoULiSy X-Google-Smtp-Source: AK7set+azhrrBqaTQHUlR0behfsoGnF9CRm7N/9VuuCUF4W72A0zqGAulO11h9t++hA831am7bC4rqed8xTtL99IWXc= X-Received: by 2002:a17:902:e8c3:b0:19a:87dd:9214 with SMTP id v3-20020a170902e8c300b0019a87dd9214mr1873521plg.7.1677170970780; Thu, 23 Feb 2023 08:49:30 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a05:6a11:3dc7:b0:412:8124:c58f with HTTP; Thu, 23 Feb 2023 08:49:29 -0800 (PST) In-Reply-To: References: From: Paul Winalski Date: Thu, 23 Feb 2023 11:49:29 -0500 Message-ID: To: Clem Cole Content-Type: text/plain; charset="UTF-8" Message-ID-Hash: 7SMFDDV242WG6O6DOLHPUQQA5TLNSCLM X-Message-ID-Hash: 7SMFDDV242WG6O6DOLHPUQQA5TLNSCLM X-MailFrom: paul.winalski@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: segaloco , The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Origins of the SGS (System Generation Software) and COFF (Common Object File Format) List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: On 2/22/23, Clem Cole wrote: >> >> - The System V manual has both this ar(1) version as well as the new >> COFF-supporting version. >> >> Why would ar(1) care? >> >> - Not sure if this implies the VAX ar format was expanded to support >> the COFF stuff for a little while until they decided on a new one or >> what. I can't think of any reason why ar(1) would care about the file format or internal contents of any of the modules it archives. ar(1) is a general archiving tool and can archive anything. It happens that the designers of ld(1) decided to use ar(1) to provide searchable object file libraries. ranlib(1) is a different matter. In order to index global symbols it has to understand the object file format(s) of the modules it is indexing. ranlib(1) most certainly would have to be taught to understand COFF. But not ar(1). >> and development software stuff until ELF comes along some time later. >> > Yep - never quite understood what the push for ELF was over COFF after all > the effort to drive COFF down people's throat. Note Microsoft "embraced > and extended" COFF as their format -- originally because of Xenix I > believe. > Someone like Paul W may have some insights on this and that was before > the 3B20. a.out was, as object file formats go, a throwback to the stone age from the get-go. Even the most primitive of IBM's link editors for System/360 supported arbitrary naming of object file sections and the ability for the programmer to arrange them in whatever order they wished. a.out's restriction to three sections (.text, .data, .bss) did manage to get the job done, and even (with ZMAGIC) could support demand-paged virtual memory, but only just. It became pretty clear in the 1980s that an object file format more powerful and flexible than a.out was needed. CMU developed their own object file format (MACH-O) for their MACH microkernel-based OS. It had up to 8 object file sections, and the section properties (e.g., read vs. read/wrkte; executable vs. data) were not tied to the section name as in a.out. A big step forward, although still primitive compared to the object formats of VAX/VMS and the IBM S/370 OSes. Apple MacOS X still uses MACH-O for object files and executables. Whatever its origins, what we now know as COFF (Common Object File Format) is, as its name implies, intended to be OS- and machine-independent. It still has a relatively small number of sections, albeit more than MACH-O. When Microsoft developed Windows NT, they needed to replace their own MZ executable format with something that could support shareable images and they decided to go with COFF for both object files and for executables. In typical Microsoft embrace-and-extend fashion, their Portable Executable and Common Object File Format (PECOFF) is a heavily modified version of COFF with lots of MS-specific extensions. When DEC's GEM back end was chosen as the optimizer and code generator for Microsoft C/C++ on Windows NT for the DEC Alpha chip, I had to add PECOFF support to GEM's existing COFF support (which was used by DEC's commercially sold compilers for Ultrix). My original idea was to put the PECOFF support under conditional compilation (#ifdef PECOFF), but the two formats were sufficiently different that I abandoned that Idea, cloned the existing COFF module, and then modified that to create a separate PECOFF module. ELF is far more flexible than either COFF, PECOFF, or MACH-O. Those three make a distinction between sections (the bits that eventually end up in memory) and the metadata pieces of an object file or executable (program headers, symbol table, debug information, etc.). In ELF, everything is a section, including the symbol table and the tables that direct the program loader in mapping shareable images into a process's memory. ELF was originally limited to 64K sections (section numbers were unsigned 16-bit), but there is now a scheme for 32-bit section numbers. The essentially unlimited number of sections is a big boon to languages such as C++, where grouped sections with a name-decoration convention provide a convenient way to support sharing of class definitions without requiring language-specific tweaks to the software development toolset. Contrast this with the Ada implementations I'm aware of, which have their own software development library systems layered on top of the conventional compiler/linker/archiver to insure that program modules are compiled and linked in the correct order. I don't know what the timeline for the invention of COFF was. It was already called COFF and in widespread use by the time I encountered it when we added Ultrix support to GEM. I think MACH-O predated COFF; it's certainly more primitive than COFF. MACH-O was probably early to mid-1980s. OS kernel bloat was a recognized problem at the time and microkernel-based OSes were all the rage. At DEC, Dave Cutler wrote a microkernel-based OS called VAXeln to replace VAX/VMS for real-time applications. A lot of concepts from VAXeln found their way into Windows NT when Cutler left DEC for Microsoft. -Paul W.