GDB Woes Continued...

GDB Woes Continued...

[wanker]

Hello everyone,

I'm running the latest version of GDB for WinNT on Win95
(I was told it should work with the latest GNAT WinNT distribution),
and I just want to check on a few things:

1) Does GDB decide to spontaneously abort half the time you
   load an executable?

2) Does GDB bring your entire system down to its knees when you
   try to quit?

3) Is the online help broken?  When you click on anything, does
   it whine about not finding stdout or some Unix-ish nonsense?

4) Does GDB expect you to debug in C, even though you just
   wrote your code in Ada?

I'm asking these questions because GDB is giving me all these
problems and more (no native look and feel, ad nauseum).  

RTFM? Sure, once I find the FM!

With the online help being broken and nothing remotely resembling
documentation to be found, I can't find any information on this
at all.

I'm sorry if you are sick of hearing from me, but there is no
where else to turn.  Nothing works, and the documentation
(when it is to be found) is 100% useless or worse (misleading).

The only thing now keeping me from reverting to C/C++ (at least
I know their distributions work), is the fact that there are
people here who claim to actually have this stuff working, so
I still have some glimmer of hope.  

Thanks, and my email address is buggered so please post answers
here.

Re: GDB Woes Continued...

[Jerry van Dijk]

> I'm running the latest version of GDB for WinNT on Win95
> (I was told it should work with the latest GNAT WinNT distribution),
> and I just want to check on a few things:

> 1) Does GDB decide to spontaneously abort half the time you
>    load an executable?

It does with me on Win95.
 
> 2) Does GDB bring your entire system down to its knees when you
>    try to quit?

Note entirely, you can break it of using the tasklist. But this is indeed
another problem.

> 3) Is the online help broken?  When you click on anything, does
>    it whine about not finding stdout or some Unix-ish nonsense?

Never tried it.

> 4) Does GDB expect you to debug in C, even though you just
>    wrote your code in Ada?

No.

It seems that with certain configurations (although I cannot tell which
ones)
gdb for 3.10p1 will not work under Win95.

Can anyone outside ACT report success with gdb under Win95 ?

-- 
-- Jerry van Dijk | Leiden, Holland
-- Team Ada       | email: jdijk@acm.org

Re: GDB Woes Continued...

[Roger Racine]

> > I'm running the latest version of GDB for WinNT on Win95
> > (I was told it should work with the latest GNAT WinNT distribution),
> > and I just want to check on a few things:
> 
> > 1) Does GDB decide to spontaneously abort half the time you
> >    load an executable?
> 
> It does with me on Win95.

I have not been able to get it to load an executable.  I get a "Something
wrong with xxxxx" message, where "xxxxx" is the file name.

>  
> > 2) Does GDB bring your entire system down to its knees when you
> >    try to quit?
> 
> Note entirely, you can break it of using the tasklist. But this is indeed
> another problem.
> 
> > 3) Is the online help broken?  When you click on anything, does
> >    it whine about not finding stdout or some Unix-ish nonsense?
> 
> Never tried it.

I get the same problem.

> 
> > 4) Does GDB expect you to debug in C, even though you just
> >    wrote your code in Ada?
> 
> No.

Does it have anything to do with how one compiles the program in
question?  I am using GIDE, with the switch set that creates debugger
information.  And I have still not been able to get the debugger to work.

> 
> It seems that with certain configurations (although I cannot tell which
> ones)
> gdb for 3.10p1 will not work under Win95.
> 
> Can anyone outside ACT report success with gdb under Win95 ?
> 
Not I.

The only reason I respond like this is that I, too, am a bit frustrated by
the level of documentation (especially when the Help system does not
work!).  

I have seen a message from Robert Dewar where he suggests that the
debugger is unnecessary, and I understand his position.  I do not think
the point is relevant, though, since a -lot- of people will be turned off
a language if the tools for that language do not meet their expectations,
no matter if the expectation is reasonable.  It would be better to not
have a tool than to have a bad one (or an undocumented one, where the tool
looks bad even if it can be made to work).

By the way, do not interpret this (or the original poster's message) as a
swipe at ACT, or Robert Dewar.  I applaud their effort to bring an
affordable, excellent product to the masses.  And I have found the
-compiler- to be reasonably well documented (it is too UNIX-oriented for
Windows users, but that is a different subject), and the compilation
system works quite well.

Please consider this as "constructive criticism" to the Ada community in
general.  If we want to get Ada accepted by the masses, we need to A)
provide tools the masses want (as opposed to what they need), and B)
provide usable tools (as opposed to useful tools).  That is a bit cynical,
but the point is that any tools that do not work "Off the Shelf" are not
going to be used.

Roger Racine

Re: GDB Woes Continued...

[wanker]

In article <rracine-0202980727040001@rjr1287.draper.com>,
Roger Racine <rracine@draper.com> wrote:

[About loading an executable]

>I have not been able to get it to load an executable.  I get a "Something
>wrong with xxxxx" message, where "xxxxx" is the file name.
>

Are you by any chance loading from the menu?  Whenever I try
any kind of load from the menu I get some kind of error messages.
Try some of the commands from the debugger command-line.  A "help"
should give you a list of things to try.

Not that it's going to do you any good.  You won't see the
error message, but you'll still see C code, and I haven't
had much luck in actually stepping through anything.



>> > 4) Does GDB expect you to debug in C, even though you just
>> >    wrote your code in Ada?
>> 
>> No.
>
>Does it have anything to do with how one compiles the program in
>question?  I am using GIDE, with the switch set that creates debugger
>information.  And I have still not been able to get the debugger to work.

I used the -g option which as far as I know, should create 
debugging information.  I got this straight out of seeing what
Adagide fed to the compiler.  I still can't get anything other
than C code, and the debugger doesn't even seem to like
stepping through that!  


>> Can anyone outside ACT report success with gdb under Win95 ?
>> 
>Not I.

And of course not I.


>
>The only reason I respond like this is that I, too, am a bit frustrated by
>the level of documentation (especially when the Help system does not
>work!).  

Definitely.  What really irks me is the fact that the bugs
and flakiness would NEVER have made it through if someone had
bothered to test the thing.  There is no way that you get
a completely, 100% broken help system and 50% (or higher)
crash rate coming through the test.

The way I see it, somebody pulled out the Unix source, 
threw it at some automatic conversion protocols and
figured "that's good enough for those windows bastards, if
they don't like it, let them get Linux!".

Well I'm one of those "windows bastards", and I have no
intention of installing Linux.  If the tools for windows
don't work, then I will find other tools.  

Ada is too good a language to give a bad rep to because
the tools stink.  How many people do you think are being
turned off because of crap like gdb?  Sorry, but gdb IS crap.
At least the Windows version is.

Successful Advocacy starts with having good tools to show
people how nice Ada programming is.  Please remember that.

You've got a superb IDE (Grasp), which can connect to a
very good compiler (GNAT), now you need a usable debugger.


>
>I have seen a message from Robert Dewar where he suggests that the
>debugger is unnecessary, and I understand his position.  I do not think
>the point is relevant, though, since a -lot- of people will be turned off
>a language if the tools for that language do not meet their expectations,
>no matter if the expectation is reasonable.  It would be better to not
>have a tool than to have a bad one (or an undocumented one, where the tool
>looks bad even if it can be made to work).

I haven't seen this message, and I am interested in knowing why
would a debugger be unnecessary?  I consider the debugger to
be THE most important tool next to the compiler itself.



>By the way, do not interpret this (or the original poster's message) as a
>swipe at ACT, or Robert Dewar.  I applaud their effort to bring an
>affordable, excellent product to the masses.  And I have found the
>-compiler- to be reasonably well documented (it is too UNIX-oriented for
>Windows users, but that is a different subject), and the compilation
>system works quite well.

I'm not insulting ACT either -- I mean this stuff IS free.  Now
if I were expected to pay for gdb, that would be an entirely
different matter (I would be raising all hell).  And as you said,
the compiler is quite good.

I consider the problem with gdb to be representative of problems
with people porting Unix programs to Windows (NT, 95) in general.
I mean look at Cygwin32 -- it's a package designed to make
windows act like Unix so that people don't have to take the time
to actually fix their programs so they work on Windows.  It's
like a layer of emulation on top of an O/S.  Cygwin32
is the ultimate "round peg in a square hole" adapter.  It's
like these tools were designed by Linux advocates so they can
say "it won't be THIS hard if you just give up and use Linux".

I think the ultimate example of this ridiculousness came when
I went out to download a language.  The language itself (the
binary for Windows) was about a meg or two in size, but in order
to run I had to download a 9 meg package to make Windows look
like Unix!  I think that says it all.

Needless to say, I didn't even bother downloading the language.

The only reason I'm putting up with this debacle so far is
because I've used Ada before and I know it's a good language.
If I didn't know this, I would have given up the first time
I had a problem.

To all the folks thinking about porting Unix apps to Windows:
Please REALLY PORT IT.  Don't expect us to break our backs to
get YOUR programs to work with Windows.  That's your job,
and remember that things should work right out of the package.
This is not Unix, where you are stuck compiling and configuring
things yourself.  Do you think Windows users, who are pampered
with things like "install wizards" and point and click configuration
are going to try to fix makefiles and set up environments manually,
especially in the absence of decent documentation?  



>
>Please consider this as "constructive criticism" to the Ada community in
>general.  If we want to get Ada accepted by the masses, we need to A)
>provide tools the masses want (as opposed to what they need), and B)
>provide usable tools (as opposed to useful tools).  That is a bit cynical,
>but the point is that any tools that do not work "Off the Shelf" are not
>going to be used.


Precisely.  At this point I'm on the fence as to whether or not
Ada is even worth my time.  I used Ada a few years back, and
deleted it from my system because there wasn't a useful debugger
available.  Without being able to debug my code, I considered
the entire development environment to be nothing more than a toy.
I sadly went back to coding in C/C++ and with even higher level
languages (ones that had a subsystem that served as a debugger).

Now I'm back, and it sadly looks like Ada95 will be deleted again.
Not only doesn't gdb work, but the TK package doesn't either -- it
won't even build (the fact that I'm even expected to build the
package under Win95 is demonstrative of what I've been complaining
about -- more unnecessary UNIXisms). The really sad thing is I'm not sure
if I want to waste my time giving Ada another chance.  Life is too
short to be trying to fix problems which should not be there.

It's like all the time and grief you'll save by programming in
Ada is more than offset by the agony you'll suffer trying to
get the thing to work!


>
>Roger Racine


I'm sure you can tell that I'm frustrated.  I've just about had it.

Thanks.

Re: GDB Woes Continued...

[Stephen Leake]

wanker@exploited.barmy.army wrote:
> 
> I'm sorry if you are sick of hearing from me, but there is no
> where else to turn.  Nothing works, and the documentation
> (when it is to be found) is 100% useless or worse (misleading).
> 
> The only thing now keeping me from reverting to C/C++ (at least
> I know their distributions work), is the fact that there are
> people here who claim to actually have this stuff working, so
> I still have some glimmer of hope.
> 

Please remember that you are using free software; the value you get out
of it is roughly proportional to the effort you put in (as opposed to
what you paid for it!). Be patient, and persevere.

GNAT/GDB is all based on the gnu software. For me, the best way to learn
how to use it is to download the sources from MIT
(ftp://prep.ai.mit.edu/pub/gnu/), because the sources usually have more
complete documentation (and if you've got lots of time, you can actually
read the code :).
 
How much did you pay for your C/C++ environment? For about the same
amount, you can buy an Ada compiler, and get a tech person to call.

That said, I've used both ObjectAda (Professional Edition) and GNAT/GDB,
and I prefer GNAT/GDB (except when I need to use Windows resources). But
I've gone thru the process of configuring it and learning how to read
the manuals. I still can't get GDB to work properly on my machine at
work under Win95; but that machine also has NT, where GDB works fine.

-- 
- Stephe

Re: GDB Woes Continued...

[Robert Dewar]

<<Definitely.  What really irks me is the fact that the bugs
and flakiness would NEVER have made it through if someone had
bothered to test the thing.  There is no way that you get
a completely, 100% broken help system and 50% (or higher)
crash rate coming through the test.

The way I see it, somebody pulled out the Unix source,
threw it at some automatic conversion protocols and
figured "that's good enough for those windows bastards, if
they don't like it, let them get Linux!".
>>

Actually, as many of you know, we delayed the release of the NT debugger
publicly even though it seemed to work fairly well on NT until we got a
version that would work reasonably well on Win95. It works well on at
least some Win95 systems, all except for the restart capability, which
is documented to be broken (and is not easy to fix). We also heard
from our beta testers that it was working.

It sure is odd to hear of reports of it being totally broken on Win95.
We have a couple of customers on Win95 who are using it without anything
like these troubles. 

We are certainly finding that Win95 is not as compatible with NT as
certain folks would like us to think :-)

Contrary to the scenario above, a LOT of work has gone into the NT
version of the debugger to get around the Win95 problems. 

One thing this confirms incidentally is that the general ACT strategy of
not releasing things publicly until they have been really well shaken
down is a good one. In the case of the Win95 debugger, people were
screaming at us for a long time for not releasing a public version,
and we very conciously decided to release this as soon as we had at
least some reports of it working fine under Win95, and (for example)
it certainly works OK on my Win95 setup. It certainly seems like
milage varies on different versions of Win95, and it is hard to know
exactly what the sources of the variation might be.

As always, if you have very specific examples of failures, send the
reports along to report@gnat.com.

Robert Dewar
Ada Core Technologies

Re: GDB Woes Continued...

[Robert Dewar]

<<<<I haven't seen this message, and I am interested in knowing why
  would a debugger be unnecessary?  I consider the debugger to
  be THE most important tool next to the compiler itself.>>
>>

Clearly a lot of people depend on debuggers, so most certainly a good
working debugger is an absolute necessity for a usable compiler system,
since clearly customer demand is what establishes such needs.

However, to explain my comment above. I continue to think that most people
greatly overuse debuggers. It is much better to write error-free code in
the first place, and if you do have errors, to think about what is wrong,
and fix it, rather than spending ages in a debugger looking arond.

Of course different people have different styles, but too many programmers
today are introduced only to the hack-and-debug school of coding. It is
interesting to present the clean-room model to typical programmers today
(this is the approach in which developers are not permitted to run their
code at all to test it, let alone to debug it -- the idea is to have
the developers develop solid correct code, and then let a separate team
do the testing).

Many programmers cannot imagine writing code without testing it themselves.
They are so used to the approximate-and-hack-into-shape approach.

Of course there are always exceptions, where subtle interactions are best
tracked down with a debugger, and a working debugger is especially
important in such cases, but never forget, it is your *brain* that is
the most important tool, not the compiler or the debugger :-)

Going back to the use of GDB and Win95, one suggestion you might want
to pursue is using NT instead of Win95. Win95 may be fine for word
processing and playing games, but it seems far too unstable to be
appropriate as a serious program development platform.

We have certainly found NT to be much more reliable than Win95, and most
of our customers using the NT/WIn95 version of GNAT are indeed using NT.
GDB itself has always been more stable under NT (the delay in releasing
it was solely because of the Win95 problems, since we realize that users
of the public version are more likely NOT to be serious developers and to
be fiddling with Win95).

Still we do have some customers using WIn95, and they are certainly
managing to get GDB up and running reasonably well. It is true that
this is the 3.11 technology, which has a LOT of very substantial
improvements in GDB and the debugging information available in
Ada mode.

Still, I don't think the reported problems here are to do with 3.10
vs 3.11, they seem more fundamental. If they are not installation
problems, then it seems like there are some versions of Win95 that
simply don't let you get past first base in loading GDB, very odd!

Robert Dewar
Ada Core Technologies

Re: GDB Woes Continued...

[Martin C. Carlisle]

In article <01bd2e9b$76253380$562c5c8b@aptiva>,
Jerry van Dijk <jvandyk@ibm.net> wrote:
>It seems that with certain configurations (although I cannot tell which
>ones)
>gdb for 3.10p1 will not work under Win95.
>
>Can anyone outside ACT report success with gdb under Win95 ?

Here at the Air Force Academy, we have a large number of students and
faculty in Computer Science and Astro using gdb under Win 95.  The only
major problem is that attempting "run" or "start" a second time without
closing and reopening GDB can cause the system to become unstable.

--Martin

-- 
Martin C. Carlisle, Computer Science, US Air Force Academy
mcc@cs.usafa.af.mil, http://www.usafa.af.mil/dfcs/bios/carlisle.html
DISCLAIMER:  This content in no way reflects the opinions, standard or 
policy of the US Air Force Academy or the United States Government.

Re: GDB Woes Continued...

[Larry Kilgallen]

In article <dewar.886438670@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> Of course different people have different styles, but too many programmers
> today are introduced only to the hack-and-debug school of coding. It is
> interesting to present the clean-room model to typical programmers today
> (this is the approach in which developers are not permitted to run their
> code at all to test it, let alone to debug it -- the idea is to have
> the developers develop solid correct code, and then let a separate team
> do the testing).

Without going that far, I have recently had the opportunity to write 25K
(not counting comments) lines of Ada which cannot be debugged yet because
the piece into which it plugs is not yet available.  I am _very_ glad to
be using Ada in this circumstance and able to make progress using only a
compiler.

> Of course there are always exceptions, where subtle interactions are best
> tracked down with a debugger,

Of particular significance in this area are the points where there is an
interface to code from others for which you do not have the source (such
as an operating system).  Ada programmers suffer in this area particularly
since such interfaces were usually not designed with Ada support as a top
priority and likewise for documentation.  The best answer even people on
this list seem to have for Microsoft situations is "you better know C".

Larry Kilgallen

Re: GDB Woes Continued...

[Robert Dewar]

Ronald Cole says

<<Sounds like a fundamental problem in your beta testing program.>>

Not really ... we certainly could take the attitude of not publicly
releasing the NT version of GDB until we were really sure it worked
on *all* Win95 systems (there is a simple method of ensuring that
we meet this requirement :-) :-) 

In fact the current version seems quite reliable on NT, and also seems
to work on many (most?) Win95 systems (note for example Martin Carlisle's
reported success at Air Force academy with a variety of machines and
users). It is at this stage hard to know if the reported problems are
oddities in particular versions of Win95, or installation/configuration
problems (we always have the experience that many problems come from not
reading all the documentation and installation instructions -- no way of
knowing that this is the case here, but also no way of knowing that it is
NOT the case).

Our strategy for this release was to release it as soon as we heard from
some significant users (including Martin) that the fundamental Win95
problem had been solved. 

Anway, you should consider that the status of the public release of
GDB for GNAT/NT is that it works OK on NT, and may well work on Win95,
but there are no guarantees (actually there are never any guarantees
in using the public versions of GNAT technology in any case!)

We haven't been able to duplicate these problems so far, and
we have run GDB on a variety of Win95 machines. One observation is
that we are running the latest version of Win95 on pretty much all
machines, not the broken version you can buy in stores, so perhaps
that is one variable.

Robert Dewar
Ada Core Technologies

Re: GDB Woes Continued...

[vonhend]

In <01bd2e9b$76253380$562c5c8b@aptiva>, "Jerry van Dijk" <jvandyk@ibm.net> writes:
>> I'm running the latest version of GDB for WinNT on Win95
>> (I was told it should work with the latest GNAT WinNT distribution),
>> and I just want to check on a few things:
>
>> 1) Does GDB decide to spontaneously abort half the time you
>>    load an executable?
>
>It does with me on Win95.
> 
>> 2) Does GDB bring your entire system down to its knees when you
>>    try to quit?
>
>Note entirely, you can break it of using the tasklist. But this is indeed
>another problem.
>
>> 3) Is the online help broken?  When you click on anything, does
>>    it whine about not finding stdout or some Unix-ish nonsense?
>
>Never tried it.
>
>> 4) Does GDB expect you to debug in C, even though you just
>>    wrote your code in Ada?
>
>No.
>
>It seems that with certain configurations (although I cannot tell which
>ones)
>gdb for 3.10p1 will not work under Win95.
>
>Can anyone outside ACT report success with gdb under Win95 ?
>
>-- 
>-- Jerry van Dijk | Leiden, Holland
>-- Team Ada       | email: jdijk@acm.org
>
Don't know about WinDoze 95, but once I got used to it, I
found that gdb for 3.10p works pretty well under OS/2.  A
real operating system seems to make quite the difference.

M. Von Hendy
LMTO

Re: GDB Woes Continued...

[Ronald Cole]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> We also heard from our beta testers that it was working.

Sounds like a fundamental problem in your beta testing program.

> One thing this confirms incidentally is that the general ACT strategy of
> not releasing things publicly until they have been really well shaken
> down is a good one.

The only thing it confirms is your religious adherance to the
cathedral model of software development.  You have yet to attempt the
bazaar model (so far as anyone can tell).

<http://www.ccil.org/~esr/writings/cathedral.html>

-- 
Forte International, P.O. Box 1412, Ridgecrest, CA  93556-1412
Ronald Cole <ronald@ridgecrest.ca.us>    Phone: (760) 499-9142
President, CEO                             Fax: (760) 499-9152
My PGP fingerprint: E9 A8 E3 68 61 88 EF 43  56 2B CE 3E E9 8F 3F 2B

Re: GDB Woes Continued...

[John English]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
: We are certainly finding that Win95 is not as compatible with NT as
: certain folks would like us to think :-)

Amen!

: Of course different people have different styles, but too many programmers
: today are introduced only to the hack-and-debug school of coding. It is
: interesting to present the clean-room model to typical programmers today
: (this is the approach in which developers are not permitted to run their
: code at all to test it, let alone to debug it -- the idea is to have
: the developers develop solid correct code, and then let a separate team
: do the testing).

: Many programmers cannot imagine writing code without testing it themselves.
: They are so used to the approximate-and-hack-into-shape approach.

Amen, amen!

[Apologies for a "me too", but so few people seem to appreciate that
you still write software if you haven't got a keyboard (or worse, a
mouse) within easy reach. Bring back twice-a-day punched card batch
systems!]

Oh reggub, I'm showing my age again... :-)

-----------------------------------------------------------------
 John English              | mailto:je@brighton.ac.uk
 Senior Lecturer           | http://www.it.bton.ac.uk/staff/je
 Dept. of Computing        | ** NON-PROFIT CD FOR CS STUDENTS **
 University of Brighton    |    -- see http://burks.bton.ac.uk
-----------------------------------------------------------------

Re: GDB Woes Continued...

[Andrew Lynch]

Robert Dewar wrote:
> 
> We haven't been able to duplicate these problems so far, and
> we have run GDB on a variety of Win95 machines. One observation is
> that we are running the latest version of Win95 on pretty much all
> machines, not the broken version you can buy in stores, so perhaps
> that is one variable.

The problem is that it is so easy to break any version of Win95,
simply by installing and deinstalling software. Do you know which
application placed which version of which DLL in your Windows
directory..?

This gets even worse with the international versions. Say my German
version of Win95 has FOO.DLL version 2 in German. What do I do if
an installation wants to replace that with FOO.DLL version 1 English?
(At least it is kind enough to ask) Something is bound to go wrong
somewhere, whichever choice I make.

If you want your application to run on all Win95 machines I guess
you might just install any system files your application needs in
the required versions and bugger whatever was in there before...
(at least *your* application is going to work)
This seems to be the approach taken by some vendors.

Andrew.

P.S. As for GDB: works fine on NT at work, but not on 95 at home
("original" September 95 German Win95 with every other DLL screwed
by some installed application)

Re: GDB Woes Continued...

[Roger Racine]

> <<Sounds like a fundamental problem in your beta testing program.>>
> 
> Not really ... we certainly could take the attitude of not publicly
> releasing the NT version of GDB until we were really sure it worked
> on *all* Win95 systems (there is a simple method of ensuring that
> we meet this requirement :-) :-) 
> 
> In fact the current version seems quite reliable on NT, and also seems
> to work on many (most?) Win95 systems (note for example Martin Carlisle's
> reported success at Air Force academy with a variety of machines and
> users). It is at this stage hard to know if the reported problems are
> oddities in particular versions of Win95, or installation/configuration
> problems (we always have the experience that many problems come from not
> reading all the documentation and installation instructions -- no way of
> knowing that this is the case here, but also no way of knowing that it is
> NOT the case).
> 
> Our strategy for this release was to release it as soon as we heard from
> some significant users (including Martin) that the fundamental Win95
> problem had been solved. 
> 
> Anway, you should consider that the status of the public release of
> GDB for GNAT/NT is that it works OK on NT, and may well work on Win95,
> but there are no guarantees (actually there are never any guarantees
> in using the public versions of GNAT technology in any case!)
> 
> We haven't been able to duplicate these problems so far, and
> we have run GDB on a variety of Win95 machines. One observation is
> that we are running the latest version of Win95 on pretty much all
> machines, not the broken version you can buy in stores, so perhaps
> that is one variable.

This is my first experience trying to use a compilation system on a
Windows 95 PC (I have used Ada on pretty much every other OS), so I have
no idea if these types of problems are usual with other commercial
compiler products (I picked my words carefully.  GNAT and GDB are
commercial products, right?  One happens to pay for the support instead of
the license, but that is, supposedly, the only difference).  

Perhaps ACT (and every other vendor; this advice is universal; the actual
suggestions are specific) should make sure that their testing is
realistic.  

1) Most people do not have access to the beta versions of commercial
OSes.  They have the "broken version you can buy in stores".  And those
computers have -lots- of other programs installed.

Do you have any idea on what configurations of Windows platforms your
testers are testing?  Are they all using some pre-release version, or a
"clean" machine used only for Ada development?

2) If you care about the unsupported folks out here (which it seems you
do, or you would not be responding) have relative novices (with the
platform and the download procedure) go through the installation process
and the documentation available on the server.  Many people are going to
simply download the .EXE files and install.  That is what they are used to
for commercial products, shareware and freeware.  Do not suggest that they
build the product from source code.  They have better things to do with
their time (and disk space).

3) Do not assume that the users of your unsupported version are not
important to your economic success.  Some are evaluating the language, the
product, or the company.  If they find a robust product, at least as good
as what they are used to, the language will get more converts, and you
will get more supported customers.  Lots of winners!

Roger Racine

Re: GDB Woes Continued...

[Robert Dewar]

Roger said

<<1) Most people do not have access to the beta versions of commercial
  OSes.  They have the "broken version you can buy in stores".  And those
  computers have -lots- of other programs installed.>>

No, that's quite wrong, most people have the OSR2 version of Win95, because
that's what comes preinstalled. Remember that Microsoft's proposal to allow
the old (store available) version to be installed by OEM's as a solution to
getting rid of explorer was widely regarded as a completely unreasonable
response to the government suit.

So unless you are in the very small minority (at this stage) who is running
the original version of WIn95, you are probably already running OSR2.

<<Do you have any idea on what configurations of Windows platforms your
  testers are testing?  Are they all using some pre-release version, or a
  "clean" machine used only for Ada development?>>

No one is using pre-releases of any kind, we are using the current version
of Win95, as distributed by Microsoft preinstalled on OEM machines. Yes, it
is a pity you can't buy this in a store, but complain to MS about this, not
to us!

<<2) If you care about the unsupported folks out here (which it seems you
  do, or you would not be responding) have relative novices (with the
  platform and the download procedure) go through the installation process
  and the documentation available on the server.  Many people are going to
  simply download the .EXE files and install.  That is what they are used to
  for commercial products, shareware and freeware.  Do not suggest that they
  build the product from source code.  They have better things to do with
  their time (and disk space).>>

No one is for a moment suggesting to anyone that they build the NT version
from sources. You never saw me or anyone else suggest this. In fact this
build is quite tricky, and we advise trying it only if you know what you
are doing!

<<3) Do not assume that the users of your unsupported version are not
  important to your economic success.  Some are evaluating the language, the
  product, or the company.  If they find a robust product, at least as good
  as what they are used to, the language will get more converts, and you
  will get more supported customers.  Lots of winners!>>

Actually we do NOT encourage people to use the public version for evaluation.
If you want to evaluate GNAT, you should contact our sales department 
regarding evaluation licenses. For any proprietary product, this is the
procedure you would normally follow anyway, and it is still the best 
approach for GNAT. 

We make the public version available for students and other casual users,
and it is useful in that mode for spreading the use of the language, but
the public version of GNAT most definitely is NOT intended for serious
evaluation purposes. For one thing, one of the most important aspects of
the use of the GNAT technology is the support that we can provide, and
if you are doing a serious evaluation of GNAT, you should also evaluate
that support!

Finally, as I noted before, we do NOT encourage the use of Win95 for
serious software development. We attempt to make sure that the NT version
works on Win95, since for student use particularly this is valuable, but
it is clear that WIn95 is not suitable for software development where any



Robert Dewar
Ada Core Technologies

Re: GDB Woes Continued...

[Roger Racine]

In article <dewar.886601304@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

> <<1) Most people do not have access to the beta versions of commercial
>   OSes.  They have the "broken version you can buy in stores".  And those
>   computers have -lots- of other programs installed.>>
> 
> No, that's quite wrong, most people have the OSR2 version of Win95, because
> that's what comes preinstalled. Remember that Microsoft's proposal to allow
> the old (store available) version to be installed by OEM's as a solution to
> getting rid of explorer was widely regarded as a completely unreasonable
> response to the government suit.
> 
> So unless you are in the very small minority (at this stage) who is running
> the original version of WIn95, you are probably already running OSR2.
> 

Actually, I have an upgrade from Windows 3.1 to Windows 95, and I did buy
it in a store. I have no idea what percentage of people get new machines
vs upgrading old ones.  But new operating system versions do not come with
processor boards.

> <<Do you have any idea on what configurations of Windows platforms your
>   testers are testing?  Are they all using some pre-release version, or a
>   "clean" machine used only for Ada development?>>
> 
> No one is using pre-releases of any kind, we are using the current version
> of Win95, as distributed by Microsoft preinstalled on OEM machines. Yes, it
> is a pity you can't buy this in a store, but complain to MS about this, not
> to us!
> 

I misunderstood your earlier statement (and did not know about Microsoft's
policy).  However, your release notes, perhaps, should mention the version
on which it was tested.

> <<2) If you care about the unsupported folks out here (which it seems you
>   do, or you would not be responding) have relative novices (with the
>   platform and the download procedure) go through the installation process
>   and the documentation available on the server.  Many people are going to
>   simply download the .EXE files and install.  That is what they are used to
>   for commercial products, shareware and freeware.  Do not suggest that they
>   build the product from source code.  They have better things to do with
>   their time (and disk space).>>
> 
> No one is for a moment suggesting to anyone that they build the NT version
> from sources. You never saw me or anyone else suggest this. In fact this
> build is quite tricky, and we advise trying it only if you know what you
> are doing!
> 

This was an impression I got from you when you said you did not know how
the installation was done.  It is very difficult to make a user mistake
with an installation procedure that asks no questions (it might want a few
questions answered, but they are trivial).  I have also seen in other
messages (not necessarily from you or anyone from ACT) suggestions that
people should build their own.

> <<3) Do not assume that the users of your unsupported version are not
>   important to your economic success.  Some are evaluating the language, the
>   product, or the company.  If they find a robust product, at least as good
>   as what they are used to, the language will get more converts, and you
>   will get more supported customers.  Lots of winners!>>
> 
> Actually we do NOT encourage people to use the public version for evaluation.
> If you want to evaluate GNAT, you should contact our sales department 
> regarding evaluation licenses. For any proprietary product, this is the
> procedure you would normally follow anyway, and it is still the best 
> approach for GNAT. 
> 
> We make the public version available for students and other casual users,
> and it is useful in that mode for spreading the use of the language, but
> the public version of GNAT most definitely is NOT intended for serious
> evaluation purposes. For one thing, one of the most important aspects of
> the use of the GNAT technology is the support that we can provide, and
> if you are doing a serious evaluation of GNAT, you should also evaluate
> that support!
> 
> Finally, as I noted before, we do NOT encourage the use of Win95 for
> serious software development. We attempt to make sure that the NT version
> works on Win95, since for student use particularly this is valuable, but
> it is clear that WIn95 is not suitable for software development where any

Did you intend to send more?  Not that more is needed, but your message
ended.  Again, subject to misinterpretation (we need a more formal
language than English), I take it that you consider the Win95 version to
-not- be important.  

I do not really care about the platform.  I only care if the language is
hurt by the perception that the tool is bad (even if it is the platform). 
Ada83 (the language) got devastating reports from evaluators who really
only had complaints with the compilers.  If more vendors were like DEC,
and only released rock-solid compilers and related tools, the language
might be in a very different position today.  History has a habit of
repeating itself if its lessons are not learned.

Roger Racine

Re: GDB Woes Continued...

[Robert Dewar]

Roger said

Actually, I have an upgrade from Windows 3.1 to Windows 95, and I did buy
it in a store. I have no idea what percentage of people get new machines
vs upgrading old ones.  But new operating system versions do not come with
processor boards.

   That means you are using the old obsolete version of Win95 (the one
   that for example does not support FAT32). If you work at picking up
   fixes and addons, you can deal with some, but not all, of the differences
   between this old release and the current one.

Did you intend to send more?  Not that more is needed, but your message
ended.  Again, subject to misinterpretation (we need a more formal
language than English), I take it that you consider the Win95 version to
-not- be important.

   We think that the Win95 version is definitely useful for and important
   for educational use, and that is why we make it available. As you will
   note from Martin Carlisle's post, the folks at the Air Force Academy
   agree, and have chosen GNAT+GDB as their Ada 95 platform of choice,
   using the nice IDE (AdaGIDE) that Martin deveoped.

   Many other schools and students are using the Win95 version of GNAT
   successfully. You seem to assume that since it does not work for you,
   it does not work for anyone. That would be as misleading as the 
   assumption that because something worked for you, it worked for
   everyone else just as well!

Robert Dewar
Ada Core Technologies

Re: GDB Woes Continued...

[Jerry van Dijk]

Robert Dewar <dewar@merv.cs.nyu.edu> schreef in artikel
<dewar.886561299@merv>...

> We haven't been able to duplicate these problems so far, and
> we have run GDB on a variety of Win95 machines. One observation is
> that we are running the latest version of Win95 on pretty much all
> machines, not the broken version you can buy in stores, so perhaps
> that is one variable.

This is the real cause of the current misery: without a reproduction
scenario there is no way to find/fix the problem.

BTW I've tried both a real 'vintage 95' Win95, and the new OSR2 
that came with my new laptop last month. Gdb fails identically 
on both systems. Yet at the same time Martin tells us he does 
not see this problem in his class.

Perhaps the answer is to wait for Win98...  :-)

-- 
-- Jerry van Dijk | Leiden, Holland
-- Team Ada       | email: jdijk@acm.org

nA edisA

[Nick Roberts]

Reminiscent of the mythical setting for Dylan Thomas' "Under Milk Wood":
Llareggub.  Try reversing it!

-- 

== Nick Roberts ================================================
== Croydon, UK                       ===========================
==                                              ================
== Proprietor, ThoughtWing Software                   ==========
== Independent Software Development Consultant            ======
== Nick.Roberts@dial.pipex.com                              ====
== Voicemail & Fax +44 181-405 1124                          ===
==                                                            ==
==           I live not in myself, but I become               ==
===          Portion of that around me; and to me             ==
====         High mountains are a feeling, but the hum        ==
=======      Of human cities torture.
===========                             -- Byron [Childe Harold]


John English <je@bton.ac.uk> wrote in article
<6b8b6m$8hb@saturn.brighton.ac.uk>...
[...]
> Oh reggub, I'm showing my age again... :-)

Re: GDB Woes Continued...

[Larry Kilgallen]

In article <01bd31b4$3dac0580$6d2c5c8b@aptiva>, "Jerry van Dijk" <jvandyk@ibm.net> writes:

> BTW I've tried both a real 'vintage 95' Win95, and the new OSR2 
> that came with my new laptop last month. Gdb fails identically 
> on both systems. Yet at the same time Martin tells us he does 
> not see this problem in his class.
> 
> Perhaps the answer is to wait for Win98...  :-)

Perhaps the answer is to switch to OS/2 (to name an operating system
that runs on the same hardware).

Many people who have trouble with an automobile will switch their
next purchase to an entirely different manufacturer, being unsatisfied
with the idea of switching to a different brand from the same builder.

Larry Kilgallen

Re: GDB Woes Continued...

[Martin C. Carlisle]

In article <01bd31b4$3dac0580$6d2c5c8b@aptiva>,
Jerry van Dijk <jvandyk@ibm.net> wrote:
>BTW I've tried both a real 'vintage 95' Win95, and the new OSR2 
>that came with my new laptop last month. Gdb fails identically 
>on both systems. Yet at the same time Martin tells us he does 
>not see this problem in his class.

The interested soul should note I am running Win 95 4.00.950 B

--Martin

-- 
Martin C. Carlisle, Computer Science, US Air Force Academy
mcc@cs.usafa.af.mil, http://www.usafa.af.mil/dfcs/bios/carlisle.html
DISCLAIMER:  This content in no way reflects the opinions, standard or 
policy of the US Air Force Academy or the United States Government.