CsrClientConnectToServer

[asherkobin]

This NT API has changed in Win8 from Win7 and previous.

Old:

Code: Select all

NTSTATUS NTAPI CsrClientConnectToServer(
  IN PWSTR ObjectDirectory,
  IN ULONG ServerId,
  IN PVOID ConnectionInfo, 
  --> IN OUT PULONG ConnectionInfoSize, <--
  OUT PBOOLEAN ServerToServerCall);

New:

Code: Select all

NTSTATUS NTAPI CsrClientConnectToServer(
  IN PWSTR ObjectDirectory,
  IN ULONG ServerId,
  IN PVOID ConnectionInfo, 
  --> IN ULONG ConnectionInfoSize, <--
  OUT PBOOLEAN ServerToServerCall);

Perhaps there are other changes as well. Does anyone have insight into this before I spend more time reversing it?

Please advise if there is a better forum for this kind of question thanks.

[Frontier]

Yeah, we're going for server 2003 compatibility, so it doesn't matter at all.

[justincase]

Yeah ... currently

we're going for server 2003 compatibility, so it doesn't matter

... yet.

You might still want to make a note of it somewhere though, cause the target version of the API(s) might change in the future.

[hbelusca]

@asherkobin: "Perhaps there are other changes as well. Does anyone have insight into this before I spend more time reversing it?" <--- they changed quite a bit of stuff in Win8, amongst which how the console is architectured (now it is in conhost.exe as on windows 7 AND in some obscure driver called condrv.sys). Knowing that before win7 (and in win7 to some extent), console was the main thing that used CSR to work, it may be that due to those internal changes, they "simplified" a bit the CSR functions (btw I've doublechecked your asserts concerning CsrClientConnectToServer by looking at kernelbase.dll, because this API is called to initialize a client/server connection between CSRSS servers and the rest, "the rest" == console and "base" clients that are in kernel***.dll).
Also, it may be interesting to reverse how the console is architectured in Windows 8+...

[mrugiero]

I agree with justincase. If there is an effort to RE it, there is nothing wrong in organizing the information. It might prove useful later, and it might also prove hard to find again. As long as it is made clear that this information is only valid for Win 8 (to avoid confussions with someone working in the current targets of ReactOS), of course.

[Konata]

This makes me wonder about ReactOS and different version of Windows. It can't support all the different Windows at once can it?
Will there be other versions of ReactOS as well? Maybe you can put these different files and APIs in some ifdefs and stuff and just compile a Win2K3 version or a 7 version or an 8 version, right?

[hbelusca]

I agree with justincase. If there is an effort to RE it, there is nothing wrong in organizing the information. It might prove useful later, and it might also prove hard to find again. As long as it is made clear that this information is only valid for Win 8 (to avoid confussions with someone working in the current targets of ReactOS), of course.

Concerning that CSR thingie, I've checked also in Win7, and indeed it changed starting Win8.

[hbelusca]

This makes me wonder about ReactOS and different version of Windows. It can't support all the different Windows at once can it?
Will there be other versions of ReactOS as well? Maybe you can put these different files and APIs in some ifdefs and stuff and just compile a Win2K3 version or a 7 version or an 8 version, right?

Then you would need to do that also at the file level (I mean, having new dlls compiled if you "compile a 7 version" for example, etc...) and first and foremost, having reversed all of the apis (old and new) from Win2k3, Win7, Win8, and check whether things change, etc... In other words, something unmaintainable.

[EmuandCo]

Lets abuse WinSXS for that

[Oddjob64]

This should only be a issue when we target NT 6.2 compatibility (and wouldn't that require that we add Metro anyway?).

[mrugiero]

This makes me wonder about ReactOS and different version of Windows. It can't support all the different Windows at once can it?
Will there be other versions of ReactOS as well? Maybe you can put these different files and APIs in some ifdefs and stuff and just compile a Win2K3 version or a 7 version or an 8 version, right?

Or at runtime, defining your functions dinamically can be an option. A common practice, at least for Linux kernel drivers, is to fill up an structure with several pointers to functions and objects as a way to create a generic interface that can be targeted by the exposed APIs while having the implementation defined by the actual driver. This way, you could load a different version of each function depending on the Windows version the app expects. If I must guess, that's how Win SXS works, but I'm really prone to err by ignorance. Almost surely someone else here has a deeper idea about how Windows deals with backwards compatibility.

[asherkobin]

Spot on. Last summer I successfully reversed the WIn7 console behavior and am able to create and control the console with only NTDLL calls. I was quite happy .

Last week, I tried to run my code on Win8 and it blew up on CsrClientConnectToServer when trying to connect to the new separated console server (CONHOST). I debugged down to where RtlHeapAlloc was returning NULL because the SIZE_T being passed in happened to be a ptr which RtlHeapAlloc nicely (?) determined that it had to be a programmer error. I was a bit confused as the ptr was a "reasonable" value to alloc (less than 700k), but perhaps there's some sanity/alignment checks.

From that I traced back up to the CsrClientConnectToServer call and realized it now just wanted a SIZE_T rather than a ptr to one. I fixed that in my code and it got way further, so I came here first before going down that rabbit hole

Anyway I am now motivated to get my code working on Win8 (and will be happy to share). Perhaps I'll now have to understand more about the new /Device/ConDrv piece of the puzzle as well and any of the changes to the Csr port communication. They probably re-architected the CSR console system with a kernel driver to reduce the costs of constant context switching (ala NT4 user/gdi Win32.sys).

@asherkobin: "Perhaps there are other changes as well. Does anyone have insight into this before I spend more time reversing it?" <--- they changed quite a bit of stuff in Win8, amongst which how the console is architectured (now it is in conhost.exe as on windows 7 AND in some obscure driver called condrv.sys). Knowing that before win7 (and in win7 to some extent), console was the main thing that used CSR to work, it may be that due to those internal changes, they "simplified" a bit the CSR functions (btw I've doublechecked your asserts concerning CsrClientConnectToServer by looking at kernelbase.dll, because this API is called to initialize a client/server connection between CSRSS servers and the rest, "the rest" == console and "base" clients that are in kernel***.dll).
Also, it may be interesting to reverse how the console is architectured in Windows 8+...

[hbelusca]

Yesterday evening I analyzed kernelbase.dll (and also kernel32.dll), and I find that now, all of the console APIs are made of calls to the console driver, directly, via "ConsoleCallServer" and "ConsoleCallServerGeneric" internal helper functions, and there is some kind of "ConsoleConnectionState". Also they seem to call NtSetSystemInformation with the information parameter 132 and NtSetInformationProcess (on the current running console process) with the information parameter 49. I don't know whether these are "new" (i.e. never used before Windows 8) or recycled parameter IDs. (Also I think a quick look at Windows 8.1 would be instructive to have, for you, to see whether they changed things a bit between Win8 and Win8.1 on this sector).
I'm also interested in those informations because I would like to "improve" the console subsystem of ReactOS a bit compared to the one of Win2k3 also by introducing some kind of (kernel-mode) console driver that could be used even outside of the Windows world (i.e. that can be used in pure NT user-mode), but in such a way that, for the purpose of ReactOS, that the whole thing is more or less compatible with Win2k3 (i.e. having the conhost part still in winsrv.dll, and having kernel32.dll making calls to the CSR).

[mrugiero]

I believe this kind of documentation belongs to the wiki. It will be valuable to have for someone working in that particular area, and the wiki is the natural place to look for it.

[hbelusca]

+1 mrugiero.