Sorry :-( RichEdit10AnsiWndProc doesn't exist in riched20.dll. All that dll exports on NT4 is
_DllMain@12
CreateTextServices
IID_IRichEditOle
IID_IRichEditOleCallback
IID_ITextHost
IID_ITextHost2
IID_ITextServices
I replaced it the dll with the version from Win 2000 and it works, did notice one bug though. For the [System Process] it ends up enumeratng the modules of the current process.
wahoooooo
Then the problem is on the usage of richedit on the rtf demo functions and not the rebuilded toolhelp apis functions :) :):):) (I´ll review the rtf fix once i succeed to fix the Heap32Next problem i´m currently doing.
Anyway, it is good to know the rebuilded Apis are fully working on NT now, the same way as the original version.
About enumerating the current system. Excellent, this happens here too. It seems to be an error on M$ example i ported and not the rebuilded Api functions.
I ported the functions examples as in here:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686701%28v=vs.85%29.aspxIf i compiled the C function in VS it will give me these results too (The same ones as in both gui versions):
=====================================================
PROCESS NAME: [System Process]
-------------------------------------------------------
WARNING: OpenProcess failed with error 87 (The parameter is incorrect)
Process ID = 0x00000000
Thread count = 8
Parent process ID = 0x00000000
Priority base = 0
MODULE NAME: Snapshot.exe
Executable = D:\RosAsm\RosAsm\ToolHelpLib\Debug\Snapshot.exe
Process ID = 0x0000B250
Ref count (g) = 0xFFFF
Ref count (p) = 0xFFFF
Base address = 0x00400000
Base size = 32768
MODULE NAME: ntdll.dll
Executable = C:\WINDOWS\system32\ntdll.dll
Process ID = 0x0000B250
Ref count (g) = 0xFFFF
Ref count (p) = 0xFFFF
Base address = 0x7C900000
Base size = 729088
Can you check this source for me ? I mean, it does as it expects, or there is actually a bug in the original Api that i also reproduced it after porting it ? I would like to be sure either it is a bug on M$ example or in the Apis themselves (If it is a bug on the api, i can try fixing them, but... it seems more like an error on the C example).
I´m amazed the rebuilded Apis worked as expected on Win NT. It means that they are being correctly ported to assembly in order for me to do a proper dll containing them. Once i finish Heap32Next i´ll try to make a function similar to Toolhelp32ReadProcessMemory (Which is already rebuilded, btw) but, instead reading the memory from a specific address it will export the whole SNAPSHOT structure to the user analyse it. Or create a Toolhelp32ReadProcessMemoryEx function where it returns the total amount of bytes necessary for the buffer, in case of failures or also under user choice.
For instance, Toolhelp32ReadProcessMemoryEx can use lpBaseAddress as a flag to determine the amount of allocated memory. So if you set lpBaseAddress = 0, it returns the amount of bytes to you use either in Toolhelp32ReadProcessMemory or in Toolhelp32ReadProcessMemoryEx
