From: Stefan Kuhr on 2 Oct 2009 16:38 Hi Ben, Ben Voigt [C++ MVP] wrote: > > <snip> > I doubt delay-load is used for entry-point forwarding. Exactly, forwarding has nothing to do with delay-loading. Delayloading is done with the help of a library, delayimp.lib. Without it, delayloading doesn't work. Forwarding is usually done by specifying it in your def file (at least this is how I did it in the past) and does not at all involve delayimp.lib. -- S
From: R.Wieser on 3 Oct 2009 08:33 Hello Ben, > You're thinking of trade secret rules, where > your rights depend on how you acquire the > information (and the burden of proving you > got it through an unencumbered source if > you were privy to the same information through > a restricted source). Not quite (about trade-secrets), but the description is what I was/am thinking about, yes. > The paragraph in question refers to patents. > You cannot use a patented idea without a > license, EVEN IF YOU DEVELOPED IT > INDEPENDENTLY. I know. That much I *do* understand from patent-law. As its at the very basis of patent-law I'm allso quit surprised that you think that is the translation of part of that EULA (its superfluous, like stating that water is wet) > Go see a lawyer for a proper explanation. Thank you for the suggestion, but no thank you. I'm a hobbyist, and have no intention to get even anywhere near the possibility of such a dispute. I allso have problems with the very notion of something *I* need to agree to can only really be read-and-understood by another person, who ofcourse expects to be handsomely be payed for doing so. Regards, Rudy Wieser -- Origional message: Ben Voigt [C++ MVP] <bvoigt(a)newsgroup.nospam> schreef in berichtnieuws 6ECB73FA-3D7A-468C-B1BF-8C0881E3AE13(a)microsoft.com... > > If its that your "plain English, and very clearly granting" than pardon > > me, > > but I think you're a fool. > > > > Currently I can use the PE info I allready have for/in any program on any > > OS > > I please. That is way more than I could do if I would accept that EULA. > > So > > yes, I *do* think its trying to restrict (me) and not, as you seem to > > think, > > grant (me) anything. > > You're thinking of trade secret rules, where your rights depend on how you > acquire the information (and the burden of proving you got it through an > unencumbered source if you were privy to the same information through a > restricted source). > > The paragraph in question refers to patents. You cannot use a patented idea > without a license, EVEN IF YOU DEVELOPED IT INDEPENDENTLY. Go see a lawyer > for a proper explanation. Of course that puts more money into the hands of > lawyers and encourages them to keep writing long complicated license > agreements :( > >
From: R.Wieser on 3 Oct 2009 08:53 Hello Ben, > Maybe this will help: [snip link] No, not really. I allready found that page (again, before posting here), and its quite devoid of actual information. At the end of it (including reading the responses and following links in them) I had/knew nothing more than I started with. :-\ At some point I got (still am) a bit frustrated. You see, none of the information (webpages and other) found offered anything *specific*, like how I can, when looking at the raw PE structure, recognise a forwarded function. Just a vague 'its there and <this> program wil show it'. Not really funny after having read thru the first 30-or-so promising hits (including quite a number of pages from MS own servers) Regards, Rudy Wieser P.s. My search for how delayed-loading functions work is actually a spin-off of my searching for how forwarded functions work. At some point I got the feeling that they might be the same, or at least that knowing how delayed-loading works could help me find answers to the other (currently I think I'm probably wrong in that, just as in my (past) feeling that they might even be the same thing ...). -- Origional message: Ben Voigt [C++ MVP] <bvoigt(a)newsgroup.nospam> schreef in berichtnieuws 4A22068E-BC8C-4C07-8D39-DCAD93A352CB(a)microsoft.com... > > > By the way : if you happen to know how relayed entries work (functions > > that > > are seemingly exported by a DLL, but are actually in another one, like in > > kernel32.dll -> ntdll.dll) I would certainly like to know. Its > > how-and-why > > I came to focus my attention to the delayed-import table. :-) > > > > Maybe this will help: > > http://blogs.msdn.com/oldnewthing/archive/2006/07/19/671238.aspx > > I doubt delay-load is used for entry-point forwarding. >
From: Liviu on 3 Oct 2009 11:53 "R.Wieser" <address(a)not.available> wrote... > > By the way : if you happen to know how relayed entries work (functions > that are seemingly exported by a DLL, but are actually in another one, > like in kernel32.dll -> ntdll.dll) I would certainly like to know. Its > how-and-why I came to focus my attention to the delayed-import table. AFAICT forwarding is independent from delay-loading and, for a difference, it does indeed require OS support from the loader. http://msdn.microsoft.com/en-us/magazine/cc301808.aspx || How can you tell if a function is forwarded rather than exported || normally? It's somewhat tricky. Normally, the EAT contains the RVA || of the exported symbol. However, if the function's RVA is inside the || exports section (as given by the VirtualAddress and Size fields in || the DataDirectory), the symbol is forwarded. || When a symbol is forwarded, its RVA obviously can't be a code or || data address in the current module. Instead, the RVA points to an || ASCII string of the DLL and symbol name to which it is forwarded. Liviu
From: R.Wieser on 3 Oct 2009 13:07
Hello Liviu, > AFAICT forwarding is independent from > delay-loading and, for a difference, it does indeed > require OS support from the loader. > > http://msdn.microsoft.com/en-us/magazine/cc301808.aspx Thank you, thank you, thank you. :-) All this time I've been looking at the wrong spot for the forwarding-table. Its there, in the *import*-section of the DLL. To add insult to injury, I even have, in my own PE-viewer, the name of that field in the import records correctly named "forward" (which I at the time I wrote it did not understand the fields function and as its contents where allways -1 I simply ignored it). I can now allso see that the W98se system-DLLs do not seem to be using forwarding, though some of them do have delayed-import tables. > || How can you tell if a function is forwarded > || rather than exported normally? That now seems to be pretty-much trivial : all the functions in the export-section are not, and those in the "forward" chain all are (as in meaning: its not a secret bit added to an exported name or ordinal). :-) Regards, Rudy Wieser -- Origional message: Liviu <lab2k1(a)gmail.c0m> schreef in berichtnieuws ea6uZHERKHA.1236(a)TK2MSFTNGP05.phx.gbl... > "R.Wieser" <address(a)not.available> wrote... > > > > By the way : if you happen to know how relayed entries work (functions > > that are seemingly exported by a DLL, but are actually in another one, > > like in kernel32.dll -> ntdll.dll) I would certainly like to know. Its > > how-and-why I came to focus my attention to the delayed-import table. > > AFAICT forwarding is independent from delay-loading and, for a > difference, it does indeed require OS support from the loader. > > http://msdn.microsoft.com/en-us/magazine/cc301808.aspx > > || How can you tell if a function is forwarded rather than exported > || normally? It's somewhat tricky. Normally, the EAT contains the RVA > || of the exported symbol. However, if the function's RVA is inside the > || exports section (as given by the VirtualAddress and Size fields in > || the DataDirectory), the symbol is forwarded. > || When a symbol is forwarded, its RVA obviously can't be a code or > || data address in the current module. Instead, the RVA points to an > || ASCII string of the DLL and symbol name to which it is forwarded. > > Liviu |