How does executable load dll ?

[exor]

hi

tutorial 15 is about hal, wrote in c;

hal functions are compiled as dll, and linked to exe ... i've understood stage2 loads kernel.exe and call entry point ( main() ), but how does kernel.exe refers to dll without include in as lib ?
should it to load dll in memory or not ?

and after load an exe, how does it knows the address where i loaded to ?
is not VAS implemented by kernel ?

[Mike]

Hello,

The main series does not use DLLs for simplicity purposes. Instead, all libraries are built and linked into the kernel as static libraries.

This does not limit you from adding DLL loading support yourself (It isnt hard) if you decide to try it.

[exor]

how does exe know the address where i loaded to ?

and couldn't i to use binary format ?
if i'll use a binary library, for example, i could to create an header where exe retrieves functions addresses, isnt it?

the main question is, why do we use pe format and dlls ?
can we make a form of dinamic library (in binary form), to load when kernel binary file instead pe needs it ?

it seems much better then make a kernel of 1 mb, with every library included in

i'm sorry for these questions, but till tutorial 15, everything was explained fine, here something (like the need for pe format instead bin) was not explained and that makes some trouble :S

tnx for help

[Mike]

Hello,

how does exe know the address where i loaded to ?

The EXE base address can be retrieved from either MSVC itself. Through programming, this involves reading a sector or two of the file and obtaining its base address (to load it to) from the PE header structures (This is described in the MSVC chapter.)

DLLs are the same way.

You will need to write your own tool if you decide to create your own library format (that of what you described.) The series uses PE format because it currently only uses the toolchain provided by MSVC. I use the PE format and DLLs in Neptune (my real OS) because I prefer them. You do not need to use any format (or even go with ELF if you prefer), it will just require some changes in your setup.

Even so, I personally would not include any of the projects as DLLs if you want to go microkernel. Rather, it would be better to build a driver interface, load them, and treat them as real drivers rather then kernel DLLs. Kernel DLLs should be reserved for kernel-specific functionality.

---

The series uses C (technically C++ but its features were never used.) as it is basically the standard systems programming language. The series provides chapters describing the setups and basic formats for different compilers (although currently only PE and MSVC are described., GCC with PE and loading with GRUB has also been possible.)

Please note that the use of PE format and how to set up MSVC to use it is explained in the Kernel Setup chapters. As of current, the only one is Kernel Setup: MSVC which provides the information you need.

[exor]

o.O

The EXE base address can be retrieved from either MSVC itself. Through programming, this involves reading a sector or two of the file and obtaining its base address (to load it to) from the PE header structures (This is described in the MSVC chapter.)

uhm .. how can msvc set the address where exe is loaded to if it doesn't know how many free memory is there ?

:S

[Mike]

Hello,

MSVC provides an option for setting the preferred base address of the executable image. This value is set in the programs header structure which can be read by your bootloader to load the program binary at that location in memory.

This is the way the series bootloader loads your kernel.

[ehenkes]

There I explain how DLL works:
http://www.henkessoft.de/C++/WinAPI/Win ... 6/api6.htm

[exor]

tnx i've read MSVC tutorial and i've understood

so, the story is that we've to load images manually in a fixed memory address. The same thing is for dlls (i found an microsoft doc where they explain dlls header is as pe header, only a check byte changes).

i suppose the only way is that untill we use a VAS method that should we to allow to set base address of our images to 0x0 ...