PE delayed import table - need a description.
in [Win32 Kernel]
|
From: R.Wieser on 1 Oct 2009 09:00 Hello Stefan, > Delayloading is not an OS feature. It is a linker feature. I do not quite agree with you there : the linker may create and insert such a table in the PE image, but without support for that table by the OS-provided program-loader-and-starter that table would be meaningless. > Rudy, just in case that helps you: I have written an article > around some common code of mine a few years ago, which > can be found here and which deals with finding delay-loaded > imports: I see the article. To bad that it does not show any code, and downloads are only available to members (which I am not, and have no intention of becoming) ... > It is based on an MSDN magazine article from Matt Pietrek > from February 2002 which can be found here: It allso mises to state the most basic of information : how is a value in that delayed-import table translated to a pointer inside the program-image (if that is what actually has to be done). :-\ I just realized that the image-base value is a same kind of big number. Alas, subtracting it from the values in the table does not result in any value that is a valid pointer for any of the sections in the image. Thanks for the (attempted) help though. Regards, Rudy Wieser -- Origional message : Stefan Kuhr <kustt110(a)gmx.li> schreef in berichtnieuws #HFfp#nQKHA.1232(a)TK2MSFTNGP05.phx.gbl... > Hi Rudy and Remy, > > R.Wieser wrote: > > <snip> > >>> As I allready mentioned, no such info is present in the > >>> 1999 version ... > >> Because Microsoft was not delay-loading DLLs yet in > >> 1999. > > > > Really ? Thats funny, as I found a table named "The Delay-Load Directory > > Table" (entry 13) in the 1999 spec, and a ntdll.dl with an OS-version of 4.0 > > (W98se) using that table. Or is that table something else altogether ? > > > > Reference : > > http://download.microsoft.com/download/e/b/a/eba1050f-a31d-436b-9281-92cdfea > > e4b45/pecoff.doc > > > > Its allso quite strange that the above-named table is mentioned in that 1999 > > document, but not actually explained in there. > > > > > > Remy is wrong with his statement, that in 1999 there was no delayload > support in MS's development products (that is how I interpret "Microsoft > was not delay-loading DLLs yet in 1999." and that he contrasts this with > Borland's compilers' ability to create binaries with the delay-loading > feature when he says "Borland had already implemented delay-loading in > its compiler by that time...") > > VC6 was the first C/C++ compiler/linker from MS that had the > delay-loading feature. It was mentioned for instance in Matt Pietrek's > "Under The Hood" column of the December 1998 "Microsoft Systems Journal" > issue. The files on my VC6 installation CD date back to the June/July > 1998 timeframe. So it should be clear that by autumn 1998 there was > indeed delay-load support in MS compilers/linkers. > > > > > I just checked the Kernel32.dll of an XP installation (OS version 5.1), and > > it has got a same-formatted "The Delay-Load Directory Table" as the above > > w98se ntdll.dll (a list of DWORDs). > > > > I'm confused : With which version of Windoes *did* that delayed-import of > > functions come to life, and what was the tables meaning/use before than ? > > > > > Delayloading is not an OS feature. It is a linker feature. I have > written applications using VC6 that use delayloading and even run on > NT3.51 which clearly predates the introduction of delayloading as a > linker feature. > > Rudy, just in case that helps you: I have written an article around some > common code of mine a few years ago, which can be found here and which > deals with finding delay-loaded imports: > > http://www.codeproject.com/KB/files/pefiles.aspx > > It is based on an MSDN magazine article from Matt Pietrek from February > 2002 which can be found here: > > http://msdn.microsoft.com/en-us/magazine/cc301805.aspx > > > Cheers, > > -- > S
From: Stefan Kuhr on 1 Oct 2009 10:55 Hello Rudy, R.Wieser wrote: > Hello Stefan, > >> Delayloading is not an OS feature. It is a linker feature. > > I do not quite agree with you there : the linker may create and insert such > a table in the PE image, but without support for that table by the > OS-provided program-loader-and-starter that table would be meaningless. > Did you take a look into the MSJ article, that I mentioned? It explains how delayloading atually works. And no, there is no OS support needed for delayloading. Maybe another quote helps here, this time from an MSDN magazine article of February 2000, again from Matt Pietrek and his "Under the hood" column: "[...] I still find people who don't know anything about DelayLoad or they think it's some feature that's available only in the latest version of Windows NT�. For starters, let me scream from the highest rooftop that DelayLoad is not an operating system feature. It works on any Win32�-based system." > > [...] and downloads are > only available to members (which I am not, and have no intention of > becoming) ... In that case, I can't help. -- S
From: R.Wieser on 1 Oct 2009 11:34 Hello Stefan, > Did you take a look into the MSJ article, that I mentioned? > It explains how delayloading atually works. Where ? I found four references to the word "delay" : 1) ====== Optimizations such as delay loading of DLLs, section merging, and binding were still over the horizon ====== No info there. 2,3&4) ====== Visual C++ 6.0 added the delayload feature, which is a hybrid between implicit linking and explicit linking. When you delayload against a DLL, the linker emits something that looks very similar to the data for a regular imported DLL. However, the operating system ignores this data. Instead, the first time a call to one of the delayloaded APIs occurs, special stubs added by the linker cause the DLL to be loaded (if it's not already in memory), followed by a call to GetProcAddress to locate the called API. ====== Minimal info, nothing explicit. No description of *how* it works anywhere in sight. Not even a mentioning what that "delayed import table" is actually used for. :-\ May I mention that I allready found-and-read that article before I posted my question/request. Yes, I acknowledge that its possible to create a delayed-loading mechanism without the aid of the OS. Though in that case the need for such a special table (why not simply store it in a data-segment somewhere, as its DLL local code and data) escapes me. > > [...] and downloads are only available to members > > (which I am not, and have no intention of becoming) ... > > In that case, I can't help. Your article-code is only available there ? Bummer. (yes, its only available there. Although a quick Google-search showed 5 pages, all link back to that one article) Regards, Rudy Wieser -- Origional message : Stefan Kuhr <kustt110(a)gmx.li> schreef in berichtnieuws #j$UPeqQKHA.2092(a)TK2MSFTNGP04.phx.gbl... > Hello Rudy, > > R.Wieser wrote: > > Hello Stefan, > > > >> Delayloading is not an OS feature. It is a linker feature. > > > > I do not quite agree with you there : the linker may create and insert such > > a table in the PE image, but without support for that table by the > > OS-provided program-loader-and-starter that table would be meaningless. > > > > Did you take a look into the MSJ article, that I mentioned? It explains > how delayloading atually works. And no, there is no OS support needed > for delayloading. > > Maybe another quote helps here, this time from an MSDN magazine article > of February 2000, again from Matt Pietrek and his "Under the hood" column: > > "[...] I still find people who don't know anything about DelayLoad or > they think it's some feature that's available only in the latest version > of Windows NT�. > For starters, let me scream from the highest rooftop that > DelayLoad is not an operating system feature. It works on any > Win32�-based system." > > > > > > [...] and downloads are > > only available to members (which I am not, and have no intention of > > becoming) ... > > In that case, I can't help. > > -- > S > > >
From: Stefan Kuhr on 1 Oct 2009 11:50 Hi Rudy, R.Wieser wrote: > Hello Stefan, > >> Did you take a look into the MSJ article, that I mentioned? >> It explains how delayloading atually works. > > Where ? > > I found four references to the word "delay" : > > 1) > ====== > Optimizations such as delay loading of DLLs, section merging, and binding > were still over the horizon > ====== > No info there. > > 2,3&4) > ====== > Visual C++ 6.0 added the delayload feature, which is a hybrid between > implicit linking and explicit linking. When you delayload against a DLL, the > linker emits something that looks very similar to the data for a regular > imported DLL. However, the operating system ignores this data. Instead, the > first time a call to one of the delayloaded APIs occurs, special stubs added > by the linker cause the DLL to be loaded (if it's not already in memory), > followed by a call to GetProcAddress to locate the called API. > ====== > Minimal info, nothing explicit. No description of *how* it works anywhere > in sight. Not even a mentioning what that "delayed import table" is > actually used for. :-\ > > May I mention that I allready found-and-read that article before I posted my > question/request. Ah I see you are talking about the msdn magazine article I referred to. However, I asked: "Did you take a look into the MSJ article, that I mentioned?". Look at the **MSJ** article from December 1998, that I referred to as well. I hope it is still on the web somewhere. If you have an older MSDN Library, it is under the "Periodicals" section. This article might help. > > Your article-code is only available there ? Bummer. (yes, its only > available there. Although a quick Google-search showed 5 pages, all link > back to that one article) > Please send an email to the email address used for this newsgroup posting. I normally do not monitor this email address, but I will do in this case and send you the article's code. Although I really don't think that it is too much of an effort to sign up at CodeProject. -- S
From: Stefan Kuhr on 1 Oct 2009 11:54
Hi everyone, Stefan Kuhr wrote: > <snip> > Ah I see you are talking about the msdn magazine article I referred to. > However, I asked: "Did you take a look into the MSJ article, that I > mentioned?". Look at the **MSJ** article from December 1998, that I > referred to as well. I hope it is still on the web somewhere. If you > have an older MSDN Library, it is under the "Periodicals" section. This > article might help. > http://www.microsoft.com/msj/1298/hood/hood1298.aspx -- S |