Use fallback for SQLColAttributeW for ODBC v2.0 drivers.
Use fallback for SQLGetDiagRecW for ODBC v2.0 drivers
Thanks Steve Fawcett
Use fallback for SQLBindParameter for ODBC v2.0 drivers.
Use fallback for SQLGetConnectAttr/W for ODBC v2.0 drivers.
Use fallback for SQLSetConnectAttr/W for ODBC v2.0 drivers.
Forward SQLSetConnectAttr onto driver.
Forward SQLError/W onto driver (new patch).
Functions SQLDataSources*/SQLDrivers* are local to this DLL and not forwards onto the driver DLL.
Hense the Environment handle being passed as the first parameter.
Said functions need to return SQL_NO_DATA to state we have no data instead of an SQL_ERROR.
Fixes: https://bugs.winehq.org/show_bug.cgi?id=56616
Allows it to run now, more work will be required to make it fully functional.
Even if one asserts that Silverlight is worth supporting in any capacity (which
I am not for the moment taking any position on), Pipelight is unusable without
downgrading Firefox. As Erich put it to me, "the point of Pipelight was to not
have to run the entire browser in Wine," but now a user would have to go to at
least such an extent anyway.
And, of course, nothing here is useful outside of Pipelight, or if it is, we
want to explicitly know about it so that we can document and properly support
those knobs.
This patch set is currently broken, as the RtlEnterCriticalSection()
implementation has changed without corresponding changes to the inline version.
More broadly, it is very surprising, and never really substantiated, that
inlining helps significantly. There is no record of why the patches were
written, but my guess is that they were written in an attempt to optimize heap
allocation, and my further guess is that targeting critical sections in
particular was motivated by perf traces.
Besides the fact that perf traces are unreliable on the best days, and that
anything that spins or uses atomics like our CS implementation is going to be
overrepresented especially relative to the practical impact, the heap
implementation was optimized for cases that matter with the introduction of the
LFH, and crucially, the LFH is lock free.
As for threadpools, I suspect that Sebastian took note of them as the only other
user of locking in ntdll, and that the inline version was used there because
there was no real reason not to.
At the end of the day, these patches are incorrect, probably help nothing, and
even if we did find they helped something we'd want to do a lot more
investigation and probably solve the problem a different way. Remove them.
