Re: NT Native API was (Re: Question about WINE and adding the "low-level" CD access APIs...)
Well if you read http://www.sysinternals.com/ntw2k/info/ntdll.shtml, you will see several things: 1.most of the "native APIs" that drivers and etc use are undocumented, only a handfull are documented in the DDK. and 2.Quite a few of the APIs could probobly "map" onto existing bits of wine code (for example most of the Registry APIs)
Yes, in fact the registry APIs are already implemented in terms of ntdll.
The way to proceed (IMHO) is this: 1.implement something that can load the win32 device drivers somehow
... hehe :) Easier said than done, methinks.
and then 2.implement the NT Native APIs (which are actually exported by ntdll.dll and callable by user apps BTW) one at a time (pick a simple driver such as the secdrv.sys from safedisk and implement the calls that it uses) then go from there.
Hmm, I'm confused. ntdll exists in kernel space too? I guess I always imagined the internals of the kernel would have its own symbol fixup system, without DLLs. But perhaps not.
For example, I got a version of SafeDisk secrdv.sys from Command & Conquer Renegade (most recent SafeDisk game I can find in my collection) with a size of 28400 bytes and a date of 29 january 02 and it only has 15 entries in its "exports" segment and only 3 are not documented in MSDN library online (NtBuildNumber, KeTickCount, IofCompleteRequest) (but best I can work out IofCompleteRequest and IoCompleteRequest are one and the same)
IIRC the kernel functions use a particular naming scheme. I forget exactly what it is, but IoCompleteRequest and IofCompleteRequest are not the same, but one is a variant of the other - much like FooA and FooW are in userland Win32.
Some of these APIs needed for SafeDisk support etc may already be implemented or may be simple to implement)
Yeah, but is it any simpler than just reverse engineering and cloning the driver? Drivers aren't needed all that often.
So, emulating enough of the guts of windows to get safedisk protected programs (and mabie other "simple" drivers) doesnt (IMHO) seem hugly difficult.
Well, rather you than me brother :)
Hmm, I'm confused. ntdll exists in kernel space too? I guess I always imagined the internals of the kernel would have its own symbol fixup system, without DLLs. But perhaps not.
Well basicly, the userland versions of these exported functions load a "system call number" into eax, load a pointer to the parameters into eax and then call an INT 2E. This call maps down to something in the kernel which uses the "system call number" as an index into a lookup table. See http://www.sysinternals.com/ntw2k/info/ntdll.shtml for the gory details
IIRC the kernel functions use a particular naming scheme. I forget exactly what it is, but IoCompleteRequest and IofCompleteRequest are not the same, but one is a variant of the other - much like FooA and FooW are in userland Win32.
ok, I didnt know that :)
Yeah, but is it any simpler than just reverse engineering and cloning the driver? Drivers aren't needed all that often.
1.implementing these APIs and using the SafeDisk .sys file makes it more likely that things will just "work" if a new version of SafeDisk comes out. (plus, as more things get implemented, more drivers will just "work") and 2.more imporantly, implementing this stuff (as opposed to cloning secdrv.sys) is a lot less likely to cause the SafeDisk people to sue WINE under the DMCA (in fact, a clone of an older version of secdrv.sys was created but not added because of this DMCA fear)
-
Jonathan Wilson -
Mike Hearn