[Autogenerated] we talked about the fact that the loader,
once it starts running code in the new process,
one of the last things it does is to load all the
dependencies for the executable,
the ones that can be read from the PE file itself.
And so the information,
the P file only contains names of DLS and all the symbols that are
imported or used by by the process or by the executable to be more
precise and the names of the DLS are just the finance,
there is no full path there and this is intentional and now
it's the job of the Lord er to figure out where those files
are and uses a certain search order, which I want to describe now.
So it just has the final name itself, like kernel 32 dot Dll.
And it's up to the loader now to figure out where that file is, if any.
So the first location to be searched,
which is not really a search that is performed and by the way this search orders
the same that is done by calling the load library function,
which will demonstrate later in this module if you just specify a fine name,
it goes through the same search order.
So the first location is the known DLS and so known DLS um,
is a set of DLS that are listed in the registry in a certain key that
are being mapped very early in the windows boot,
two section objects which are used to map files in this case,
those pE files And those always take precedence over any kind of file
system search and so it's not possible to spoof a process or executable by
providing an alternative version of Kernel 32,
for example, because it is part of the known dealers list.
And so the next thing,
assuming that the question is not part of the non d alleged list.
The next location to look for the alliance is the directory of the executable.
That's the first location being searched in the file system and that
should be the most common case for private dealers used by the process
that are needed by that executable by process created based on that
executable it makes it easy to move around the application just by
coping all the files to a different directory and that's why it's the
preferred way or the preferred location to put the LS that the
executable needs.
And then if the delay is not found there the next direction to be searched
is the fairly well known System 32 directory that can also be obtained
programmatically using the Gate System Directory,
API And this is where most of the Microsoft DLS reside.
And so um System 32 contains those Microsoft DLS and we typically don't want
to put our own private dealers in the system 32 directory.
That would be a bad idea.
In fact it would cause issues that even were given a name called DLL ____.
So what's DLL ____.
And so suppose they have an application a being installed and
the that's using a Dll called X dot Dll.
And that's putting those,
that particular DLL system 32 because it knows it will always be founder.
So you're an application and everything seems to be working fine.
However next you might be installing application called B,
which is a different application,
but it is using another DLL that has the name X dot Dll.
In fact, it could be the same kind DLL, but perhaps a newer version.
And if that application puts its version into system 32 it
would overwrite the previous x dot Dll.
Now, application B runs just fine,
but application A fails to run or misbehaves in some way because
compatibility might not be perfect between the second version and
the previous version of x dot Dll.
So that is the problem.
The advantage of putting things in system 32 is that
they can be shared in physical memory, which of course saves round,
which is nice.
However, because of the Dll health problem,
this is not considered a good practice anymore.
And even if you might have these two X Dll files,
which might happen to be the same with exactly the same
version stored in different directories,
each one in the current directory or the executable
direct Of those applications,
they will not be shared in physical memory because they're
coming from different paths and windows will not compare those
files bite by bite for sharing purposes,
so you might be wasting a bit more ram but because Ram sizes too,
they're much bigger than they used to be in the past,
it's considered still a better approach for stability and robustness.
So season 32 really should be used just for Microsoft's own binaries.
So next if the delay in question is not found there,
the next location to be searched is the Windows directory,
something like C Windows, which is the case for most systems.
Again, this is part of the default search path.
If it's not found even there,
then the current director of the process is being searched.
This is a property of a process you might recall from the creative process API
the creator can provide its own or some current director that's going to be used
as part of this search path for the new process.
Normally after the process already alive and well,
it can change its own current directory by calling the set current
directory P which affects further loading of other dealers that are
loaded explicitly but for the purpose of just loading those
dependencies when the process just starts up,
there's no code in the executable that has a chance to run just yet.
So the current directory is is provided by the creator,
you might be familiar with that in a different aspect if you create a shortcut,
for example, like on the desktop,
you can specify something called the working directory and
that working directory is the one that's going to be used by
Windows Explorer when it calls,
create process on your behalf when you double click that shortcut.
So this is where that current director is coming from,
in case you're creating a shortcut.
But in general,
the creator has the power to provide that extra directory for for
this for search purposes for these dependencies.
And finally that DLL is not found even in the current director of the process.
The last locations to search are all the past that are listed in the path
environment variable which of course can contain multiple directories or
searched in sequence in order until the deal is found or not.
And if it is not found,
this is where the LAUDER gives and we get something like this.
We get this _____ message box saying the code couldn't really
move forward because the DLL was missing.
Couldn't find this particular DLL in this case, it's some sample leave dot dll.
So in that case the process shuts down and the L will
terminate the process and that is it.
So obviously all these dependencies have to be fulfilled in order for
the process to make its way into the main function.
And of course, it's not just about finding dealers themselves,
it's also about running their DLL main function,
which we'll look at in some more detail later on in this module.
Um,
so that dealers can initialize themselves properly and they all
have to report success in that initialization.
If anyone reports a failure, then a different message box is going to be shown,
but the final result is the same, the process is going to terminate.