[ros-kernel] TEB offsets wrong - suggested fix - feedback pls

Royce Mitchell III royce3 at ev1.net
Thu Feb 5 10:06:36 CET 2004


The merits of the opengl function table being in the TEB has been argued 
in great detail in linux circles, and I don't wish to engage in it here. 
It's how MS does it, and opengl performance is important because gaming 
is going to be a large market for ReactOS.

Even if the exact offsets for GL don't matter, there's still a problem 
with the TEB that my patch corrects, and that is that all offsets listed 
after the GL stuff *must* be wrong, because the GL stuff made them 
incorrect, at least.

Royce3

Mike Nordell wrote:

>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
>
>_______________________________________________
>Ros-kernel mailing list
>Ros-kernel at reactos.com
>http://reactos.com/mailman/listinfo/ros-kernel
>
>.
>
>  
>



More information about the Ros-kernel mailing list