[Bug 33311] New: Loading of libraries intended to be delay loaded for a built-in module actually is not delayed

http://bugs.winehq.org/show_bug.cgi?id=33311

Bug #: 33311
           Summary: Loading of libraries intended to be delay loaded for a
                    built-in module actually is not delayed
           Product: Wine
           Version: 1.5.27
          Platform: x86-64
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: build-env
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
    Classification: Unclassified

If a DLL is listed in DELAYIMPORTS statement in Makefile.in of built-in Wine
module (under /dlls or /programs) this actually doesn't mean that its loading
is going to be really delayed, that DLL will be loaded together with other
module imports.

A part of the problem is that modules listed in DELAYIMPORTS are passed
in the same list with other modules lised in IMPORTS to winegcc. This means
that winegcc passes them along as not delay loaded modules to other helper
tools.

[Bug 33311] Loading of libraries intended to be delay loaded for a built-in module actually is not delayed

http://bugs.winehq.org/show_bug.cgi?id=33311

--- Comment #1 from Alexandre Julliard  2013-04-01 04:25:06 CDT ---
That's how it's supposed to work. There's an additional flag to specify that
the import is delayed. What is the actual problem you are seeing?

[Bug 33311] Loading of libraries intended to be delay loaded for a built-in module actually is not delayed

http://bugs.winehq.org/show_bug.cgi?id=33311

--- Comment #2 from Dmitry Timoshkov  2013-04-01 04:37:17 CDT ---
The problem is that all the additional overhead caused by loading the DLL
is actually not being delayed. For instance marking winspool as delay loaded
module doesn't mean that it will be loaded and initialized only when one of
its APIs is called like it works under Windows. In other words adding a module
to DELAYIMPORTS list in Makefile does nothing.

[Bug 33311] Loading of libraries intended to be delay loaded for a built-in module actually is not delayed

http://bugs.winehq.org/show_bug.cgi?id=33311

--- Comment #3 from Alexandre Julliard  2013-04-01 05:41:28 CDT ---
Probably some other dll is importing the library you are looking at. Delay
imports definitely work.

[Bug 33311] Loading of libraries intended to be delay loaded for a built-in module actually is not delayed

http://bugs.winehq.org/show_bug.cgi?id=33311

--- Comment #4 from Dmitry Timoshkov  2013-04-01 06:47:49 CDT ---
(In reply to comment #3)
> Probably some other dll is importing the library you are looking at. Delay
> imports definitely work.

How do you test that delay imports work?

As far as I can see in the +relay,+module log if a dll such as setupapi.dll
(which delay loads winspool) is being loaded by a small preloader app (that
doesn't import winspool in any of its dependencies) then main application
which actually performs printing faces a bug fixed by
http://www.winehq.org/pipermail/wine-patches/2013-March/123253.html
The bug manifests itself that main app fails to print some of cyrillic
glyphs because generic.ppd gets used instead of the printer's PPD (because
libcups is treated by already loaded in winspool imported by main app) where
correct *TTRasterizer is specified instead of None (which in turn leads
to the bug fixed by
http://www.winehq.org/pipermail/wine-patches/2013-April/123263.html.

[Bug 33311] Loading of libraries intended to be delay loaded for a built-in module actually is not delayed

http://bugs.winehq.org/show_bug.cgi?id=33311

--- Comment #5 from Alexandre Julliard  2013-04-01 07:22:38 CDT ---
Delay imports are used all over the place, if they didn't work it would be
obvious.

Now it's possible that there's something broken for the specific case of
winspool, since the library name doesn't match the import name.

[Bug 33311] Loading of libraries intended to be delay loaded for a built-in module actually is not delayed

http://bugs.winehq.org/show_bug.cgi?id=33311

--- Comment #6 from Alexandre Julliard  2013-04-01 07:36:06 CDT ---
Created attachment 44061
  --> http://bugs.winehq.org/attachment.cgi?id=44061
Check delay name before parsing.

Something like this would probably help.

[Bug 33311] Loading of winspool.drv intended to be delay loaded for a built-in module actually is not delayed

http://bugs.winehq.org/show_bug.cgi?id=33311

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
      Fixed by SHA1|                            |2467c06a30e96f1b6f400b99af1
                   |                            |90a2a2033f5bf
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
            Summary|Loading of libraries        |Loading of winspool.drv
                   |intended to be delay loaded |intended to be delay loaded
                   |for a built-in module       |for a built-in module
                   |actually is not delayed     |actually is not delayed

--- Comment #7 from Dmitry Timoshkov  2013-04-02 01:19:39 CDT ---
Thanks Alexandre!

[Bug 33311] Loading of winspool.drv intended to be delay loaded for a built-in module actually is not delayed

http://bugs.winehq.org/show_bug.cgi?id=33311

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #8 from Alexandre Julliard  2013-04-12 13:46:25 CDT ---
Closing bugs fixed in 1.5.28.