[ros-kernel] Differences between ntdll and ntoskrnl Rtl functions

[Eric Kohl]

"Gunnar Dalsnes" <hardon at online.no> wrote:

> I guess i'll dump the ntdll variant and go for the ntoskrnl variant [Ptr =
> (PULONG)BitMapHeader->Buffer + (StartingIndex / 32); etc.etc.]
> I don't know if it's a bug since it looks like both versions should work
as
> expected, but i think it's strange that they are different in the first
> place, like it was done on purpose...

IIRC, Hartmut Birr modified one implementation but forgot to modify the
other one.


> And the atom tables: i'll reenable the locking of the kmode atom table.
>
> Most stuff are now merged, but still problems:
>
> Ntdll\rtl\registry.c->RtlQueryRegistryValues and
> ntoskrnl\rtl\cm\rtlfunc.c->RtlQueryRegistryValues are very different. The
> ntdll version does correctly handle the environment argument while the
> ntoskrnl variant seem to have various other improvements. Can one of them
be
> dumped or should i try to merge them?

Don't merge them! Kernel-mode doesn't use the environment because it is a
user-mode-only concept. Both versions have to stay the way they are.

Btw, don't dare to merge the rangelist code! Both implementations differ and
I plan to use a lookaside list for the kernel-mode version.


> Another problem:
> First priority is to get all shared (ntdll/ntoskrnl) components into rtl
but
> i would prefer to add every rtl component into the library. This would
have
> worked fine if the linker would behave. Currently the linker links in
object
> files without external references also, bloating both ntoskrnl and ntdll
> with unused and non-exported rtl routines. Is it possible to fix this by
> passing some parameter to the linker?

This is one of the reasons why I am strictly against sharing source code.
Most linkers work object-file-based. This means they cannot take a function
from an object file and omit the unused ones they add all code of an object
file. That's why the runtime libaries use to implement a single function per
source file.

Another reason against shared code is the fact that a simple 'make ntdll'
won't build the shared code even if it has been modified. This requires a
'make rtl' and 'make ntdll'. This effect caused me a lot of trouble when I
fixed the FAT12/16/32 format code for usetup because the format code resides
in vfatlib, so 'make vfatlib' must be run before running 'make usetup'. IMO,
this is not acceptable.

The third reason against sharing source code this the fact that
implementations may differ more or less. ExAllocatePool vs. RtlAllocateHeap
come to my mind. Adding wrapper functions to hide the differences raise the
complexity of the code without a real gain.

IMO, the disadvantages of sharing code outweigh the benefits.


Regards,
Eric Kohl