I notice when my prog is calling Kernel32.LockResource OllyDbg thinks it's calling SetHandleCount (an obsolete Win16 function). I don't know how OllyDbg figures out which function is being called, but if it's by ordinal then this one has probably changed. As I understand it Microsoft reserve the right to be stingy with ordinals and reuse them, move them about, etc... So maybe OllyDbg should be using a more portable method of locating the api functions. Or maybe it's just a bug with this one function. Using OllyDbg 1.08b on Win XP btw.

Blazde: here is the FASM code that i use for testing and it works ok on my NT4SP6, OllyDbg 1.08b
<pre>format PE GUI 4.0
include 'include&#92;macro&#92;import.inc'
start:
push 0
push 0
call [LoadResource]
push 0
call [ExitProcess]
data import
library kernel,'KERNEL32.DLL'
kernel:

import ExitProcess,'ExitProcess',&#92;
LoadResource, 'LoadResource'
end data

data fixups
end data
</pre>

It's LockResource tho, not LoadResource. When I try either LockResource or SetHandleCount in your FASM test, this same address in kernel32.dll gets called:

.text:77E7E351 ; Exported entry 590. LockResource
.text:77E7E351 ; Exported entry 777. SetHandleCount
.text:77E7E351
.text:77E7E351 ; ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ S U B R O U T I N E ŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚŚ
.text:77E7E351
.text:77E7E351
.text:77E7E351 ; UINT __stdcall LockResource(UINT uNumber)
.text:77E7E351 public _LockResource@4
.text:77E7E351 _LockResource@4 proc near ; CODE XREF: GetStringTableEntry(x,x,x,x,x)+69p
.text:77E7E351 ; EnumLangsFunc(void *,ushort *,ushort *,ushort,long)+C2p
.text:77E7E351 ; DATA XREF: ...
.text:77E7E351
.text:77E7E351 uNumber = dword ptr 4
.text:77E7E351
.text:77E7E351 mov eax, [esp+uNumber] ; LockResource
.text:77E7E355 retn 4
.text:77E7E355 _LockResource@4 endp

Two exports, one function. It looks like a kind of transitional phaze. SetHandleCount and LockResource both do nothing, but there's a place holder for them. You can bet there's going to be some real headaches in the future about this. Old apps that think they're getting SetHandleCount will start faulting in the middle of LockResource code when it arrives.

So I guess OllyDbg isn't wrong just yet. Btw, the code I had calling LockResource was explorer.exe. Microsoft getting ahead of themselves a bit there.

Or... they have different names, /and/ different ordinal numbers so maybe this is just some weird compiler optimization that recognises both functions do the same thing and lumps them together. Perhaps they'll become two again when LockResource is implemented.