Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: "Paul Derbyshire" To: cygwin AT cygwin DOT com Date: Fri, 2 Aug 2002 03:34:52 -0400 MIME-Version: 1.0 Subject: Re: Automating Windows from cygwin Reply-to: derbyshire AT globalserve DOT net Message-ID: <3D49FDDC.5887.6C9D6C6A@localhost> In-reply-to: Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body On 31 Jul 2002 at 13:36, James Ganong wrote: > I have some scientific instruments that will only talk to > a proprietary Windows app, and some Linux programs that > analyze the data. > I would really like to automate the process of running the Windows > program so that the Linux programs could talk to cygwin over the net > and get the data. > The problem is that the windows app was written long ago, > and source is not available. So I am wondering if there > is a way to run an arbitrary windows application and do something > like mouse macros from cygwin. > > Does anybody know of a way to do mouse macros from cygwin, or a way > to invoke menu items from a arbitrary windows app from cygwin, or a better way > to approach this? I have the impression that some people do mouse macros > via vnc. Is there some O'Reilly book that I should have read? Cron could be used to run the app on a regular schedule. As for manipulating its interface or closing it on a regular schedule, you could cobble up a VB app that uses DDE to manipulate its UI. This could be triggered from cron and then do whatever needs doing. A better solution would be to contact the vendor and ask for Linux software for these instruments. Failing that, see if anyone's created some. Failing that, ask the vendor for documentation of the communication protocols and write a C program to acquire the data. Failing that, reverse engineer the communication protocols and do likewise. A lot of linux drivers for Winhardware came about through processes like this. Your scientific instruments may be unusual devices, but they are still devices and the data acqusiition program still a device driver of sorts, so the same kind of situation exists here as with making other hardware work with Linux that came from clueless or M$-corrupted hardware vendors. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/