What assembly is this RuntimeAssembly?

Say that you are debugging a .NET application in windbg and happen to have a System.Reflection.RuntimeAssembly (the actual implementation of System.Reflection.Assembly) and you want to find out which assembly it actually references. You could try dumping the object (i'm using the sosex extension here):

That wasn't very helpful. The object is just a thin wrapper around the native object pointed to by m_assembly. So what is this object? This is what it looks like:

A good trick is to check whether the first value is a vtable pointer:

So apparently the object is a DomainAssembly object, whatever that is (you can find some of these classes in the Rotor source, but the structure of them are vastly different). Using this trick combined with the !mln sosex command we find:

The PEAssembly object:

CAssemblyName? That sounds promising, right?

and…

There was the name. And we had a pointer to the AppDomain earlier, so that should be sufficient to uniquely identify the assembly. I haven't figured out where the actual assembly or module objects as used by !DumpAssembly and !DumpModule resides, but they are probably somewhere in there (the modules are CModule objects, the assembly objects starts with a null pointer, so I couldn't tell the C++ class from that).

Fixing frequent freezing of Wasteland 1 when using mouse

UPDATE: According to inXile this fix will probably be incorporated into the next patch.

UPDATE2: This has been incorporated into patch 2.

Wasteland (the original) has a problem where it randomly freezes after playing for some time.
From the known issues FAQ:

The game freeze frequently.
o This is a heritage issue which may be circumvented by using only the keyboard to control the game.

Also:

In general, fixing legacy issues is a quasi-impossibility as the original is not buildable.

I'm not completely sure about what they mean by "not buildable", but frankly I would rather that inXile focus on T:ToN and Wasteland 2 than wasting resources on fixing legacy code from 25 years ago. However nothing prevents me from "wasting" resources on fixing 25 year old dos games. So I took it upon myself to localize and fix the issue.

The short version is this: find rom\DATA\WLA.BIN in your steamapps/GoG folder and open it in your favourite hex editor, go to offset 0E5E where it says "77 1F" and replace with "EB 1F". The long version below explains how I figured this out, and probably requires a good understanding of x86 assembler and the PC platform to read.
Continue reading

__declspec(thread) on windows

Microsoft Visual C++ Compiler v.100 (the one for Visual Studio 2010) compiles the main function of the following short program:

__declspec(thread) int i = 0;

int main() {
    i++;
}

To this:

int main(int argc, char **argv) {
00CC1890  push        ebp
00CC1891  mov         ebp,esp
00CC1893  sub         esp,0C0h
00CC1899  push        ebx
00CC189A  push        esi
00CC189B  push        edi
00CC189C  lea         edi,[ebp+FFFFFF40h]
00CC18A2  mov         ecx,30h
00CC18A7  mov         eax,0CCCCCCCCh
00CC18AC  rep stos    dword ptr es:[edi]
	i++;
00CC18AE  mov         eax,dword ptr ds:[00CC8194h]
00CC18B3  mov         ecx,dword ptr fs:[0000002Ch]
00CC18BA  mov         edx,dword ptr [ecx+eax*4]
00CC18BD  mov         eax,dword ptr [edx+00000104h]
00CC18C3  add         eax,1
00CC18C6  mov         ecx,dword ptr ds:[00CC8194h]
00CC18CC  mov         edx,dword ptr fs:[0000002Ch]
00CC18D3  mov         ecx,dword ptr [edx+ecx*4]
00CC18D6  mov         dword ptr [ecx+00000104h],eax
}
00CC18DC  xor         eax,eax
00CC18DE  pop         edi
00CC18DF  pop         esi
00CC18E0  pop         ebx
00CC18E1  mov         esp,ebp
00CC18E3  pop         ebp
00CC18E4  ret

So what is going on here? The interesting part here is this:

ecx,dword ptr fs:[0000002Ch]

What is at fs:[0000002Ch]? The fs segment is offset to start at the start of the Thread Environment Block (TEB). Microsoft won’t tell you much except for “don’t touch”. Wikipedia has more information. Offset 2Ch is a pointer to the Thread Local Storage (TLS) slots. So it stores a TLS index at 00CC8194h, looks up the data at that TLS slot, which apparently is a pointer to an array of thread local values for that thread – where the variable i is placed at offset 104h.

So Microsoft tells us that the TEB is an internal structure subject to change from one Windows version to another, and toying around with it is a big no-no. And yet their compiler happily generates code that directly accesses this “internal implementation detail”.

Hipocrisy much?