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

List:       perl5-porters
Subject:    [perl #123658] [PATCH] stop checking the Win32 registry if *"/Software/Perl" doesn't exist
From:       "bulk88 via RT" <perlbug-followup () perl ! org>
Date:       2015-05-28 20:03:03
Message-ID: rt-4.0.18-14692-1432843383-1180.123658-15-0 () perl ! org
[Download RAW message or body]

On Thu May 28 12:49:20 2015, bulk88 wrote:
> Looking at my winxp secur32.dll, I see secur32.dll loads advapi32.dll,
> so whether you delay load with Perl on GetUserNameA/advapi32.dll or
> GetUserNameExA/secur32.dll, when you call either both advapi32 and
> secur32 will wind up being loaded into the perl process in any case,
> the point is to keep advapi32/secur32.dll/rpcrt4.dll out of the
> process until you call getlogin. I need to do some research if calling
> GetUserNameExA/secur32.dll will trigger advapi32 to instantly delay
> load/bind itself to secur32 or not (perl->DelayLoadDLL@perl522.dll-
> > GetUserNameExA@secur32.dll->FooBar@advapi32.dll-
> > DelayLoadDLL@advapi32.dll->Baz@secur32.dll). If advapi32.dll stays
> unbound and unaware that secur32.dll is in the process even though
> secur32.dll is what loaded advapi32.dll into the process, some CPU and
> maybe a COW mem page (4KB) representing the delay import table in
> advapi32.dll is saved. Static dynamic linking is more efficient than
> the VC delay loader code I believe. For example the VC delay loader
> uses GetProcAddress, and each call to GetProcAddress has to get the
> DLL Loader mutex, while using static dynamic linking the lock is
> obtained once inside LoadLibrary() in kernel32/Ldr*() in ntdll.

The USERNAME env var could be used for getlogin instead of advapi32/secur32, but \
there is a tiny risk someone will mess with the env var in the parent process of perl \
(a cmd.exe process), or in the perl process at runtime. The USERNAME env var is \
created in Winlogon.exe, specifically in userenv.dll, userenv.dll calls \
GetUserNameExW from secur32.dll. No undocumented APIs there for me to try to use. \
USERNAME env var is then inherited down process tree. Both taskman and explorer, when \
launches from winlogon/ctl-alt-del screen get USERNAME. Service processes never have \
USERNAME in their env vars according to process explorer.

-- 
bulk88 ~ bulk88 at hotmail.com

---
via perlbug:  queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=123658


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