[ros-kernel] TEB offsets wrong - suggested fix - feedback pls
Mike Nordell
tamlin at algonet.se
Thu Feb 5 15:13:02 CET 2004
Royce Mitchell III wrote:
> The TEB needs some work...
>
> Here's a snippet illustrating the problem:
>
> PVOID UserReserved[5]; /* 700h */
> PVOID glDispatchTable[0x118]; /* 714h */
> ULONG glReserved1[0x1A]; /* B74h */
>
> okay, first problem: glDispatchTable starts at offset 7C4, not 714, and
> has 163 (A3h) entries.
Is that a problem? AFAIK this is an opengl32.dll-private area, holding the
function pointers to the implementation (opengl32.dll-provided, or 3:rd
party vendor provided OpenGL DLL). As such, the only thing it would prohibit
would be using a Microsoft proprietary opengl32.dll - something that would
still be dependent on version of NT this DLL was ripped from. AFAIK NT4 and
NT5 uses different offsets (check NT4 and I think you'll find those offsets
are correct).
As such, I'd even propose a "better" solution - remove this array
completely! :-)
Less than 1% of the applications used are using OpenGL. Yet every thread in
the system pays the penalty of this memory usage (OK, so it still fits one
page, why it won't be noticed - but I think it's still waste).
I'd rather propose ReactOS's opengl32.dll use TlsAlloc, and GlobalAlloc a
struct (holding among other things the vector of these function pointers).
Doing one single more pointer indirection to get to the function pointer
will IMHO not be noticed in context when calling OpenGL functions.
While speaking of OpenGL...
There is the problem that many OpenGL applications are hard-coded to check
for the string "Microsoft" for GL_VENDOR, where they really should have
checked for PFD_GENERIC_ACCELERATED in the PIXELFORMATDESCRIPTOR. That means
ReactOS will have to present itself exactly as Microsoft does for GL_VENDOR.
There's also the matter that MS OpenGL software implementation is (still
:-<) only OpenGL 1.1, while the obvious choice of Mesa for default software
OpenGL implementation is way above this (1.4?). What's the intention in this
area? Strip all but the basic 1.1 functionality from Mesa, or provide its
1.4 (?) software implementation?
> second problem: glReserved1 - listed as being offset B74h, *isn't at*
> B74h. 714h + 118h = 82Ch
Again, depends on version.
[snip]
> I'm convinced my patch is correct,
Depending on version of NT you compare with it might be. Or not. :-)
/Mike
More information about the Ros-kernel
mailing list