From: Rolf K. <rol...@ci...> - 2004-03-10 12:49:26
|
Jim Kring [mailto:ji...@ji...] wrote: > Regarding TortoiseCVS and piping into Plink, here is a snip > from an email I > got back from Ian: > > ########### > > My first take used the WinAPI file functions to read/write > pipes (ReadFile and WriteFile). I now see that the Tortoise > project has now added POSIX calls for the non-Win32 interface. > It might be possible to use POSIX calls from msvcrt instead > of Win32 calls from User32. Not sure what the advantage of this would be. Win32 specific code will be in there anyway and msvcrt is just built on top of the Win32 API so you basically add another software layer to it. And last but not least msvcrt is not fully POSIX complaint so you may end up with platform differences even there. > Both chunks of code are in the link below (see the "run" > function about two-thirds of the way down). I'll take a quick > peek at using execvp() from LabVIEW. > > <http://cvs.sourceforge.net/viewcvs.py/tortoisecvs/TortoiseCVS > /src/cvsgui/cv > sgui_process.cpp?rev=1.7&view=auto> I think the clean solution here would be rather to create a DLL which provides the same interface as that used by the Linux VIs. That will be enough problems to tackle I'm sure. Enclosed is a first version of what I have in mind. Rough and not tested yet but what I would see a possible implementation. Need yet to add the PipeOpenCmd implementation. Rolf Kalbermatter /* * Pipe shared library for LabVIEW * * Copyright (C) 2004 Rolf Kalbermatter, r.k...@hc... * * Please visit http://www.OpenG.org to learn about the * Open Source LabVIEW software movement. * * This library is free software; you can redistribute it and/or * modify it under the terms of the GNU Lesser General Public * License as published by the Free Software Foundation; either * version 2.1 of the License, or (at your option) any later version. * * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU * Lesser General Public License for more details. * * You should have received a copy of the GNU Lesser General Public * License along with this library; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #include "extcode.h" #include <windows.h> #ifdef _DEBUG #define DebugBreaking() {__asm int 3} #else #define DebugBreaking() #endif #if defined(PIPES_EXPORTS) #define LibAPI __declspec(dllexport) __cdecl #else #define LibAPI static #endif typedef enum { kReadMode, kWriteMode, kReadWriteMode } Modes; MgErr LibAPI PipeOpen(CStr name, uInt8 mode, uInt32 *fd); MgErr LibAPI PipeOpenCmd(CStr name, uInt8 mode, uInt32 *fdIn, uInt32 *fdOut, uInt32 *fdErr, uInt32 processID); MgErr LibAPI PipeClose(uInt32 fd); MgErr LibAPI PipeRead(uInt32 fd, uInt32 *bytesRead, LStrHandle data, uInt32 *eof); MgErr LibAPI PipeWrite(uInt32 fd, uInt32 *bytesWritten, LStrHandle data); #if defined(MSWin) static MgErr Win32ToLVErr(DWORD error); #elif defined (Unix) static MgErr UnixToLVErr(int32 errno); #endif MgErr LibAPI PipeOpen(CStr name, uInt8 mode, uInt32 *fd) { MgErr err = noErr; #if defined(MSWin) HANDLE handle; DWORD dwMode; DebugBreaking(); if (mode > kReadWriteMode) return mgArgErr; if (WaitNamedPipe(name, 2000)) { switch (mode) { case kReadMode: dwMode = FILE_READ_DATA; break; case kWriteMode: dwMode = FILE_WRITE_DATA; break; case kReadWriteMode: dwMode = FILE_READ_DATA | FILE_WRITE_DATA; break; } /* There is a server to connect to, so connect as client */ handle = CreateFile(name, dwMode, 0, NULL, OPEN_EXISTING, 0 /* SECURITY_SQOS_PRESENT | SECURITY_IDENTIFICATION */, NULL); } else { switch (mode) { case kReadMode: dwMode = PIPE_ACCESS_INBOUND; break; case kWriteMode: dwMode = PIPE_ACCESS_OUTBOUND; break; case kReadWriteMode: dwMode = PIPE_ACCESS_DUPLEX; break; } /* There is no server to connect to, so create our own server */ handle = CreateNamedPipe(name, dwMode, PIPE_TYPE_BYTE | PIPE_READMODE_BYTE, PIPE_UNLIMITED_INSTANCES, 1024, 1024, NMPWAIT_USE_DEFAULT_WAIT, NULL); } if (handle == INVALID_HANDLE_VALUE) { err = Win32ToLVErr(GetLastError()); *fd = 0; } else *fd = (uInt32)handle; #elif defined(Unix) #else err = mgNotImplementd: #endif return err; } MgErr LibAPI PipeOpenCmd(CStr name, uInt8 mode, uInt32 *fdIn, uInt32 *fdOut, uInt32 *fdErr, uInt32 processID) { SECURITY_ATTRIBUTES lsa = { 0 }; STARTUPINFO si = { 0 }; PROCESS_INFORMATION pi = { 0 }; MgErr err = noErr; return err; } MgErr LibAPI PipeClose(uInt32 fd) { MgErr err = noErr; if (!fd) return mgArgErr; #if defined(MSWin) if (!CloseHandle((HANDLE)fd)) err = Win32ToLVErr(GetLastError()); #elif defined(Unix) if (close((pipe_t)fd) < 0) ..err = UnixToLVErr(errno); #else err = mgNotImplementd: #endif return err;} MgErr LibAPI PipeRead(uInt32 fd, uInt32 *bytesRead, LStrHandle data, uInt32 *eof) { MgErr err = noErr; DWORD ret, bytes = *bytesRead; if (!fd) return mgArgErr; *eof = FALSE; err = NumericArrayResize(uB, 1, (UHandle*)&data, bytes); if (err) return err; /* We need to do this in LabVIEW 7.0 as otherwise the next NumericArrayResize() will optimize out and only copy as much characters as it sees to be in the array into the new handle if any. */ LStrLen(*data) = bytes; #if defined(MSWin) if (!ReadFile((HANDLE)fd, LStrBuf(*data), bytes, bytesRead, NULL)) { ret = GetLastError(); *eof = (ret == ERROR_HANDLE_EOF); if (!*eof) err = Win32ToLVErr(ret); } #elif defined(Unix) *bytesRead = read((pipe_t)fd, LStrBuf(*data), bytes) if (*bytesRead == 0xFFFFFFFF) { *eof = (errno == EEOF); if (!*eof) err = UnixToLVErr(errno); } #else err = mgNotImplementd; #endif if (!err && (bytes != *bytesRead)) { err = NumericArrayResize(uB, 1, &(UHandle)data, *bytesRead); LStrLen(*data) = *bytesRead; } return err; } MgErr LibAPI PipeWrite(uInt32 fd, uInt32 *bytesWritten, LStrHandle data) { MgErr err = noErr; if (!fd) return mgArgErr; #if defined(MSWin) if (!WriteFile((HANDLE)fd, LStrBuf(*data), LStrLen(*data), bytesWritten, NULL) ) err = Win32ToLVErr(GetLastError()); #elif defined(Unix) *bytesWritten = write((pipe_t)fd, LStrBuf(*data), LStrLen(*data); if (*bytesWritten == -1) err = UnixToLVErr(errno); #else err = mgNotImplementd: #endif return err; } #if defined(MSWin) static MgErr Win32ToLVErr(DWORD error) { /* No translation yet */ return error; } #elif defined(Unix) static MgErr UnixToLVErr(int32 errno) { /* No translation yet */ return error; } #endif |
From: Dees, I. <Ian...@an...> - 2004-03-11 22:14:56
|
Hi, everyone. > Not sure what the advantage of this would be. Win32 specific > code will be in there anyway and msvcrt is just built on top > of the Win32 API so you basically add another software layer > to it. And last but not least msvcrt is not fully POSIX > complaint so you may end up with platform differences even there. Well, the main issues would be ease of calling from LabVIEW, or ease of wrapping in a DLL. There are several gotchas with unnamed pipes on Windows; it's at least possible that the POSIX layer, while not a perfect emulator, uses more sensible blocking semantics. I like your approach with named pipes. This may indeed work better; one thing to watch out for, though, is that IIRC named pipes are only available for NT/2000/XP and not for 95/98/Me (don't know about CE/PocketPC). --Ian |
From: Rolf K. <rol...@ci...> - 2004-03-14 21:11:41
|
RE: LabVIEW SSH ToolsDees, Ian wrote:=20 Well, the main issues would be ease of calling from LabVIEW, or=20 ease of wrapping in a DLL. There are several gotchas with=20 unnamed pipes on Windows; it's at least possible that the POSIX=20 layer, while not a perfect emulator, uses more sensible blocking=20 semantics.=20 Mmm, this were also my concerns at first. But I thought I would = investigate into it as the work would proceed. I have to admit that I = was wondering about the blocking semantics of the Unix read() function = in general and on pipes in special. Seeing the example Jim had created I = had to assume that read() definitely would not block on unsuccesful = reads at all but just return with whatever data was present. Windows = ReadFile will indeed not work the same as in non overlapped mode it will = just block until the data it wants arrives or the pipe gets an error = such as being closed on the other side. Using overlapped mode should be = able to avoid that but is not very simple. I would however like = confirmation that read() indeed does not block on pipe reads.=20 I like your approach with named pipes. This may indeed work better;=20 one thing to watch out for, though, is that IIRC named pipes are=20 only available for NT/2000/XP and not for 95/98/Me (don't know=20 about CE/PocketPC). =20 Well there is little to do about that. The msvcrt functions won't = implement named pipes on non NT systems if the underlaying system does = not support them. Also the problem remains that named pipes under = Windows have a different name syntax than on Unix, as they are = implemented as special NT sub-namespace unlike unix which maps them into = the normal file system name space. But any help and suggestion on this is very much appreciated. Rolf Kalbermatter |
From: Dees, I. <Ian...@an...> - 2004-03-15 17:36:58
|
Hello, Rolf. > Windows ReadFile will indeed not work the same as in non overlapped > mode it will just block until the data it wants arrives or the pipe > gets an error such as being closed on the other side. I've even seen situations where ReadFile blocks indefinitely, even after the other end of the pipe was closed. That was plaguing us on the TortoiseCVS project; in fact, we had to start another thread to handle pipe I/O, so that we could kill it if there was nothing to read (which happens with CVS in some cases, even some non-error ones). --Ian |
From: Jim K. <ji...@ji...> - 2004-03-24 15:21:30
|
Hello All, Someone just started a thread in the LAVA forum called "System Exec With Interaction?" "I need to launch and control an existing commandline app from Labview. By this I mean I need to be able to read it's STDOUT and send things to STDIN while it is actually running..." http://forums.lavausergroup.org/index.php?showtopic=213 It looks like we might already have a good potential user base for the pipe package :-) -Jim |
From: Swinarsky, DJ D. (5. @ I. <d.s...@L-...> - 2004-03-24 15:53:07
|
Well... I didn't even see the pipes VIs and I have an application that needs the same functionality. I don't mind helping out with these, but need to know what is/isn't working... I have downloaded all the VIs and in the pipes directory under cvs as well as the dll. I do not have Visual C++ so I won't be much help with the dll (though I do have cygwin if it can make the dlls?). Derrick -----Original Message----- From: Jim Kring [mailto:ji...@ji...] Sent: Wednesday, March 24, 2004 9:21 AM To: ope...@li... Subject: RE: LabVIEW SSH Tools Hello All, Someone just started a thread in the LAVA forum called "System Exec With Interaction?" "I need to launch and control an existing commandline app from Labview. By this I mean I need to be able to read it's STDOUT and send things to STDIN while it is actually running..." http://forums.lavausergroup.org/index.php?showtopic=213 <http://forums.lavausergroup.org/index.php?showtopic=213> It looks like we might already have a good potential user base for the pipe package :-) -Jim |
From: Jim K. <ji...@ji...> - 2004-03-24 16:14:00
|
Derrik, =20 Thanks for the offer to help. The DLL is the workhorse of this package = and that's what's left to be developed. Rolf has done all of the work on = the DLL, so far, and Ian has contributed some feedback based on his = experience with pipes. There are still a few loose ends as far as whether to go through Win32 API or msvcrt for the pipe calls. =20 -Jim =20 -----Original Message----- From: ope...@li... [mailto:ope...@li...] On Behalf = Of Swinarsky, DJ Derrick (5453) @ IS Sent: Wednesday, March 24, 2004 7:53 AM To: 'ope...@li...' Subject: RE: LabVIEW SSH Tools Well... I didn't even see the pipes VIs and I have an application that needs the same functionality. I don't mind helping out with these, but = need to know what is/isn't working... I have downloaded all the VIs and in = the pipes directory under cvs as well as the dll. I do not have Visual C++ = so I won't be much help with the dll (though I do have cygwin if it can make = the dlls?). =20 Derrick -----Original Message----- From: Jim Kring [mailto:ji...@ji...] Sent: Wednesday, March 24, 2004 9:21 AM To: ope...@li... Subject: RE: LabVIEW SSH Tools Hello All, =20 Someone just started a thread in the LAVA forum called "System Exec With Interaction?" =20 "I need to launch and control an existing commandline app from Labview. = By this I mean I need to be able to read it's STDOUT and send things to = STDIN while it is actually running..." =20 http://forums.lavausergroup.org/index.php?showtopic=3D213 =20 It looks like we might already have a good potential user base for the = pipe package :-) =20 -Jim=20 |
From: Rolf K. <rol...@ci...> - 2004-03-25 08:44:13
|
Hi Derrick Swinarsky, DJ Derrick (5453) @ IS wrote: >Well... I didn't even see the pipes VIs and I have an application that needs the >same functionality. I don't mind helping out with these, but need to know what >is/isn't working... I have downloaded all the VIs and in the pipes directory under >cvs as well as the dll. I do not have Visual C++ so I won't be much help with the >dll (though I do have cygwin if it can make the dlls?). Not sure about cygwin use here. As I have Visual C available at my workplace I haven't felt much compelling reasons to go through the hassle of installing and getting cygwin to work. As to the dll: There are certainly several things to consider. First the currently available C code is really only a very rough draft of what the DLL should be in the end. Also the main important function with the system exe + std IO + std err pipes is not yet filled in, eventhough I have the code from both the Turtoise CVS function and the MSDN example here to draw from. Named pipes will only work on NT based Windows systems. So the simple Open function will fail on Win 9x/Me systems. Little we can do about this as Win9x just doesn't know about named pipes at all. Last but not least is it very likely that the Win32 API ReadFile() function will not behave as desired on pipe handles as in default mode it just seems to block for as long as necessary to get the requested data. For this we have to investigate a little into this. Possible solutions in order of preference: 1) Using overlapped read mode (this is the MSDN term for in principle asynchronous file IO) in ReadFile() might give us enough functionality in order to investigate both the error status of the pipe and the number of available bytes in the buffer, to abort the overlapped read mode immediately and retrieve the available data or return with an according error. 2) Creating a seperate thread to monitor the pipe handle(s). This is ugly but was the route Ian and his friends appearently decided to go in the Turtoise CVS solution. Problem is I have also a life besides of the computer programming and that is currently interfering heavily, so things on the pipe source code do not go as fast as I would like it myself. Rolf Kalbermatter CIT Engineering Nederland BV tel: +31 (070) 415 9190 Treubstraat 7H fax: +31 (070) 415 9191 2288 EG Rijswijk http://www.citengineering.com Netherlands mailto:rol...@ci... |
From: Jim K. <ji...@ji...> - 2004-03-11 04:23:45
|
Rolf Kalbermatter wrote: >=20 > Jim Kring [mailto:ji...@ji...] wrote: >=20 > > Regarding TortoiseCVS and piping into Plink, here is a snip > > from an email I > > got back from Ian: > >=20 > > ########### > >=20 > > My first take used the WinAPI file functions to read/write > > pipes (ReadFile and WriteFile). I now see that the Tortoise > > project has now added POSIX calls for the non-Win32 interface. > > It might be possible to use POSIX calls from msvcrt instead > > of Win32 calls from User32. >=20 > Not sure what the advantage of this would be. Win32 specific=20 > code will be in there anyway and msvcrt is just built on top=20 > of the Win32 API so you basically add another software layer=20 > to it. And last but not least msvcrt is not fully POSIX=20 > complaint so you may end up with platform differences even there. OK, then let's go with the WinAPI approach. >=20 > > Both chunks of code are in the link below (see the "run" > > function about two-thirds of the way down). I'll take a quick > > peek at using execvp() from LabVIEW. > >=20 > > <http://cvs.sourceforge.net/viewcvs.py/tortoisecvs/TortoiseCVS > > /src/cvsgui/cv > > sgui_process.cpp?rev=3D1.7&view=3Dauto> >=20 > I think the clean solution here would be rather to create a=20 > DLL which provides the same interface as that used by the=20 > Linux VIs. That will be enough problems to tackle I'm sure. > I think that the Linux VIs might use CINs (the VIs are locked). = Regardless, I think you are right, that this interface would be good to implement. = I have just created the interface VI "shells" (empty VIs) and populated = them with controls, indicators, icons, etc (all they need now is a Dll ;-). These have been committed to CVS (more info below). >=20 > Enclosed is a first version of what I have in mind. Rough and=20 > not tested yet but what I would see a possible=20 > implementation. Need yet to add the PipeOpenCmd implementation. >=20 > Rolf Kalbermatter >=20 > /* > * Pipe shared library for LabVIEW > * [snip] I have just created an opengtoolkit CVS module named "pipe". The VIs are located here: pipe/source/OGPIPE - VI TREE.vi pipe/source/OGPIPE Close Pipe.vi pipe/source/OGPIPE Open Pipe.vi pipe/source/OGPIPE Open System Command Pipe.vi pipe/source/OGPIPE Read From Pipe.vi pipe/source/OGPIPE RefNum.ctl pipe/source/OGPIPE Write To Pipe.vi And, the c_source is located here: pipe/c_source/pipe.c Regards, -Jim |
From: Rolf K. <rol...@ci...> - 2004-03-11 07:39:03
|
Jim Kring [mailto:ji...@ji...] =20 > I think that the Linux VIs might use CINs (the VIs are=20 > locked). In 6.x they were not locked and contained a master PIPE core VI with a CIN. The 7.0 VIs however do most probably call directly into LabVIEW with a Call Library Node, into functions which are Unix specific. > Regardless, I think you are right, that this interface would > be good to implement. I have just created the interface VI > "shells" (empty VIs) and populated them with controls, > indicators, icons, etc (all they need now is a Dll ;-). > These have been committed to CVS (more info below). You are to fast ;-). Except the OpenG color icons and the name prefix I already had those VIs laying around here. Nevermind, I'll copy the diagram code into it. Rolf Kalbermatter =20 |
From: Rolf K. <rol...@ci...> - 2004-03-11 08:51:05
|
I updated the pipe module a bit. Moved the VIs into a subfolder pipe.llb to match the other modules. Added the diagram code to the VIs and also added a first compiled dll to the module. This dll does not yet run properly but it allows to open the VIs without file dialog box. Also added the Visual C project files to build the dll from the sources. This has a problem as it contains references to the LabVIEW cintools directory in the include search path for the compiler options and the library search path for the linker options. These will need to be adjusted to the locations on your local computer to be able to use them. These will be different on different computers maybe we should add a global CINTOOLS directory to the CVS repository but there are a few issues: 1) The material is copyrighted and therefore can't be put out easily. 2) Each LabVIEW version has its own version of the cintools. I have not seen any problems when using CINs or dlls created with an older cintools version than the LabVIEW version which tries to load them. Currently I still always work with a copy of the LabVIEW 6.0 cintools to create CINs and DLLs which use LabVIEW manager functions and that seems to work fine even in LabVIEW 7.0. Rolf Kalbermatter =20 |