opengtoolkit-developers — OpenG Toolkit developers mailing list

FW: [SourceForge.net Release] opengtoolkit : ctl_buttons

[Jim K. <ji...@ji...>]

The "buttons" package has been updated for the Dynamic Palette View.  It
will place additional buttons in the 2D and 3D Boolean Controls palette.

-Jim

Release Name: 2.1

Notes:
-=3D ogctl_buttons-2.1-1.ogp =3D-

Changes:
Changes from 1.0-1 --> 2.1-1
--------------------------------
2004-03-11
[MOD] Updated packaging for dynamic palette view



-----Original Message-----
From: SourceForge.net [mailto:no...@so...]=20
Sent: Thursday, March 11, 2004 9:05 PM
To: no...@so...
Subject: [SourceForge.net Release] opengtoolkit : ctl_buttons


Project: OpenG Toolkit  (opengtoolkit)
Package: ctl_buttons
Date   : 2004-03-11 21:04

Project "OpenG Toolkit" ('opengtoolkit') has released the new version of
package 'ctl_buttons'. You can download it from SourceForge.net by =
following
this link:
<https://sourceforge.net/project/showfiles.php?group_id=3D52435&release_i=
d=3D223
061>
or browse Release Notes and ChangeLog by visiting this link:
<https://sourceforge.net/project/shownotes.php?release_id=3D223061>=20

You receive this email because you requested to be notified when new
versions of this package were released. If you don't wish to be notified =
in
the future, please login to SourceForge.net and click this link:
<https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=3D=
1120
57>
If you lost your SourceForge.net login name or password, refer to this
document:
<https://sourceforge.net/docman/display_doc.php?docid=3D760&group_id=3D1>=


Note that you may receive this message indirectly via one of your =
mailing
list subscriptions. Please review message headers before reporting
unsolicited mailings.

RE: LabVIEW SSH Tools

[Dees, I. <Ian...@an...>]

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

RE: OpenG Port IO library

[Jim K. <ji...@ji...>]

Rolf,

Rolf Kalbermatter wrote:
>=20
> Hello
>=20
> I have made two changes:
>=20
> 1) I added a description.htm file inside the c_source directory
>    which is the beginning of a description of the workings of the
>    device driver/user space shared library.

I noticed that the portIO icon image was "broken" when I viewed it, so I
changed description.htm so that the path to ogportio.bmp is relative =
instead
of absolute.

-Jim

>=20
> 2) I created a project page on OpenG for this module with a short
>    description. However I made a mistake when creating that page
>    by naming it "Open G Port IO" instead of "OpenG Port IO" but
>    I don't know how to change the name of a page once it has been
>    created.
>=20
>=20
> Rolf Kalbermatter
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President=20
> and CEO of GenToo technologies. Learn everything from=20
> fundamentals to system=20
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
> _______________________________________________
> OpenGToolkit-Developers mailing list=20
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
>=20

RE: OpenG Port IO library

[Jim K. <ji...@ji...>]

Rolf,

Rolf Kalbermatter wrote:
> 
> Hello
> 
> I have made two changes:
> 
> 1) I added a description.htm file inside the c_source directory
>    which is the beginning of a description of the workings of the
>    device driver/user space shared library.
>
> 2) I created a project page on OpenG for this module with a short
>    description. However I made a mistake when creating that page
>    by naming it "Open G Port IO" instead of "OpenG Port IO" but
>    I don't know how to change the name of a page once it has been
>    created.

I have just changed it.  I have not assigned users the permission to change
page names - otherwise you would have seen a tab called "rename" at the top
of the page.  I might need to create a group for project admins and give
them more access -- I'll work on this.

-Jim

> 
> 
> Rolf Kalbermatter
> 
> 
> 

OpenG Port IO library

[Rolf K. <rol...@ci...>]

Hello

I have made two changes:

1) I added a description.htm file inside the c_source directory
   which is the beginning of a description of the workings of the
   device driver/user space shared library.

2) I created a project page on OpenG for this module with a short
   description. However I made a mistake when creating that page
   by naming it "Open G Port IO" instead of "OpenG Port IO" but
   I don't know how to change the name of a page once it has been
   created.


Rolf Kalbermatter

RE: LabVIEW SSH Tools

[Rolf K. <rol...@ci...>]

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

RE: LabVIEW SSH Tools

[Rolf K. <rol...@ci...>]

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

RE: LabVIEW SSH Tools

[Jim K. <ji...@ji...>]

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

OpenG Public License - Draft Version (was RE: FW: MPL vs LGPL)

[Jim K. <ji...@ji...>]

Albert et al.,

I have completed a first draft of the OGPL, which is a derivitive of the =
MPL
1.1 and includes the changes that I previously mentioned:

<http://www.openg.org/tiki/tiki-index.php?page=3DOpenG+Public+License>

Please keep in mind that:

A) This is a draft version
B) I have not yet had any laywer-types review this
C) I have not yet had *anyone* review this ;-)

> Thanks for the work you do.

It is a pleasure :-)  And, thank you for your continued support and
participation.

-Jim


-----Original Message-----
From: ope...@li...
[mailto:ope...@li...] On Behalf =
Of
alb...@ph...
Sent: Tuesday, March 09, 2004 6:40 AM
To: ope...@li...
Subject: Re: FW: MPL vs. LGPL



Hi Jim=20

Thanks for the work you do. In fact you are openG.=20

=20
=20
I think that hese modifications will do but before I agree completely I =
will
check with our legal guys.=20

I keep you informed

Albert Geven                                         Tel  +31 (0)40 27 =
43019
Philips Research                                 email
alb...@ph...
prof Holstlaan 4        WAA01
5656AA Eindhoven

RE: LabVIEW SSH Tools

[Rolf K. <rol...@ci...>]

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

Re: FW: MPL vs. LGPL

[<alb...@ph...>]

Hi Jim

Thanks for the work you do. In fact you are openG.

I think that hese modifications will do but before I agree completely I 
will check with our legal guys.

I keep you informed

Albert Geven                                         Tel  +31 (0)40 27 
43019
Philips Research                                 email 
alb...@ph...
prof Holstlaan 4        WAA01
5656AA Eindhoven

FW: MPL vs. LGPL

[Jim K. <ji...@ji...>]

Hello All,

A while ago, I began an initiative to find a new license for OpenG code,
which would eliminate the need to allow users to relink/rebuild to new
version of protected libraries.  This requirement of the LGPL is not =
very
useful to the end customer's of LabVIEW software products and it is a =
pain
for developers who use OpenG libraries in their software products.  With
that in mind, I set out to find or build a better license.  The Mozilla
Public License seems like the best fit, but has a few issues that need =
to be
addressed.  I have responded, at length, to a question posted by David
Moore, on the OpenG.org discussion form titled "MPL vs. LGPL" which =
talks
about the issues I have with the MPL and what I think it will take to =
modify
the license and transfer over to the new license.  The forum topic is
located here:

<http://www.openg.org/tiki/tiki-view_forum_thread.php?forumId=3D3&comment=
s_par
entId=3D286>

I have reproduced my response, below, but you might want to visit the =
forum
since there are hyperlinks to the various licenses and there is =
formatting
that might make it easier to read.

Regards,

-Jim Kring


###########################################################

David,

First of all, let me reiterate what we want (or at least what I have
gathered that a majority of us want) from our license:

--------------------------------------------
The Purpose (according to Jim) of an Open Source license for OpenG:
--------------------------------------------
The purpose of the license is to place minimal restrictions on users of =
the
protected code, but require that modifications to the protected code be
licensed under the terms of the same license and made available to the
public free of charge.
--------------------------------------------


You asked, "How do we make that happen, or are there objections?" The =
answer
is that we need to decide on the final form of the license (keep reading =
for
some of my issues with the MPL) and get the direct contributors of OpenG
source code to agree (in writing) to the new license. I have already =
gotten
informal approval for this transition from nearly all of the direct
contributors. No, I don't see there being any objections to loosening =
the
license by removing the relinking requirement. However, prior to
transferring code over to the new license, I will need to send the new
license to the legal departments of a few of the larger private
organizations using LabVIEW, and get a green light.

As I have mentioned, I like the Mozilla Public License (MPL) because it =
was
designed to allow commercial use of protected code, with minimal
restrictions on original works and unmodified protected code. It =
requires
that modifications to protected code be made available to recipients of
executable code, and it does not have the "relinking requirement" of the
LGPL.

However, I do have some issues with the MPL which we need to address. =
The
first issue that I see with the MPL is this:

Do we want to use the MPL, as is, or do we want to make any changes to =
it?

Sections 6.1 and 6.2 shown, below, allow the recipients of Covered Code =
to
(optionally) use the Covered Code under the terms of any future version =
of
the MPL.

--------------------------------------------
Sections 6.1 and 6.2 of the MPL 1.1:
--------------------------------------------
6.1. New Versions.
Netscape Communications Corporation (Netscape) may publish revised =
and/or
new versions of the License from time to time. Each version will be =
given a
distinguishing version number.

6.2. Effect of New Versions.
Once Covered Code has been published under a particular version of the
License, You may always continue to use it under the terms of that =
version.
You may also choose to use such Covered Code under the terms of any
subsequent version of the License published by Netscape. No one other =
than
Netscape has the right to modify the terms applicable to Covered Code
created under this License.
--------------------------------------------


We must then ask the question: "Do we implicitly trust future versions =
of
the MPL that Netscape (an AOL Time Warner subsidiary) may publish?" My =
gut
instinct is to say, "No".

If we decide that we do not want Netscape to have the authority to =
release
the new versions of our license, let's call it the OpenG Public License
(OGPL), then who should have the authority? There are a couple choices: =
(A)
Nobody - meaning that the OGPL will remain forever static, or (B) Us - =
but
who are we? OpenG.org is owned and controlled solely by me (Jim Kring), =
and
I don't know if that fact would help people sleep at night any more than =
if
Netscape had the authority to release new versions of our license. We =
could
establish OpenG.org as a legal entity controlled by a governing body =
made up
of voting community members, like IEEE. This, however, would probably be
pretty complicated and require levels of funding and organization that =
don't
yet exist within the OpenG community. So, it seems like the best choice =
is
to make the OGPL unchanging. And, this is not a terrible choice. For
example, the MIT License, BSD License, and Artistic License do not have
provisions for releasing new versions.

So it seems to me that we would want to create derivative of the MPL, =
and as
such, per section 6.3 (shown below), we must remove all references to
Mozilla and Netscape.

--------------------------------------------
Section 6.3 of the MPL 1.1:
--------------------------------------------
6.3. Derivative Works.
If You create or use a modified version of this License (which you may =
only
do in order to apply it to code which is not already Covered Code =
governed
by this License), You must (a) rename Your license so that the phrases
Mozilla, MOZILLAPL, MOZPL, Netscape, "MPL", NPL or any confusingly =
similar
phrase do not appear in your license (except to note that your license
differs from this License) and (b) otherwise make it clear that Your =
version
of the license contains terms which differ from the Mozilla Public =
License
and Netscape Public License. (Filling in the name of the Initial =
Developer,
Original Code or Contributor in the notice described in Exhibit A shall =
not
of themselves be deemed to be modifications of this License.)
--------------------------------------------


So, if we decide to change the license, we should change all instances =
of
Mozilla to OpenG (and MPL to OGPL), and remove Section 6, in its =
entirety
(which consists of 6.1, 6.3, and 6.3 shown above).

I also think that we should remove Section 13, "Multiple-Licensed Code"
(shown below), which was introduced in version 1.1 of the MPL.

--------------------------------------------
Section 6.1 of the MPL 1.1:
--------------------------------------------
13. MULTIPLE-LICENSED CODE.

Initial Developer may designate portions of the Covered Code as
Multiple-Licensed?. Multiple-Licensed? means that the Initial Developer
permits you to utilize portions of the Covered Code under Your choice of =
the
NPL or the alternative licenses, if any, specified by the Initial =
Developer
in the file described in Exhibit A.
--------------------------------------------

I think that allowing multiple licenses just complicates things. So,
removing Section 13 also results in the second half of Exhibit A (shown
below) disappearing:

--------------------------------------------
Bottom Half of Exhibit A of the MPL 1.1:
--------------------------------------------
Alternatively, the contents of this file may be used under the terms of =
the
_ license (the _ License), in which case the provisions of License are
applicable instead of those above. If you wish to allow use of your =
version
of this file only under the terms of the License and not to allow others =
to
use your version of this file under the MPL, indicate your decision by
deleting the provisions above and replace them with the notice and other
provisions required by the _ License. If you do not delete the =
provisions
above, a recipient may use your version of this file under either the =
MPL or
the _ License."

NOTE: The text of this Exhibit A may differ slightly from the text of =
the
notices in the Source Code files of the Original Code. You should use =
the
text of this Exhibit A rather than the text found in the Original Code
Source Code for Your Modifications.
--------------------------------------------

Additionally, I would like to augment section 3.2. "Availability of =
Source
Code" (shown below) so that it requires that modifications to the =
Covered
Code which are distributed outside one's organization be made available =
to
the entire community, not just the recipients of the Executable version.

--------------------------------------------
Section 3.2 of the MPL 1.1:
--------------------------------------------
3.2. Availability of Source Code.
Any Modification which You create or to which You contribute must be =
made
available in Source Code form under the terms of this License either on =
the
same media as an Executable version or via an accepted Electronic
Distribution Mechanism to anyone to whom you made an Executable version
available; and if made available via Electronic Distribution Mechanism, =
must
remain available for at least twelve (12) months after the date it =
initially
became available, or at least six (6) months after a subsequent version =
of
that particular Modification has been made available to such recipients. =
You
are responsible for ensuring that the Source Code version remains =
available
even if the Electronic Distribution Mechanism is maintained by a third
party.
--------------------------------------------

For example, the Artistic License states the following (pay attention to
3.a.):

--------------------------------------------
Section 3 of the Artistic License:
--------------------------------------------
3. You may otherwise modify your copy of this Package in any way, =
provided
that you insert a prominent notice in each changed file stating how and =
when
you changed that file, and provided that you do at least ONE of the
following:
a) place your modifications in the Public Domain or otherwise make them
Freely Available, such as by posting said modifications to Usenet or an
equivalent medium, or placing the modifications on a major archive site =
such
as ftp.uu.net, or by allowing the Copyright Holder to include your
modifications in the Standard Version of the Package.
b) use the modified Package only within your corporation or =
organization.
c) rename any non-standard executables so the names do not conflict with
standard executables, which must also be provided, and provide a =
separate
manual page for each non-standard executable that clearly documents how =
it
differs from the Standard Version.
d) make other distribution arrangements with the Copyright Holder.
--------------------------------------------

Well, I've said a mouthful. I'll work on a draft of the OGPL with the
changes that I have mentioned and post it for review and comments.

-Jim Kring

FW: [SourceForge.net Release] opengtoolkit : rsc_deab

[Jim K. <ji...@ji...>]

Oops, I added a bug in 0.8.  It wasn't reading the "Namespace" from the
build file.  I also added a new feature that automatically renames =
illegal
file names during the build.  This fixes problems caused by the infamous
"Open/Create/Replace File.vi".  BTW, when will NI create a renamed =
version
of this VI and push the original one into the compatibility archive?...

Please upgrade to 0.9,

-Jim

---------------------------------------------

Release Name: 0.9

Notes:
-=3D ogrsc_deab-0.9-1.ogp =3D-

Changes:
Changes from 0.8-1 --> 0.9-1
--------------------------------
2004-03-08
[FIX] Namespace was not being read from build file
[MOD] Illegal file names are now converted automatically
      by .\project\llbedit.llb\Is Name Multiplatform.vi


Changes from 0.7-1 --> 0.8-1
--------------------------------
2004-03-06
[Mod] Rebuilt with appcontrol 2.2 to fix build on 6.0 and 6.1
[Mod] Added Project Root key and better construction of paths
2003-12-01
[Fix] Now ignores comments in INI file
[Fix] Only attempts to delete files (to overwrite)
      if they exist.  This was causing errors if
      the files didn't exist.
[Mod] Now only deletes target files, not the entire
      target folder


-----Original Message-----
From: SourceForge.net [mailto:no...@so...]=20
Sent: Monday, March 08, 2004 8:21 PM
To: no...@so...
Subject: [SourceForge.net Release] opengtoolkit : rsc_deab


Project: OpenG Toolkit  (opengtoolkit)
Package: rsc_deab
Date   : 2004-03-08 20:20

Project "OpenG Toolkit" ('opengtoolkit') has released the new version of
package 'rsc_deab'. You can download it from SourceForge.net by =
following
this link:
<https://sourceforge.net/project/showfiles.php?group_id=3D52435&release_i=
d=3D222
488>
or browse Release Notes and ChangeLog by visiting this link:
<https://sourceforge.net/project/shownotes.php?release_id=3D222488>=20

You receive this email because you requested to be notified when new
versions of this package were released. If you don't wish to be notified =
in
the future, please login to SourceForge.net and click this link:
<https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=3D=
4659
0>
If you lost your SourceForge.net login name or password, refer to this
document:
<https://sourceforge.net/docman/display_doc.php?docid=3D760&group_id=3D1>=


Note that you may receive this message indirectly via one of your =
mailing
list subscriptions. Please review message headers before reporting
unsolicited mailings.

FW: [SourceForge.net Release] opengtoolkit : rsc_deab

[Jim K. <ji...@ji...>]

Oops, I added a bug in 0.8.  It wasn't reading the "Namespace" from the
build file.  I also added a new feature that automatically renames =
illegal
file names during the build.  This fixes problems caused by the infamous
"Open/Create/Replace File.vi".  BTW, when will NI create a renamed =
version
of this VI and push the original one into the compatibility archive?...

Please upgrade to 0.9,

-Jim

---------------------------------------------

Release Name: 0.9

Notes:
-=3D ogrsc_deab-0.9-1.ogp =3D-

Changes:
Changes from 0.8-1 --> 0.9-1
--------------------------------
2004-03-08
[FIX] Namespace was not being read from build file
[MOD] Illegal file names are now converted automatically
      by .\project\llbedit.llb\Is Name Multiplatform.vi


Changes from 0.7-1 --> 0.8-1
--------------------------------
2004-03-06
[Mod] Rebuilt with appcontrol 2.2 to fix build on 6.0 and 6.1
[Mod] Added Project Root key and better construction of paths
2003-12-01
[Fix] Now ignores comments in INI file
[Fix] Only attempts to delete files (to overwrite)
      if they exist.  This was causing errors if
      the files didn't exist.
[Mod] Now only deletes target files, not the entire
      target folder


-----Original Message-----
From: SourceForge.net [mailto:no...@so...]=20
Sent: Monday, March 08, 2004 8:21 PM
To: no...@so...
Subject: [SourceForge.net Release] opengtoolkit : rsc_deab


Project: OpenG Toolkit  (opengtoolkit)
Package: rsc_deab
Date   : 2004-03-08 20:20

Project "OpenG Toolkit" ('opengtoolkit') has released the new version of
package 'rsc_deab'. You can download it from SourceForge.net by =
following
this link:
<https://sourceforge.net/project/showfiles.php?group_id=3D52435&release_i=
d=3D222
488>
or browse Release Notes and ChangeLog by visiting this link:
<https://sourceforge.net/project/shownotes.php?release_id=3D222488>=20

You receive this email because you requested to be notified when new
versions of this package were released. If you don't wish to be notified =
in
the future, please login to SourceForge.net and click this link:
<https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=3D=
4659
0>
If you lost your SourceForge.net login name or password, refer to this
document:
<https://sourceforge.net/docman/display_doc.php?docid=3D760&group_id=3D1>=


Note that you may receive this message indirectly via one of your =
mailing
list subscriptions. Please review message headers before reporting
unsolicited mailings.

RE: Login to openG

[Jim K. <ji...@ji...>]

Rolf,

It appears that when Tiki (the OpenG.org engine) tries to contact your =
mail
server (deliver20.hccnet.nl:25) it causes a TCP socket error in Tiki.  I
tried opening a connection to this server on port 25 (from LabVIEW ;-) =
and
it seems OK, to me.  Your other email address doesn't seem to cause this
problem, with Tiki.  Since you are now registered, just go to the
preferences page and change your email address.

Preferences Page:
<http://openg.org/tiki/tiki-user_preferences.php>

-Jim

> -----Original Message-----
> From: ope...@li...=20
> [mailto:ope...@li...]=20
> On Behalf Of Rolf Kalbermatter
> Sent: Saturday, March 06, 2004 5:02 PM
> To: ope...@li...
> Subject: Login to openG
>=20
>=20
> Hi Jim
>=20
> I just decided to register on OpenG but funny enough it=20
> rejected my private email address r.k...@hc....=20
> Does your signup verification only accept .com addresses?
>=20
> Well I signed up using my company address by now but find it=20
> strange that a totally legal email address is rejected to be invalid.
>=20
> Rolf Kalbermatter
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President=20
> and CEO of GenToo technologies. Learn everything from=20
> fundamentals to system=20
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
> _______________________________________________
> OpenGToolkit-Developers mailing list=20
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
>=20
>=20

Login to openG

[Rolf K. <rol...@ci...>]

Hi Jim

I just decided to register on OpenG but funny enough it rejected my
private email address r.k...@hc.... Does your signup =
verification
only accept .com addresses?

Well I signed up using my company address by now but find it strange =
that
a totally legal email address is rejected to be invalid.

Rolf Kalbermatter

FW: [SourceForge.net Release] opengtoolkit : rsc_deab

[Jim K. <ji...@ji...>]

Hello all,

I just released version 0.8 of the Development Environment Application
Builder.  This new version features several improvements. In fact it is
finally a suitable replacement for the LabVIEW Application Builder =
(IMO),
with the only shortcoming being that it cannot create an installer.

There are links to downloads and documentation on the following page:

<http://openg.org/tiki/tiki-index.php?page=3DDevelopment+Environment+Appl=
icati
on+Builder>

On the above page, there are links to:

* the DEAB v0.8 download from SourceForge.net
* a page with documentation on the DEAB Build File Format.
* an updated example project download with complete annotation of the
various sections and keys of the DEAB build file.

Please download the example project and see how you can build EXE's with =
the
DEAB.  Also, note that this provides the ability to push OpenG VIs into =
an
external LLB and preserve the Block Diagrams (Source Code), per the LGPL
req's.

As always, feedback is valuable and appreciated ;-)

Regards,

-Jim

---------------------------------------------------

Release Name: 0.8

Notes:
-=3D ogrsc_deab-0.8-1.ogp =3D-

Visit=20

http://openg.org for documentation and examples


Changes:
Changes from 0.7-1 --> 0.8-1
--------------------------------
2004-03-06
[Mod] Rebuilt with appcontrol 2.2 to fix EXE build on 6.0 and 6.1
[Mod] Added Project Root key and better construction of paths
2003-12-01
[Fix] Now ignores comments in INI file
[Fix] Only attempts to delete files (to overwrite)
      if they exist.  This was causing errors if
      the files didn't exist.
[Mod] Now only deletes target files, not the entire
      target folder


-----Original Message-----
From: SourceForge.net [mailto:no...@so...]=20
Sent: Saturday, March 06, 2004 3:26 PM
To: no...@so...
Subject: [SourceForge.net Release] opengtoolkit : rsc_deab


Project: OpenG Toolkit  (opengtoolkit)
Package: rsc_deab
Date   : 2004-03-06 15:25

Project "OpenG Toolkit" ('opengtoolkit') has released the new version of
package 'rsc_deab'. You can download it from SourceForge.net by =
following
this link:
<https://sourceforge.net/project/showfiles.php?group_id=3D52435&release_i=
d=3D221
941>
or browse Release Notes and ChangeLog by visiting this link:
<https://sourceforge.net/project/shownotes.php?release_id=3D221941>=20

You receive this email because you requested to be notified when new
versions of this package were released. If you don't wish to be notified =
in
the future, please login to SourceForge.net and click this link:
<https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=3D=
4659
0>
If you lost your SourceForge.net login name or password, refer to this
document:
<https://sourceforge.net/docman/display_doc.php?docid=3D760&group_id=3D1>=


Note that you may receive this message indirectly via one of your =
mailing
list subscriptions. Please review message headers before reporting
unsolicited mailings.

FW: [SourceForge.net Release] opengtoolkit : all_packages

[Jim K. <ji...@ji...>]

Release Name: 2.1.6

Notes:
-=3D all_packages-2.1.6 =3D-

oglib_appcontrol-2.2-1
oglib_array-2.0-1
oglib_boolean-2.0-1
oglib_comparison-2.0-1
oglib_error-2.0-1
oglib_file-2.2-1
oglib_lvdata-2.2-1
oglib_lvzip-2.0-2
oglib_msgqueue-2.0-1
oglib_numeric-2.0-1
oglib_string-2.1-1
oglib_time-2.0-1
oglib_variantconfig-2.2-1
ogrsc_dynamicpalette-0.6-1
ogrsc_restart-1.0-1

Notes:

* dynamicpalette-0.6 is compatible with LabVIEW 6.0, 6.1, and 7.0 on
  Windows; 6.1 and 7.0 on Linux; and 7.0 on Mac OS X
* OpenG Toolkit 2.x packages are name mangled as "*__ogtk.vi" to avoid
  namespace collisions with vi.lib


Changes:
-=3D 2.1.6 Changelog =3D-

all_packages         2.1.5 --> 2.1.6
--------------------------------------
oglib_appcontrol     2.1-1 --> 2.2-1 (fixed 'Dist Build App from LLB
(proxy)' for 6.1-7.0)



-----Original Message-----
From: SourceForge.net [mailto:no...@so...]=20
Sent: Friday, March 05, 2004 6:51 PM
To: no...@so...
Subject: [SourceForge.net Release] opengtoolkit : all_packages


Project: OpenG Toolkit  (opengtoolkit)
Package: all_packages
Date   : 2004-03-05 18:50

Project "OpenG Toolkit" ('opengtoolkit') has released the new version of
package 'all_packages'. You can download it from SourceForge.net by
following this link:
<https://sourceforge.net/project/showfiles.php?group_id=3D52435&release_i=
d=3D221
772>
or browse Release Notes and ChangeLog by visiting this link:
<https://sourceforge.net/project/shownotes.php?release_id=3D221772>=20

You receive this email because you requested to be notified when new
versions of this package were released. If you don't wish to be notified =
in
the future, please login to SourceForge.net and click this link:
<https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=3D=
6073
1>
If you lost your SourceForge.net login name or password, refer to this
document:
<https://sourceforge.net/docman/display_doc.php?docid=3D760&group_id=3D1>=


Note that you may receive this message indirectly via one of your =
mailing
list subscriptions. Please review message headers before reporting
unsolicited mailings.

FW: [SourceForge.net Release] opengtoolkit : lib_appcontrol

[Jim K. <ji...@ji...>]

Release Name: 2.2

Notes:
-=3D oglib_appcontrol-2.2-1.ogp =3D-


Changes:
Changes from 2.1-2 --> 2.2-1
--------------------------------
2004-03-05
[FIX] "Dist Build App from LLB (proxy).vi" works in 6.1 and 7.0


Changes from 2.0-2 --> 2.1-1
--------------------------------
2003-12-01
[FIX] 'Mangle VI Name' window title no longer shows '__ogtk'


-----Original Message-----
From: SourceForge.net [mailto:no...@so...]=20
Sent: Friday, March 05, 2004 6:50 PM
To: no...@so...
Subject: [SourceForge.net Release] opengtoolkit : lib_appcontrol


Project: OpenG Toolkit  (opengtoolkit)
Package: lib_appcontrol
Date   : 2004-03-05 18:50

Project "OpenG Toolkit" ('opengtoolkit') has released the new version of
package 'lib_appcontrol'. You can download it from SourceForge.net by
following this
link:
<https://sourceforge.net/project/showfiles.php?group_id=3D52435&release_i=
d=3D221
773>
or browse Release Notes and ChangeLog by visiting this link:
<https://sourceforge.net/project/shownotes.php?release_id=3D221773>=20

You receive this email because you requested to be notified when new
versions of this package were released. If you don't wish to be notified =
in
the future, please login to SourceForge.net and click this link:
<https://sourceforge.net/project/filemodule_unmonitor.php?filemodule_id=3D=
5615
1>
If you lost your SourceForge.net login name or password, refer to this
document:
<https://sourceforge.net/docman/display_doc.php?docid=3D760&group_id=3D1>=


Note that you may receive this message indirectly via one of your =
mailing
list subscriptions. Please review message headers before reporting
unsolicited mailings.

RE: First release of Port IO library for Windows 9x/ME/NT/2000/XP/2003

[Jim K. <ji...@ji...>]

Rolf Kalbermatter <rol...@ci...> said:

[snip]
 
> One possibility might be to test the port at 0x42 which should be
> the counter for the beeper. I included a beeper example which might
> be useful as test/example utility for people to see that the
> routines actually work at all ;-)

It beeps beautifully on my WinXP Laptop.  It even turned the head of the 
fellow in the cubicle next to mine  :-)

[snip]

> > Also, I'll volunteer to create an MNU file for this package 
> > so that we can integrate it into the palettes.
> 
> Well thanks I just looked at teh OpenG installer you sent me. Nice.

Thanks,

-Jim

RE: First release of Port IO library for Windows 9x/ME/NT/2000/XP/2003

[Rolf K. <rol...@ci...>]

Jim Kring [mailto:ji...@ji...] wrote:

> I downloaded and tested on my WinXP laptop, but I couldn't=20
> get it to work.
> My laptop doesn't have a parallel port, which might be the problem (no
> hardware at 0x378).  When I run the test VI, regardless of=20
> what I set the
> "write value" to, the "written value" (read value) is always 255.

Well 255 is the inactive state of the databus as it is terminated
with pullup resistors in all modern systems. Not really sure what
other addresses would be save. I completely crashed my system the
first time I wrote into the first few address at 0x0 by accident ;-)

One possibility might be to test the port at 0x42 which should be
the counter for the beeper. I included a beeper example which might
be useful as test/example utility for people to see that the
routines actually work at all ;-)

But I'm sure there are soon computers out there which do not have
this speaker anymore! The hardware will probably remain as it is
nowadays all integrated in the chipsets but the speaker may have
to go to save another 5 cent in production costs in some computers.

> I'll see if I can get some other folks to do some further testing.
> It might be nice to do some speed benchmarks in a real-world=20
> application.  I know someone with a Parallel Port I2C/SPI driver
> board. The device driver for the board currently uses NI's PortIO
> driver. A speed boost would be really useful for this person's
> application since chip test folks always want to do things *faster* =
:-) =20

Well, I was thinking that with a little change I may squezze out
another few ns ;-). No honestly this is about as fast as it gets
and it is a real hack as it effectively circumvents all the protection
the Windows NT kernel puts up to prevent an application from trashing
the system or even possibiliy gaining access to resources usually
protected by passwords and such.
But hey there are people who want this and I'm not going to prevent
other people from shooting in their own foot ;-)=20
On Linux there is also a similar possible hack I have investigated,
but to be honest I am reluctant to try to do that there. It just
goes around any and all protection built into the kernel by requiring
a user to have root privileges to do certain stuff.

> Also, I'll volunteer to create an MNU file for this package=20
> so that we can integrate it into the palettes.

Well thanks I just looked at teh OpenG installer you sent me. Nice.

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...
=20

RE: LabVIEW SSH Tools

[Jim K. <ji...@ji...>]

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.

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=3D1.7&view=3Dauto>

###########

-Jim

RE: First release of Port IO library for Windows 9x/ME/NT/2000/XP/2003

[Jim K. <ji...@ji...>]

Very nice work, Rolf.

I downloaded and tested on my WinXP laptop, but I couldn't get it to =
work.
My laptop doesn't have a parallel port, which might be the problem (no
hardware at 0x378).  When I run the test VI, regardless of what I set =
the
"write value" to, the "written value" (read value) is always 255.

I'll see if I can get some other folks to do some further testing.  It =
might
be nice to do some speed benchmarks in a real-world application.  I know
someone with a Parallel Port I2C/SPI driver board.  The device driver =
for
the board currently uses NI's PortIO driver.  A speed boost would be =
really
useful for this person's application since chip test folks always want =
to do
things *faster* :-) =20

Also, I'll volunteer to create an MNU file for this package so that we =
can
integrate it into the palettes.

-Jim

> -----Original Message-----
> From: ope...@li...=20
> [mailto:ope...@li...]=20
> On Behalf Of Rolf Kalbermatter
> Sent: Wednesday, March 03, 2004 6:00 AM
> To: ope...@li...
> Subject: First release of Port IO library for Windows=20
> 9x/ME/NT/2000/XP/2003
>=20
>=20
> Hello all,
>=20
> I have just uploaded the first release V1.01 of a VI library=20
> with associated user space dll and NT device driver to allow=20
> access of the Port IO address space on x86 systems. The CVS=20
> module name is "portIO".
>=20
> Packaging is not yet done and I would prefer some people with=20
> CVS access using this library first on different systems. It=20
> has been tested on NT4, 2000, and XP to work as suspected ;-)=20
>=20
> The way this works is that the user space DLL decides if the=20
> system is NT based and opens, and if necessary, installs the=20
> device driver on the system. Each function should be able to=20
> perform this check but in general it is a good idea to first=20
> call once the PORT IO Get Version.vi. For this to work you=20
> need to have administrator rights the first time when it is=20
> attempting to install the device driver.
>=20
> Then the PORT IO Read and Write functions have basically two=20
> modes. A normal mode where they access the device driver to=20
> let it read or write the actual value (this is the same as=20
> what the current LabVIEW distributed IO library does), and a=20
> fast mode where they will directly perform the according IO=20
> port access in the user space DLL. (For Windows 9x/ME systems=20
> there is no difference between these two modes as no device=20
> driver is needed to access Port IO from user space.)
>=20
> In order for the user space library to be able to access the=20
> port directly on NT based systems you need however to enable=20
> that port or port range first with the PORT IO Enable=20
> Range.vi function. Just pass in the base address and the=20
> number of consecutive port addresses you want to have access=20
> to and you should be able to access these ports in fast mode.
>=20
> =3D=3D> Watch out writing randomly to IO ports in your system=20
> will most probably result in a crash and eventually damage=20
> your hardware and/or software.
>=20
> Save address ranges are usually 0x220-0x22F (unless you use a=20
> GPIB card), 0x300-0x33F (prototype range), and 0x378-0x37F=20
> (LPT1), but your mileage may vary.
>=20
> Tests on my Pentium 3 Mobile 866 MHz system show that to read=20
> 1000 times 8 registers uses around 750 ms in traditional=20
> (device driver access) mode whereas it performs the same=20
> operation in 20 ms in the fast mode.
>=20
> Depending on time and motivation I may also try to upload the=20
> necessary source code and shared library to perform these=20
> same operations transparently on Linux systems.
>=20
> Enjoy
>=20
> 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...
> =20
>=20
>=20

First release of Port IO library for Windows 9x/ME/NT/2000/XP/2003

[Rolf K. <rol...@ci...>]

Hello all,

I have just uploaded the first release V1.01 of a VI library with associated
user space dll and NT device driver to allow access of the Port IO address
space on x86 systems. The CVS module name is "portIO".

Packaging is not yet done and I would prefer some people with CVS access using
this library first on different systems. It has been tested on NT4, 2000, and XP
to work as suspected ;-) 

The way this works is that the user space DLL decides if the system is NT based
and opens, and if necessary, installs the device driver on the system. Each function
should be able to perform this check but in general it is a good idea to first
call once the PORT IO Get Version.vi. For this to work you need to have administrator
rights the first time when it is attempting to install the device driver.

Then the PORT IO Read and Write functions have basically two modes. A normal mode
where they access the device driver to let it read or write the actual value (this
is the same as what the current LabVIEW distributed IO library does), and a fast
mode where they will directly perform the according IO port access in the user
space DLL. (For Windows 9x/ME systems there is no difference between these two
modes as no device driver is needed to access Port IO from user space.)

In order for the user space library to be able to access the port directly on NT
based systems you need however to enable that port or port range first with the
PORT IO Enable Range.vi function. Just pass in the base address and the number of
consecutive port addresses you want to have access to and you should be able to
access these ports in fast mode.

==> Watch out writing randomly to IO ports in your system will most probably result
in a crash and eventually damage your hardware and/or software.

Save address ranges are usually 0x220-0x22F (unless you use a GPIB card),
0x300-0x33F (prototype range), and 0x378-0x37F (LPT1), but your mileage may vary.

Tests on my Pentium 3 Mobile 866 MHz system show that to read 1000 times 8 registers
uses around 750 ms in traditional (device driver access) mode whereas it performs
the same operation in 20 ms in the fast mode.

Depending on time and motivation I may also try to upload the necessary source code
and shared library to perform these same operations transparently on Linux systems.

Enjoy

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...
 

RE: LabVIEW SSH Tools

[Jim K. <ji...@ji...>]

Hi Rolf,

>=20
>=20
> Hi Jim
> =20
> > I haven't done any works with pipes in Windows and did a=20
> > little bit of research.  I found the following on MSDN:
> >=20
> >=20
> > =
<http://msdn.microsoft.com/library/default.asp?url=3D/library/en-us/dllp
> > =
roc/base/creating_a_child_process_with_redirected_input_and_output.asp
> >=20
>=20
> >Has anyone gotten pipes working in LabVIEW?  Would anyone more C++=20
> >savvy than myself be interested in working with me to get a generic=20
> >"System Exec w/ Pipes" working?  I envision a DLL that could=20
> >be called=20
> >from LabVIEW (or maybe LabVIEW could call WinAPI DLLs directly) with=20
> >functions for Spawning the Process (the command-line executable),=20
> >Reading from, and Writing to a Pipe for communication with=20
> the running=20
> >executable.
>=20
> I haven't done anything with pipes yet although it isn't=20
> really difficult. The article you qoute seems fairly straight=20
> forward. I think the current System Exec most probably uses=20
> pipes for the three standard IO handles to get the StdIn/Out=20
> and Err at all. What is the problem is that you do not get=20
> the handle back but just the entire text after execution of=20
> the command.

You are right, I think.  In fact, if you look at the "Pipes" function
palette VIs in LabVIEW for Unix/Linux, "Open System Command Pipe.vi" =
does
just that (asynchronous system exec call with pipe outputs for
Read/Write/Error).  I have attached an example which uses this method to
call plink (also included in the attachment).  I have tgz'ed (rather =
than
zip'ed) the archive to preserve the Unix file system executable bit of =
the
plink file.  I have also attached a screenshot (pipe2plink.png) of the
example code for those out there without LabVIEW for Unix/Linux (and the
needed "Pipes" VIs).  This is a simple terminal-like GUI App that allows =
you
to execute single link commands via the secure shell and displays the =
I/O in
a buffered string indicator.

>=20
> I think although it might be sort of possible to go directly=20
> from LabVIEW to the Win32 API, it is a much better and=20
> smarter aproach to pack everything into a DLL. Instead of=20
> returning the entire StdOut/Err text at once it would return=20
> the three handles which can then be used by other DLL=20
> functions to read and write to/from those handles.
>=20

Yes, I think so too.  I was noticing that the WinAPI functions use some
compund (struct) data structures that might be hard to pass into a CLF =
node
from LabVIEW.

> The code as shown in above example would almost work for that=20
> already. At the moment I'm busy getting the Generic PortIO=20
> device driver working (Well generic in that it supports Port=20
> IO in direct fast and indirect slow mode (the one the current=20
> LabVIEW PortIO functions support) and possibly low mem=20
> access, not multiplattform although I got a Linux example=20
> too, just need to adapt it a bit to get it working nicely=20
> with LabVIEW.) I hope I have it ready end of this week and=20
> then I'll look into the inherited pipe system exec if nobody=20
> else stepped up to it until then.
>=20
> Rolf Kalbermatter
>=20

OK, thanks.  I've also pinged a TortoiseCVS developer (who is also an =
OpenG
Developer ;-) about this.  I'm hoping to hear back soon.

-Jim