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=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 32620 invoked from network); 23 Feb 2023 18:38:52 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 23 Feb 2023 18:38:52 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 0152142280; Fri, 24 Feb 2023 04:38:47 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuhs.org; s=dkim; t=1677177527; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=NZjtZpPSuydXV5y4Y7pKTea8yXDW82B+oCbRdqTG30A=; b=2Tv48GhIh4qaxm5qEfJSHHeZZtVTR9vwaiwJMZwKycxT15c8lGu/TkVHOVNIgdUCVkXrqv C2wgC/djP4Izdln44RkbAA24aOekCCALZDka2wExycyqlwX70oVYuQsN49PvrjZcrFP62s q/vLOP18orMjfY84+LLf4Vaz1IgA1tU= Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch [185.70.40.140]) by minnie.tuhs.org (Postfix) with ESMTPS id 554DD4227C for ; Fri, 24 Feb 2023 04:38:41 +1000 (AEST) Date: Thu, 23 Feb 2023 18:38:25 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1677177518; x=1677436718; bh=NZjtZpPSuydXV5y4Y7pKTea8yXDW82B+oCbRdqTG30A=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=sTq0x2YAbEK2mkQnGOWXPEhEVrNSl5q3wFJmJFnqCWh9GAsZtx3lQM9fIkmE2Rbly WCkjGPdfQFSV6UU4S71l/wE+WczCjKxRFWu8lXeiUrY9QAIn+q+lKSA++gcg0NsTX7 5JS2E7wsObmOCDxycXgzptGWMF50MfhpCd3UHPjsODVgugKQDByygn1XttkTtKL/Ms qka/o9LA6txrpZYBpYwebfcxRmIIUqJ+E1PyaYaVy4Ip0ZJF+Esa7rNBHldeYwS+eO xhlyfa8qayxVLz92iXiZ1hnPfyjJ/LKri1LByhSzJlowEYES+5l5qXAjzxpZqGYKHd gttzl6TusKN9Q== To: Paul Winalski Message-ID: In-Reply-To: References: Feedback-ID: 35591162:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: PWB7DX6YR3S3VHKXFQLZZBIXH3MA25IP X-Message-ID-Hash: PWB7DX6YR3S3VHKXFQLZZBIXH3MA25IP X-MailFrom: segaloco@protonmail.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: 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: From: segaloco via TUHS Reply-To: segaloco For the sake of timelines: June 1980 - Publication date on the front page of the 3.0 manual in which t= he utilities are still very much research for PDP-11 and 32V-ish for VAX wh= ere distinctions matter. June 1981 - Publication date on the front page of the 4.1 manual in which t= he man-pages very much refer to all of this as the "3B-20 object format" June 1982 - Publication date on the front page of the 5.0 manual by which p= oint these same pages had been edited and extended to describe the "common = object file format" Additions at the 1981 release include dump(1), list(1), and the ld-prefixed= library routines for managing these object files. These likewise persist = in 5.0, SysV, and beyond as COFF-related tools. So this puts the backstop of what would become COFF at at least '81. - Matt G. ------- Original Message ------- On Thursday, February 23rd, 2023 at 8:49 AM, Paul Winalski wrote: > On 2/22/23, Clem Cole clemc@ccc.com wrote: >=20 > > > - The System V manual has both this ar(1) version as well as the new > > > COFF-supporting version. > > >=20 > > > Why would ar(1) care? > > >=20 > > > - 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. >=20 >=20 > 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. >=20 > 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). >=20 > > > and development software stuff until ELF comes along some time later. > >=20 > > 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. >=20 >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > -Paul W.