🚀 go-pugleaf

"Bob Gonder" <notbg@notmindspring.invalid> wrote in message
news:rftcp05c1rv7h9tahtrs9i6u38kt3au33b@4ax.com...

> I don't think that last part is correct.

Yes, it is correct.  When starting a new process, the OS looks at all of the
functions that the executable statically links to, and tries to resolve the
calls to the appropriate DLL files.  If any function cannot be found in the
DLL that it belongs to, the OS fails to load the process at all, displaying
an error message to the user.  This is done before a single line of code in
the executable is processed.

> I don't think the startup even knows which functions you use.

Yes, it does.  The compiler stores all of the statically linked DLL function
names into a special lookup table in the executable file.  The OS loader
automatically updates that lookup table with the appropriate memory
addresses for all of the specified DLLs and called DLL functions.  This
table is required because DLLs can be loaded into different memory
addresses, so a lookup table is needed so that the executable code does not
need to programmed with the actual memory addreses used at runtime.  The
executable stores the desired function names and offsets, and then the OS
automatically updates the table appropriately with the real memory addresses
after the DLLs have been loaded into the process address space during
startup.

> It just fills in the table with what it finds in the dll. If a table
> entry isn't filled in (new function, didn't exists in old dll) then
> if the application calls it, it gets a return error of function
> not supported.

Wrong.  If the code makes a call to a newer function, that function is still
stored in the static lookup table, and the OS tries to resolve its memory
address at startup.  If not found, since it does not exist on an older
system, then the process fails to load at startup.

> For example: CopyFileEx on '98 system has GetLastError
> of 120. Same for MoveFileEx

Those functions actually exist in Win98.  You can verify that for yourself
by loading kernel32.dll into any program that displays the export table
information.  Under Win98, you will see the functions listed.  They simply
have empty implementations that sets the error code.

This is not the case with the WinInet API, which is what is actually under
discussion at the moment.

> It's an ilink32 option.

Actually, it is a compiler option.  The compiler produces different code for
the function calls that call into delay-loaded DLLs.  As far as ilink knows,
the programmer may have writen the code directly.  It is normal C code,
which you can see for yourself in the
"$(BCB)\Source\RTL\source\misc\delayhlp.c" file, if you have Borland's
VCL/RTL source code installed.

The delay-load code maintains a runtime lookup table of DLL handles and
function pointers.  When you statically call a function in a delay-loaded
DLL, the compiled code is actually invoking the lookup code instead.  That
code checks to see if the DLL is already loaded or not.  If not, then
LoadLibrary() is called.  Then the function pointer is loaded via
GetProcAddress().  Finally, if the function pointer ends up as NULL because
the DLL could not be loaded or the function does not exist, then a runtime
error is thrown for the function call (which can be caught via the
__pfnDliFailureHook notification hook).


Gambit