This, in particular, fixes Farlight 84 getting locked in a thread performing wbemprox queries which results in voice chat not working.
The game seems to leak EnumClassObject returned from _ExecQuery on a different thread which does some wbemprox queries earlier (and succeeds). Then, doing wbemprox queries from another thread hangs that thread forever because a builtin table has CS locked by the previous thread (with table grabbed in the query's view). Leaking (or intentionally keeping) wbemprox objects shouldn't block different threads.
I think even without leaking any objects the current way of avoiding races on tables is problematic: - the query / table may be released from a thread different from which executed query / take CS; - if two threads are doing queries in parallel and access builtin tables in different order that may deadlock.
The attached patch gets rid of CS in the table and instead copies the table when needed (that seems to be just one place in query.c:exec_select_view(). The rest is boilerplate to make the table 'const', which is not strictly needed but I suppose that would be helpful to avoid accidental racing on table access in the future.