On Fri, 24 May 2002, Bang Jun-Young wrote:

> On Fri, May 24, 2002 at 01:04:13AM +0900, TAMURA Kent wrote:
> >
> > In message "Re: Modifications of standard headers for PECOFF"
> >     on 02/05/24, Bang Jun-Young <junyoung@mogua.com> writes:
> > > BTW, what advantages can we get by having support for PE/COFF in
> > > the base system, compared to leaving it as separate package like
> > > PEACE?
> >
> > We have a plan to implement some kernel32.dll functions in
> > compat_pecoff.  It should be more efficient than server approach
> > like Wine.

As the other message mentioned, I don't think that answered the question.

> Hmm...I'm skeptical that it's the right direction for us to have
> PE/COFF support in the base source. IMHO, it'd be better to keep it
> under sys/compat/pecoff and provide pkgsrc entries for PEACE.

On the flip side, I don't think you quite understood the suggestion. Or at
least I got a different understanding than you did. :-)

> More specifically, some reasons why I think so:
>
>  * PEACE need cross toolchain to build.
>
>  * PE/COFF has never been the native binary format of NetBSD, and never
>    will. It's only designed for Windows, not Unix.
>
>  * There are quite a number of API differences between MSVCRT and
>    NetBSD libc. Any binaries compiled with and successfully running with
>    PEACE libc.dll are not guaranteed to run on Windows with MSVCRT.DLL,
>    or vice versa.

I don't think that's what the PEACE project is doing.

From the ancient install I have, what they are doing is:

1) providing a loader which will load & link PECOFF executables.

2) providing DLLs that have the same name as standard windows ones, that
windows apps will link against. Like say kernel32.dll, ddraw.dll,
ole32.dll, user32.dll, etc.

3) Implementing said dlls using a unix-like environment. i.e. the innards
of these dlls look like (Net)BSD libraries. They just get bundled as dlls.

4) providing dll-versions of NetBSD libraries for use in 3). i.e. the
libc.dll is for the PEACE dlls, not the windows apps.

While libc mightn't seem like much, looking at the (old) PEACE install I
have, I have libX11.dll, libXext.dll, libXmu.dll, and libXt.dll (among
others). While the peace folks could probably get away w/o libc, making
the X libs work without libc is not something I would wish on anyone.

Since X is the windowing system we use, PEACE dlls have to turn Windows
DirectDraw calls into X calls.

My understanding of what Tamura-san was wanting is to make life easier for
these dlls; these dlls that are based off of NetBSD code (makes sense).
However routines that are in dlls need a "I'm inside your dll" or "I'm
outside your dll" attribute on the prototype.

So all of the standard NetBSD headers could be used in the PECOFF
envirnoment if they had these attributes.

The PEACE folks have macros set up so that the right thing happens when
you're building different DLLs; the prototypes in that dll say "i'm in
your dll". The same prototypes say "I'm in dll foo" when compiling other
code.

From everything I can tell, to add these attributes/macros is a manual
task. You have to find EACH prototype, and add the right one.

More imortantly, over time as we add stuff to the NetBSD headers, the new
prototypes we add need to get these new macros. Manually.

That looks like a maintainance nightmare, which is why TAMURA-san wanted
to have the NetBSD-source tree contain the macros.

Of course, in the NetBSD build envirnment, the macros expand to nothing.
:-)

We can choose to add these macros or not. But let's understand what we're
adding and why.

>  * We don't want to fork off NetBSD/i386pecoff, NetBSD/alphapecoff, ...
>    from existing ports (do we?).

I don't think that was suggested. ??

Oh, while I think it would be a bit weird to see in our code, I'm up for
adding this stuff to our tree.

Take care,

Bill