[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: Elfdlls -> take 2 RFC
From:       Bertho Stultiens <bertho () panter ! soci ! aau ! dk>
Date:       1999-08-31 20:02:57
[Download RAW message or body]

Ulrich Weigand wrote:
> Hmmm. Just from a quick look over the new code, it seems 16-bit
> modules are still rather broken:

Indeed; I promised it would be broken.

> - You *really* need to generate new-style entry table entries
>   (ET_BUNDLE, ET_ENTRY); this is not just cosmetics, but the
>   format is very different ...

I know, hadn't gotten to that yet. I have to paste your code into that
part yet.

> - You apparently don't create the data segment at all?  I can't
>   even understand how you intend to fix this at that place (i.e.
>   how do you know the data offsets if you want to write the NE
>   header *before* the data segment?) ...

There is a "FIXME" there stating that it needs to be fixed? I have
hacked a lot of the win16 code lately because the new format made a lot
of old stuf obsolete and could be generated much more flexible. The
datasegment sufferd from lack of time. 

> - The 32-bit handlers for 'cdecl' routines are nevertheless declared
>   WINAPI; the 'cdecl' is talking only about the handling of
>   arguments on the *16-bit* stack.  This is broken at several
>   places in your code, both in the generation of the CallFrom routines
>   and in the auto-stubs.

Let me check what I missed there. I guess that I just put one case too
many in a general rule...

> - The CallFrom routines must perform the PTR_SEG_TO_LIN conversion;
>   just typecasting the segptr to LPVOID really isn't enough ;-)

Darn, hoped you wouldn't have discovered that one... Caught my eye too
:-)

> - Interrupt routines are not implemented.

Nether are win32 register functions yet.

> (Nearly) all of these problems were already fixed in the patch I sent
> you recently, b.t.w. ;-)

True, but I did not like the patch because it was on top of code that
should be shuffled a bit more. One particular thing that I disliked was
the (re-)parsing of the profile string when all data is available one
level higher. So I started to modify it a bit more. Then I first started
to implement the configuration stuff, the automatic imports and the
forwards.

BTW, the import statement has one drawback. The import file-dependencies
are not recognised by the makefiles. Not that I believe that it will be
severe because we are basically importing by name, but nevertheless, a
beauty error because the hint can now be off (seldom, but well...).

Your patch also started to implemented win16 importtables (CallTo16).
This is not going to be in the code. This has been discussed earlier and
Alexandre did not want this into the code. I had a complete
implementation of this at one stage and zapped it because it was not
suppose to happen. Did someone change this point of view?

Greetings Bertho



=========================================================================

[prev in list] [next in list] [prev in thread] [next in thread]