• NtReplyWaitReceivePortEx timeout problems

    From R.Wieser@21:1/5 to All on Sat Dec 5 18:35:24 2020
    Hello all,

    I've got some consol based code using NtReplyWaitReceivePort (directly after
    an NtCreatePort call) which works. But ... It blocks forever. So, I tried
    to replace it with NtReplyWaitReceivePortEx, as it has got a timeout
    argument.

    Alas, no matter what I try I either directly get a 0x0 (WAIT_OBJECT_0) or an 0x0102 (WAIT_TIMEOUT) result, with nothing in between,no matter which
    timeout value I use.

    I've tried to find documentation to the obove NtReplyWaitReceivePortEx function, but MS doesn't offer it, and the pages did find do not say
    anything other than that the timeout argument is a pointer to a
    LARGE_INTEGER

    So, my question is: does anyone know how the "timeout" argument to the NtReplyWaitReceivePortEx function works ? Is it perhaps a record that
    needs a special setup ? If so, what ? Anything else ?

    Secondary question : what is the function of NtListenPort ? NtReplyWaitReceivePort seems to do something quite similar ...

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Sat Dec 5 20:44:54 2020
    Don't you hate it when you post a question and than you find the answer mere minutes later ?

    So, my question is: does anyone know how the "timeout" argument to the NtReplyWaitReceivePortEx function works ? Is it perhaps a record that
    needs a special setup ? If so, what ? Anything else ?

    It turns out it was a double problem.

    1) Some further google-hunting showed that there is also an "NtCreateWaitablePort" function. Although I could not find any description
    the "Waitable" in its name suggest that would need it.[1]

    2) A quick test with "NtCreateWaitablePort" and "NtWaitForSingleObject"
    showed that the latter still failed the same way. However, "WaitForSingleObject" did actually wait the set time. So, after
    disassembling it it turns out that the timeout argument for "NtWaitForSingleObject" is in 100 nSec increments, and needs to be the *negative* of the desired value.

    [1]Indeed, "NtCreatePort" with the correct timeout value for "NtWaitForSingleObject" also still failed.

    Doing the same for the "NtReplyWaitReceivePortEx" shows it works there too.

    In short: Victory! :-)


    Secondary question : what is the function of NtListenPort ? NtReplyWaitReceivePort seems to do something quite similar ...

    I could still use an answer to this one though ...

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Apd@21:1/5 to R.Wieser on Sun Dec 6 03:02:33 2020
    "R.Wieser" wrote:
    Don't you hate it when you post a question and than you find the answer
    mere minutes later ?

    Have you seen the book "Windows NT/2000 Native API Reference" by Gary
    Nebbett? I found a PDF of it years ago.

    So, my question is: does anyone know how the "timeout" argument to the
    NtReplyWaitReceivePortEx function works ? Is it perhaps a record that
    needs a special setup ? If so, what ? Anything else ?

    It turns out it was a double problem.

    1) Some further google-hunting showed that there is also an "NtCreateWaitablePort" function. Although I could not find any
    description the "Waitable" in its name suggest that would need it.[1]

    2) A quick test with "NtCreateWaitablePort" and "NtWaitForSingleObject" showed that the latter still failed the same way. However, "WaitForSingleObject" did actually wait the set time. So, after disassembling it it turns out that the timeout argument for "NtWaitForSingleObject" is in 100 nSec increments, and needs to be the *negative* of the desired value.

    Timeout
    "Optionally points to a value that specifies the absolute or relative
    time at which the wait is to be timed out.A negative value specifies
    an interval relative to the current time.The value is expressed in
    units of 100 nanoseconds.Absolute times track any changes in the
    system time; relative times are not affected by system time changes.
    If Timeout is a null pointer, the wait will not timeout".

    [1]Indeed, "NtCreatePort" with the correct timeout value for "NtWaitForSingleObject" also still failed.

    Doing the same for the "NtReplyWaitReceivePortEx" shows it works there
    too.

    In short: Victory! :-)


    Secondary question : what is the function of NtListenPort ?
    NtReplyWaitReceivePort seems to do something quite similar ...

    I could still use an answer to this one though ...

    Substitute Nt for Zw (most of the native functions are doubly nameed -
    makes no difference from user mode).

    ZwListenPort
    Listens on a port for a connection request message.

    NTSYSAPI
    NTSTATUSNTAPI
    ZwListenPort(
    IN HANDLE PortHandle,
    OUT PPORT_MESSAGE Message
    );

    PortHandle
    A handle to a port object.The handle need not grant any specific
    access.

    Message
    Points to a caller-allocated buffer or variable that receives the
    connect message sent to the port.

    Return Value
    Returns STATUS_SUCCESS or an error status, such as
    STATUS_INVALID_HANDLE.

    Remarks
    The message type of the received message is
    LPC_CONNECTION_REQUEST.The message data is the connect data
    specified in the call to ZwConnectPort.


    ZwReplyWaitReceivePort
    Optionally sends a reply message to a port and waits for a message.

    NTSYSAPI
    NTSTATUS
    NTAPI
    ZwReplyWaitReceivePort(
    IN HANDLE PortHandle,
    OUT PULONG PortIdentifier OPTIONAL,
    IN PPORT_MESSAGE ReplyMessage OPTIONAL,
    OUT PPORT_MESSAGE Message
    );

    PortHandle
    A handle to either a port object or a waitable port object.The
    handle need not grant any specific access.

    PortIdentifier
    Optionally points to a variable that receives a numeric identifier
    associated with the port.

    ReplyMessage
    Optionally points to a caller-allocated buffer or variable that
    specifies the reply mes- sage to send to the port.

    Message
    Points to a caller-allocated buffer or variable that receives the
    message sent to the port.

    Return Value
    Returns STATUS_SUCCESS or an error status, such as
    STATUS_INVALID_HANDLE or STATUS_REPLY_MESSAGE_MISMATCH.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Sun Dec 6 07:51:05 2020
    Apd,

    Have you seen the book "Windows NT/2000 Native API Reference"
    by Gary Nebbett? I found a PDF of it years ago.

    Nope. And a google search just now shows its rather unavailable in /any/
    form (pdf, text, other). Any chance you can share your copy of it ?

    Timeout
    "Optionally points to a value that
    ...

    I wish I could have found that info. But no. The best I got was this : http://undocumented.ntinternals.net/helpcontents.html

    Substitute Nt for Zw (most of the native functions are doubly
    nameed - makes no difference from user mode).

    I noticed that when extracting function names from a DLL. Didn't think of /remember searching for the "Zw" name though. :-\

    ZwListenPort
    ...
    Remarks
    The message type of the received message is
    LPC_CONNECTION_REQUEST.The message data is the
    connect data specified in the call to ZwConnectPort.

    Ah, so that is the whole difference: where NtReplyWaitReceivePort waits for /any/ message, NtListenPort filters out a specific one. Good to know.
    Thanks.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Apd@21:1/5 to R.Wieser on Sun Dec 6 12:16:59 2020
    "R.Wieser" wrote:
    Apd,

    Have you seen the book "Windows NT/2000 Native API Reference"
    by Gary Nebbett? I found a PDF of it years ago.

    Nope. And a google search just now shows its rather unavailable in /any/ form (pdf, text, other). Any chance you can share your copy of it ?

    Sure:
    http://s000.tinyupload.com/?file_id=11764490474007274119

    The introduction, contents and index are missing.

    Timeout
    "Optionally points to a value that
    ...

    I wish I could have found that info. But no. The best I got was this : http://undocumented.ntinternals.net/helpcontents.html

    Yes, I've seen that before. Nebbett's book is better.

    Substitute Nt for Zw (most of the native functions are doubly
    nameed - makes no difference from user mode).

    I noticed that when extracting function names from a DLL. Didn't think of /remember searching for the "Zw" name though. :-\

    It's a weird way of doing things and the difference is in the way kernel
    code handles calls from user mode. I don't know why both types are
    available from user mode.

    ZwListenPort
    ...
    Remarks
    The message type of the received message is
    LPC_CONNECTION_REQUEST.The message data is the
    connect data specified in the call to ZwConnectPort.

    Ah, so that is the whole difference: where NtReplyWaitReceivePort waits for /any/ message, NtListenPort filters out a specific one. Good to know. Thanks.

    I guess so. I've never used these functions. Isn't the win32 WaitForSingleObject good enough?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Sun Dec 6 14:27:59 2020
    Apd,

    Sure:
    [Snip]

    The introduction, contents and index are missing.

    Lol. My first thought was "with even the contents gone, what, if anything, will be left ?".

    Luckily when I opened the PDF there was still enough to read there ...

    The best I got was this :
    [Snip]

    Yes, I've seen that before. Nebbett's book is better.

    I can imagine. Multiple Nt* functions in the link I posted have zero information about what certain arguments should look like and are ment for,
    let alone a description of any dependancies of the function itself (not that
    MS itself fares much better in the latter case).

    Didn't think of /remember searching for the "Zw" name
    though. :-\

    It's a weird way of doing things and the difference is in the way
    kernel code handles calls from user mode.

    The code itself determines in which mode it called its called and than
    responds differently ? Thats ... interresting.

    I don't know why both types are available from user mode.

    If most of the code is the same with only the pre- and postamble different (setting up for kernel or usermode call) I can see it as a good decision (de-duplicating code).

    That both the Nt* and Zw* names still exists is than probably a legacy thing (where both origionally pointed to different routines).

    I guess so. I've never used these functions. Isn't the
    win32 WaitForSingleObject good enough?

    :-) I only used that kernel32 function on a hunch to test.

    The target was to get the NtReplyWaitReceivePortEx function to work (I'm
    trying to write some local IPC), but thought it would be a good idea to
    isolate the "wait for" functionality to make things easier to check. I
    first tried the NtWaitForSingleObject, but after that one failed too I
    wondered if maybe the "higher level" function in Kernel32 might be doing something extra that might make it work. And it did.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Apd@21:1/5 to R.Wieser on Sun Dec 6 16:37:49 2020
    "R.Wieser" wrote:
    The introduction, contents and index are missing.

    Lol. My first thought was "with even the contents gone, what, if anything, will be left ?".

    Yep! Of course, I meant "table of contents".

    Luckily when I opened the PDF there was still enough to read there ...

    I hope you find it useful. There's plenty of info despite the missing introduction.

    Didn't think of /remember searching for the "Zw" name
    though. :-\

    It's a weird way of doing things and the difference is in the way
    kernel code handles calls from user mode.

    The code itself determines in which mode it called its called and than responds differently ? Thats ... interresting.

    <https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/using-nt-and-zw-versions-of-the-native-system-services-routines>

    See also the link to "previous mode".

    The ntoskrnl exports of the Zw routines go via the system service
    table whereas the Nt ones go straight to the code that implements the
    service. My understanding from other sources is that drivers should
    use Zw to be safe but the article above suggests Nt. Who knows? I
    don't write kernel code but I sometimes analyse it.

    I don't know why both types are available from user mode.

    If most of the code is the same with only the pre- and postamble different (setting up for kernel or usermode call) I can see it as a good decision (de-duplicating code).

    That both the Nt* and Zw* names still exists is than probably a legacy thing (where both origionally pointed to different routines).

    That would make sense but I don't think it's the case. Being in a user
    module (ntdll), I don't see the need for different routines like that.
    I wonder why the Zw names are needed at all in ntdll since a number of
    them are exported from ntoskrnl.exe. Those prefixes didn't exist in
    pre-NT versions of Windows.

    Somewhere at Microsoft I read that user code should use Nt and that Zw
    was not supported. Despite that, both varieties of a name point to the
    same entry point in ntdll and all go through the system service table
    via INT 2E for W2k and SYSENTER for XP.

    I guess so. I've never used these functions. Isn't the
    win32 WaitForSingleObject good enough?

    :-) I only used that kernel32 function on a hunch to test.

    The target was to get the NtReplyWaitReceivePortEx function to work (I'm trying to write some local IPC), but thought it would be a good idea to isolate the "wait for" functionality to make things easier to check. I
    first tried the NtWaitForSingleObject, but after that one failed too I wondered if maybe the "higher level" function in Kernel32 might be doing something extra that might make it work. And it did.

    So you need to go down to the native ntdll level to get things to
    work. Not sure I completely understand why the win32 API won't do what
    you want, but Ok!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Sun Dec 6 18:47:35 2020
    Apd,

    My understanding from other sources is that drivers
    should use Zw

    That is what I read too. Knowing that both call the same NTDLL function I could only imagine that its either legacy, or that the name prefix is ment
    as a "warning, you are writing kernel-mode stuff".

    Those prefixes didn't exist in pre-NT versions of Windows.

    That sure makes mince-meat of my "legacy" idea.

    There ofcourse is also the possibility that they wanted to make the way free to, in the future, make those functions different. Though that is nothing
    more than guesswork - for which I've not seen anything to support it.

    So you need to go down to the native ntdll level to get things
    to work.

    Not quite. At some point in my looking thru IPC methods read that there is also a Local IPC (or LPC) method. From there I landed on a webpage showing
    some example code, which used the Nt* functions.

    Not sure I completely understand why the win32 API won't
    do what you want, but Ok!

    While searching for information on LPC and subsequently on the different NtCreatePort family of functions I have not seen any mentioning of the existence of Win32 API counterparts. Than again, I did not really look
    for it either ...

    A bit of disclosure: My programming language of choice is Assembly. Which might explain why I was (and am) not bothered by using low-level functions.
    :-)

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Mon Dec 7 17:49:37 2020
    Apd,

    Drivers don't - they call Zw funcs exported from ntoskrnl.exe

    Doesn't that end in the same difference ?

    I could only imagine that its either legacy, or that the name
    prefix is ment as a "warning, you are writing kernel-mode
    stuff".

    Warning: Here be dragons!

    :-) Yep, that.

    Having now read the start of the section dealing with ports, I can
    see why it uses native funcs.

    Can you tell a bit about that ? I've got no idea about why that is, and
    I'm intending two wrap code using those NT port functions up in an API DLL.
    Is there perhaps a reason why I should not be doing that ?

    It's one thing knowing that but another finding out how the
    half-documented NT API works.

    Indeed. I'm currently trying to figure out which datagram functions need to
    be used in which order to send and receive a stream of data.

    And in that direction having contradicting documentation doesn't really help either :Like the second argument to NtAcceptConnectPort. The PDF I got from you named it "PortIdentifier". The info on the undocumented.ntinternals.net website describes it as "AlternativeReceivePortHandle". Without a usage description I've decided to just name it "UserValue".

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Apd@21:1/5 to R.Wieser on Mon Dec 7 16:21:14 2020
    "R.Wieser" wrote:

    My understanding from other sources is that drivers
    should use Zw

    That is what I read too. Knowing that both call the same NTDLL
    function

    Drivers don't - they call Zw funcs exported from ntoskrnl.exe of which
    there are fewer than in ntdll. They mainly use other kernel APIs.

    I could only imagine that its either legacy, or that the name prefix
    is ment as a "warning, you are writing kernel-mode stuff".

    Warning: Here be dragons!

    So you need to go down to the native ntdll level to get things
    to work.

    Not quite. At some point in my looking thru IPC methods read that
    there is also a Local IPC (or LPC) method. From there I landed on a
    webpage showing some example code, which used the Nt* functions.

    Having now read the start of the section dealing with ports, I can see
    why it uses native funcs.

    While searching for information on LPC and subsequently on the
    different NtCreatePort family of functions I have not seen any
    mentioning of the existence of Win32 API counterparts

    I see the native API book says: "Port objects are not directly exposed
    via the Win32 API".

    A bit of disclosure: My programming language of choice is Assembly.
    Which might explain why I was (and am) not bothered by using low-level functions. :-)

    I remember you saying you prefer ASM. It's one thing knowing that but
    another finding out how the half-documented NT API works.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Apd@21:1/5 to R.Wieser on Mon Dec 7 18:41:49 2020
    "R.Wieser" wrote:
    Apd,

    Drivers don't - they call Zw funcs exported from ntoskrnl.exe

    Doesn't that end in the same difference ?

    Um... Yes. What I don't undersand is the need for ntdll to export them
    since user mode doesn't need them at all, and kernel mode gets them
    from ntoskrnl.

    Having now read the start of the section dealing with ports, I can
    see why it uses native funcs.

    Can you tell a bit about that ? I've got no idea about why that is,
    and I'm intending two wrap code using those NT port functions up in an
    API DLL. Is there perhaps a reason why I should not be doing that ?

    Sorry, all I know is what it says about there being no Win32
    equivalents. How about using rpcrt4.dll? At least you can see how it
    uses those funcs. There's also example usage in Appendix D.4.

    It's one thing knowing that but another finding out how the
    half-documented NT API works.

    Indeed. I'm currently trying to figure out which datagram functions need to be used in which order to send and receive a stream of data.

    And in that direction having contradicting documentation doesn't really help either :Like the second argument to NtAcceptConnectPort. The PDF I got from you named it "PortIdentifier". The info on the undocumented.ntinternals.net website describes it as "AlternativeReceivePortHandle". Without a usage description I've decided to just name it "UserValue".

    Might also be worth checking how/if these native routines are
    implemented in ReactOS.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Mon Dec 7 22:00:18 2020
    Apd,

    What I don't undersand is the need for ntdll to export them
    since user mode doesn't need them at all, and kernel mode
    gets them from ntoskrnl.

    Ehrmmm ... no, I can't think of such a reason either. On the other hand
    .... Didn't you say that ntdll has a few more Nt* functions than ntoskrnl ?
    Is that perhaps why they "shortcutted" the other functions into ntdll too ?

    Sorry, all I know is what it says about there being no
    Win32 equivalents.

    Ah. You ment that "I can see why it uses native funcs" as "because there
    are no Win32 equivalents". I thought that you maybe had some further
    insight into it.

    Might also be worth checking how/if these native routines
    are implemented in ReactOS.

    Might be worth anther look. Though I did look into the ReactOS code for the timeout problem of the NtReplyWaitReceivePortEx function (as in my initial question), and got nowhere fast. The ReactOS function did some "is the argument actually readable" checking, but I could not see where it was
    actually used for its purpose. A page-wide search for the argument name
    turned up zilch.

    Worse: At some point I even found some diff-ing removing the timeout functionality from that function - presumably because of problems with its implementation.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Tue Dec 8 09:03:10 2020
    Apd,

    How about using rpcrt4.dll?

    Somehow I forgot to mention that I did take a look at the functions the DLL exposed, and must say that those names do not really hint at what they are
    for.

    I see five groups and (some ungroupable ones at the begin), and cannot even figure out which of those groups I should be starting with, or which
    function of each group initialises ... whatever it is those groups do. :-|

    I'll probably do a google for them though (can't stand not knowing what they
    do :-) ). Even though their names indicate remote, not local IPC ...

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Apd@21:1/5 to R.Wieser on Tue Dec 8 14:39:27 2020
    "R.Wieser" wrote:
    Apd,

    What I don't undersand is the need for ntdll to export them
    since user mode doesn't need them at all, and kernel mode
    gets them from ntoskrnl.

    Ehrmmm ... no, I can't think of such a reason either. On the other hand .... Didn't you say that ntdll has a few more Nt* functions than ntoskrnl ? Is that perhaps why they "shortcutted" the other functions into ntdll too ?

    To me it seems strange that the kernel needs any Nt or Zw funcs, after
    all it has its own subsystems. For example, the IO subsystem has
    IoCreateFile so why the need for ZwCreateFile? Perhaps some don't have
    a place in those subsystems or it's convenient to have the strict
    parameter verification done when user data is involved. This may
    explain why it needs fewer of those user-mode interface functions,
    which is how I see the Nt* routines.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Apd@21:1/5 to R.Wieser on Tue Dec 8 14:40:06 2020
    "R.Wieser" wrote:
    Apd,

    How about using rpcrt4.dll?

    Somehow I forgot to mention that I did take a look at the functions the DLL exposed, and must say that those names do not really hint at what they are for.

    That could be a problem. Otherwise, it might help if you could see how
    they used the NT port functions. Don't forget the example in the API
    book.

    How about another book?

    Undocumented Windows NT
    Chapter 8 LPC http://index-of.es/Programming/Programming%20-%20Undocumented%20Windows%20NT/part_II_8.pdf

    All the other chapters can be found there, too.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Tue Dec 8 19:49:49 2020
    Apd,

    Don't forget the example in the API book.

    The API book ? I take it you mean the PDF link you just provided ? The
    first one did have some code, but no example that I could see.

    How about another book?

    Undocumented Windows NT
    Chapter 8 LPC

    Fun. It looks like thats same as the webpage I found containing the
    example code I started with :

    https://web.archive.org/web/20080612141354/http://www.windowsitlibrary.com/Content/356/08/toc.html

    All the other chapters can be found there, too.

    I don't know why, but pretty-much my first thought after downloading the PDF was to see what would happen if I would remove the PDF filename part, to see
    if I would drop into the folder and what would be there. :-)

    Thanks.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Apd@21:1/5 to R.Wieser on Tue Dec 8 23:43:59 2020
    "R.Wieser" wrote:
    Apd,

    Don't forget the example in the API book.

    The API book ? I take it you mean the PDF link you just provided ?

    Yes.

    The first one did have some code, but no example that I could see.

    The debug example 4 in the Appendix. Search the pdf for
    ZwReplyWaitReceivePort.

    Undocumented Windows NT
    Chapter 8 LPC

    Fun. It looks like thats same as the webpage I found containing the
    example code I started with :

    https://web.archive.org/web/20080612141354/http://www.windowsitlibrary.com/Content/356/08/toc.html

    Ah, you've seen it.

    All the other chapters can be found there, too.

    I don't know why, but pretty-much my first thought after downloading the
    PDF was to see what would happen if I would remove the PDF filename
    part, to see if I would drop into the folder and what would be there.
    :-)

    That's how I found it!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Wed Dec 9 08:36:47 2020
    Apd,

    The first one did have some code, but no example that I could see.

    The debug example 4 in the Appendix. Search the pdf for ZwReplyWaitReceivePort.

    Ah yes. Thank you. I must have browsed it to fast to notice it :-\

    I certainly can use everything there is. I'm having a blast of a time
    trying to figure out what message types the different "request" and "reply" functions send and wish to accept[1] (trying to find working client/server combinations). I also got a fair share of STATUS_INVALID_PARAMETER (0xC000000D) errors, until I figured out that the (optional) reply message needed to have its Client and Server ID's filled in.

    [1] I just tried to have the *server* close the connection, but in response
    the client (using NtRequestWaitReplyPort) just threw an error (STATUS_LPC_REPLY_LOST, 0xC0000253). I can understand why that that
    happened, but as there does not seem to be an NtRequestWaitReceivePort
    function available ...

    was to see what would happen if I would remove the PDF filename part, to
    see if I would drop into the folder and what would be there. :-)

    That's how I found it!

    I downloaded the lot for further reference. Did you notice that chaper 7 is missing ? Not that I think I will ever need it (adding services to the
    kernel) though.

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Apd@21:1/5 to R.Wieser on Wed Dec 9 13:00:08 2020
    "R.Wieser" wrote:
    I certainly can use everything there is. I'm having a blast of a time
    trying to figure out what message types the different "request" and "reply" functions send and wish to accept[1] (trying to find working client/server combinations). I also got a fair share of STATUS_INVALID_PARAMETER (0xC000000D) errors, until I figured out that the (optional) reply message needed to have its Client and Server ID's filled in.

    [1] I just tried to have the *server* close the connection, but in response the client (using NtRequestWaitReplyPort) just threw an error (STATUS_LPC_REPLY_LOST, 0xC0000253). I can understand why that that happened, but as there does not seem to be an NtRequestWaitReceivePort function available ...

    Maybe these:
    ReplyWaitReceivePort ReplyWaitReceivePortEx

    These two seem to be paired:
    ReplyWaitReplyPort ReplyWaitReceivePort

    I really don't know. Just throwing out some suggestions.

    I downloaded the lot for further reference. Did you notice that chaper 7 is missing ? Not that I think I will ever need it (adding services to the kernel) though.

    It's at the Wayback Machine web archive link you gave earlier if you
    follow the book table of contents. I already have that short chapter
    as a single html doc from when I was trying to understand how the
    system service table was used.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Thu Dec 10 08:46:49 2020
    Apd,

    [1] I just tried to have the *server* close the connection, but in
    response
    the client (using NtRequestWaitReplyPort) just threw an error
    (STATUS_LPC_REPLY_LOST, 0xC0000253). I can understand why that that
    happened, but as there does not seem to be an NtRequestWaitReceivePort
    function available ...

    Maybe these:
    ReplyWaitReceivePort ReplyWaitReceivePortEx

    I just tried swapping the code between the server and the client (the client opens the connection after which the server than calls
    NtRequestWaitReplyPort, initiating the actual data transfer). Alas, when
    the server closes its port it doesn't seem to send a LPC_PORT_CLOSED to the client (which does happen when the client closes its side). As such the client, using NtReplyWaitReceivePort, keeps waiting for more stuff to come
    in (doesn't throw an "connection gone" error either).

    And damn, due to the limited range of functions with hard-coded
    message-types I'm not even able to have the server send such a "port closed" message myself.

    Yes, I do know that I could either put that in the (extra four bytes of) the servers LPC_REQUEST message itself or send a LPC_DATAGRAM message, but I'd rather use an already, and rather apropriate, existing message for that.
    Alas it looks like thats not going to be. :-|

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From R.Wieser@21:1/5 to All on Wed Dec 9 19:28:00 2020
    Apd,

    Maybe these:
    ReplyWaitReceivePort ReplyWaitReceivePortEx

    The problem is that the client needs to initiate the communication - which I assume needs a "Request" function.

    Than again, I'm still trying to figure out the pairings ... It might work differently than I now assume.

    So, thanks for the suggestion. I definitily must take a look at it.

    It's at the Wayback Machine web archive link you gave earlier if you
    follow the book table of contents.

    Sigh ... I did not even think of doing that. :-\

    Regards,
    Rudy Wieser

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)