Re: [avrdude-dev] avrdude Prob with Win2000

[E. Weddington]

On 17 Dec 2003 at 16:50, Theodore A. Roth wrote:

> 
> 
> On Wed, 17 Dec 2003, E. Weddington wrote:
> 
> > On 17 Dec 2003 at 15:03, Theodore A. Roth wrote:
> >
> > > Does this shed any light on the problem?
> > >
> > >   http://sources.redhat.com/ml/gdb/2003-09/msg00295.html
> > >
> > FYI, the avrdude shipped with WinAVR uses Cygwin DLL 1.3.x
> >
> >
> 
> I wondering if we should change this:
> 
>         *-*-msdos* | *-*-mingw32* | *-*-cygwin* | *-*-windows*)
>                 DEFAULT_PAR_PORT="lpt1"
>                 DEFAULT_SER_PORT="com1"
> 
> to something this (might need to split out the cygwin case though):
> 
>         *-*-msdos* | *-*-mingw32* | *-*-cygwin* | *-*-windows*)
>                 DEFAULT_PAR_PORT="/dev/lpt1"
>                 DEFAULT_SER_PORT="/dev/com1"
> 
> in configure.ac so as to allow things to work for cygwin users
> independent of which version of cygwin they decide to use.
> 
> Does cygwin always provide the /dev/* files? What does mingw32 do?

As I understand the link that you gave me is that Cygwin used to provide 
both /dev/* files and regular lptx/comx files in the 1.3.x DLL. Now with 
the 1.5.x DLL, it hangs when presented with lptx/comx, and that this is a 
problem, i.e. possible bug. Is that your interpretation of the thread from 
the link you gave?

I'm not sure what mingw would do as they do not provide a POSIX environment 
such as Cygwin does.

> Would native msdos and windows even use a /dev/* file?
No.
Ok, let's say, I highly doubt it.

The whole /dev/* is very much a Unix-ism and is not a part of DOS/Windows 
in any way. If Windows now provides such a path, then it's probably for 
compatibility purposes, but I wouldn't think that one could rely on it, 
especially across all Win variants (95,98,ME,NT,2K,XP).

IMHO, I would say to leave the default values for Windows alone, at least 
for now. Using comx works for the avrdude I built for WinAVR, and it ships 
with Cygwin 1.3.x. I had the opportunity to try to build with Cygwin 1.5.x 
but,
1. I was having too many problems getting things to execute correctly.
2. Most of the Cygwin packages were still in the middle of converting at 
the time.
3. Other people were having other, general problems with either converting 
to 1.5.x or using packages that were built with 1.5.x

I'd rather wait until the dust settles.

Eric