#1823 msys.dll: Don't pull user32.dll just to see if right alt ...


Subject: [PATCH] msys.dll: Don't pull user32.dll & friends just to detect whether right alt should be used as meta

I've discovered that every msys program pulls lots of dlls on startup.
In particular the following simple program

---- 8< ----
#include <stdio.h>
#include <stdlib.h>

int main()
printf("Hello World\n");
---- 8< -----

when compiled with mingw compiler, executes almost instantly, but when
compiled with msys compiler and linked with msys.dll, starts
significantly longer - ~0.2 - 0.5 seconds depending on machine.

As Kirill K. Smirnov already found[1] the problem lies in that on
startup, msys.dll pulls in user32.dll and does lot's of "unnecessary
things". And the following test justifies it:

$ WINEDEBUG=loaddll wine xmsys.exe
trace:loaddll:load_builtin_dll Loaded L"KERNEL32.dll" at 0x7ed50000: builtin
trace:loaddll:load_native_dll Loaded L"Z:\\home\\kirr\\src\\tools\\git\\msysgit\\bin\\xmsys.exe" at 0x400000: native
trace:loaddll:load_native_dll Loaded L"Z:\\home\\kirr\\src\\tools\\git\\msysgit\\bin\\msys-1.0.dll" at 0x68000000: native
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\advapi32.dll" at 0x7e950000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\gdi32.dll" at 0x7e780000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\version.dll" at 0x7ef30000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\user32.dll" at 0x7e820000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\imm32.dll" at 0x7e410000: builtin
trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\winex11.drv" at 0x7e5c0000: builtin

Investigating showed that msys.dll imports kernel32.dll only, but also
implements some form of lazy-import (see .../winsup/cygwin/autoload.cc)
for symbols from other dlls, with the intention (as I see it) not to
other system dlls until needed.

But also, it turned out, that in order to see whether AltGr should be
used as META or not, on _every_ msys startup, we were calling
GetKeyboardLayout() which is from user32.dll OOPS...

Avoid that, and suddenly my test program runs significantly faster. It
still pulls in advapi32.dll - this can be investigated later...

[1] http://bugs.winehq.org/show_bug.cgi?id=13606#c8

Signed-off-by: Kirill Smelkov <kirr@landau.phys.spbu.ru>


  • Earnie Boyd

    Earnie Boyd - 2013-02-14

    Ticket moved from /p/mingw/patches/484/

  • Earnie Boyd

    Earnie Boyd - 2013-02-14
    • labels: msys -->
    • status: open --> assigned
    • assigned_to: Cesar Strauss
    • milestone: --> MSYS
    • type: --> Task
    • resolution: --> none
    • category: --> Unknown
    • patch_attached: --> True
  • Sebastian Schuberth

    As part of contributing the "msysgit" changes back upstream I'd really like to see this patch applied. Any particular reason for it not being considered for two years now?

    • Cesar Strauss

      Cesar Strauss - 2013-05-13

      Any particular reason for it not being considered for two years now?

      Sheer lack of time. Also, I was giving priority to some other bug-fixing patches (this is more of an enhancement patch).

      I appreciate the effort to contribute changes upstream. I'll work on this.


  • Cesar Strauss

    Cesar Strauss - 2013-05-13
    • labels: --> cesar-work-in-progress
  • Cesar Strauss

    Cesar Strauss - 2013-08-01
    • labels: cesar-work-in-progress --> new-in-msys-1.19
    • Type: Task --> Feature
    • Resolution: none --> accepted
    • Category: Unknown --> IINR_-_Include_In_Next_Release
  • Cesar Strauss

    Cesar Strauss - 2016-07-15

    Released with msys-runtime 1.0.19.

  • Cesar Strauss

    Cesar Strauss - 2016-07-15
    • labels: new-in-msys-1.19 --> new-in-msys-1.0.19
    • Category: IINR_-_Include_In_Next_Release --> Unknown
  • Cesar Strauss

    Cesar Strauss - 2016-07-15
    • status: assigned --> closed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks