Serial communication under Windows 
Author Message
 Serial communication under Windows

NOTE: For those that want to get to the point, skip the next 2
paragraphs (which provide a bit of background to the problem).

As many know, the 'serial.st' filein from ParcPlace provides access to
the serial interface of many machines.  VW 1.0 used to use class names
prefaced by 'Dos' (DosTtyAccessor, etc.) which supposedly worked under
Windows (I never tested it out).  As of VW 2.0, however, the hierarchy
was altered to provide PCTtyAccessor and PCIOAccessor with subclasses
that support OS/2.  Unfortunately, there are no subclasses for Windows.

In chatting with PP tech support, it was revealed that Microsoft made
some changes to Win32s that affected how PP did their serial
primitives causing some sort of problems.  The end result is that the
Windows support was removed and there is no longer Windows serial
communication capabilities from ParcPlace.

PP recommends the use of DLL & C connect to provide the necessary
interface for serial communications.  While I would personally enjoy
playing with the SDK once again, it seems a wiser course of action to
see if anyone has something available - free or otherwise - to do the
job or provide a starting point (some may call this cheating...I
prefer the term "reuse" :-).  I found nothing in the UIUC archives, so
any other help would be appreciated.

Feel free to post replies, but I would appreciate email as well since
our news server has yet to prove itself reliable.

Thanks!

t
--

Arbor Intelligent Systems                       Voice:     (313) 996-4238
      "I think you've got a few too many H's, and not quite enough R's.
           Other than that, it seems a fairly literate response..."



Fri, 27 Mar 1998 03:00:00 GMT  
 Serial communication under Windows

Quote:

>....
>It is not that I mind them changing the baseline image... some classes,
> e.g. the Lens, could well use it... it's just that if you're
>going to convince someone of the advantages of maintainability, extensibility
> and REUSABILITY, they should seriously consider providing work arounds for
> those of us who have clients using our previous implementations rather than
> put it on our backs and expect us to bear the cost of migration and
> compatibility.

I quite agree.  Backward compatibility is a heavy cross to bear
if you must carry it very far (look for example at what happened
to InterLisp), but there is also a strong argument in favor of
supporting existing implementations unchanged for at least
some reasonable transition period.  Actually, I think PPS did
pretty well on this score in the transition from VW1.0 to 2.0,
but I haven't seen 2.5 yet.  OTI, on the other hand, "overlooked"
the compatibility files in their support for 2.0, and were not
very anxious to do anything about it when we reported it to
them.  By the time they actually made a minimal effort and
provided a partial ENVYized version of the compat stuff, we
had been forced to deal with it ourselves, at a very bad time
when we had far more important things to worry about.  Sigh.


Sat, 28 Mar 1998 03:00:00 GMT  
 
 [ 3 post ] 

 Relevant Pages 

1. Clipper Serial Communications under Windows NT 4.0

2. Serial Communications in MS Windows

3. Serial communication, Windows GetCommError

4. RXCOMM.DLL for windows, provides access to serial communications devices

5. Serial communication with GNAT on a Windows-PC

6. z Windows serial communication

7. help with serial port communication from Windows

8. trouble with serial communication (serial port init.vi)

9. Serial Port Communication

10. Serial communication in APL2000

11. Serial Communication with Smalltalk?

12. APL+Win, NT and Serial Communications

 

 
Powered by phpBB® Forum Software