Attach process

[Devron Blatchford]

Hi there,

I am trying to develop a small menu application to run on an RF network, we
are using a wavelink server to communicate with our rf scanners and run
VB.NET applications on our server that repond to the scanner requests. I
would like to know if there is a way that I can spawn a process on the
server and attach it to the current thread (allow it to take control of the
server requests)? Once this spawned app exits it will return control back to
the exe (menu) that fired it.

Example:

Scanner connect to Server on port xxxx
Wavelink server fires ...\MenuApp.exe on connection to handle the requests.

MenuApp responds with some options to the RF screen.
1) App 1, ...\App1.exe
2) App 2, ...\App2.exe

App 1 selected by user.
Menu app fires App1.exe on the server and tells it to receive and respond to
future requests.
App1 exits.
MenuApp takes control again and gives the user options 1) and 2)

Any help would be appreciated.

Thanks
Devron

[Peter Huang]

Hi Devron,

Thanks for posting in the community.

First of all, I would like to confirm my understanding of your issue.
Since I am not farmilar with RF network, here I reword your senario as
below.

You have an VB.NET app which is waiting for connection form an client, once
the a client sent a request to the VB.NET application, you hope the VB.NET
application will spawn a new process to attach to the current thread. Is
the attach you mean here to run current thread in the new spawned process?

Have I fully understood you? If there is anything I misunderstood, please
feel free to let me know.

Based on knowledge, we can not attach another process to current thread.
In this senario, I think you may try to spawn a new process and pass the
necessary arguments to the process. I suggest you create a new thread to
handle the connection, this will prevent the IPC.

Threading Tutorial
http://msdn.microsoft.com/library/de...us/csref/html/
vcwlkthreadingtutorial.asp

MultiThread Port Scanner
http://www.gotdotnet.com/Community/U...mpleGuid=02c6e
0e2-c596-46e6-8aad-716161dda8e6

If you have any concern on this issue, please post here.
Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Devron Blatchford]

Yes you are on the right track. The new spawned process should handle all
future requests until it exits. I have read that this can be done somehow by
the new spawned process inheriting the handles of the existing process but
have been unable to find any examples on this.

Any more help would be appreciated.

Thanks
Devron

"Peter Huang" <v-******@online.microsoft.com> wrote in message
news:R3**************@cpmsftngxa07.phx.gbl...

Hi Devron,

Thanks for posting in the community.

First of all, I would like to confirm my understanding of your issue.
Since I am not farmilar with RF network, here I reword your senario as
below.

You have an VB.NET app which is waiting for connection form an client, once the a client sent a request to the VB.NET application, you hope the VB.NET
application will spawn a new process to attach to the current thread. Is
the attach you mean here to run current thread in the new spawned process?
Have I fully understood you? If there is anything I misunderstood, please
feel free to let me know.

Based on knowledge, we can not attach another process to current thread.
In this senario, I think you may try to spawn a new process and pass the
necessary arguments to the process. I suggest you create a new thread to
handle the connection, this will prevent the IPC.

Threading Tutorial
http://msdn.microsoft.com/library/de...us/csref/html/ vcwlkthreadingtutorial.asp

MultiThread Port Scanner
http://www.gotdotnet.com/Community/U...mpleGuid=02c6e 0e2-c596-46e6-8aad-716161dda8e6

If you have any concern on this issue, please post here.
Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Devron Blatchford]

I think the inheriting of the handle is somehow done via the CreateProcess
API.

Thanks
Devron

"Devron Blatchford" <de****@auspine.com.au> wrote in message
news:O$**************@TK2MSFTNGP12.phx.gbl...

Yes you are on the right track. The new spawned process should handle all
future requests until it exits. I have read that this can be done somehow by the new spawned process inheriting the handles of the existing process but
have been unable to find any examples on this.

Any more help would be appreciated.

Thanks
Devron

"Peter Huang" <v-******@online.microsoft.com> wrote in message
news:R3**************@cpmsftngxa07.phx.gbl...

Hi Devron,

Thanks for posting in the community.

First of all, I would like to confirm my understanding of your issue.
Since I am not farmilar with RF network, here I reword your senario as
below.

You have an VB.NET app which is waiting for connection form an client,

once

the a client sent a request to the VB.NET application, you hope the VB.NET application will spawn a new process to attach to the current thread. Is
the attach you mean here to run current thread in the new spawned

process?

Have I fully understood you? If there is anything I misunderstood, please feel free to let me know.

Based on knowledge, we can not attach another process to current thread.
In this senario, I think you may try to spawn a new process and pass the
necessary arguments to the process. I suggest you create a new thread to
handle the connection, this will prevent the IPC.

Threading Tutorial

http://msdn.microsoft.com/library/de...us/csref/html/

vcwlkthreadingtutorial.asp

MultiThread Port Scanner

http://www.gotdotnet.com/Community/U...mpleGuid=02c6e

0e2-c596-46e6-8aad-716161dda8e6

If you have any concern on this issue, please post here.
Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no

rights.

[Devron Blatchford]

Here is a snapshot of an example I have found in C++, can someone please
help me port this to VB.NET?

secAttribs.nLength = sizeof (SECURITY_ATTRIBUTES);
secAttribs.lpSecurityDescriptor = NULL;
secAttribs.bInheritHandle = TRUE;

//Set up application arguments
memset(szBuffer, 0, sizeof(szBuffer));
argStrm << (char*)appIface->Path ();
argStrm << " ";
argStrm << (char*)appIface->Args ();

memset((void*)&sisInfo, 0, sizeof(STARTUPINFO));
sisInfo.cb = sizeof(STARTUPINFO);

std::string newDirectory = appIface->Path ();
int slashNdex = newDirectory.find_last_of ('\\');

//Change current directory if needed.
if(slashNdex >= 0)
{
newDirectory = newDirectory.substr (0, slashNdex);
SetCurrentDirectory(newDirectory.data());
}//end if(slashNdex >= 0)

//Spawn child process.
process = CreateProcess(appIface->Path (), szBuffer, &secAttribs,
&secAttribs, TRUE, DETACHED_PROCESS,
NULL, NULL, &sisInfo, &piPInfo);

//Display an error if CreateProcess fails
if(!process)
{
errState->ClearError ();
errState->SetErrorLine ("Error Starting App");
errState->SetNextState (MENU);
}//end if(!process)

//Loop while spawned process is executing.
while (GetExitCodeProcess (piPInfo.hProcess , &dwResult) && (dwResult ==
STILL_ACTIVE))
Sleep(1000);

//Delete __WLPM__ menu
mnuIface->DeleteMenu ("__WLPM__");

//After process exits return to MenuSt8.
return nextState;
}

void CMenuSt8::SetErrorState ()
{
CErrorSt8* errState = (CErrorSt8*)parentMachine->ParseStateList
(ERRORSTATE);

errState->ClearError ();
errState->SetErrorLine (" User has no ");
errState->SetErrorLine (" applications ");
errState->SetNextState (SIGNON);
exitState = true;
nextState = ERRORSTATE;
}


"Devron Blatchford" <de****@auspine.com.au> wrote in message
news:Om**************@TK2MSFTNGP10.phx.gbl...

I think the inheriting of the handle is somehow done via the CreateProcess
API.

Thanks
Devron

"Devron Blatchford" <de****@auspine.com.au> wrote in message
news:O$**************@TK2MSFTNGP12.phx.gbl...

Yes you are on the right track. The new spawned process should handle all

future requests until it exits. I have read that this can be done somehow

by

the new spawned process inheriting the handles of the existing process

but have been unable to find any examples on this.

Any more help would be appreciated.

Thanks
Devron

"Peter Huang" <v-******@online.microsoft.com> wrote in message
news:R3**************@cpmsftngxa07.phx.gbl...

Hi Devron,

Thanks for posting in the community.

First of all, I would like to confirm my understanding of your issue.
Since I am not farmilar with RF network, here I reword your senario as
below.

You have an VB.NET app which is waiting for connection form an client,

once

the a client sent a request to the VB.NET application, you hope the

VB.NET application will spawn a new process to attach to the current thread. Is the attach you mean here to run current thread in the new spawned

process?

Have I fully understood you? If there is anything I misunderstood, please feel free to let me know.

Based on knowledge, we can not attach another process to current thread. In this senario, I think you may try to spawn a new process and pass the necessary arguments to the process. I suggest you create a new thread to handle the connection, this will prevent the IPC.

Threading Tutorial

http://msdn.microsoft.com/library/de...us/csref/html/

vcwlkthreadingtutorial.asp

MultiThread Port Scanner

http://www.gotdotnet.com/Community/U...mpleGuid=02c6e

0e2-c596-46e6-8aad-716161dda8e6

If you have any concern on this issue, please post here.
Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no

rights.

[Tom Shelton]

In article <u9**************@tk2msftngp13.phx.gbl>, Devron Blatchford wrote:

Hi there,

I am trying to develop a small menu application to run on an RF network, we
are using a wavelink server to communicate with our rf scanners and run
VB.NET applications on our server that repond to the scanner requests. I
would like to know if there is a way that I can spawn a process on the
server and attach it to the current thread (allow it to take control of the
server requests)? Once this spawned app exits it will return control back to
the exe (menu) that fired it.

Example:

Scanner connect to Server on port xxxx
Wavelink server fires ...\MenuApp.exe on connection to handle the requests.

MenuApp responds with some options to the RF screen.
1) App 1, ...\App1.exe
2) App 2, ...\App2.exe

App 1 selected by user.
Menu app fires App1.exe on the server and tells it to receive and respond to
future requests.
App1 exits.
MenuApp takes control again and gives the user options 1) and 2)

Any help would be appreciated.

Thanks
Devron

Devron,

I've been reading through this a little and I'm having a hard time
understanding why the apps have to be a separate process?

I think the best way to do this is using threads. You could implement
the various options as dll's (like plugins) that implement a simple
interface. The menu option just sets what dll to use to process
requests.

That way, you would have the ability to expand the implementation, and
not incure the problems/performance drawbacks of doing this using
interprocess communication.

If for some reason, you feel this must be done as separate applications,
then I would consider making them console apps. Then you could use the
System.Diagnostics.Process class to spawn the process, and redirect the
console programs stdin and stdout. Then, the server would just read and
write to the console application which would process the requests.

--
Tom Shelton [MVP]
OS Name: Microsoft Windows XP Professional
OS Version: 5.1.2600 Service Pack 1 Build 2600
System Up Time: 0 Days, 14 Hours, 23 Minutes, 25 Seconds

[Peter Huang]

Hi Devron,

Thanks for your quickly reply!

Here I write an interop code to call CreateProcess in VB.NET.

<StructLayout(LayoutKind.Sequential)> Public Structure
SECURITY_ATTRIBUTES
Public nLength As Integer
Public lpSecurityDescriptor As Integer
Public bInheritHandle As Integer
End Structure
<StructLayout(LayoutKind.Sequential)> Public Structure STARTUPINFO
Public cb As Integer
Public lpReserved As String
Public lpDesktop As String
Public lpTitle As String
Public dwX As Integer
Public dwY As Integer
Public dwXSize As Integer
Public dwYSize As Integer
Public dwXCountChars As Integer
Public dwYCountChars As Integer
Public dwFillAttribute As Integer
Public dwFlags As Integer
Public wShowWindow As Integer
Public cbReserved2 As Integer
Public lpReserved2 As Integer
Public hStdInput As Integer
Public hStdOutput As Integer
Public hStdError As Integer
End Structure
<StructLayout(LayoutKind.Sequential)> Public Structure
PROCESS_INFORMATION
Public hProcess As Integer
Public hThread As Integer
Public dwProcessId As Integer
Public dwThreadId As Integer
End Structure
Public Declare Function CreateProcess Lib "kernel32" Alias
"CreateProcessA" (ByVal lpApplicationName As String, ByVal lpCommandLine As
String, <MarshalAs(UnmanagedType.Struct)> ByRef lpProcessAttributes As
SECURITY_ATTRIBUTES, <MarshalAs(UnmanagedType.Struct)> ByRef
lpThreadAttributes As SECURITY_ATTRIBUTES, ByVal bInheritHandles As
Integer, ByVal dwCreationFlags As Integer, ByVal lpEnvironment As Integer,
ByVal lpCurrentDriectory As String, <MarshalAs(UnmanagedType.Struct)> ByRef
lpStartupInfo As STARTUPINFO, <MarshalAs(UnmanagedType.Struct)> ByRef
lpProcessInformation As PROCESS_INFORMATION) As Integer
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles Button1.Click
Dim saProcess As SECURITY_ATTRIBUTES
Dim saThread As SECURITY_ATTRIBUTES
saProcess.bInheritHandle = True
saProcess.lpSecurityDescriptor = 0
saProcess.nLength = Marshal.SizeOf(saProcess)
saThread.bInheritHandle = True
saThread.lpSecurityDescriptor = 0
saThread.nLength = Marshal.SizeOf(saThread)
Dim pi As PROCESS_INFORMATION
Dim si As STARTUPINFO
CreateProcess("C:\WINDOWS\system32\notepad.exe", " C:\test.txt",
saProcess, saThread, True, 0, Nothing, vbNullString, si, pi)
End Sub

I agree with Tom's suggestion.
From you code snipper, it seems that when you create a new child process,
the parent process will wait. That is to say the programming modal is
synchronized, so did you have any concern why you do need to create a new
process but not a thread or just do the thing in the same process.
As Tom said, in .NET you can redirect an process's stdin and stdout to do
the IPC stuff which will help you avoid the P/Invoke stuff.

In ASP.NET, as a webserver, the server application will get the request and
write the request to a named pipe and the spawned child process will read
the request from the named pipe and write the response to the parent
process by the named pipe too. But this will cause many IPC operation. So I
strongly recomment you deal with the request in the current thread, since
it seems that you do not need multiple thread function. If you wants to
separate the code that handles the request by create a new classlibrary.
Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

[Devron Blatchford]

Thanks for your responses,

I like the idea of creating the applications as classes/dll's and
registering them. I have tried this and got the desired result.

Thanks again for you suggestions and help.

Devron
"Tom Shelton" <to*@mtogden.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

In article <u9**************@tk2msftngp13.phx.gbl>, Devron Blatchford

wrote:

Hi there,

I am trying to develop a small menu application to run on an RF network, we are using a wavelink server to communicate with our rf scanners and run
VB.NET applications on our server that repond to the scanner requests. I
would like to know if there is a way that I can spawn a process on the
server and attach it to the current thread (allow it to take control of the server requests)? Once this spawned app exits it will return control back to the exe (menu) that fired it.

Example:

Scanner connect to Server on port xxxx
Wavelink server fires ...\MenuApp.exe on connection to handle the requests.
MenuApp responds with some options to the RF screen.
1) App 1, ...\App1.exe
2) App 2, ...\App2.exe

App 1 selected by user.
Menu app fires App1.exe on the server and tells it to receive and respond to future requests.
App1 exits.
MenuApp takes control again and gives the user options 1) and 2)

Any help would be appreciated.

Thanks
Devron

Devron,

I've been reading through this a little and I'm having a hard time
understanding why the apps have to be a separate process?

I think the best way to do this is using threads. You could implement
the various options as dll's (like plugins) that implement a simple
interface. The menu option just sets what dll to use to process
requests.

That way, you would have the ability to expand the implementation, and
not incure the problems/performance drawbacks of doing this using
interprocess communication.

If for some reason, you feel this must be done as separate applications,
then I would consider making them console apps. Then you could use the
System.Diagnostics.Process class to spawn the process, and redirect the
console programs stdin and stdout. Then, the server would just read and
write to the console application which would process the requests.

--
Tom Shelton [MVP]
OS Name: Microsoft Windows XP Professional
OS Version: 5.1.2600 Service Pack 1 Build 2600
System Up Time: 0 Days, 14 Hours, 23 Minutes, 25 Seconds