Re: NT Native API was (Re: Question about WINE and adding the "low-level" CD access APIs...)

[Mike Hearn]

> 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 :)

-- 
Mike Hearn <m.hearn(a)signal.qinetiq.com>
QinetiQ - Malvern Technology Center

NT Native API was (Re: Question about WINE and adding the "low-level" CD access APIs...)

[Jonathan Wilson]

> 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)