Re: Compiling a windows.exe against cygwin1.dll ?

[Wim Van Oudenhove <wim dot van dot oudenhove at philips dot com>]

Igor Pechtchanski <pechtcha <at> cs.nyu.edu> writes:

> 
> On Mon, 25 Oct 2004, Wim Van Oudenhove wrote:
> 
> > > >
> > > > Is there something I can 'borrow' from cygwin1.dll or some
> > > > other dll to make my
> > > > program support these two cases ?
> > > > (The program is a command line tool written using visual C++)
> > >
> > >   Well, yeah: what you're really saying there is that you want a
> > > cygwin app rather than a 'doze one.  Rewrite it using the standard
> > > ANSI C stdio functions (f)open, (f)close, (f)read, (f)write (assuming
> > > it isn't already using them), and use cygwin gcc to compile it instead
> > > of msvc, and you'll get all that functionality for free.
> >
> > I would have done that a long time ago if I knew how to use COM under
> > GCC.
> 
> Just like you'd use it under MSVC: call the functions.  Nothing prevents a
> Cygwin program from calling pure Windows functions for the functionality
> not present in Cygwin -- that's what the w32api effort is for.  Just don't
> reinvent the wheel and reimplement functionality that's already present in
> Cygwin.  Many Cygwin programs do that, e.g., XWin and rxvt.
> 
> 
> See how the perl libwin32 does it.  Or you could just use cron... 

It is cron ;-)

> > It also uses some of the AFX CList, CMap, and CArray templates. I'm sure
> > someone has written equivalents for them in ansi C somewhere, but all
> > this sounds like too much work for the same purpose.
> 
> Those are probably more of a problem for gcc than the Win32 functions.  To
> be pedantic, you want their equivalents in ANSI C++, not ANSI C.  AFAIK,
> the Cygwin version of gcc comes with an STL implementation -- will that
> do?
> 
> > The function it performs is available by default on a unix workstation,
> > so I doubt that I'll ever need it for another operating system than
> > windoze.
> 
> Which function is that?  Perhaps it's also available on Cygwin already?
> 	Igor

So I've written a program that translates crontab compatible files to schedules 
for the windows scheduler. We've used cron, but that relies on the availability 
of the cygwin stack, which in turn relies on the availability of the central 
repository on the network. We've seen it failing rather frequently due to 
network outage and that's why we decided to use the windows scheduler instead. 
The first option is the file to use, I load it in a CStdioFile class, which I'm 
sure internally uses fopen, fclose, etc...

I'm not at all a gcc expert, I only know of it's existence and the fact that 
others use it here in the company. Trying to compile StdAfx.cpp doesn't seem to 
work at all with all that internal windows stuff. g++ isn't much different.

How about 'borrowing' gcc's implementation of fopen ? Does that sound like a 
good idea ? I only need to open the file, once I have the handle, I can re-
attach to it with CStdioFile and keep the rest of my code.