Menu
▾
▴
opengtoolkit-cvs — OpenG Toolkit CVS commits mailing list
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(42) |
Nov
(368) |
Dec
(248) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
(207) |
Mar
(180) |
Apr
(9) |
May
(39) |
Jun
(9) |
Jul
(22) |
Aug
(56) |
Sep
(82) |
Oct
(113) |
Nov
(236) |
Dec
(219) |
| 2005 |
Jan
(119) |
Feb
(81) |
Mar
(53) |
Apr
(177) |
May
(2) |
Jun
(67) |
Jul
(17) |
Aug
(5) |
Sep
(53) |
Oct
(17) |
Nov
(122) |
Dec
(77) |
| 2006 |
Jan
(293) |
Feb
(16) |
Mar
(32) |
Apr
(14) |
May
(29) |
Jun
(6) |
Jul
|
Aug
|
Sep
(18) |
Oct
(28) |
Nov
|
Dec
(2) |
| 2007 |
Jan
(8) |
Feb
(19) |
Mar
(4) |
Apr
(7) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(37) |
Oct
(1) |
Nov
(8) |
Dec
(25) |
| 2008 |
Jan
(1) |
Feb
(13) |
Mar
(17) |
Apr
(3) |
May
(2) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
(10) |
Nov
(19) |
Dec
(16) |
| 2009 |
Jan
(6) |
Feb
(9) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <jk...@us...> - 2004-03-11 15:58:11
|
Update of /cvsroot/opengtoolkit/portIO/c_source In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22326/c_source Modified Files: Description.htm Log Message: changed the path to ogportio.bmp from absolute to relative Index: Description.htm =================================================================== RCS file: /cvsroot/opengtoolkit/portIO/c_source/Description.htm,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -d -r1.3 -r1.4 *** Description.htm 11 Mar 2004 09:54:04 -0000 1.3 --- Description.htm 11 Mar 2004 15:39:23 -0000 1.4 *************** *** 8,12 **** <body> <big style="font-weight: bold;"><big><img style="width: 36px; height: 36px;" alt="" ! src="file:///D:/CVS/OpenG/development/portIO/ogportio.bmp"> OpenG Port IO Driver</big> </big><br> <br> --- 8,12 ---- <body> <big style="font-weight: bold;"><big><img style="width: 36px; height: 36px;" alt="" ! src="../ogportio.bmp"> OpenG Port IO Driver</big> </big><br> <br> |
|
From: <lab...@us...> - 2004-03-11 10:12:41
|
Update of /cvsroot/opengtoolkit/portIO/c_source In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv10877/c_source Modified Files: Description.htm Log Message: Some small formatting changes Index: Description.htm =================================================================== RCS file: /cvsroot/opengtoolkit/portIO/c_source/Description.htm,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -d -r1.2 -r1.3 *** Description.htm 11 Mar 2004 09:46:45 -0000 1.2 --- Description.htm 11 Mar 2004 09:54:04 -0000 1.3 *************** *** 7,17 **** </head> <body> ! <br> ! <big style="font-weight: bold;"><big><img ! style="width: 36px; height: 36px;" alt="" ! src="file:///D:/CVS/OpenG/development/portIO/ogportio.bmp"> OpenG Port IO Driver<br> ! </big><br> ! Introduction<br> </big><br> For Windows NT based systems (NT 4, 2000, XP, 2003) access to hardware resources from user space (e.g.. any application) is restricted to --- 7,16 ---- </head> <body> ! <big style="font-weight: bold;"><big><img style="width: 36px; height: 36px;" alt="" ! src="file:///D:/CVS/OpenG/development/portIO/ogportio.bmp"> OpenG Port IO Driver</big> </big><br> + <br> + <big style="font-weight: bold;">Introduction</big><br> + <br> For Windows NT based systems (NT 4, 2000, XP, 2003) access to hardware resources from user space (e.g.. any application) is restricted to *************** *** 20,24 **** catched by the Windows NT kernel. The kernel then displays a dialog (or optionally offers to start a system debugger) and terminates the ! process which caused the Protection Fault.<br> <br> If you want to program prototype hardware, this restriction is rather --- 19,23 ---- catched by the Windows NT kernel. The kernel then displays a dialog (or optionally offers to start a system debugger) and terminates the ! process that caused the Protection Fault.<br> <br> If you want to program prototype hardware, this restriction is rather *************** *** 38,45 **** in comparison to the actual time needed for the device driver call itself. For our port driver however this is different. A port address ! read itself typically takes less than 1 us while the time needed to switch from user space to kernel space and back is typically somewhere ! around 100us on an older 866MHz Pentium system. You can see that while ! the IO port access itself is quite fast the necessary context switches are expensive. Therefore it would be interesting if we had a possibility to enable port address access directly from the user --- 37,44 ---- in comparison to the actual time needed for the device driver call itself. For our port driver however this is different. A port address ! read itself typically takes less than 1 µs while the time needed to switch from user space to kernel space and back is typically somewhere ! around 100 µs on an older 866MHz Pentium system. You can see that while ! the IO port access itself is quite fast, the necessary context switches are expensive. Therefore it would be interesting if we had a possibility to enable port address access directly from the user *************** *** 57,61 **** development :-) or even damage the hardware or destroy information in the system or on it's connected devices.<br> ! <big style="font-weight: bold;"><br> Manipulating the IOPM (IO Permission bitMap)</big><br> <br> --- 56,61 ---- development :-) or even damage the hardware or destroy information in the system or on it's connected devices.<br> ! <br> ! <big style="font-weight: bold;"> Manipulating the IOPM (IO Permission bitMap)</big><br> <br> |
|
From: <lab...@us...> - 2004-03-11 10:05:23
|
Update of /cvsroot/opengtoolkit/portIO/c_source In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv9548/c_source Modified Files: Description.htm Log Message: Corrected spelling errors Index: Description.htm =================================================================== RCS file: /cvsroot/opengtoolkit/portIO/c_source/Description.htm,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 *** Description.htm 10 Mar 2004 20:27:01 -0000 1.1 --- Description.htm 11 Mar 2004 09:46:45 -0000 1.2 *************** *** 10,20 **** <big style="font-weight: bold;"><big><img style="width: 36px; height: 36px;" alt="" ! src="file:///D:/CVS/OpenG/development/portIO/ogportio.bmp"> Open ! G Port IO Driver<br> </big><br> Introduction<br> </big><br> For Windows NT based systems (NT 4, 2000, XP, 2003) access to hardware ! resources from user space (eg. any application) is restricted to improve system security. If an application tries to access such resources directly, the CPU indicates a Protection Fault which then is --- 10,19 ---- <big style="font-weight: bold;"><big><img style="width: 36px; height: 36px;" alt="" ! src="file:///D:/CVS/OpenG/development/portIO/ogportio.bmp"> OpenG Port IO Driver<br> </big><br> Introduction<br> </big><br> For Windows NT based systems (NT 4, 2000, XP, 2003) access to hardware ! resources from user space (e.g.. any application) is restricted to improve system security. If an application tries to access such resources directly, the CPU indicates a Protection Fault which then is *************** *** 25,38 **** If you want to program prototype hardware, this restriction is rather strong and it would be nice to loosen that protection partly for such ! situtions. There ! are basically two options to acess the port IO address range. The first ! is letting a device driver perform the actual port IO access, as device ! drivers run in the privileged kernel space and do not have the same ! limitations as applications in the user space. This is the method used ! by most device drivers for specific hardware. For such drivers the ! performance loss caused by a device driver call is not really important, as the device driver provides a high level API which can for instance return an entire buffer of data per single call. The access to ! the individual addresses (sometimes a driver needs to program dozensor much more of registers for a single operation) are all done inside the single device driver call, so that the performance loss caused by --- 24,36 ---- If you want to program prototype hardware, this restriction is rather strong and it would be nice to loosen that protection partly for such ! situations. There are basically two options to access the port IO address ! range. The first is letting a device driver perform the actual port IO ! access, as device drivers run in the privileged kernel space and do not ! have the same limitations as applications in the user space. This is the ! method used by most device drivers for specific hardware. For such ! drivers the performance loss caused by a device driver call is not really important, as the device driver provides a high level API which can for instance return an entire buffer of data per single call. The access to ! the individual addresses (sometimes a driver needs to program dozens or much more of registers for a single operation) are all done inside the single device driver call, so that the performance loss caused by *************** *** 45,49 **** the IO port access itself is quite fast the necessary context switches are expensive. Therefore it would be interesting if we had a ! possibility to enable port address access dirctly from the user application.<br> <br> --- 43,47 ---- the IO port access itself is quite fast the necessary context switches are expensive. Therefore it would be interesting if we had a ! possibility to enable port address access directly from the user application.<br> <br> *************** *** 90,96 **** <br> Ke386SetIoAccessMap will copy the IOPM to the TSS, and ! Ke386QueryIoAccessMap ! witll read it from the TSS. The first parameter of these functions is ! not documented and should be set to 1 to work as expected.<br> <br> NTKERNELAPI void Ke386IoSetAccessProcess(PEPROCESS pProc, int install);<br> --- 88,94 ---- <br> Ke386SetIoAccessMap will copy the IOPM to the TSS, and ! Ke386QueryIoAccessMap will read it from the TSS. The first parameter of ! these functions is not documented and should be set to 1 to work as ! expected.<br> <br> NTKERNELAPI void Ke386IoSetAccessProcess(PEPROCESS pProc, int install);<br> *************** *** 109,113 **** from kernel space you do need a device driver which can run in the kernel space and access the necessary routines and resources, ! independant if you want to let the device driver do the IO port access or provide functions to manipulate the IOPM to allow direct user space access to certain IO port addresses.<br> --- 107,111 ---- from kernel space you do need a device driver which can run in the kernel space and access the necessary routines and resources, ! independent if you want to let the device driver do the IO port access or provide functions to manipulate the IOPM to allow direct user space access to certain IO port addresses.<br> *************** *** 120,133 **** the device driver (which is the classical way as implemented by the Port IO functionality distributed with LabVIEW 7.0) or directly using ! the according x86 opcodes . However to be able to use the direct access functions you will first have to enable the according addresses. Be aware that if you want to access port 0x220 as 16 bit value, you will for instance have to enable port address 0x220 with a length of 2.<br> Failing to enable a port before accessing it with the direct access ! function will generate a General Protection Fault error under LabVIEW ! 6.0 where as LabVIEW 6.1 and higher will catch the according exceptions itself and display a dialog box to that fact and suggesting to restart LabVIEW. If you are sure that this dialog was caused by such an ! unprivileged IO port access you can safely ignore the dialog as no modifications to any LabVIEW application data has been caused by the DLL.<br> --- 118,131 ---- the device driver (which is the classical way as implemented by the Port IO functionality distributed with LabVIEW 7.0) or directly using ! the according x86 opcodes. However to be able to use the direct access functions you will first have to enable the according addresses. Be aware that if you want to access port 0x220 as 16 bit value, you will for instance have to enable port address 0x220 with a length of 2.<br> Failing to enable a port before accessing it with the direct access ! function, will generate a General Protection Fault error under LabVIEW ! 6.0 whereas LabVIEW 6.1 and higher will catch the according exceptions itself and display a dialog box to that fact and suggesting to restart LabVIEW. If you are sure that this dialog was caused by such an ! unprivileged IO port access you can safely ignore the dialog, as no modifications to any LabVIEW application data has been caused by the DLL.<br> *************** *** 136,142 **** need any device drivers and will always directly access the IO port addresses. The functions to enable and disable certain port addresses ! are just empty operations on those systems. This allows ! applications to always use the same function calls (LabVIEW VIs) and ! still run correctly on Win9x/ME systems.<br> On Windows NT systems the DLL checks before each call if the device driver is already installed and running, and attempts to start and --- 134,140 ---- need any device drivers and will always directly access the IO port addresses. The functions to enable and disable certain port addresses ! are just empty operations on those systems. This allows applications ! to always use the same function calls (LabVIEW VIs) and still run ! correctly on Win9x/ME systems.<br> On Windows NT systems the DLL checks before each call if the device driver is already installed and running, and attempts to start and |
|
From: <lab...@us...> - 2004-03-11 08:37:32
|
Update of /cvsroot/opengtoolkit/pipe/c_source In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25228/c_source Added Files: pipes.c pipes.dsp pipes.dsw Removed Files: pipe.c Log Message: Added Visual C 6.0 project files and renamed source file --- NEW FILE: pipes.c --- /* * 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 --- NEW FILE: pipes.dsp --- # Microsoft Developer Studio Project File - Name="pipes" - Package Owner=<4> # Microsoft Developer Studio Generated Build File, Format Version 6.00 # ** DO NOT EDIT ** # TARGTYPE "Win32 (x86) Dynamic-Link Library" 0x0102 CFG=pipes - Win32 Debug !MESSAGE This is not a valid makefile. To build this project using NMAKE, !MESSAGE use the Export Makefile command and run !MESSAGE !MESSAGE NMAKE /f "pipes.mak". !MESSAGE !MESSAGE You can specify a configuration when running NMAKE !MESSAGE by defining the macro CFG on the command line. For example: !MESSAGE !MESSAGE NMAKE /f "pipes.mak" CFG="pipes - Win32 Debug" !MESSAGE !MESSAGE Possible choices for configuration are: !MESSAGE !MESSAGE "pipes - Win32 Release" (based on "Win32 (x86) Dynamic-Link Library") !MESSAGE "pipes - Win32 Debug" (based on "Win32 (x86) Dynamic-Link Library") !MESSAGE # Begin Project # PROP AllowPerConfigDependencies 0 # PROP Scc_ProjName "" # PROP Scc_LocalPath "" CPP=cl.exe MTL=midl.exe RSC=rc.exe !IF "$(CFG)" == "pipes - Win32 Release" # PROP BASE Use_MFC 0 # PROP BASE Use_Debug_Libraries 0 # PROP BASE Output_Dir "Release" # PROP BASE Intermediate_Dir "Release" # PROP BASE Target_Dir "" # PROP Use_MFC 0 # PROP Use_Debug_Libraries 0 # PROP Output_Dir "Release" # PROP Intermediate_Dir "Release" # PROP Target_Dir "" # ADD BASE CPP /nologo /MT /W3 /GX /O2 /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "PIPES_EXPORTS" /YX /FD /c # ADD CPP /nologo /MT /W3 /GX /O2 /I "..\cintools60" /D "WIN32" /D "NDEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "PIPES_EXPORTS" /YX /FD /c # ADD BASE MTL /nologo /D "NDEBUG" /mktyplib203 /win32 # ADD MTL /nologo /D "NDEBUG" /mktyplib203 /win32 # ADD BASE RSC /l 0x409 /d "NDEBUG" # ADD RSC /l 0x409 /d "NDEBUG" BSC32=bscmake.exe # ADD BASE BSC32 /nologo # ADD BSC32 /nologo LINK32=link.exe # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /machine:I386 # ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib labview.lib /nologo /dll /machine:I386 /nodefaultlib:"msvcrt" /libpath:"..\cintools60" !ELSEIF "$(CFG)" == "pipes - Win32 Debug" # PROP BASE Use_MFC 0 # PROP BASE Use_Debug_Libraries 1 # PROP BASE Output_Dir "Debug" # PROP BASE Intermediate_Dir "Debug" # PROP BASE Target_Dir "" # PROP Use_MFC 0 # PROP Use_Debug_Libraries 1 # PROP Output_Dir "Debug" # PROP Intermediate_Dir "Debug" # PROP Ignore_Export_Lib 0 # PROP Target_Dir "" # ADD BASE CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "PIPES_EXPORTS" /YX /FD /GZ /c # ADD CPP /nologo /MTd /W3 /Gm /GX /ZI /Od /I "..\cintools60" /D "WIN32" /D "_DEBUG" /D "_WINDOWS" /D "_MBCS" /D "_USRDLL" /D "PIPES_EXPORTS" /YX /FD /GZ /c # ADD BASE MTL /nologo /D "_DEBUG" /mktyplib203 /win32 # ADD MTL /nologo /D "_DEBUG" /mktyplib203 /win32 # ADD BASE RSC /l 0x409 /d "_DEBUG" # ADD RSC /l 0x409 /d "_DEBUG" BSC32=bscmake.exe # ADD BASE BSC32 /nologo # ADD BSC32 /nologo LINK32=link.exe # ADD BASE LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /debug /machine:I386 /pdbtype:sept # ADD LINK32 kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib labview.lib /nologo /dll /debug /machine:I386 /nodefaultlib:"msvcrt" /pdbtype:sept /libpath:"..\cintools60" # SUBTRACT LINK32 /nodefaultlib !ENDIF # Begin Target # Name "pipes - Win32 Release" # Name "pipes - Win32 Debug" # Begin Group "Source Files" # PROP Default_Filter "cpp;c;cxx;rc;def;r;odl;idl;hpj;bat" # Begin Source File SOURCE=.\pipes.c # End Source File # End Group # Begin Group "Header Files" # PROP Default_Filter "h;hpp;hxx;hm;inl" # End Group # Begin Group "Resource Files" # PROP Default_Filter "ico;cur;bmp;dlg;rc2;rct;bin;rgs;gif;jpg;jpeg;jpe" # End Group # End Target # End Project --- NEW FILE: pipes.dsw --- Microsoft Developer Studio Workspace File, Format Version 6.00 # WARNING: DO NOT EDIT OR DELETE THIS WORKSPACE FILE! ############################################################################### Project: "pipes"=.\pipes.dsp - Package Owner=<4> Package=<5> {{{ }}} Package=<4> {{{ }}} ############################################################################### Global: Package=<5> {{{ }}} Package=<3> {{{ }}} ############################################################################### --- pipe.c DELETED --- |
|
From: <lab...@us...> - 2004-03-11 08:36:46
|
Update of /cvsroot/opengtoolkit/pipe/source In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25018/source Added Files: pipes.dll Removed Files: OGPIPE - VI TREE.vi OGPIPE Close Pipe.vi OGPIPE Open Pipe.vi OGPIPE Open System Command Pipe.vi OGPIPE Read From Pipe.vi OGPIPE RefNum.ctl OGPIPE Write To Pipe.vi Log Message: Moved the VIs in their LLB directory and added diagram code to them --- NEW FILE: pipes.dll --- (This appears to be a binary file; contents omitted.) --- OGPIPE - VI TREE.vi DELETED --- --- OGPIPE Close Pipe.vi DELETED --- --- OGPIPE Open Pipe.vi DELETED --- --- OGPIPE Open System Command Pipe.vi DELETED --- --- OGPIPE Read From Pipe.vi DELETED --- --- OGPIPE RefNum.ctl DELETED --- --- OGPIPE Write To Pipe.vi DELETED --- |
|
From: <lab...@us...> - 2004-03-11 08:36:44
|
Update of /cvsroot/opengtoolkit/pipe/source/ogpipe.llb In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25018/source/ogpipe.llb Added Files: OGPIPE - VI TREE.vi OGPIPE Close Pipe.vi OGPIPE Open Pipe.vi OGPIPE Open System Command Pipe.vi OGPIPE Read From Pipe.vi OGPIPE RefNum.ctl OGPIPE Write To Pipe.vi Log Message: Moved the VIs in their LLB directory and added diagram code to them --- NEW FILE: OGPIPE - VI TREE.vi --- (This appears to be a binary file; contents omitted.) --- NEW FILE: OGPIPE Close Pipe.vi --- (This appears to be a binary file; contents omitted.) --- NEW FILE: OGPIPE Open Pipe.vi --- (This appears to be a binary file; contents omitted.) --- NEW FILE: OGPIPE Open System Command Pipe.vi --- (This appears to be a binary file; contents omitted.) --- NEW FILE: OGPIPE Read From Pipe.vi --- (This appears to be a binary file; contents omitted.) --- NEW FILE: OGPIPE RefNum.ctl --- (This appears to be a binary file; contents omitted.) --- NEW FILE: OGPIPE Write To Pipe.vi --- (This appears to be a binary file; contents omitted.) |
|
From: <lab...@us...> - 2004-03-11 08:31:09
|
Update of /cvsroot/opengtoolkit/pipe/source/ogpipe.llb In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24223/ogpipe.llb Log Message: Directory /cvsroot/opengtoolkit/pipe/source/ogpipe.llb added to the repository |
Update of /cvsroot/opengtoolkit/pipe/source In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv14906/source Added Files: OGPIPE - VI TREE.vi OGPIPE Close Pipe.vi OGPIPE Open Pipe.vi OGPIPE Open System Command Pipe.vi OGPIPE Read From Pipe.vi OGPIPE RefNum.ctl OGPIPE Write To Pipe.vi Log Message: initial commit --- NEW FILE: OGPIPE - VI TREE.vi --- (This appears to be a binary file; contents omitted.) --- NEW FILE: OGPIPE Close Pipe.vi --- (This appears to be a binary file; contents omitted.) --- NEW FILE: OGPIPE Open Pipe.vi --- (This appears to be a binary file; contents omitted.) --- NEW FILE: OGPIPE Open System Command Pipe.vi --- (This appears to be a binary file; contents omitted.) --- NEW FILE: OGPIPE Read From Pipe.vi --- (This appears to be a binary file; contents omitted.) --- NEW FILE: OGPIPE RefNum.ctl --- (This appears to be a binary file; contents omitted.) --- NEW FILE: OGPIPE Write To Pipe.vi --- (This appears to be a binary file; contents omitted.) |
|
From: <jk...@us...> - 2004-03-11 04:12:32
|
Update of /cvsroot/opengtoolkit/pipe/c_source In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv14906/c_source Added Files: pipe.c Log Message: initial commit --- NEW FILE: pipe.c --- /* * 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: <jk...@us...> - 2004-03-11 04:11:02
|
Update of /cvsroot/opengtoolkit/pipe/c_source In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv14694/c_source Log Message: Directory /cvsroot/opengtoolkit/pipe/c_source added to the repository |
|
From: <jk...@us...> - 2004-03-11 04:11:02
|
Update of /cvsroot/opengtoolkit/pipe/source In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv14694/source Log Message: Directory /cvsroot/opengtoolkit/pipe/source added to the repository |
|
From: <lab...@us...> - 2004-03-10 20:45:12
|
Update of /cvsroot/opengtoolkit/portIO/c_source In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21446/c_source Added Files: Description.htm Log Message: Added a first draft of documentation of the device driver and its operation --- NEW FILE: Description.htm --- <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="content-type"> <title>Open G Port IO Driver</title> </head> <body> <br> <big style="font-weight: bold;"><big><img style="width: 36px; height: 36px;" alt="" src="file:///D:/CVS/OpenG/development/portIO/ogportio.bmp"> Open G Port IO Driver<br> </big><br> Introduction<br> </big><br> For Windows NT based systems (NT 4, 2000, XP, 2003) access to hardware resources from user space (eg. any application) is restricted to improve system security. If an application tries to access such resources directly, the CPU indicates a Protection Fault which then is catched by the Windows NT kernel. The kernel then displays a dialog (or optionally offers to start a system debugger) and terminates the process which caused the Protection Fault.<br> <br> If you want to program prototype hardware, this restriction is rather strong and it would be nice to loosen that protection partly for such situtions. There are basically two options to acess the port IO address range. The first is letting a device driver perform the actual port IO access, as device drivers run in the privileged kernel space and do not have the same limitations as applications in the user space. This is the method used by most device drivers for specific hardware. For such drivers the performance loss caused by a device driver call is not really important, as the device driver provides a high level API which can for instance return an entire buffer of data per single call. The access to the individual addresses (sometimes a driver needs to program dozensor much more of registers for a single operation) are all done inside the single device driver call, so that the performance loss caused by switching between the user space and kernel space context is minimal, in comparison to the actual time needed for the device driver call itself. For our port driver however this is different. A port address read itself typically takes less than 1 us while the time needed to switch from user space to kernel space and back is typically somewhere around 100us on an older 866MHz Pentium system. You can see that while the IO port access itself is quite fast the necessary context switches are expensive. Therefore it would be interesting if we had a possibility to enable port address access dirctly from the user application.<br> <br> Fortunately there is a possibility, as the x86 architecture controls access to the IO port address space by an IO Permission bitMap (IOPM). This bitmap contains 1 bit per port address and as the IO port address space of the x86 goes from 0x0000 - 0xFFFF this bitmap is 8096 bytes long.<br> <br> <span style="font-weight: bold;">NOTE</span>: This method is not really recommended for production grade systems as a misbehaving user application can easily trash the entire system (as I have found during development :-) or even damage the hardware or destroy information in the system or on it's connected devices.<br> <big style="font-weight: bold;"><br> Manipulating the IOPM (IO Permission bitMap)</big><br> <br> To understand how this can work we also need to explain a little more about the x86 CPU architecture. These CPUs have four so called rings, which can be assigned to certain subsystem of an operating system. Ring 0 has the highest access rights and can basically access any opcodes and resources in the x86 CPU. The Windows NT kernel runs in ring 0. Ring 3 has the lowest access rights and some of the CPU opcodes as well as certain CPU registers are not accessible while the CPU runs in ring 3. The Windows NT user space in which all applications run is assigned to ring 3.<br> <br> If a particular bit is set in that IOPM the according IO port address is protected and the processor will generate a software interrupt when running in ring 3. Windows NT will see this interrupt as exception and usually notify the user and terminate the current process. The Windows NT kernel maintains the IOPM and makes sure that it is always setup correctly for the current process. By default all processes have a default IOPM which disables access to all IO port addresses completely.<br> <br> However the Windows NT kernel exports some undocumented functions to modify the IOPM for a particular process. With these functions a device driver can allow a particular process to access some or all IO port addresses directly from user space. These functions are:<br> <br> NTKERNELAPI void Ke386SetIoAccessMap(int, IOPM *pBitmap);<br> NTKERNELAPI void Ke386QueryIoAccessMap(int, IOPM *pBitmap);<br> <br> Ke386SetIoAccessMap will copy the IOPM to the TSS, and Ke386QueryIoAccessMap witll read it from the TSS. The first parameter of these functions is not documented and should be set to 1 to work as expected.<br> <br> NTKERNELAPI void Ke386IoSetAccessProcess(PEPROCESS pProc, int install);<br> NTKERNELAPI NTSTATUS PsLookupProcessByProcessId(IN ULONG ulProcId, OUT PEPROCESS * pEProcess);<br> <br> Ke386IoSetAccessProcess adjusts the IOPM offset pointer of the CPU to point to the current IOPM. The second parameter specifies if the IOPM should be installed or removed. As Ke386IoSetAccessProcess expects a pointer to an internal kernel structure identifying the process to change the IOPM pointer for, we have another undocumented function PsLookupProcessByProcessId to translate a user space process ID into the according kernel structure pointer.<br> <br> As the necessary interfaces are all protected and only accessible from kernel space you do need a device driver which can run in the kernel space and access the necessary routines and resources, independant if you want to let the device driver do the IO port access or provide functions to manipulate the IOPM to allow direct user space access to certain IO port addresses.<br> <br> <big>Talking to the Device Driver (User Mode APIs)</big><br> <br> To access the device driver, a user mode API has been developed as a DLL. This DLL provides different functions to control access to the IO port address range. It both allows to access IO port addresses trough the device driver (which is the classical way as implemented by the Port IO functionality distributed with LabVIEW 7.0) or directly using the according x86 opcodes . However to be able to use the direct access functions you will first have to enable the according addresses. Be aware that if you want to access port 0x220 as 16 bit value, you will for instance have to enable port address 0x220 with a length of 2.<br> Failing to enable a port before accessing it with the direct access function will generate a General Protection Fault error under LabVIEW 6.0 where as LabVIEW 6.1 and higher will catch the according exceptions itself and display a dialog box to that fact and suggesting to restart LabVIEW. If you are sure that this dialog was caused by such an unprivileged IO port access you can safely ignore the dialog as no modifications to any LabVIEW application data has been caused by the DLL.<br> The DLL controls itself if it is running on Windows NT based systems and behaves accordingly. For non-NT systems (9x/ME) the DLL does not need any device drivers and will always directly access the IO port addresses. The functions to enable and disable certain port addresses are just empty operations on those systems. This allows applications to always use the same function calls (LabVIEW VIs) and still run correctly on Win9x/ME systems.<br> On Windows NT systems the DLL checks before each call if the device driver is already installed and running, and attempts to start and eventually install the device driver. This will however only work if the current user has administrator rights at that moment. Once the driver is installed no administrator rights are necessary anymore to use the device driver.<br> <br> </body> </html> |
|
From: <lab...@us...> - 2004-03-10 13:02:55
|
Update of /cvsroot/opengtoolkit/portIO/built/portio In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv18711/built/portio Modified Files: ogportio.dll Log Message: Changed version number of DLL to be 1.0.2 Index: ogportio.dll =================================================================== RCS file: /cvsroot/opengtoolkit/portIO/built/portio/ogportio.dll,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -d -r1.2 -r1.3 Binary files /tmp/cvs5ua6ve and /tmp/cvslpk3Mf differ |
|
From: <lab...@us...> - 2004-03-10 13:02:53
|
Update of /cvsroot/opengtoolkit/portIO/c_source In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv18711/c_source Modified Files: ogportio.h ogportio.rc Log Message: Changed version number of DLL to be 1.0.2 Index: ogportio.h =================================================================== RCS file: /cvsroot/opengtoolkit/portIO/c_source/ogportio.h,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 *** ogportio.h 3 Mar 2004 13:20:24 -0000 1.1 --- ogportio.h 10 Mar 2004 12:44:54 -0000 1.2 *************** *** 23,27 **** #define OGPORTIO_NAME "\\\\.\\OGPortIO" ! #define OGPORTIO_VERSION 0x0101 #define OGPORTIO_TYPE 43210 /* 32768-65535 are reserved for customers */ --- 23,27 ---- #define OGPORTIO_NAME "\\\\.\\OGPortIO" ! #define OGPORTIO_VERSION 0x0102 #define OGPORTIO_TYPE 43210 /* 32768-65535 are reserved for customers */ Index: ogportio.rc =================================================================== RCS file: /cvsroot/opengtoolkit/portIO/c_source/ogportio.rc,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 *** ogportio.rc 3 Mar 2004 13:20:24 -0000 1.1 --- ogportio.rc 10 Mar 2004 12:44:54 -0000 1.2 *************** *** 13,21 **** #define VER_PRODUCTNAME_STR "OpenG Generic Port I/O Driver" ! #define VER_FILEVERSION 1,0,1,0 ! #define VER_FILEVERSION_STR "Version 1.0.1" ! #define VER_PRODUCTVERSION 1,0,1 ! #define VER_PRODUCTVERSION_STR "OpenG Generic Port I/O Driver Version 1.0.1" #include "common.ver" --- 13,21 ---- #define VER_PRODUCTNAME_STR "OpenG Generic Port I/O Driver" ! #define VER_FILEVERSION 1,0,2,0 ! #define VER_FILEVERSION_STR "Version 1.0.2" ! #define VER_PRODUCTVERSION 1,0,2 ! #define VER_PRODUCTVERSION_STR "OpenG Generic Port I/O Driver Version 1.0.2" #include "common.ver" |
|
From: <lab...@us...> - 2004-03-10 13:02:53
|
Update of /cvsroot/opengtoolkit/portIO/source In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv18711/source Modified Files: ogportio.dll Log Message: Changed version number of DLL to be 1.0.2 Index: ogportio.dll =================================================================== RCS file: /cvsroot/opengtoolkit/portIO/source/ogportio.dll,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -d -r1.2 -r1.3 Binary files /tmp/cvssa3S7i and /tmp/cvsjLDBzk differ |
|
From: <lab...@us...> - 2004-03-10 13:00:32
|
Update of /cvsroot/opengtoolkit/portIO/c_source In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv18303/c_source Modified Files: ogportiodll.c ogportiodll.h Log Message: Added function to DLL to reset the port IO map for a process Index: ogportiodll.c =================================================================== RCS file: /cvsroot/opengtoolkit/portIO/c_source/ogportiodll.c,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 *** ogportiodll.c 3 Mar 2004 13:20:24 -0000 1.1 --- ogportiodll.c 10 Mar 2004 12:42:32 -0000 1.2 *************** *** 425,428 **** --- 425,459 ---- } + DWORD LibAPI PortIODisableAll(unsigned long processID) + { + DWORD BytesReturned, err = ERROR_SUCCESS; + + if (gWinNT) + { + PORTMAP param; + + if (hDevice == INVALID_HANDLE_VALUE) + { + err = PortIOOpen(); + if (err) return err; + } + + param.processID = processID; + + if (!DeviceIoControl(hDevice, + IOCTL_RESET_IOPM, + ¶m, + sizeof(PORTMAP), + NULL, + 0, + &BytesReturned, + NULL)) + { + err = GetLastError(); + } + } + return err; + } + DWORD LibAPI PortIOReadDirect(unsigned short address, unsigned long size, void *value) { Index: ogportiodll.h =================================================================== RCS file: /cvsroot/opengtoolkit/portIO/c_source/ogportiodll.h,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 *** ogportiodll.h 3 Mar 2004 13:20:24 -0000 1.1 --- ogportiodll.h 10 Mar 2004 12:42:32 -0000 1.2 *************** *** 22,28 **** */ #if defined(OGPORTIO_EXPORTS) ! #define LibAPI __declspec(dllexport) __cdecl #else ! #define LibAPI __declspec(dllimport) __cdecl #endif --- 22,28 ---- */ #if defined(OGPORTIO_EXPORTS) ! #define LibAPI __declspec(dllexport) __cdecl #else ! #define LibAPI __declspec(dllimport) __cdecl #endif *************** *** 37,42 **** --- 37,47 ---- DWORD LibAPI PortIOEnablePort(unsigned long processID, unsigned short start, unsigned short size); DWORD LibAPI PortIOReleasePort(unsigned long processID, unsigned short start, unsigned short size); + DWORD LibAPI PortIODisableAll(unsigned long processID); DWORD LibAPI PortIOReadDirect(unsigned short address, unsigned long size, void *value); DWORD LibAPI PortIORead(unsigned short address, unsigned long size, void *value); DWORD LibAPI PortIOWriteDirect(unsigned short address, unsigned long size, void *value); DWORD LibAPI PortIOWrite(unsigned short address, unsigned long size, void *value); + + /* Not yet implemented */ + DWORD LibAPI PortIOReadMem(unsigned long address, unsigned long size, char *value); + DWORD LibAPI PortIOWriteMem(unsigned long address, unsigned long size, char *value); |
|
From: <lab...@us...> - 2004-03-10 13:00:32
|
Update of /cvsroot/opengtoolkit/portIO/source In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv18303/source Modified Files: ogportio.dll Log Message: Added function to DLL to reset the port IO map for a process Index: ogportio.dll =================================================================== RCS file: /cvsroot/opengtoolkit/portIO/source/ogportio.dll,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvse50Edw and /tmp/cvsmcN0uN differ |
|
From: <lab...@us...> - 2004-03-10 13:00:32
|
Update of /cvsroot/opengtoolkit/portIO/built/portio In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv18303/built/portio Modified Files: ogportio.dll Log Message: Added function to DLL to reset the port IO map for a process Index: ogportio.dll =================================================================== RCS file: /cvsroot/opengtoolkit/portIO/built/portio/ogportio.dll,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvsNRnrWf and /tmp/cvsReHhVw differ |
|
From: <jk...@us...> - 2004-03-06 23:36:42
|
Update of /cvsroot/opengtoolkit/deab/source/Support In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2458/source/Support Modified Files: Build VI Hierarchy from VI List.vi Copy VIs to Destinations and Mangle Names.vi Expand Build Parameter Paths.vi Find Source VIs Destination Folder.vi Get Dir to LLB and EXE Conversions.vi List VIs Hierarchy in Memory.vi List VIs to Unload.vi Load Top-Level and Dynamic VIs.vi Log Message: 0.7 --> 0.8 Index: Build VI Hierarchy from VI List.vi =================================================================== RCS file: /cvsroot/opengtoolkit/deab/source/Support/Build VI Hierarchy from VI List.vi,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvsilPU3s and /tmp/cvsHaNpGB differ Index: Copy VIs to Destinations and Mangle Names.vi =================================================================== RCS file: /cvsroot/opengtoolkit/deab/source/Support/Copy VIs to Destinations and Mangle Names.vi,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -d -r1.3 -r1.4 Binary files /tmp/cvs6Fe2em and /tmp/cvs20sEVu differ Index: Expand Build Parameter Paths.vi =================================================================== RCS file: /cvsroot/opengtoolkit/deab/source/Support/Expand Build Parameter Paths.vi,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvsVttilu and /tmp/cvsnRfA4C differ Index: Find Source VIs Destination Folder.vi =================================================================== RCS file: /cvsroot/opengtoolkit/deab/source/Support/Find Source VIs Destination Folder.vi,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvsqm5S6u and /tmp/cvsKwIURD differ Index: Get Dir to LLB and EXE Conversions.vi =================================================================== RCS file: /cvsroot/opengtoolkit/deab/source/Support/Get Dir to LLB and EXE Conversions.vi,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvsQORC0x and /tmp/cvsH9zrNG differ Index: List VIs Hierarchy in Memory.vi =================================================================== RCS file: /cvsroot/opengtoolkit/deab/source/Support/List VIs Hierarchy in Memory.vi,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvsM3C2FD and /tmp/cvsNsKwvM differ Index: List VIs to Unload.vi =================================================================== RCS file: /cvsroot/opengtoolkit/deab/source/Support/List VIs to Unload.vi,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvsiUA1QH and /tmp/cvslejPIQ differ Index: Load Top-Level and Dynamic VIs.vi =================================================================== RCS file: /cvsroot/opengtoolkit/deab/source/Support/Load Top-Level and Dynamic VIs.vi,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvsdng6xK and /tmp/cvsnfTurT differ |
|
From: <jk...@us...> - 2004-03-06 23:36:42
|
Update of /cvsroot/opengtoolkit/deab/source/Support/Data Structures In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2458/source/Support/Data Structures Modified Files: Build Parameters Cluster.ctl Source Dir and Destination Cluster.ctl Log Message: 0.7 --> 0.8 Index: Source Dir and Destination Cluster.ctl =================================================================== RCS file: /cvsroot/opengtoolkit/deab/source/Support/Data Structures/Source Dir and Destination Cluster.ctl,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvsdCYiLj and /tmp/cvsyX7wos differ |
Update of /cvsroot/opengtoolkit/deab/source/Static API In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2458/source/Static API Modified Files: Build Application from Build File.vi Build Application.vi Read Build Paramters from File.vi Added Files: Convert Build Params to Abs Paths.vi Log Message: 0.7 --> 0.8 --- NEW FILE: API Convert Build Params to Abs Paths.vi --- Index: Build Application from Build File.vi =================================================================== RCS file: /cvsroot/opengtoolkit/deab/source/Static API/Build Application from Build File.vi,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvstMVc7t and /tmp/cvszhXW6B differ Index: Build Application.vi =================================================================== RCS file: /cvsroot/opengtoolkit/deab/source/Static API/Build Application.vi,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvsGve76w and /tmp/cvsGnI88E differ Index: Read Build Paramters from File.vi =================================================================== RCS file: /cvsroot/opengtoolkit/deab/source/Static API/Read Build Paramters from File.vi,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -d -r1.2 -r1.3 Binary files /tmp/cvs2MfsSC and /tmp/cvsb75oXK differ |
Update of /cvsroot/opengtoolkit/deab/source/Support/Data Structures/Build Parameters In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2458/source/Support/Data Structures/Build Parameters Added Files: Build Root.ctl Convert Target to EXE.ctl Convert Target to LLB.ctl Destinations.ctl Dynamic VIs.ctl Exclude Lib Dirs from Build.ctl Namespace.ctl Overwrite Existing Files.ctl Project Root.ctl Remove Diagrams.ctl Source Dir.ctl Source Root.ctl Target Dir.ctl Top Level VIs.ctl Log Message: 0.7 --> 0.8 --- NEW FILE: Structures/Build Parameters Build Root.ctl --- --- NEW FILE: Convert Target to EXE.ctl --- (This appears to be a binary file; contents omitted.) --- NEW FILE: Convert Target to LLB.ctl --- (This appears to be a binary file; contents omitted.) --- NEW FILE: Destinations.ctl --- (This appears to be a binary file; contents omitted.) --- NEW FILE: Dynamic VIs.ctl --- (This appears to be a binary file; contents omitted.) --- NEW FILE: Exclude Lib Dirs from Build.ctl --- (This appears to be a binary file; contents omitted.) --- NEW FILE: Namespace.ctl --- (This appears to be a binary file; contents omitted.) --- NEW FILE: Overwrite Existing Files.ctl --- (This appears to be a binary file; contents omitted.) --- NEW FILE: Project Root.ctl --- (This appears to be a binary file; contents omitted.) --- NEW FILE: Remove Diagrams.ctl --- (This appears to be a binary file; contents omitted.) --- NEW FILE: Source Dir.ctl --- (This appears to be a binary file; contents omitted.) --- NEW FILE: Source Root.ctl --- (This appears to be a binary file; contents omitted.) --- NEW FILE: Target Dir.ctl --- (This appears to be a binary file; contents omitted.) --- NEW FILE: Top Level VIs.ctl --- (This appears to be a binary file; contents omitted.) |
|
From: <jk...@us...> - 2004-03-06 23:36:42
|
Update of /cvsroot/opengtoolkit/deab/source In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2458/source Modified Files: VI Tree - deab.vi VI Tree - deab_api.vi Log Message: 0.7 --> 0.8 Index: VI Tree - deab.vi =================================================================== RCS file: /cvsroot/opengtoolkit/deab/source/VI Tree - deab.vi,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvsoOvUWk and /tmp/cvs8116zt differ Index: VI Tree - deab_api.vi =================================================================== RCS file: /cvsroot/opengtoolkit/deab/source/VI Tree - deab_api.vi,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvs5xehdm and /tmp/cvs17UaSu differ |
|
From: <jk...@us...> - 2004-03-06 23:36:41
|
Update of /cvsroot/opengtoolkit/deab In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2458 Modified Files: build_ deab.vi build_deab_api.vi change-log.txt deab.spec Log Message: 0.7 --> 0.8 Index: build_ deab.vi =================================================================== RCS file: /cvsroot/opengtoolkit/deab/build_ deab.vi,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvsgFATVV and /tmp/cvsG9LWs3 differ Index: build_deab_api.vi =================================================================== RCS file: /cvsroot/opengtoolkit/deab/build_deab_api.vi,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvseY0tV1 and /tmp/cvskVEOu9 differ Index: change-log.txt =================================================================== RCS file: /cvsroot/opengtoolkit/deab/change-log.txt,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -d -r1.2 -r1.3 *** change-log.txt 2 Dec 2003 03:45:53 -0000 1.2 --- change-log.txt 6 Mar 2004 23:21:29 -0000 1.3 *************** *** 1,7 **** ! -= oglib_file-0.8-1.ogp =- Changes from 0.7-1 --> 0.8-1 -------------------------------- 2003-12-01 [Fix] Now ignores comments in INI file --- 1,14 ---- ! -= ogrsc_deab-0.8-1.ogp =- ! ! Visit ! ! http://openg.org/deab for documentation and examples 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 Index: deab.spec =================================================================== RCS file: /cvsroot/opengtoolkit/deab/deab.spec,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 *** deab.spec 3 Nov 2003 04:31:21 -0000 1.1 --- deab.spec 6 Mar 2004 23:21:29 -0000 1.2 *************** *** 3,7 **** Name=ogrsc_deab ! Version=0.7 Release=1 --- 3,7 ---- Name=ogrsc_deab ! Version=0.8 Release=1 |
Update of /cvsroot/opengtoolkit/deab/source/Dynamic API In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv2458/source/Dynamic API Modified Files: Build Application API.vi Build Application from Build File API.vi Read Build Paramters from File API.vi Added Files: Convert Build Params to Abs Paths API.vi Log Message: 0.7 --> 0.8 --- NEW FILE: API Convert Build Params to Abs Paths API.vi --- Index: Build Application API.vi =================================================================== RCS file: /cvsroot/opengtoolkit/deab/source/Dynamic API/Build Application API.vi,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvsgOlQp5 and /tmp/cvs0XUc3c differ Index: Build Application from Build File API.vi =================================================================== RCS file: /cvsroot/opengtoolkit/deab/source/Dynamic API/Build Application from Build File API.vi,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvsZ0MrL9 and /tmp/cvsUO8srh differ Index: Read Build Paramters from File API.vi =================================================================== RCS file: /cvsroot/opengtoolkit/deab/source/Dynamic API/Read Build Paramters from File API.vi,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -d -r1.1 -r1.2 Binary files /tmp/cvsG4TYcd and /tmp/cvs5f8EVk differ |
