--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> I certainly don't want to add 5000 auto-generated stubs. Now if you
> want to use winedump to help you write stubs for the cases that are
> really necessary (like ordinal exports) sure, but each stub needs
> to
> be reviewed to make sure the retu
Jon Griffiths <[EMAIL PROTECTED]> writes:
> So will you accept patches to do this (add empty stubs)? winedump has
> had the capacity to auto-generate these functions for _ages_.
I certainly don't want to add 5000 auto-generated stubs. Now if you
want to use winedump to help you write stubs for th
Hi,
> The solution is not to start building a .spec.c
> file for MSVC, it's to fix our spec files so that they can work on
> Windows without generating extra code. This means replacing the
> stubs by real functions.
So will you accept patches to do this (add empty stubs)? winedump has
had the cap
Hi,
> Is there anyway we could add some magic to msvcmaker to do this? It
> seems to me that if we need to have the stubs defined in a source
> file on msvc we can have msvcmaker parse the spec files and
> generate a extra source file when its making the makefiles.
If Alexandre will accept patc
Robert Shearman <[EMAIL PROTECTED]> writes:
> Mike Hearn wrote:
>
> >Perhaps the first step then would be to implement support in winebuild
> >and the loader such that the list of stubbed functions is exported then
> >the loader can link imports from those to stubs generated on the fly. At
> >tha
Jon Griffiths <[EMAIL PROTECTED]> writes:
> I would like to point out again that the VC linker will not generate
> a correct dll unless the ordinal stubs are present. Other native
> linkers may have the same problem. It seems very silly to me that we
> can't use M$'s own compiler/linker to build v
Hi Jon,
--- Jon Griffiths <[EMAIL PROTECTED]> wrote:
> I would like to point out again that the VC linker will not generate
> a correct dll unless the ordinal stubs are present. Other native
> linkers may have the same problem. It seems very silly to me that we
> can't use M$'s own compiler/linker
On Tue, 2004-12-14 at 12:01 -0500, Dimitrie O. Paun wrote:
> On Tue, Dec 14, 2004 at 10:16:29AM -0600, Robert Shearman wrote:
> > IMHO, the Wine project should be moving away from just-in-time
> > implementing of functions and moving towards implementing *everything*
> > (with some obvious except
On Tue, Dec 14, 2004 at 10:16:29AM -0600, Robert Shearman wrote:
> IMHO, the Wine project should be moving away from just-in-time
> implementing of functions and moving towards implementing *everything*
> (with some obvious exceptions). This is the only way a high percentage
> of applications wi
Hi,
I had a patch which enabled stub generation for building native dlls
last year
(http://www.winehq.org/hypermail/wine-patches/2003/07/0176.html),
that part was not accepted for the same reasons that are being
mentioned in this thread.
I would like to point out again that the VC linker will not
Mike Hearn wrote:
On Tue, 2004-12-14 at 15:41 +0100, Alexandre Julliard wrote:
Not adding the functions at all is even easier, and the results are
pretty much the same... As you noted, in general the only advantage of
stubs is that you get a better error message, but that would be fairly
easy to
"Ge van Geldorp" <[EMAIL PROTECTED]> writes:
> I was mixing native shell32.dll with Wine-derived shlwapi.dll. Native
> shell32.dll imports those stubs from shlwapi.dll but then doesn't call them
> in our usage scenarios.
> I'm just a little bit surprised that stubs are ok for elf builds but not fo
Ge van Geldorp <[EMAIL PROTECTED]> writes:
> Send for review to wine-devel:
> http://www.winehq.org/hypermail/wine-devel/2004/11/0658.html (no comments)
> Submitted to wine-patch:
> http://www.winehq.org/hypermail/wine-patches/2004/11/0327.html
> Resubmitting against current CVS
>
> Changelog:
On Tue, 14 Dec 2004 15:13:51 +0100, Alexandre Julliard wrote:
> So now it will be a bit of work before we can get rid of
> them, but that should be the long term goal; and that's why I don't
> think we should add more code to support them.
I'm a bit confused, the specfile level stubs are handy if
On Tue, 2004-12-14 at 15:41 +0100, Alexandre Julliard wrote:
> Not adding the functions at all is even easier, and the results are
> pretty much the same... As you noted, in general the only advantage of
> stubs is that you get a better error message, but that would be fairly
> easy to handle at th
Mike Hearn <[EMAIL PROTECTED]> writes:
> They also make adding new DLLs easier, as you don't have to submit lots of
> stub functions for every entry point. I guess we could have a script to
> generate them given a header, but still ...
Not adding the functions at all is even easier, and the resu
"Ge van Geldorp" <[EMAIL PROTECTED]> wrote:
> > I don't think we want to add a special mode just for stubs;
> > they should really be replaced by proper functions (even if
> > the functions are stubs themselves, at least they can print
> > the parameters and try to return something meaningful i
> From: Alexandre Julliard
>
> > Seems impossible for functions with unknown calling conventions and
> > number of parameters.
>
> I don't think that's a common case, most of these have been
> identified by now. But anyway, if you have an app calling the
> function you should be able to determi
Hi,
On Tue, Dec 14, 2004 at 11:47:11AM +0100, Ge van Geldorp wrote:
> > From: [EMAIL PROTECTED]
> >
> > I don't think we want to add a special mode just for stubs;
> > they should really be replaced by proper functions (even if
> > the functions are stubs themselves, at least they can print
>
"Ge van Geldorp" <[EMAIL PROTECTED]> writes:
> Seems impossible for functions with unknown calling conventions and number
> of parameters.
I don't think that's a common case, most of these have been identified
by now. But anyway, if you have an app calling the function you should
be able to deter
> From: [EMAIL PROTECTED]
>
> I don't think we want to add a special mode just for stubs;
> they should really be replaced by proper functions (even if
> the functions are stubs themselves, at least they can print
> the parameters and try to return something meaningful instead
> of killing the
Stubs declared in .spec files were not generated or exported for PE (MinGW)
builds. The patch below fixes that. It adds a new mode to winebuild, --pedll,
which generates the stubs.
Since it's a global change I'm sending it here for review first.
Ge van Geldorp.
Index: Make.rules.in
==
22 matches
Mail list logo
