Re: traditional Intel & Microsoft formats...

[Erich Stefan Boleyn <erich@uruk.org>]

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