[Bug 7414] Feature Request: provide SharedUserData area + accessors

[Wine Bugs]

http://bugs.winehq.org/show_bug.cgi?id=7414

------- Additional Comments From [e-mail]  2007-14-02 02:33 -------
Hello,

well i followed control flow of some apis and saw places in kernel32 exports
that access this area like this:

--- snip pseudocode ---

==== kernel32 usermode api

some_info_accessor()
{

// short circuit like a cache
if( getSharedUserData()->MemberValid)
{
   return getSharedUserData()->MemberData;
}

// "cache miss" -> make call to native api to fetch info
var ret_data;
SetLastError( NtStatusToDosError( NtQuerySystemInformation( info_class,
&ret_data, sizeof(ret_data), 0)));
return ret_data;

}
}

===== native api:

NtQuerySystemInformation():

case some_info_class:

// first time init ?
if( !getSharedUserData()->MemberValid)
{
  // collect info .. read from file, registry, make calls to other native api
  do_some_lengthy_stuff()
  // set member data = valid
  getSharedUserData()->MemberData = data_from_lengthy_op()

...
  lasterror()
}

*ret_val = getSharedUserData()->MemberData;

...
---

So i wanted to mimic that behavior.
But you got a point. It might not be a good idea at all...
To quote from MSDN:

--- quote ---

The NtQuerySystemInformation function and the structures that it returns are
internal to the operating system and subject to change from one release of
Windows to another.

--- quote ---

So i have some options left.

First option is to completely handle the stuff in "high level" kernel32 exports,
implementing local cached data "one time init" and skipping the
NtQuerySystemInformation stuff (the stuff from NtQuerySystemInformation() case
goes to kernel32 exports). 
This might lead to code duplication if same mechanism is used twice somewhere in
other modules than kernel32 (one has yet to see).

Another option: use local cached data "one time init", if cache miss call
NtQuerySystemInformation() right away.
NtQuery .. implements the stuff like shown in pseudo code except no shared data
struct used.
The returned data from call is directly used to update the local cached data in
kernel32.

I think option 1 is way to go (i guess implementing undocumented system info
classes is not your preferred choice).

Regards