_WIN32?

_WIN32?

[Andrew Cagney]

Hello,

utils.c contains:

#if !defined (MPW) && !defined (_WIN32)
      /* No termcap under MPW, although might be cool to do something
         by looking at worksheet or console window sizes. */
      /* Initialize the screen height and width from termcap.  */

Given the ``!defined (MPW)'' bit is about to go, I'm wondering if the
!defined(_WIN32) is needed?

Hmm, actually, I'm puzzled.  Can anyone fill in the gaps?
	
	__GO32__	djgpp I think
	__CYGWIN__	ok - cygwin
	__CYGWIN32__	ok - old __CYGWIN__
	_WIN32
	_WIN32_WCE
	__MSDOS__

enjoy,
	Andrew

Re: _WIN32?

[Mo DeJong]

On Tue, 17 Apr 2001, Andrew Cagney wrote:

> Hello,
> 
> utils.c contains:
> 
> #if !defined (MPW) && !defined (_WIN32)
>       /* No termcap under MPW, although might be cool to do something
>          by looking at worksheet or console window sizes. */
>       /* Initialize the screen height and width from termcap.  */
> 
> Given the ``!defined (MPW)'' bit is about to go, I'm wondering if the
> !defined(_WIN32) is needed?
> 
> Hmm, actually, I'm puzzled.  Can anyone fill in the gaps?
> 	
> 	__GO32__	djgpp I think
> 	__CYGWIN__	ok - cygwin
> 	__CYGWIN32__	ok - old __CYGWIN__
> 	_WIN32
> 	_WIN32_WCE
> 	__MSDOS__
> 
> enjoy,
> 	Andrew

I think that -D_WIN32 is passed in the CFLAGS for the Windows
port of Tcl. If this is a file used in gdbtk, that might
explain where the _WIN32 define came from. The windows
build of Tcl also uses -DWIN32 if that helps.

Mo DeJong
Red Hat Inc

Re: _WIN32?

[Christopher Faylor]

On Tue, Apr 17, 2001 at 05:49:41PM -0400, Andrew Cagney wrote:
>utils.c contains:
>
>#if !defined (MPW) && !defined (_WIN32)
>      /* No termcap under MPW, although might be cool to do something
>         by looking at worksheet or console window sizes. */
>      /* Initialize the screen height and width from termcap.  */
>
>Given the ``!defined (MPW)'' bit is about to go, I'm wondering if the
>!defined(_WIN32) is needed?
>
>Hmm, actually, I'm puzzled.  Can anyone fill in the gaps?
>	
	__GO32__	djgpp I think
	__CYGWIN__	ok - cygwin
	__CYGWIN32__	ok - old __CYGWIN__
	_WIN32		Pure WIN32 support 'gcc -mno-cygwin' --
			don't know if it even builds.  _WIN32 is
			now no longer defined by gcc.
	_WIN32_WCE	Windows CE
	__MSDOS__	Dunno

cgf

Re: _WIN32?

[Andrew Cagney]

Christopher Faylor wrote:

>         _WIN32          Pure WIN32 support 'gcc -mno-cygwin' --
>                         don't know if it even builds.  _WIN32 is
>                         now no longer defined by gcc.

So, can I delete this one? :-)

	Andrew

Re: _WIN32?

[Christopher Faylor]

On Mon, Apr 30, 2001 at 01:05:17PM -0400, Andrew Cagney wrote:
>Christopher Faylor wrote:
>
>>         _WIN32          Pure WIN32 support 'gcc -mno-cygwin' --
>>                         don't know if it even builds.  _WIN32 is
>>                         now no longer defined by gcc.
>
>So, can I delete this one? :-)

I don't know.  Someone used to maintain a non-cygwin Windows version of
gdb.  I don't know if it even builds, like I said.  I'm not even sure
how to configure it.

Perhaps the people at mingw-users@lists.sourceforge.net know the answer
to this?  I've Cc'ed them.

cgf

Re: [Mingw-users] Re: _WIN32?

[Danny Smith]

--- Christopher Faylor <cgf@redhat.com> wrote: > On Mon, Apr 30, 2001 at
01:05:17PM -0400, Andrew Cagney wrote:
> >Christopher Faylor wrote:
> >
> >>         _WIN32          Pure WIN32 support 'gcc -mno-cygwin' --
> >>                         don't know if it even builds.  _WIN32 is
> >>                         now no longer defined by gcc.
> >
> >So, can I delete this one? :-)
> 
> I don't know.  Someone used to maintain a non-cygwin Windows version of
> gdb.  I don't know if it even builds, like I said.  I'm not even sure
> how to configure it.
> 
> Perhaps the people at mingw-users@lists.sourceforge.net know the answer
> to this?  I've Cc'ed them.
> 
> cgf
> 

The last non-cygwin windows version of gdb that I know of is 4.18 which Mumit
made available here: 
ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/ports

The diff file for that port is dated May 1999.

I have just started work on gdb 5.0 for mingw. I have not gotten far, mainly
because of lack of time.  Has anyone else made progress.

Danny

_____________________________________________________________________________
http://store.yahoo.com.au - Yahoo! Store
- It's time you had your business online!

Re: [Mingw-users] Re: _WIN32?

[Christopher Faylor]

On Tue, May 01, 2001 at 09:19:39AM +1000, Danny Smith wrote:
>
>--- Christopher Faylor <cgf@redhat.com> wrote: > On Mon, Apr 30, 2001 at
>01:05:17PM -0400, Andrew Cagney wrote:
>> >Christopher Faylor wrote:
>> >
>> >>         _WIN32          Pure WIN32 support 'gcc -mno-cygwin' --
>> >>                         don't know if it even builds.  _WIN32 is
>> >>                         now no longer defined by gcc.
>> >
>> >So, can I delete this one? :-)
>> 
>> I don't know.  Someone used to maintain a non-cygwin Windows version of
>> gdb.  I don't know if it even builds, like I said.  I'm not even sure
>> how to configure it.
>> 
>> Perhaps the people at mingw-users@lists.sourceforge.net know the answer
>> to this?  I've Cc'ed them.
>
>The last non-cygwin windows version of gdb that I know of is 4.18 which Mumit
>made available here: 
> ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/ports
>
>The diff file for that port is dated May 1999.
>
>I have just started work on gdb 5.0 for mingw. I have not gotten far, mainly
>because of lack of time.  Has anyone else made progress.

If you are at least considering this, then it sounds like the _WIN32 conditionals
in gdb sources should not be removed.

I assume that they will be required if you build a no-cygwin version of gdb,
correct?

cgf

Re: [Mingw-users] Re: _WIN32?

[Danny Smith]

--- Christopher Faylor <cgf@redhat.com> wrote: > On Tue, May 01, 2001 at
09:19:39AM +1000, Danny Smith wrote:
> >
> >--- Christopher Faylor <cgf@redhat.com> wrote: > On Mon, Apr 30, 2001 at
> >01:05:17PM -0400, Andrew Cagney wrote:
> >> >Christopher Faylor wrote:
> >> >
> >> >>         _WIN32          Pure WIN32 support 'gcc -mno-cygwin' --
> >> >>                         don't know if it even builds.  _WIN32 is
> >> >>                         now no longer defined by gcc.
> >> >
> >> >So, can I delete this one? :-)
> >> 
> >> I don't know.  Someone used to maintain a non-cygwin Windows version of
> >> gdb.  I don't know if it even builds, like I said.  I'm not even sure
> >> how to configure it.
> >> 
> >> Perhaps the people at mingw-users@lists.sourceforge.net know the answer
> >> to this?  I've Cc'ed them.
> >
> >The last non-cygwin windows version of gdb that I know of is 4.18 which
> Mumit
> >made available here: 
> > ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/ports
> >
> >The diff file for that port is dated May 1999.
> >
> >I have just started work on gdb 5.0 for mingw. I have not gotten far, mainly
> >because of lack of time.  Has anyone else made progress.
> 
> If you are at least considering this, then it sounds like the _WIN32
> conditionals
> in gdb sources should not be removed.
> 
> I assume that they will be required if you build a no-cygwin version of gdb,
> correct?
> 

Correct.  
Danny



_____________________________________________________________________________
http://store.yahoo.com.au - Yahoo! Store
- It's time you had your business online!

Re: [Mingw-users] Re: _WIN32?

[Kai Ruottu]

Christopher Faylor wrote:

> On Tue, May 01, 2001 at 09:19:39AM +1000, Danny Smith wrote:
> >
> >--- Christopher Faylor <cgf@redhat.com> wrote: > On Mon, Apr 30, 2001 at
> >01:05:17PM -0400, Andrew Cagney wrote:
> >> >Christopher Faylor wrote:
> >> >
> >> >>         _WIN32          Pure WIN32 support 'gcc -mno-cygwin' --
> >> >>                         don't know if it even builds.  _WIN32 is
> >> >>                         now no longer defined by gcc.
> >> >
> >> >So, can I delete this one? :-)
> >>
> >> I don't know.  Someone used to maintain a non-cygwin Windows version of
> >> gdb.  I don't know if it even builds, like I said.  I'm not even sure
> >> how to configure it.

 Perhaps this 'MSC_VER'-one, as the more detailed #ifdef's define it,
may be
removed. For me the _WIN32 has always been unclear.  It is more clear to
use
the '__CYGWIN32__' and '__MINGW32__' than the 'combined' _WIN32 meaning
them
both (at least earlier).

 If a port, another than for GCC, would be needed, let it at least be
for the
free or very cheap (coming with books and magazines) Borland
compilers(5.5 and
CodeBuilders), not for the very expensive MS-ones....

> >The last non-cygwin windows version of gdb that I know of is 4.18 which Mumit
> >made available here:
> > ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/ports
> >
> >The diff file for that port is dated May 1999.
> >
> >I have just started work on gdb 5.0 for mingw. I have not gotten far, mainly
> >because of lack of time.  Has anyone else made progress.

 Yes, with both 4.18.x and 5.0  using the Insight-derivation. The
snapshots
weren't yet looked by me but I wouldn't expect big surprises. In order
to get
something to download, I put the latest incarnations of these (the
binaries,
DLLs and scripts, some of these a year or more old though) for download
via
my new homepage :

     http://koti.mbnet.fi/"karuottu

 Perhaps some day I will try to collect the diffs against something (may
be
hard when adapting stuff when needed from the snapshots has been my
habit...)

> If you are at least considering this, then it sounds like the _WIN32 conditionals
> in gdb sources should not be removed.
>
> I assume that they will be required if you build a no-cygwin version of gdb,
> correct?

 As said, they just make the things more unclear. Questions like "Does
this work
under Cygwin, Mingw, MSVC++, BorlandC++, WatcomC,... ?" do arise,
because the
_WIN32 seems to mean them all. If only the Cygwin and Mingw ports are
only used
to compile GDB/Insight, why not use only the '__CYGWIN32__' and
'__MINGW32__' ?

 Removing the special Cygwin '_imp____cygwin_environ' etc. stuff, still
in the
snapshots (e.g. 'tcl/generic/tclEnv.c') when I last saw them, should be
sane...
These things should be defined in the Cygwin standard headers, not in
the GDB/tcl/tk/tix/itcl etc. sources. I'm quite sure I stripped all
these kind of
stuff for Mingw away, it already being defined in the standard
headers...

Cheers, Kai

Re: [Mingw-users] Re: _WIN32?

[Christopher Faylor]

On Tue, May 01, 2001 at 05:01:00PM +0300, Kai Ruottu wrote:
>Christopher Faylor wrote:
>>On Tue, May 01, 2001 at 09:19:39AM +1000, Danny Smith wrote:
>>>
>>>--- Christopher Faylor <cgf@redhat.com> wrote: > On Mon, Apr 30, 2001
>>>at 01:05:17PM -0400, Andrew Cagney wrote:
>>>>>Christopher Faylor wrote:
>>>>>
>>>>>>_WIN32          Pure WIN32 support 'gcc -mno-cygwin' --
>>>>>>don't know if it even builds.  _WIN32 is now no longer defined by gcc.
>>>>>
>>>>>So, can I delete this one?  :-)
>>>>
>>>>I don't know.  Someone used to maintain a non-cygwin Windows version of
>>>>gdb.  I don't know if it even builds, like I said.  I'm not even sure
>>>>how to configure it.
>
>Perhaps this 'MSC_VER'-one, as the more detailed #ifdef's define it,
>may be removed.  For me the _WIN32 has always been unclear.  It is more
>clear to use the '__CYGWIN32__' and '__MINGW32__' than the 'combined'
>_WIN32 meaning them both (at least earlier).
>
>If a port, another than for GCC, would be needed, let it at least be
>for the free or very cheap (coming with books and magazines) Borland
>compilers(5.5 and CodeBuilders), not for the very expensive MS-ones....

>>If you are at least considering this, then it sounds like the _WIN32
>>conditionals in gdb sources should not be removed.
>>
>>I assume that they will be required if you build a no-cygwin version of
>>gdb, correct?
>
>As said, they just make the things more unclear.  Questions like "Does
>this work under Cygwin, Mingw, MSVC++, BorlandC++, WatcomC,...  ?" do
>arise, because the _WIN32 seems to mean them all.  If only the Cygwin
>and Mingw ports are only used to compile GDB/Insight, why not use only
>the '__CYGWIN32__' and '__MINGW32__' ?
>
>Removing the special Cygwin '_imp____cygwin_environ' etc.  stuff, still
>in the snapshots (e.g.  'tcl/generic/tclEnv.c') when I last saw them,
>should be sane...  These things should be defined in the Cygwin
>standard headers, not in the GDB/tcl/tk/tix/itcl etc.  sources.  I'm
>quite sure I stripped all these kind of stuff for Mingw away, it
>already being defined in the standard headers...

Unfortunately, unless you are going to be doing this, none of it is
going to get done.  We aren't looking for volunteers with suggestions,
we're looking for volunteers willing to do the work.

I'm the Cygwin/Windows maintainer but I am really not interested in
getting a non-Cygwin version of gdb working.

If you have patches available against the current CVS sources, please
submit them to gdb-patches@sources.redhat.com and
insight@sources.redhat.com and I will evaluate them.

cgf

Re: _WIN32?

[Andrew Cagney]

Christopher Faylor wrote:
> 
> On Mon, Apr 30, 2001 at 01:05:17PM -0400, Andrew Cagney wrote:
> >Christopher Faylor wrote:
> >
> >>         _WIN32          Pure WIN32 support 'gcc -mno-cygwin' --
> >>                         don't know if it even builds.  _WIN32 is
> >>                         now no longer defined by gcc.
> >
> >So, can I delete this one? :-)
> 
> I don't know.  Someone used to maintain a non-cygwin Windows version of
> gdb.  I don't know if it even builds, like I said.  I'm not even sure
> how to configure it.

Was there ever anything beyond the ledgendary wingdb (a long deleted
version of GDB that compiled and ran using the windows environment).

> Perhaps the people at mingw-users@lists.sourceforge.net know the answer
> to this?  I've Cc'ed them.

Hope so.  I wouldn't mind adding this cleanup to the 5.2 release
criteria.

	Andrew

Re: _WIN32?

[DJ Delorie]

Andrew Cagney <ac131313@cygnus.com> writes:
> 	__GO32__	djgpp I think

DJGPP V1, also defined by DJGPP V2 for backwards compatibility.
__DJGPP__ is the current recommended symbol.

> 	_WIN32

These are the 'canonical' way of detecting a Windows native compiler
(MSVC, MinGW, cygwin with -mno-cygwin).

> 	__MSDOS__

DJGPP, Borland C, older MSC's, and other dos-hosted compilers.  This
is (was?) the canonical way of detecting any dos-hosted compiler
(compiler-independent filesystem issues, for example)

Re: _WIN32?

[Eli Zaretskii]

On 17 Apr 2001, DJ Delorie wrote:

> > 	__GO32__	djgpp I think
> 
> DJGPP V1, also defined by DJGPP V2 for backwards compatibility.
> __DJGPP__ is the current recommended symbol.

I don't like changing code just for the sake of changing, that's why I
consistently left the old __GO32__ symbol unless I had a good reason
for changing it into __DJGPP__ (e.g., if DJGPP v1.x behaved
differently from the current DJGPP versions).  You can never know:
someone, somewhere could still use ye olde v1.x of DJGPP.

> > 	__MSDOS__
> 
> DJGPP, Borland C, older MSC's, and other dos-hosted compilers.  This
> is (was?) the canonical way of detecting any dos-hosted compiler
> (compiler-independent filesystem issues, for example)

In some code I contributed, __MSDOS__ is used instead of __DJGPP__
where the underlying issue is not specific to DJGPP, but rather is
common to all MS-DOS-based compilers.  An example is some problem with
limitations of a 8+3 DOS filesystem, e.g. that file names like
`.gdbinit' are not allowed.

By contrast, I use __DJGPP__ for code that won't (or shouldn't) work
with anything but DJGPP.  An example is a snippet in
mant.c:maintenance_dump_me which uses SIGABRT instead of SIGQUIT, for
the reason explained in a comment there.

Re: _WIN32?

[Eli Zaretskii]

[I'm resending this because qmail rejected my original message for some 
obscure reason.]

On 17 Apr 2001, DJ Delorie wrote:

> > 	__GO32__	djgpp I think
> 
> DJGPP V1, also defined by DJGPP V2 for backwards compatibility.
> __DJGPP__ is the current recommended symbol.

I don't like changing code just for the sake of changing, that's why I
consistently left the old __GO32__ symbol unless I had a good reason
for changing it into __DJGPP__ (e.g., if DJGPP v1.x behaved
differently from the current DJGPP versions).  You can never know:
someone, somewhere could still use ye olde v1.x of DJGPP.

> > 	__MSDOS__
> 
> DJGPP, Borland C, older MSC's, and other dos-hosted compilers.  This
> is (was?) the canonical way of detecting any dos-hosted compiler
> (compiler-independent filesystem issues, for example)

In some code I contributed, __MSDOS__ is used instead of __DJGPP__
where the underlying issue is not specific to DJGPP, but rather is
common to all MS-DOS-based compilers.  An example is some problem with
limitations of a 8+3 DOS filesystem, e.g. that file names like
`.gdbinit' are not allowed.

By contrast, I use __DJGPP__ for code that won't (or shouldn't) work
with anything but DJGPP.  An example is a snippet in
mant.c:maintenance_dump_me which uses SIGABRT instead of SIGQUIT, for
the reason explained in a comment there.