Experimental Physics and
Industrial Control System

Hi Alex,

 

Integration of your efforts into the distribution sounds like a great idea to me. This will of course be beneficial for LabVIEW / EPICS integration.

 

Ø  Only WinSock 1.1 is supported on Phar Lap

 

That’s unfortunate because newer Winsock interfaces have been around for a long time, and we do use them to query the list of network interfaces that are attached. What is implied functionally is that EPICS can populate the address lists for search requests and beacons automatically (EPICS_AUTO_ADDRESS_LIST=YES) if winsock II is available – otherwise not. As I recall, the winsock II interface is not available initially only on certain archaic W95/98/NT windows OS, and furthermore I think that we are currently not supporting system that don’t have winsockII because as, at one time, it wasn’t difficult to upgrade older systems.

 

Ø  You cannot create a process, only one process allowed on PharLap

 

Really not an issue because on such systems {currently RTEMS and vxWorks} we just spawn off a thread instead. We only need to stub out which one is allowed in an OS specific code.

 

Ø  Thread Priority Range is (-128 to 127), much like VxWorks' (0 to 256)

 

Ditto – we only need to stub out in OS specific code the code that maps the priority.

 

So I see three issues that someone will need to look into:

1)      The pharlap constraints are strongly reminiscent, if I recall correctly, of Windows CE constraints. So perhaps we should try to look for a source code structure that will allow also Windows CE to be easily integrated.

2)      Packaging is maybe also an important issue as we might prefer to have a common directory under libCom/osi/os that is shared by pharlap, win32, and Windows CE so that the code is properly organized for easy maintenance. Perhaps we will need folders under osi/os called winXX, WIN32, pharlap, and WINCE?

3)      Do we give up on querying the network interface on pharlap and Windows CE or is there some OS specific plug-in we can implement? That approach is certainly easily accommodated by the current structuring of the source code if alternative callable interfaces exist specific to pharlap. In fact, we already have an OS specific plug in for winsock as I recall.

 

Thanks for your efforts,

 

Jeff