SEEM trivial, and ARE trivial, are 2 different things though.Riley Pizt wrote:I disagree. For example, many programs which would otherwise run on Windows 9X will not simply because the developer chose to use "GlobalMemoryStatusEx" instead of "GlobalMemoryStatus". Hooking Kernel32.dll on Windows 9X systems to handle the slight differences between these two functions would seem trivial.
.gif "Smile"){kind=small}
Not only do you have to write the functions that are missing, you have to "fool" the calling programs into thinking its an NT version. Which developers use GetVersion/GetVersionEx and some even use the DLL version numbers, which can be messy, cuz you don't know what dll its getting a version from. It may even make calls to NTDLL.DLL, in which case, you have to recreate that DLL, which isn't on non NT kernels. Like I said, It would be work than its worth.(example is in Delphi, but you can do it in C++ too)Riley Pizt wrote:True, but how do you write a DLL to pass all function calls that you don't want to modify (or possibly don't even know exist since some functions in Windows DLL's like Kernel32.dll are undocumented) to the real DLL when you don't have the source code to the original DLL?
1) Use a program, such as "depends.exe". This will list ALL exported functions the DLL provides.
2) Get the address for the function (for sample purposes, i'll use CreateFileA)
var CFAPointer: Pointer;
CFAPointer := GetProcAddress(OriginalKernel32Handle, "CreateFileA");
3) Make a function (remember you don't know the calling convention or whats passed it or EVEN what it returns)
procedure CreateFileA();
asm
JMP CFAPointer
end;
4) Export Your New function.
This is exact how an import table USUALLY is
Program calls into the Import Table, the import table JUMPs to the real function.
Wine is one of them. Which is a cross platform emulation of the system dlls.Riley Pizt wrote:Such as?Then again, there are alright projects out there that does this for you.