These two days have been ruined by this function. In the case of XP 32, connections can be established and accepted. However, after being compiled into 64-bit Windows 7, the connection cannot be connected, ntstatus 0xc0000d, status_invalid_parame
Ter.
The environment on XP 32 is:
1: An NTDLL is used. h file, and a NTDLL is connected. lib file, where NTDLL. H is the same in 32-bit and 64-bit modes, but NTDLL. the LIB files are different in 32-bit and 64-bit modes.
So: Suspect
1: Should NTDLL. h file be different in 32 and 64?
2: Is the 64-bit version of NTDLL. Lib incorrect?
3: Is the ntdll. h file version incorrect?
At first I suspected it was NTDLL on win7. the DLL file upgrade has changed, so it cannot be used, but think about it carefully. Many software and many functions can continue to run on win7, and Microsoft cannot connect to this LPC mechanism, if I have changed a lot of software, I will not be able to use it anymore. I will go to the Windows 32-bit server for testing one day, which is a waste of time,
PM: 17: 35:
Now I have found some clues, because I have two examples, one of which is encapsulated with the following:
Typedef struct _ transferred_message
{
Port_message header;
Ulong command;
Wchar messagetext [48];
} Transferred_message, * ptransferred_message;
The other name is large_message_size. Maybe this setting is a little big, but I still don't know what's going on. I will study it again next time.
The previous method can be used to connect and communicate with each other on 64-bit. However, the data I receive is not what I want. I use 32-bit data and 64-bit data, you may need to make some changes to the port_message or related message structure. I don't know yet. I will study it tomorrow and I will be off duty.