* traditional Intel & Microsoft formats... @ 1994-11-09 8:05 Erich Stefan Boleyn 1994-11-09 8:59 ` Arthur Kreitman 1994-11-10 22:53 ` John Gilmore 0 siblings, 2 replies; 17+ messages in thread From: Erich Stefan Boleyn @ 1994-11-09 8:05 UTC (permalink / raw) To: gas2, bfd Greetings. I'm curious if there is an intention of any on these lists to try to be able to (for the i386 processor series): 1) assemble (GAS) and manipulate (BFD) traditional Intel/Microsoft 16-bit code (OMF/NE formats). 2) assemble (GAS) and manipulate (BFD) traditional Intel/Microsoft 32-bit code (OMF/PE formats). "assemble" is reasonably obvious, but by "manipulate", I mean support in the full sense of the BFD library code, so that you could (if possible) link it via the GNU linker with other object file formats, etc. My interest is mostly as targets, not as hosts, and the 16-bit assembly is less interesting to me (though I saw the message posted about others being interested in 16-bit assembly). The goal behind this is that, well, I'd already announced on the BFD list working on a BFD-based dynamic linker... well, my long-term goal would be a flexible binary emulation system using the BFD to handle format and system-dependent structures and symbols. The idea would be that the HURD (and Linux, FreeBSD, too if others cared to port it, though it is easier on the HURD, I think) could then run MS-Windows 3.1, DOS, NT, and Chicago applications regardless of the host processor, and at native speeds if you have a processor with an "Intel 386 emulation mode" in hardware. Well, all that is far off, but some essential parts are the items mentioned above. The BFD already supports the object file formats of other UNIX-like OS's, so that's mostly work on the side of the emulator piece. Anyway, I'm tossing this out for those who might be interested/ are thinking about working on such support/might be now... Thanks for your time. Erich Boleyn -- Erich Stefan Boleyn \__ E-mail (preferred): <erich@uruk.org> Mathematician, Software Engineer \__ home #: +1 (503) 226-0741 Mad Genius wanna-be, CyberMuffin \_ phys loc: 924 S.W. 16th Ave, #202 Motto: "I'll live forever or die trying" \ Portland, OR, USA 97205 ^ permalink raw reply [flat|nested] 17+ messages in thread
* traditional Intel & Microsoft formats... 1994-11-09 8:05 traditional Intel & Microsoft formats Erich Stefan Boleyn @ 1994-11-09 8:59 ` Arthur Kreitman 1994-11-09 9:41 ` Erich Stefan Boleyn ` (3 more replies) 1994-11-10 22:53 ` John Gilmore 1 sibling, 4 replies; 17+ messages in thread From: Arthur Kreitman @ 1994-11-09 8:59 UTC (permalink / raw) To: erich; +Cc: gas2, bfd > From: Erich Stefan Boleyn <erich@uruk.org> > > Greetings. > > I'm curious if there is an intention of any on these lists to > try to be able to (for the i386 processor series): > > 1) assemble (GAS) and manipulate (BFD) traditional Intel/Microsoft > 16-bit code (OMF/NE formats). > > 2) assemble (GAS) and manipulate (BFD) traditional Intel/Microsoft > 32-bit code (OMF/PE formats). You should be aware that the "microsoft" formats are being dropped by microsoft. All future microsoft 32 bit systems are sort of coff based. As far as gas is concerned, only minor changes are required to support microsoft's coff interperation (we've done it, and will be integrating the changes into the latest gas release, and contributing back the changes to the fsf). ar only makes sense if you have ld. For ld to work with Windows NT and Windows95 require more changes then you can imagine. Its at least several man years of work. There's the further problem that much of it must be done by reverse engineering microsoft executables. If gnu cared about market impact, Windows95 support would take the highest priority. I don't think that the gnu community realizes the potential (and the impact) of every pc being a workstation class device with a sophisticated, multitasking, multithreaded operating system. Remember, the windows install base is 70,000,000. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: traditional Intel & Microsoft formats... 1994-11-09 8:59 ` Arthur Kreitman @ 1994-11-09 9:41 ` Erich Stefan Boleyn 1994-11-09 9:56 ` DJ Delorie ` (2 subsequent siblings) 3 siblings, 0 replies; 17+ messages in thread From: Erich Stefan Boleyn @ 1994-11-09 9:41 UTC (permalink / raw) To: Arthur Kreitman; +Cc: gas2, bfd artk@congruent.com (Arthur Kreitman) writes: > You should be aware that the "microsoft" formats are being dropped > by microsoft. All future microsoft 32 bit systems are sort of > coff based. Yes, the PE format (that used by MS-Windows NT) is much like COFF, particularly with an extra set of identifier fields. The suggestion about the other formats is for the point of view of binary emulation and linking with other libraries. > As far as gas is concerned, only minor changes are required to > support microsoft's coff interperation (we've done it, and will > be integrating the changes into the latest gas release, and contributing > back the changes to the fsf). Cool! > ar only makes sense if you have ld. For ld to work with Windows NT > and Windows95 require more changes then you can imagine. Its at > least several man years of work. There's the further problem that > much of it must be done by reverse engineering microsoft executables. Really? The Developer docs that come with the Microsoft "developer's network" aren't too helpful, but there are a couple of articles about them that have given me explicit layout rules. Is this an estimate for targeting, or hosting? I'd be interested in discussing some of it, though I am certainly less expert than others on this list, just interested ;-). > If gnu cared about market impact, Windows95 support would take the > highest priority. I don't think that the gnu community realizes the > potential (and the impact) of every pc being a workstation class device > with a sophisticated, multitasking, multithreaded operating system. > Remember, the windows install base is 70,000,000. I think some (like myself) are aware and interested in this impact. Particularly the ability of a GNU OS to run more executables than the Microsoft OS's (say, almost a superset), would give a lot more weight to the free software community. Also, with MS-Windows NT & Chicago, there isn't going to be binary emulation of 32-bit apps, only 16-bit i386 apps, so far. This project would be much more aimed at running any app on any hardware architecture (in theory ;-). In short, there is probably 3 or 4 big-ticket projects that together could put the free (GNU, I presume ;-) OS's ahead of the commercial ones, IMHO. Anyway, this topic should be taken off-line, it's not the point of the e-mail lists involved. Erich -- Erich Stefan Boleyn \__ E-mail (preferred): <erich@uruk.org> Mathematician, Software Engineer \__ home #: +1 (503) 226-0741 Mad Genius wanna-be, CyberMuffin \_ phys loc: 924 S.W. 16th Ave, #202 Motto: "I'll live forever or die trying" \ Portland, OR, USA 97205 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: traditional Intel & Microsoft formats... 1994-11-09 8:59 ` Arthur Kreitman 1994-11-09 9:41 ` Erich Stefan Boleyn @ 1994-11-09 9:56 ` DJ Delorie 1994-11-09 9:57 ` Ken Raeburn 1994-11-10 8:11 ` Richard Stallman 3 siblings, 0 replies; 17+ messages in thread From: DJ Delorie @ 1994-11-09 9:56 UTC (permalink / raw) To: artk; +Cc: erich, gas2, bfd > ar only makes sense if you have ld. For ld to work with Windows NT > and Windows95 require more changes then you can imagine. Its at > least several man years of work. There's the further problem that > much of it must be done by reverse engineering microsoft executables. NT libraries are the same format as unix libraries. In fact, GNU make built on NT already knows about library timestamps! NT objects appear to be straight COFF objects, perhaps with different reloc types or something, but objdump seems to like them. The NT "pe" executable format is coff-ish, but it's NOT coff. At least, not enough to use our standard tools on it. I've been reverse engineering it and working on determining the feasability of writing an NT linker. As for ld, it's probably almost easier to do this from scratch, as the NT linker needs to know a LOT about dll's and resources. I'm guessing that an NT-specific linker is 2/3 this stuff and 1/3 actual linking. It would be more work merging gld's stuff to the NT extensions than just writing an NT-specific linker from scratch, although you'd still want to use BFD to load objects. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: traditional Intel & Microsoft formats... 1994-11-09 8:59 ` Arthur Kreitman 1994-11-09 9:41 ` Erich Stefan Boleyn 1994-11-09 9:56 ` DJ Delorie @ 1994-11-09 9:57 ` Ken Raeburn 1994-11-09 10:33 ` DJ Delorie ` (2 more replies) 1994-11-10 8:11 ` Richard Stallman 3 siblings, 3 replies; 17+ messages in thread From: Ken Raeburn @ 1994-11-09 9:57 UTC (permalink / raw) To: Arthur Kreitman; +Cc: gas2, bfd, erich Date: Wed, 9 Nov 94 11:39:23 est From: artk@congruent.com (Arthur Kreitman) > From: Erich Stefan Boleyn <erich@uruk.org> > > Greetings. > > I'm curious if there is an intention of any on these lists to > try to be able to (for the i386 processor series): > > 1) assemble (GAS) and manipulate (BFD) traditional Intel/Microsoft > 16-bit code (OMF/NE formats). > > 2) assemble (GAS) and manipulate (BFD) traditional Intel/Microsoft > 32-bit code (OMF/PE formats). How much would supporting those Microsoft formats buy us over what DJ Delorie has already done with DJGPP and GO32? (Please excuse my cluelessness, I've never done development on DOS or Windows and know next to nothing about their file formats &c.) As far as gas is concerned, only minor changes are required to support microsoft's coff interperation (we've done it, and will be integrating the changes into the latest gas release, and contributing back the changes to the fsf). Cool. I look forward to merging it in... ar only makes sense if you have ld. For ld to work with Windows NT and Windows95 require more changes then you can imagine. Its at least several man years of work. There's the further problem that much of it must be done by reverse engineering microsoft executables. Hm. I could believe it might be significantly different from the formats we use on other systems, but man-years of work? Is it *that* different? The primary goal would be to produce working executables. Using object and library formats compatible with the native tools would be a plus, but not absolutely necessary, especially if the vendor is anal about releasing information. And given that this vendor is Microsoft, I think we should be especially paranoid about not violating license terms &c, when trying to do any of that reverse engineering... We don't want to make Cygnus or the FSF an easy lawsuit target. If gnu cared about market impact, Windows95 support would take the highest priority. I don't think that the gnu community realizes the potential (and the impact) of every pc being a workstation class device with a sophisticated, multitasking, multithreaded operating system. Remember, the windows install base is 70,000,000. I agree it's a huge market. But I'm always skeptical about any numbers quoted. My laptop is probably counted as one of those 70M systems, because it was shipped to me with Windows, but that doesn't mean I reinstalled it after repartitioning the disk... So call it an install base of 69,999,999; it's still big. :-) ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: traditional Intel & Microsoft formats... 1994-11-09 9:57 ` Ken Raeburn @ 1994-11-09 10:33 ` DJ Delorie 1994-11-09 11:56 ` Erich Stefan Boleyn 1994-11-09 10:49 ` Arthur Kreitman 1994-11-10 8:22 ` Richard Stallman 2 siblings, 1 reply; 17+ messages in thread From: DJ Delorie @ 1994-11-09 10:33 UTC (permalink / raw) To: raeburn; +Cc: artk, gas2, bfd, erich > How much would supporting those Microsoft formats buy us over what > DJ Delorie has already done with DJGPP and GO32? (Please excuse my > cluelessness, I've never done development on DOS or Windows and know > next to nothing about their file formats &c.) It's like having a Unix compiler that can't produce X programs. Djgpp can build text-based programs, but can't build graphics programs (Win32s or NT) because it can't generate the executable (it's different than a command-line executable). > Hm. I could believe it might be significantly different from the > formats we use on other systems, but man-years of work? Is it > *that* different? Well, I think man-months or less, assuming you already know the file formats and basic linking theory. This doesn't include the resource compiler that you'll need to write to go along with the library, which is probably another few man-months. > The primary goal would be to produce working executables. Using > object and library formats compatible with the native tools would be > a plus, but not absolutely necessary, especially if the vendor is > anal about releasing information. The obj and lib is straight unix COFF. It's just the executable that's weird. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: traditional Intel & Microsoft formats... 1994-11-09 10:33 ` DJ Delorie @ 1994-11-09 11:56 ` Erich Stefan Boleyn 0 siblings, 0 replies; 17+ messages in thread From: Erich Stefan Boleyn @ 1994-11-09 11:56 UTC (permalink / raw) To: DJ Delorie; +Cc: gas2, bfd > It's like having a Unix compiler that can't produce X programs. Djgpp > can build text-based programs, but can't build graphics programs > (Win32s or NT) because it can't generate the executable (it's > different than a command-line executable). I personally think this part of Misrosoft's strategy is a pain... I'm glad this is being worked on! (I already saw the "winnt" preliminary configuration for GCC 2.6.1) > Well, I think man-months or less, assuming you already know the file > formats and basic linking theory. This doesn't include the resource > compiler that you'll need to write to go along with the library, which > is probably another few man-months. Much different estimate here! Are you/others already planning this? > The obj and lib is straight unix COFF. It's just the executable > that's weird. That's the impression I received as well from the docs I've read. The object and library formats being straight COFF certainly will simplify things. Erich -- Erich Stefan Boleyn \__ E-mail (preferred): <erich@uruk.org> Mathematician, Software Engineer \__ home #: +1 (503) 226-0741 Mad Genius wanna-be, CyberMuffin \_ phys loc: 924 S.W. 16th Ave, #202 Motto: "I'll live forever or die trying" \ Portland, OR, USA 97205 ^ permalink raw reply [flat|nested] 17+ messages in thread
* traditional Intel & Microsoft formats... 1994-11-09 9:57 ` Ken Raeburn 1994-11-09 10:33 ` DJ Delorie @ 1994-11-09 10:49 ` Arthur Kreitman 1994-11-09 12:02 ` Erich Stefan Boleyn 1994-11-10 8:22 ` Richard Stallman 2 siblings, 1 reply; 17+ messages in thread From: Arthur Kreitman @ 1994-11-09 10:49 UTC (permalink / raw) To: raeburn; +Cc: gas2, bfd, erich > How much would supporting those Microsoft formats buy us over what DJ > Delorie has already done with DJGPP and GO32? (Please excuse my > cluelessness, I've never done development on DOS or Windows and know next > to nothing about their file formats &c.) This would be for native support. Remember, what go32 does is provide a 32 bit environment. > Hm. I could believe it might be significantly different from the formats > we use on other systems, but man-years of work? Is it *that* different? Its different enough to require two or three people working for six or nine months. That's just the binutils side. That doesn't include MS's special debugging formats, or the gcc changes needed to really fit in to MS's world, or doing gdb. > The primary goal would be to produce working executables. Using object > and library formats compatible with the native tools would be a plus, but > not absolutely necessary, especially if the vendor is anal about releasing > information. You need to link against microsoft libraries to be able to create an executable that runs. > And given that this vendor is Microsoft, I think we should be especially > paranoid about not violating license terms &c, when trying to do any of > that reverse engineering... We don't want to make Cygnus or the FSF an > easy lawsuit target. Reverse engineering isn't a problem. Even Microsoft know's that its not enforcable. However, it is a ton of work. I've been trying to get unencumbered specs (not marked Microsoft Confidential). > I agree it's a huge market. But I'm always skeptical about any numbers Prime didn't believe the impact of workstations. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: traditional Intel & Microsoft formats... 1994-11-09 10:49 ` Arthur Kreitman @ 1994-11-09 12:02 ` Erich Stefan Boleyn 0 siblings, 0 replies; 17+ messages in thread From: Erich Stefan Boleyn @ 1994-11-09 12:02 UTC (permalink / raw) To: Arthur Kreitman; +Cc: gas2, bfd > > Hm. I could believe it might be significantly different from the formats > > we use on other systems, but man-years of work? Is it *that* different? > Its different enough to require two or three people working for six or > nine months. That's just the binutils side. That doesn't include MS's > special debugging formats, or the gcc changes needed to really fit in > to MS's world, or doing gdb. The debugging format and GDB would certainly add a bunch of extra work, but I really don't know how much. > You need to link against microsoft libraries to be able to create an > executable that runs. They're COFF, so it shouldn't be too much problem there. > > I agree it's a huge market. But I'm always skeptical about any numbers > Prime didn't believe the impact of workstations. ??? We're not workstation vendors (at least not myself, and I doubt that Cygnus and the others on the list are). What does this really matter ? PC's or not don't bother me, and Microsoft hasn't just automatically pushed everything else out. Erich -- Erich Stefan Boleyn \__ E-mail (preferred): <erich@uruk.org> Mathematician, Software Engineer \__ home #: +1 (503) 226-0741 Mad Genius wanna-be, CyberMuffin \_ phys loc: 924 S.W. 16th Ave, #202 Motto: "I'll live forever or die trying" \ Portland, OR, USA 97205 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: traditional Intel & Microsoft formats... 1994-11-09 9:57 ` Ken Raeburn 1994-11-09 10:33 ` DJ Delorie 1994-11-09 10:49 ` Arthur Kreitman @ 1994-11-10 8:22 ` Richard Stallman 2 siblings, 0 replies; 17+ messages in thread From: Richard Stallman @ 1994-11-10 8:22 UTC (permalink / raw) To: raeburn; +Cc: artk, gas2, bfd, erich There are certain states in which courts have ruled that shrink-wrap licenses are not valid, and perhaps you can count on this now in all states. Meanwhile, there are states in which the Federal courts have ruled that disassembly is lawful. Also, in the EC, a law was passed that explicitly makes disassembly lawful, when used for the purposes of finding out the information necessary to make something that can interoperate. If you buy a copy in a state where shrink-wrap licenses have been ruled not valid, you can then lawfully take it to the EC (assuming this is not export-restricted), and there lawfully disassemble it and use the information. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: traditional Intel & Microsoft formats... 1994-11-09 8:59 ` Arthur Kreitman ` (2 preceding siblings ...) 1994-11-09 9:57 ` Ken Raeburn @ 1994-11-10 8:11 ` Richard Stallman 1994-11-10 9:35 ` Erich Stefan Boleyn 3 siblings, 1 reply; 17+ messages in thread From: Richard Stallman @ 1994-11-10 8:11 UTC (permalink / raw) To: artk; +Cc: erich, gas2, bfd The main purpose of GNU is to make a free operating system--not to enhance proprietary ones. If everyone in the world ran GNU software on Windows, that would perhaps please some users, but fundamentally the project would have gone astray. If a community, whether large or small, can be viable using entirely free software, that is success. We do support non-GNU-like operating systems, when it is not a lot of trouble and someone writes the code. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: traditional Intel & Microsoft formats... 1994-11-10 8:11 ` Richard Stallman @ 1994-11-10 9:35 ` Erich Stefan Boleyn 0 siblings, 0 replies; 17+ messages in thread From: Erich Stefan Boleyn @ 1994-11-10 9:35 UTC (permalink / raw) To: Richard Stallman; +Cc: artk, gas2, bfd > The main purpose of GNU is to make a free operating system--not to > enhance proprietary ones. If everyone in the world ran GNU software > on Windows, that would perhaps please some users, but fundamentally > the project would have gone astray. If a community, whether large or > small, can be viable using entirely free software, that is success. Hmmm... I think you're responding to <artk@congruent.com>'s comment about going with Windows-NT, but it sounds enough like you're responding to my comment on emulation that I'm sending this. My reasoning for interest in a flexible binary emulator that is free and runs on a free OS, but can run proprietary executables is that it opens the doors for those who would like to use a non-proprietary OS, but are required to use proprietary software. The biggest argument is always the existence argument. We need to do <task>, and the only software available to really help with <task> is <package> running on <OS> on <hardware>, and each one is proprietary, and possibly incompatible with other things they have. In the long run, in theory, binary emulation for systems that don't have process migration may be useless, but I don't foresee the free software world taking over that completely for a very long time, even given that people will go that route without a lot of persuasion. To get poeple to use a free OS on a lot of machines willingly, the only way I see to do it is at least OS-emulation (running executables form different OS's on the same hardware), and binary emulation is the logical conclusion which makes it just that much better. For example, (I hope you don't hate me for saying this, Richard :-/, I think that a PPC/68K Mac emulation system would be a very good addition. The reason is that it would encourage people who are stuck using Mac applications to run on a HURD OS supported machine. They wouldn't have to buy from Apple, then. My girlfriend, for example, has to use Mac application for her job, and will have to for some time. > We do support non-GNU-like operating systems, when it is not a lot of > trouble and someone writes the code. I think at least supporting the formats is a Good Thing, as long as someone wants to use a free OS for some proprietary thing they need to work on. In case you're interested, I really do believe in the GNU idea, and liked the manifesto, but I really want to get it used widely. Erich -- Erich Stefan Boleyn \__ E-mail (preferred): <erich@uruk.org> Mathematician, Software Engineer \__ home #: +1 (503) 226-0741 Mad Genius wanna-be, CyberMuffin \_ phys loc: 924 S.W. 16th Ave, #202 Motto: "I'll live forever or die trying" \ Portland, OR, USA 97205 ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: traditional Intel & Microsoft formats... 1994-11-09 8:05 traditional Intel & Microsoft formats Erich Stefan Boleyn 1994-11-09 8:59 ` Arthur Kreitman @ 1994-11-10 22:53 ` John Gilmore 1994-11-10 23:25 ` John Gilmore ` (2 more replies) 1 sibling, 3 replies; 17+ messages in thread From: John Gilmore @ 1994-11-10 22:53 UTC (permalink / raw) To: Erich Stefan Boleyn; +Cc: gas2, bfd, gnu I applaud your effort to support more file formats in the hope of making it possible to run (proprietary or free) programs from the PC world on GNU systems. Have you examined the Wine emulator for Windows programs? And the "sim" directory of instruction-set simulators in the GDB releases? Some of us have similar dreams... Specs for some of the formats you are interested in *are* available and don't have to be reverse-engineered. (Some other info, such as debug sections, may require more work -- I haven't checked into all the details.) There's an organization of OS and tool companies called the Tool Interface Standards committee. It publishes specs and talks about new formats and revisions. Cygnus asked how we could join one time, but never got a response. Here are my old notes about this: Subject: [Intel x86] Tool Interface Standards committee Announced in Open Systems Today, March 1, 1993. Committee is Borland, IBM, Intel, Lotus, MetaWare, Microsoft, SCO, Watcom. Contact: David Bernstein, director of technology at SCO. Volume 1: Portable executable format (from Windows NT) and STI (symbol and type information). Volume 2: ELF, DWARF, and OMF. Version 1.0 of the standard is free of charge (in hard copy) on request. Available from Intel. +1 800 548 4725 Order # 241-597 Takes 7-10 working days. Arrived from: Tool Interface Standards c/o Intel Corporation RN6-30 2200 Mission College Blvd. Santa Clara, CA 95052 signature space left for "Secretary, TIS Committee", but not signed. "The TIS Committee is an open forum in which corporations can provide leadership for advancing the PC software market. The Committee welcomes participation by new company members. Interested companies can learn more about TIS by using Intel ACCESS on CompuServe." John The Tool Interface Standards ad-hoc committee has produced two documents, describing ELF, DWARF (almost 2.0), OMF, PE, and STI object formats. The intent is that every vendor's tools can interoperate, at least on Intel x86 platforms. Some of the formats describe other CPUs as well. The committee is currently Borland, IBM, Intel, Lotus, Metaware, Microsoft, SCO, and Watcom, with help from PharLap and Symantec. The standards haven't been jiggered -- e.g. ELF is the real thing. ELF is the only one that we currently support. Our DWARF support is for a previous rev, and we don't do OMF (which is used for DOS and OS/2 relocatable files), PE (Windows NT executable, basically COFF), and STI (Windows NT debug info). But now we can if we want to. --- By the way, it looks to me like Windows DLL linking is remarkably like dynamic linking on SVR4 or SunOS. Since the GNU Linker now supports dynamic linking (which was, indeed, a fair bit of work), making it handle DLL's is probably not as big a job as you think. The way to support any of these formats is to write a new BFD back-end. It's really pretty easy. Look at one of the simple ones that isn't full of macros -- say, binary.c or tekhex.c or srec.c or oasys.c. (The macro-ized bfd target code is to support seventeen variants of a.out or COFF on seventeen Unix machines.) To read a new file format, you only need to write a dozen functions (check file format, get section info, get section contents, get symbol table size, get symbol table, etc). Once you get this simple stuff into a BFD target, you get immense leverage from the already-99%-working code in the assembler, linker, binutils, and GDB that calls BFD. John Gilmore Cygnus Support ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: traditional Intel & Microsoft formats... 1994-11-10 22:53 ` John Gilmore @ 1994-11-10 23:25 ` John Gilmore 1994-11-11 5:34 ` Arthur Kreitman 1994-11-11 10:21 ` Erich Stefan Boleyn 2 siblings, 0 replies; 17+ messages in thread From: John Gilmore @ 1994-11-10 23:25 UTC (permalink / raw) To: Erich Stefan Boleyn, gas2, bfd, gnu Ah, it's gradually coming back to me! There *are* online versions of the specs for most of these file formats, available from Intel. Look at: ftp://ftp.intel.com/pub/tis or ftp://ftp.intel.com/pub/IAL/TIS Note that any ".gps" files there seem to really be ".zip" files. Here's the overview of what's there, from the /pub/IAL/libdir.txt file: SYM10H.ZIP/Bin Bytes: 189258, Count: 26, 05-Nov-93 Last:10-May-94 Title: Microsoft Symbol and Type Information Spec., V1. Keywords: SYMBOL TYPE MS TIS The Microsoft Symbol and Type Information Spec., V1.0 is a chapter in the Formats Specification for Windows, V1.0 (which is also posted in this forum in its entirety.) It may also be ordered from Intel Corporate Literature at 1-800-548-4725. This specification is posted royalty-free for you to use to make your software TIS-compliant. FORMAT; Pkzipped file extracts to a H/P postscript file. Copy to your H/P PS printer to print (tested on an HPIIISi PS printer.) SYM10G.ZIP/Bin Bytes: 187651, Count: 15, 05-Nov-93 Last:10-May-94 Title: Microsoft Symbol and Type Information Spec., V1. Keywords: MS SYMBOL TYPE SPEC. The Microsoft Symbol and Type Information Spec., V1.0 is a chapter in the Fomats Specification for Windows, V1.0 (which is also posted in this forum in its entirety). It may also be ordered through Intel Corporate Literature at 1-800-548-4725. OMF11H.ZIP/Bin Bytes: 113929, Count: 35, 05-Nov-93 Last:30-May-94 Title: Relocatable Object Module Format (OMF), V1.1 Keywords: OMF RELOCATABLE OBJECT TIS PE The Relocatable Object Module Format (OMF) V1.1 is a chapter of the Portable Formats Specification, V1.1 (which is also posted on this forum in its entirety). This spec. may also be ordered from Intel Corporate Literature, at 1-800-548-4725. OMF11G.ZIP/Bin Bytes: 112573, Count: 26, 05-Nov-93 Last:10-May-94 Title: Relocatable Object Module Format (OMF) , V1.1 Keywords: OMF OBJECT RELOCATABLE TIS PE The Relocatable Object Module Format (OMF), V1.1 is a chapter in the Portable Formats Specification, V1.1 (which is also posted in its entirety in this forum). ELF11H.ZIP/Bin Bytes: 76717, Count: 36, 05-Nov-93 Last:10-May-94 Title: Executable and Linkable Format (ELF) V1.1 Keywords: ELF EXECUTABLE FORMAT TIS The Executable and Linkable Format Specification, V1.1, is part of the TIS standard Portable Formats Specification, V1.1, (which is also posted in this forum in its entirety). This standard may also be ordered by calling the Intel Lit. Ctr. at 1-800-548-4725. ELF11G.ZIP/Bin Bytes: 76670, Count: 22, 05-Nov-93 Last:10-May-94 Title: Executable and Linkable Format (ELF) V1.1 Keywords: ELF EXECUTABLE LINKABLE TIS Part of the Portable Formats Specification (also posted in this forum), V1.1, ELF is the Executable and Linkable Format. DWF11.ZIP/Bin Bytes: 120951, Count: 31, 04-Nov-93 Last:29-Apr-94 Title: DWARF Debug Information Format, V1.1 Keywords: DEBUG DWARF TIS OBJECT This document, prepared in cooperation with the TIS committee, defines the format for the information generated by compilers, assemblers, and linkage editors that is necessary for symbolic, source-level debugging. WINFMH.ZIP/Bin Bytes: 262359, Count: 38, 04-Nov-93 Last:10-May-94 Title: Format Specification for Windows, Version 1.0 Keywords: PE PORTABLE EXECUTABLE SYMBOL SYM Format Specification for Windows, Version 1.0. This spec. contains the portable executable (PE) format, and the Microsoft Symbol and Type Information. PF11H.ZIP/Bin Bytes: 377691, Count: 38, 04-Nov-93 Last:10-May-94 Title: Portable Formats Specification, Version 1.1 Keywords: OMF ELF DWARD PORTABLE OBJECT RELOCATABLE This zip file contains the Portable Formats Specification, V1.1. It is composed of chapters on DWARF (debugging information format), ELF (executable and linkable format), and OMF (relocatable object module format). MEMAPP.DOC/Bin Bytes: 5382, Count: 23, 06-Oct-93 Last:02-Jun-94 Title: TIS Committee Application Form and Membership Ru Keywords: TIS APPLICATION Tools Interface Standards Committee membership rules and membership application form. FORMAT: Word for Windows BYLAWS.DOC/Bin Bytes: 19550, Count: 21, 06-Oct-93 Last:23-Apr-94 Title: TIS Committee Bylaws, V1.0 Keywords: TIS TOOLS BYLAWS The Tools Interface Standards Committee Bylaws, V1.0, January 21, 1993, define the committee role and purposes. FORMAT: Word for Windows. TISGLS.TXT/Text Bytes: 3231, Count: 119, 03-Mar-93 Last:04-Jun-94 Title: TIS Glossary Keywords: TIS GLOSSARY APPLICATIONS SOFTWARE DEVELOPMENT TOOL This file contains the TIS (Tool Interface Standards) Glossary which defines some typical TIS lingo. TISFQA.TXT/Text Bytes: 3622, Count: 96, 03-Mar-93 Last:02-Jun-94 Title: TIS Questions and Answers Keywords: TIS QUESTIONS ANSWERS This file contains commonly asked questions and answers in regards to TIS (Tool Interface Standards) and additional information on TIS Standards. TISFPR.TXT/Text Bytes: 4141, Count: 102, 03-Mar-93 Last:02-Jun-94 Title: TIS Press Release March 93 Keywords: TIS PRESS RELEASE This file contains the TIS (Tool Interface Standards) Press Release dated Feb. 23, 1993. It describes the standards committee to expedite 32-bit PC applications development, endorses open, compatible, cross-OS tool interface. ^ permalink raw reply [flat|nested] 17+ messages in thread
* traditional Intel & Microsoft formats... 1994-11-10 22:53 ` John Gilmore 1994-11-10 23:25 ` John Gilmore @ 1994-11-11 5:34 ` Arthur Kreitman 1994-11-11 8:31 ` Ian Lance Taylor 1994-11-11 10:21 ` Erich Stefan Boleyn 2 siblings, 1 reply; 17+ messages in thread From: Arthur Kreitman @ 1994-11-11 5:34 UTC (permalink / raw) To: gnu; +Cc: erich, gas2, bfd, gnu > Specs for some of the formats you are interested in *are* available > and don't have to be reverse-engineered. (Some other info, such as > debug sections, may require more work -- I haven't checked into all the > details.) There's an organization of OS and tool companies called the As far as what Microsoft is calling their PE format (the one that's being used for NT and will be used for Windows95, none of those documents you listed are either complete or valid. > Tool Interface Standards committee. It publishes specs and talks > about new formats and revisions. Cygnus asked how we could join one > time, but never got a response. Here are my old notes about this: I think the reason you never got a response it that the effort was stillborn. It was announced about the same time as NT was announced. They advertised that DWARF was the answer to all your problems, and ignored Microsoft. They then disappeared. I don't know if they exist or not, but I'm certain that Microsoft has continued to enhance aspects of their object format without asking their permission. > By the way, it looks to me like Windows DLL linking is remarkably like > dynamic linking on SVR4 or SunOS. Since the GNU Linker now supports > dynamic linking (which was, indeed, a fair bit of work), making it > handle DLL's is probably not as big a job as you think. I don't think that the mechanism used to support dll's is similar to sunos shared library support in any way. Their capabilities differ significantly. > The way to support any of these formats is to write a new BFD > back-end. It's really pretty easy. Look at one of the simple ones That's the easiest part of supporting the Microsoft formats. There are new section types that have to be generated, import tables, export tables, resources. BFD get you alot closer, but I would guess that it will that more resources to get the current BFD to completely support MS executables then it took to add sunos dynamic linking. As an aside, do you know how much work was required to add sun dymanic linking. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: traditional Intel & Microsoft formats... 1994-11-11 5:34 ` Arthur Kreitman @ 1994-11-11 8:31 ` Ian Lance Taylor 0 siblings, 0 replies; 17+ messages in thread From: Ian Lance Taylor @ 1994-11-11 8:31 UTC (permalink / raw) To: artk; +Cc: gnu, erich, gas2, bfd, gnu Date: Fri, 11 Nov 94 08:11:00 est From: artk@congruent.com (Arthur Kreitman) > By the way, it looks to me like Windows DLL linking is remarkably like > dynamic linking on SVR4 or SunOS. Since the GNU Linker now supports > dynamic linking (which was, indeed, a fair bit of work), making it > handle DLL's is probably not as big a job as you think. I don't think that the mechanism used to support dll's is similar to sunos shared library support in any way. Their capabilities differ significantly. I don't know that much about dll's. Could you give a brief summary of why they are so much more difficult than, say, ELF dynamic libraries? The GNU linker currently has full support for ELF dynamic libraries. > The way to support any of these formats is to write a new BFD > back-end. It's really pretty easy. Look at one of the simple ones That's the easiest part of supporting the Microsoft formats. There are new section types that have to be generated, import tables, export tables, resources. BFD get you alot closer, but I would guess that it will that more resources to get the current BFD to completely support MS executables then it took to add sunos dynamic linking. It's true that the BFD paradigm does not represent certain things well. For example, MIPS ELF uses an unusual debugging format (ECOFF) which requires linker support, as well as recording information like how much an object file would be changed by compiling with different values of the -G switch. BFD can not represent this information publically, but that does not mean that BFD does not help enormously when writing a linker. It just means that special routines are required in that BFD backend. As an aside, do you know how much work was required to add sun dymanic linking. I did all the work to support SunOS dynamic linking. I did it mostly on my own time, since Cygnus did not have a customer for it. The hardest part was reverse engineering the largely undocumented format. I don't want to pass over that too lightly, because it was quite difficult. On the other hand I am assured by friends at Microsoft that the object file format is reasonably well described on some CD or set of CD's which is available for $195. Once I understood the format, it probably took me about a week all told to write the linker support. The ELF dynamic linking code had already been written, largely by Eric Youngdale, so I was able to use that as a guide. You could add in a couple of days I spent early in the process to add some calls to BFD to read the dynamic symbol table and the dynamic relocs, so that I could examine them with objdump while I tried to figure out what the runtime linker did with them. Ian ^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: traditional Intel & Microsoft formats... 1994-11-10 22:53 ` John Gilmore 1994-11-10 23:25 ` John Gilmore 1994-11-11 5:34 ` Arthur Kreitman @ 1994-11-11 10:21 ` Erich Stefan Boleyn 2 siblings, 0 replies; 17+ messages in thread From: Erich Stefan Boleyn @ 1994-11-11 10:21 UTC (permalink / raw) To: John Gilmore; +Cc: gas2, bfd John Gilmore <gnu@cygnus.com> writes: > I applaud your effort to support more file formats... EEK! I didn't say I was doing all of the file formats. I was asking who is working on/interested in/might be interested in those formats. Having said that, I'll probably end up doing some to support them. My major project(s) is the dynamic linker, then an emulation/dynamic translation system. > ...in the hope of > making it possible to run (proprietary or free) programs from the > PC world on GNU systems. Have you examined the Wine emulator > for Windows programs? And the "sim" directory of instruction-set > simulators in the GDB releases? Yes, I have a fairly complete list of instruction-set emulators for the more recent chips out there (no offense, but supporting such things as the Apple II is of little or no interest to me ;-). The WINE project is intersting, but I don't think it is of large enough scope without a fast binary emulator out there. Considering that an OS emulation must be done in addition to the binary emulation, it may well be that large parts of the WINE project get used. > Some of us have similar dreams... I'm glad to hear that. Actually, I traded e-mail messages with Micheal Bushnell (of the HURD, though most of you know that) about this topic, and he mentioned interest in the same goal. I've started putting together a design/concept doc with the info I have so far. This is both to flush out the ideas, and to get feedback, as a useful emulator can be a tricky business. On a practical level, it would also be to drum up support, since the whole project is pretty big, and supporting some formats that otherwise might be ignored would be necessary. Oh, yes... it's a moral obligation to call it SPAM, for "Synthetic Processing on Aribitrary Machines" or somesuch ;-). > By the way, it looks to me like Windows DLL linking is remarkably like > dynamic linking on SVR4 or SunOS. Since the GNU Linker now supports > dynamic linking (which was, indeed, a fair bit of work), making it > handle DLL's is probably not as big a job as you think. MS-Windows 3.1 DLLs have their own weirdness to deal with, though I tend to agree that it isn't a huge job. DLLs are supported directly by the MS runtime loader. > The way to support any of these formats is to write a new BFD > back-end. It's really pretty easy. Look at one of the simple ones > that isn't full of macros -- say, binary.c or tekhex.c or srec.c or > oasys.c. (The macro-ized bfd target code is to support seventeen > variants of a.out or COFF on seventeen Unix machines.) To read a new > file format, you only need to write a dozen functions (check file > format, get section info, get section contents, get symbol table size, > get symbol table, etc). Once you get this simple stuff into a BFD > target, you get immense leverage from the already-99%-working code > in the assembler, linker, binutils, and GDB that calls BFD. Really, what I'm looking to do with an "emulator" scheme is to extend the BFD to have a runtime for dealing with other OSs and hardware architectures on most any machine. The existence of the BFD and its leverage is what's going to make this possible in the first place. Let's just finish the job ;-). Erich -- Erich Stefan Boleyn \__ E-mail (preferred): <erich@uruk.org> Mathematician, Software Engineer \__ home #: +1 (503) 226-0741 Mad Genius wanna-be, CyberMuffin \_ phys loc: 924 S.W. 16th Ave, #202 Motto: "I'll live forever or die trying" \ Portland, OR, USA 97205 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~1994-11-11 10:21 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1994-11-09 8:05 traditional Intel & Microsoft formats Erich Stefan Boleyn 1994-11-09 8:59 ` Arthur Kreitman 1994-11-09 9:41 ` Erich Stefan Boleyn 1994-11-09 9:56 ` DJ Delorie 1994-11-09 9:57 ` Ken Raeburn 1994-11-09 10:33 ` DJ Delorie 1994-11-09 11:56 ` Erich Stefan Boleyn 1994-11-09 10:49 ` Arthur Kreitman 1994-11-09 12:02 ` Erich Stefan Boleyn 1994-11-10 8:22 ` Richard Stallman 1994-11-10 8:11 ` Richard Stallman 1994-11-10 9:35 ` Erich Stefan Boleyn 1994-11-10 22:53 ` John Gilmore 1994-11-10 23:25 ` John Gilmore 1994-11-11 5:34 ` Arthur Kreitman 1994-11-11 8:31 ` Ian Lance Taylor 1994-11-11 10:21 ` Erich Stefan Boleyn
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).