traditional Intel & Microsoft formats...

traditional Intel & Microsoft formats...

[Erich Stefan Boleyn]

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

traditional Intel & Microsoft formats...

[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).
  
   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.

Re: traditional Intel & Microsoft formats...

[Erich Stefan Boleyn]

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

Re: traditional Intel & Microsoft formats...

[DJ Delorie]

>   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.

Re: traditional Intel & Microsoft formats...

[Ken Raeburn]

   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. :-)

Re: traditional Intel & Microsoft formats...

[DJ Delorie]

> 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.

Re: traditional Intel & Microsoft formats...

[Erich Stefan Boleyn]

> 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

traditional Intel & Microsoft formats...

[Arthur Kreitman]

>   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.  

Re: traditional Intel & Microsoft formats...

[Erich Stefan Boleyn]

> >   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

Re: traditional Intel & Microsoft formats...

[Richard Stallman]

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.

Re: traditional Intel & Microsoft formats...

[Richard Stallman]

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.

Re: traditional Intel & Microsoft formats...

[Erich Stefan Boleyn]

> 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

Re: traditional Intel & Microsoft formats...

[John Gilmore]

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

Re: traditional Intel & Microsoft formats...

[John Gilmore]

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.

traditional Intel & Microsoft formats...

[Arthur Kreitman]

>   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.

Re: traditional Intel & Microsoft formats...

[Ian Lance Taylor]

   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

Re: traditional Intel & Microsoft formats...

[Erich Stefan Boleyn]

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