Re: Wish List item

[Miha Markic]

VCL works great with auto-resizing. Hope VB7 will have something like that.
It would simplify programing a lot.

Miha

"Klaus H. Probst" <kprobst@vbbox.com> wrote in message
news:38c80d14$1@news.devx.com...
> Hi John,
>
> > Let's see intrinsic ability for vb apps/controls/fonts to
> > resize themselves according to user's screen resolution settings. Let's
> > include Tab controls in this mix also.
> > I don't know (and have not understood) why we are expected to write
> > cumbersome routines for this OR go out and buy custom controls to
> accomplish
> > this most basic problem in windows development.
>
> I don't get this. If you don't want to write code, and you don't want to
get
> a third-party solution, how do you want to accomplish things?
>
> The best idea would be to have a *code based* control framework, much like
> the VCL, that you can expand or customize to your liking. Now that we're
> getting inheritance thrown in, that is entirely possible. Otherwise we'll
> get more monolithic binaries with tons of features we don't need and tons
of
> features missing or incorrectly implemented that can't be fixed any way
> other than by entirely replacing them with something else.
>
> . . . . . . . . . . . . . . . . . . . . . .
> Please post/reply to the
> newsgroup(s)
>
> Klaus H. Probst, MVP
> http://www.vbbox.com/
> http://www.mvps.org/ccrp/
>
>
>
>

[Dan Rhea]

"John Johnson" <john_johnson@firstdatabank.com> wrote:

This is interesting in theory but personally I don't want to pass resizing
of my windows on to anything but my own code. I have tried several resizing
programs and in most cases I find they do not give me the level of control
I want (I.E. the window is too narrow for my toolbar, Instead of hiding the
whole toolbar or removing items from one side or the other, no I want to
selectively remove the toolbar items so the more important ones remain...
I can do this in my code, but I haven't seen a resize package that can do
this... well not yet anyway).

>Let's see intrinsic ability for vb apps/controls/fonts to
>resize themselves according to user's screen resolution settings. Let's
>include Tab controls in this mix also.
>I don't know (and have not understood) why we are expected to write
>cumbersome routines for this OR go out and buy custom controls to accomplish
>this most basic problem in windows development.

[Russ Holsclaw]

>Let's see intrinsic ability for vb apps/controls/fonts to
>resize themselves according to user's screen resolution settings.

Maybe I'm just a kook, but I've always found that writing a resize routine
to be one of the more interesting and enjoyable aspects of writing a VB
program.

Having said that, I gather that there is something in VB7 (although I don't
recall just what) that is supposed to simplify resize, perhaps some sort of
new container control that works like one of the third-party tools.

I've never looked into a third-party resize tool myself, partly because I
get a kick out of writing my own resizers.

BTW, I've been told here, in no uncertain terms, that the wishbook for VB7
is firmly closed. Especially if your wish involves reversing a decision that
MS has already made.

[Phil Weber]

> BTW, I've been told here, in no uncertain terms, that the
> wishbook for VB7 is firmly closed. Especially if your wish
> involves reversing a decision that MS has already made.

Russ: If you're referring to my comments, allow me to clarify that I have no
inside information on VB.NET. My comments are based on the assumption that
Microsoft designed the .NET architecture before they started coding it.
Since the coding is obviously pretty far along, it seems unlikely that there
will be any fundamental changes to the underlying architecture at this
point, unless such changes are needed to correct serious bugs.

[Shelly Rosenfeld]

Phil Weber <pweber@devx.com> wrote in message news:397af9df@news.devx.com...
> Since the coding is obviously pretty far along, it seems unlikely that
there
> will be any fundamental changes to the underlying architecture at this
> point, unless such changes are needed to correct serious bugs.

May I take exception to your statement? Where I
come from, EVERY bug is serious. It's very sad
how some bugs are "acceptable" as they are not
"showstoppers". :(

Sheldon

[Phil Weber]

> May I take exception to your statement? Where I come
> from, EVERY bug is serious. It's very sad how some bugs
> are "acceptable" as they are not "showstoppers". :(

Sheldon: If a company decided not to ship its applications until EVERY bug
had been identified and eliminated, we would see very few products from that
company. The realities of business and the software development process
require companies to make cost/benefit analyses and decide when a product is
"good enough."
---
Phil Weber

[Shelly Rosenfeld]

That's probably why I don't have Gates' money.
I don't subscribe to this new mentality of "good
enough" - "good" means just that...

Ya see, I NEVER shipped software where I knew
a bug was unresolved.

Yeah, I know, you'd rather buy MS software than mine <g>.

Sheldon


Phil Weber <pweber@devx.com> wrote in message
news:397c4827$1@news.devx.com...
> > May I take exception to your statement? Where I come
> > from, EVERY bug is serious. It's very sad how some bugs
> > are "acceptable" as they are not "showstoppers". :(
>
> Sheldon: If a company decided not to ship its applications until EVERY bug
> had been identified and eliminated, we would see very few products from
that
> company. The realities of business and the software development process
> require companies to make cost/benefit analyses and decide when a product
is
> "good enough."
> ---
> Phil Weber
>
>

[John Hughes]

Its impossible to ship software without bugs.

What do you write your software in? Where do you deploy it to?


"Shelly Rosenfeld" <ShellyRo@worldnet.att.net> wrote in message
news:397c5962@news.devx.com...
>
> That's probably why I don't have Gates' money.
> I don't subscribe to this new mentality of "good
> enough" - "good" means just that...
>
> Ya see, I NEVER shipped software where I knew
> a bug was unresolved.
>
> Yeah, I know, you'd rather buy MS software than mine <g>.
>
> Sheldon
>
>
> Phil Weber <pweber@devx.com> wrote in message
> news:397c4827$1@news.devx.com...
> > > May I take exception to your statement? Where I come
> > > from, EVERY bug is serious. It's very sad how some bugs
> > > are "acceptable" as they are not "showstoppers". :(
> >
> > Sheldon: If a company decided not to ship its applications until EVERY
bug
> > had been identified and eliminated, we would see very few products from
> that
> > company. The realities of business and the software development process
> > require companies to make cost/benefit analyses and decide when a
product
> is
> > "good enough."
> > ---
> > Phil Weber
> >
> >
>
>

[Alan Gillott]

Let's differentiate between 10,000,000 lines of code and 10,000 lines. In
10,000 you can eliminate everything you know about and a 1 week delay won't
hurt your revenues. In 10,000,000 you have to classify bugs into levels and
draw a line between acceptable and unacceptable. I'm not going to cry over
something three pixels to the left of where it should be.
Microsoft is much tougher on released bugs than most of the companies that
write software for Windows and much tougher than most of the Unix OS
suppliers who are pretty lax.
The only exception to this is IBM who have software writing and testing down
to fine art.

Shelly Rosenfeld <ShellyRo@worldnet.att.net> wrote in message
news:397c5962@news.devx.com...
>
> That's probably why I don't have Gates' money.
> I don't subscribe to this new mentality of "good
> enough" - "good" means just that...
>
> Ya see, I NEVER shipped software where I knew
> a bug was unresolved.
>
> Yeah, I know, you'd rather buy MS software than mine <g>.
>
> Sheldon
>
>
> Phil Weber <pweber@devx.com> wrote in message
> news:397c4827$1@news.devx.com...
> > > May I take exception to your statement? Where I come
> > > from, EVERY bug is serious. It's very sad how some bugs
> > > are "acceptable" as they are not "showstoppers". :(
> >
> > Sheldon: If a company decided not to ship its applications until EVERY
bug
> > had been identified and eliminated, we would see very few products from
> that
> > company. The realities of business and the software development process
> > require companies to make cost/benefit analyses and decide when a
product
> is
> > "good enough."
> > ---
> > Phil Weber
> >
> >
>
>

[Shelly Rosenfeld]

John Hughes <hughesj@netcomuk.co.uk> wrote in message
news:397c5c19@news.devx.com...
> Its impossible to ship software without bugs.

"impossible" is a strong word, but let's say that I
agree with you.
My point is not "no bugs", rather "no known bugs".

> What do you write your software in? Where do you deploy it to?

Sorry, wrong question. It's not the tool/language/platform
something was written in; it's a question of how much
testing was put in.
I was taught to test by attempting to break the
software.
Clicking a button when a textbox is enabled works
nice - did anyone try the click when it's not
enabled???

And that sir, is the nature of our profession. When
you cannot break the software, it is ready for
release.

Oh yeah - I write in VB. I've got manufacturing clients,
a school, a large garage operation etc.

I don't believe in this bug stuff, and never charged to
fix one when it surfaced.

Sheldon

[Shelly Rosenfeld]

It must be very comforting to believe what you do,
but I don't believe that the 747 aircraft has 10k
lines.

BUT! It better not kick you out to the system
at 30k feet!

Sheldon

P.S. ANY reason off the top of your head, why IBM
has testing down to a science, whereas MS
does not?
I'd love to hear it...

Alan Gillott <agillott@compuserve.com> wrote in message
news:397c5c3f@news.devx.com...
> Let's differentiate between 10,000,000 lines of code and 10,000 lines. In
> 10,000 you can eliminate everything you know about and a 1 week delay
won't
> hurt your revenues. In 10,000,000 you have to classify bugs into levels
and
> draw a line between acceptable and unacceptable. I'm not going to cry over
> something three pixels to the left of where it should be.
> Microsoft is much tougher on released bugs than most of the companies that
> write software for Windows and much tougher than most of the Unix OS
> suppliers who are pretty lax.
> The only exception to this is IBM who have software writing and testing
down
> to fine art.
>
> Shelly Rosenfeld <ShellyRo@worldnet.att.net> wrote in message
> news:397c5962@news.devx.com...
> >
> > That's probably why I don't have Gates' money.
> > I don't subscribe to this new mentality of "good
> > enough" - "good" means just that...
> >
> > Ya see, I NEVER shipped software where I knew
> > a bug was unresolved.
> >
> > Yeah, I know, you'd rather buy MS software than mine <g>.
> >
> > Sheldon
> >
> >
> > Phil Weber <pweber@devx.com> wrote in message
> > news:397c4827$1@news.devx.com...
> > > > May I take exception to your statement? Where I come
> > > > from, EVERY bug is serious. It's very sad how some bugs
> > > > are "acceptable" as they are not "showstoppers". :(
> > >
> > > Sheldon: If a company decided not to ship its applications until EVERY
> bug
> > > had been identified and eliminated, we would see very few products
from
> > that
> > > company. The realities of business and the software development
process
> > > require companies to make cost/benefit analyses and decide when a
> product
> > is
> > > "good enough."
> > > ---
> > > Phil Weber
> > >
> > >
> >
> >
>
>

[Keith Franklin, MCSD]

Shelly,

What is your definition of bugs?

When Win2k there was a big bruhaha because of the so called 73,000 issues in
the Win2k issues database.

Does that mean that all those bugs cause a blow up of a program.

I know of one that is a good example that it is an issue but does no harm.

In COM+ Services on a Application if I write click sometimes the context
menu is for the previously clicked on node. What happens...Nothing...So what
do I have to do I click on the node again then right click and the proper
context menu is shown.

An issue...Should it have stopped the shipment of Win2k....No

Later


--
Keith Franklin, MCSD
Senior Solution Developer Achitect
ka_franklin@empowered.com

Empowered Software Solutions, Inc.
Microsoft Certified Solution Provider
www.empowered.com

"Shelly Rosenfeld" <ShellyRo@worldnet.att.net> wrote in message
news:397c6b26@news.devx.com...
>
> John Hughes <hughesj@netcomuk.co.uk> wrote in message
> news:397c5c19@news.devx.com...
> > Its impossible to ship software without bugs.
>
> "impossible" is a strong word, but let's say that I
> agree with you.
> My point is not "no bugs", rather "no known bugs".
>
> > What do you write your software in? Where do you deploy it to?
>
> Sorry, wrong question. It's not the tool/language/platform
> something was written in; it's a question of how much
> testing was put in.
> I was taught to test by attempting to break the
> software.
> Clicking a button when a textbox is enabled works
> nice - did anyone try the click when it's not
> enabled???
>
> And that sir, is the nature of our profession. When
> you cannot break the software, it is ready for
> release.
>
> Oh yeah - I write in VB. I've got manufacturing clients,
> a school, a large garage operation etc.
>
> I don't believe in this bug stuff, and never charged to
> fix one when it surfaced.
>
> Sheldon
>
>

[Keith Franklin, MCSD]

Huh,

Dont kid youself about IBM...I used to be a mainframe systems programmer and
we did hot fixes all of the time (monthly)...Not to mention IBM sometimes
even had us do ....I forget what they are called but the techiniue was to
actually change the OS code that was running on the machine. Think about
that they knew an instruction was at x address and we would run a utility
that would replace that instruction with another...

Later

--
Keith Franklin, MCSD
Senior Solution Developer Achitect
ka_franklin@empowered.com

Empowered Software Solutions, Inc.
Microsoft Certified Solution Provider
www.empowered.com
"Alan Gillott" <agillott@compuserve.com> wrote in message
news:397c5c3f@news.devx.com...
> Let's differentiate between 10,000,000 lines of code and 10,000 lines. In
> 10,000 you can eliminate everything you know about and a 1 week delay
won't
> hurt your revenues. In 10,000,000 you have to classify bugs into levels
and
> draw a line between acceptable and unacceptable. I'm not going to cry over
> something three pixels to the left of where it should be.
> Microsoft is much tougher on released bugs than most of the companies that
> write software for Windows and much tougher than most of the Unix OS
> suppliers who are pretty lax.
> The only exception to this is IBM who have software writing and testing
down
> to fine art.
>
> Shelly Rosenfeld <ShellyRo@worldnet.att.net> wrote in message
> news:397c5962@news.devx.com...
> >
> > That's probably why I don't have Gates' money.
> > I don't subscribe to this new mentality of "good
> > enough" - "good" means just that...
> >
> > Ya see, I NEVER shipped software where I knew
> > a bug was unresolved.
> >
> > Yeah, I know, you'd rather buy MS software than mine <g>.
> >
> > Sheldon
> >
> >
> > Phil Weber <pweber@devx.com> wrote in message
> > news:397c4827$1@news.devx.com...
> > > > May I take exception to your statement? Where I come
> > > > from, EVERY bug is serious. It's very sad how some bugs
> > > > are "acceptable" as they are not "showstoppers". :(
> > >
> > > Sheldon: If a company decided not to ship its applications until EVERY
> bug
> > > had been identified and eliminated, we would see very few products
from
> > that
> > > company. The realities of business and the software development
process
> > > require companies to make cost/benefit analyses and decide when a
> product
> > is
> > > "good enough."
> > > ---
> > > Phil Weber
> > >
> > >
> >
> >
>
>

[Shelly Rosenfeld]

I remember this too - ****, I was a computer
operator (I even learned to get the CPU addresses
from the lights!).

They may be buggy, but it's PUBLIC knowledge,
and everyone is warned if the fix is not in within
a short (2 weeks?) time span.

Look, I dislike IBM just like the next guy. I watched
them leave all that money on the table with their
insistence of pursuing a proprietary h/w & s/w
platform.

But they would come clean with their (OUR) problems...

Sheldon



Keith Franklin, MCSD <ka_franklin@empowered.com> wrote in message
news:397c711f$1@news.devx.com...
> Huh,
>
> Dont kid youself about IBM...I used to be a mainframe systems programmer
and
> we did hot fixes all of the time (monthly)...Not to mention IBM sometimes
> even had us do ....I forget what they are called but the techiniue was to
> actually change the OS code that was running on the machine. Think about
> that they knew an instruction was at x address and we would run a utility
> that would replace that instruction with another...
>
> Later
>
> --
> Keith Franklin, MCSD
> Senior Solution Developer Achitect
> ka_franklin@empowered.com
>
> Empowered Software Solutions, Inc.
> Microsoft Certified Solution Provider
> www.empowered.com
> "Alan Gillott" <agillott@compuserve.com> wrote in message
> news:397c5c3f@news.devx.com...
> > Let's differentiate between 10,000,000 lines of code and 10,000 lines.
In
> > 10,000 you can eliminate everything you know about and a 1 week delay
> won't
> > hurt your revenues. In 10,000,000 you have to classify bugs into levels
> and
> > draw a line between acceptable and unacceptable. I'm not going to cry
over
> > something three pixels to the left of where it should be.
> > Microsoft is much tougher on released bugs than most of the companies
that
> > write software for Windows and much tougher than most of the Unix OS
> > suppliers who are pretty lax.
> > The only exception to this is IBM who have software writing and testing
> down
> > to fine art.
> >
> > Shelly Rosenfeld <ShellyRo@worldnet.att.net> wrote in message
> > news:397c5962@news.devx.com...
> > >
> > > That's probably why I don't have Gates' money.
> > > I don't subscribe to this new mentality of "good
> > > enough" - "good" means just that...
> > >
> > > Ya see, I NEVER shipped software where I knew
> > > a bug was unresolved.
> > >
> > > Yeah, I know, you'd rather buy MS software than mine <g>.
> > >
> > > Sheldon
> > >
> > >
> > > Phil Weber <pweber@devx.com> wrote in message
> > > news:397c4827$1@news.devx.com...
> > > > > May I take exception to your statement? Where I come
> > > > > from, EVERY bug is serious. It's very sad how some bugs
> > > > > are "acceptable" as they are not "showstoppers". :(
> > > >
> > > > Sheldon: If a company decided not to ship its applications until
EVERY
> > bug
> > > > had been identified and eliminated, we would see very few products
> from
> > > that
> > > > company. The realities of business and the software development
> process
> > > > require companies to make cost/benefit analyses and decide when a
> > product
> > > is
> > > > "good enough."
> > > > ---
> > > > Phil Weber
> > > >
> > > >
> > >
> > >
> >
> >
>
>

[Shelly Rosenfeld]

Ya know, you have a point there.

If there is no data corruption, and all can be
accomplished, albeit through a fudge/kludge,
that's fine.

BUT! Do you the developer, or your customer
know ALL 73k "anomalies"?

With us knowing them, the onus is on us, and
not MS...

Sheldon



Keith Franklin, MCSD <ka_franklin@empowered.com> wrote in message
news:397c7069$1@news.devx.com...
> Shelly,
>
> What is your definition of bugs?
>
> When Win2k there was a big bruhaha because of the so called 73,000 issues
in
> the Win2k issues database.
>
> Does that mean that all those bugs cause a blow up of a program.
>
> I know of one that is a good example that it is an issue but does no harm.
>
> In COM+ Services on a Application if I write click sometimes the context
> menu is for the previously clicked on node. What happens...Nothing...So
what
> do I have to do I click on the node again then right click and the proper
> context menu is shown.
>
> An issue...Should it have stopped the shipment of Win2k....No
>
> Later
>
>
> --
> Keith Franklin, MCSD
> Senior Solution Developer Achitect
> ka_franklin@empowered.com
>
> Empowered Software Solutions, Inc.
> Microsoft Certified Solution Provider
> www.empowered.com
>
> "Shelly Rosenfeld" <ShellyRo@worldnet.att.net> wrote in message
> news:397c6b26@news.devx.com...
> >
> > John Hughes <hughesj@netcomuk.co.uk> wrote in message
> > news:397c5c19@news.devx.com...
> > > Its impossible to ship software without bugs.
> >
> > "impossible" is a strong word, but let's say that I
> > agree with you.
> > My point is not "no bugs", rather "no known bugs".
> >
> > > What do you write your software in? Where do you deploy it to?
> >
> > Sorry, wrong question. It's not the tool/language/platform
> > something was written in; it's a question of how much
> > testing was put in.
> > I was taught to test by attempting to break the
> > software.
> > Clicking a button when a textbox is enabled works
> > nice - did anyone try the click when it's not
> > enabled???
> >
> > And that sir, is the nature of our profession. When
> > you cannot break the software, it is ready for
> > release.
> >
> > Oh yeah - I write in VB. I've got manufacturing clients,
> > a school, a large garage operation etc.
> >
> > I don't believe in this bug stuff, and never charged to
> > fix one when it surfaced.
> >
> > Sheldon
> >
> >
>
>

[Dave Rothgery]

"Shelly Rosenfeld" <ShellyRo@worldnet.att.net> wrote:
>
> John Hughes <hughesj@netcomuk.co.uk> wrote:
> > What do you write your software in? Where do you deploy it to?
>
> Sorry, wrong question. It's not the tool/language/platform
> something was written in; it's a question of how much
> testing was put in.

It's more a question of a good design in the first place, IMO.

A poor design will inherently be buggy, because it's hard to make
it work. Bugs will be hard to track down, fixes will often be
incomplete, and problems will be recurring, because modules weren't
set up so that code was shared when it made sense.

Whereas if things are set up right, you won't see code in various
parts of the same system trying to do the same thing a dozen
different ways, all of them forgetting to check for exceptional
conditions. You'll be able to fix problems once, and logical errors
will have been fixed at design time, not in maintence, where your
fix has to go through a few weeks of testing before it goes live.

Can you tell I'm working on maintence for a fairly large web-based
project right now?

--
Dave Rothgery
drothgery@myrealbox.com

[Keith Franklin, MCSD]

Oh ...

I dont hate IBM ... It was they like everyone else has bugs/issues with
their code...

It is just like the Delphi people (and others) coming in here screaming
about Service packs to fix bugs...Or that Microsoft shouldnt put out a new
version of XXXX until the previous version has no bugs...When "insert name
here" does the same thing...What I think that Borland/Imprise/Whatever they
are called today has put out 3 versions of Delphi in 3 years and numerous
update packs...

Later


"Shelly Rosenfeld" <ShellyRo@worldnet.att.net> wrote in message
news:397c74a4@news.devx.com...
>
> I remember this too - ****, I was a computer
> operator (I even learned to get the CPU addresses
> from the lights!).
>
> They may be buggy, but it's PUBLIC knowledge,
> and everyone is warned if the fix is not in within
> a short (2 weeks?) time span.
>
> Look, I dislike IBM just like the next guy. I watched
> them leave all that money on the table with their
> insistence of pursuing a proprietary h/w & s/w
> platform.
>
> But they would come clean with their (OUR) problems...
>
> Sheldon
>
>
>
> Keith Franklin, MCSD <ka_franklin@empowered.com> wrote in message
> news:397c711f$1@news.devx.com...
> > Huh,
> >
> > Dont kid youself about IBM...I used to be a mainframe systems programmer
> and
> > we did hot fixes all of the time (monthly)...Not to mention IBM
sometimes
> > even had us do ....I forget what they are called but the techiniue was
to
> > actually change the OS code that was running on the machine. Think about
> > that they knew an instruction was at x address and we would run a
utility
> > that would replace that instruction with another...
> >
> > Later
> >
> > --
> > Keith Franklin, MCSD
> > Senior Solution Developer Achitect
> > ka_franklin@empowered.com
> >
> > Empowered Software Solutions, Inc.
> > Microsoft Certified Solution Provider
> > www.empowered.com
> > "Alan Gillott" <agillott@compuserve.com> wrote in message
> > news:397c5c3f@news.devx.com...
> > > Let's differentiate between 10,000,000 lines of code and 10,000 lines.
> In
> > > 10,000 you can eliminate everything you know about and a 1 week delay
> > won't
> > > hurt your revenues. In 10,000,000 you have to classify bugs into
levels
> > and
> > > draw a line between acceptable and unacceptable. I'm not going to cry
> over
> > > something three pixels to the left of where it should be.
> > > Microsoft is much tougher on released bugs than most of the companies
> that
> > > write software for Windows and much tougher than most of the Unix OS
> > > suppliers who are pretty lax.
> > > The only exception to this is IBM who have software writing and
testing
> > down
> > > to fine art.
> > >
> > > Shelly Rosenfeld <ShellyRo@worldnet.att.net> wrote in message
> > > news:397c5962@news.devx.com...
> > > >
> > > > That's probably why I don't have Gates' money.
> > > > I don't subscribe to this new mentality of "good
> > > > enough" - "good" means just that...
> > > >
> > > > Ya see, I NEVER shipped software where I knew
> > > > a bug was unresolved.
> > > >
> > > > Yeah, I know, you'd rather buy MS software than mine <g>.
> > > >
> > > > Sheldon
> > > >
> > > >
> > > > Phil Weber <pweber@devx.com> wrote in message
> > > > news:397c4827$1@news.devx.com...
> > > > > > May I take exception to your statement? Where I come
> > > > > > from, EVERY bug is serious. It's very sad how some bugs
> > > > > > are "acceptable" as they are not "showstoppers". :(
> > > > >
> > > > > Sheldon: If a company decided not to ship its applications until
> EVERY
> > > bug
> > > > > had been identified and eliminated, we would see very few products
> > from
> > > > that
> > > > > company. The realities of business and the software development
> > process
> > > > > require companies to make cost/benefit analyses and decide when a
> > > product
> > > > is
> > > > > "good enough."
> > > > > ---
> > > > > Phil Weber
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

[Alan Gillott]

Actually 747's have bugs. I flew a early release /400 and it was riddled
with the things: the APU wouldn't work, most of the lights and air didn't
work etc. etc. Actually if you read the Boeing's & the FAA maintenance
notices, I think you'd guess that a 747 wouldn't fly any more than Windows
will boot.
PS.
747's have mice too, but these ones eat the hardware...

"Shelly Rosenfeld" <ShellyRo@worldnet.att.net> wrote in message
news:397c6c35@news.devx.com...
>
> It must be very comforting to believe what you do,
> but I don't believe that the 747 aircraft has 10k
> lines.
>
> BUT! It better not kick you out to the system
> at 30k feet!
>
> Sheldon
>
> P.S. ANY reason off the top of your head, why IBM
> has testing down to a science, whereas MS
> does not?
> I'd love to hear it...
>
> Alan Gillott <agillott@compuserve.com> wrote in message
> news:397c5c3f@news.devx.com...
> > Let's differentiate between 10,000,000 lines of code and 10,000 lines.
In
> > 10,000 you can eliminate everything you know about and a 1 week delay
> won't
> > hurt your revenues. In 10,000,000 you have to classify bugs into levels
> and
> > draw a line between acceptable and unacceptable. I'm not going to cry
over
> > something three pixels to the left of where it should be.
> > Microsoft is much tougher on released bugs than most of the companies
that
> > write software for Windows and much tougher than most of the Unix OS
> > suppliers who are pretty lax.
> > The only exception to this is IBM who have software writing and testing
> down
> > to fine art.
> >
> > Shelly Rosenfeld <ShellyRo@worldnet.att.net> wrote in message
> > news:397c5962@news.devx.com...
> > >
> > > That's probably why I don't have Gates' money.
> > > I don't subscribe to this new mentality of "good
> > > enough" - "good" means just that...
> > >
> > > Ya see, I NEVER shipped software where I knew
> > > a bug was unresolved.
> > >
> > > Yeah, I know, you'd rather buy MS software than mine <g>.
> > >
> > > Sheldon
> > >
> > >
> > > Phil Weber <pweber@devx.com> wrote in message
> > > news:397c4827$1@news.devx.com...
> > > > > May I take exception to your statement? Where I come
> > > > > from, EVERY bug is serious. It's very sad how some bugs
> > > > > are "acceptable" as they are not "showstoppers". :(
> > > >
> > > > Sheldon: If a company decided not to ship its applications until
EVERY
> > bug
> > > > had been identified and eliminated, we would see very few products
> from
> > > that
> > > > company. The realities of business and the software development
> process
> > > > require companies to make cost/benefit analyses and decide when a
> > product
> > > is
> > > > "good enough."
> > > > ---
> > > > Phil Weber
> > > >
> > > >
> > >
> > >
> >
> >
>
>

[Shelly Rosenfeld]

Alan Gillott <agillott@compuserve.com> wrote in message
news:397c89ed$3@news.devx.com...
> Actually 747's have bugs. I flew a early release /400 and it was riddled
> with the things:

But you're still here...

> the APU wouldn't work, most of the lights and air didn't
> work etc. etc.

Which is why it was not released to production at that
point in time...

Sheldon

[Alan Gillott]

Actually, this was a post production model. Not a beta, gamma, delta ore any
other but a Gold CD production 747: it was still riddled with bugs.

"Shelly Rosenfeld" <ShellyRo@worldnet.att.net> wrote in message
news:397c9187$1@news.devx.com...
>
> Alan Gillott <agillott@compuserve.com> wrote in message
> news:397c89ed$3@news.devx.com...
> > Actually 747's have bugs. I flew a early release /400 and it was riddled
> > with the things:
>
> But you're still here...
>
> > the APU wouldn't work, most of the lights and air didn't
> > work etc. etc.
>
> Which is why it was not released to production at that
> point in time...
>
> Sheldon
>
>

[Russell P. Holsclaw]

> Dont kid youself about IBM...I used to be a mainframe systems programmer
and
> we did hot fixes all of the time (monthly)...Not to mention IBM sometimes
> even had us do ....I forget what they are called but the techiniue was to
> actually change the OS code that was running on the machine. Think about
> that they knew an instruction was at x address and we would run a utility
> that would replace that instruction with another...

That was called SUPERZAP. It didn't actually change the running code loaded
into
memory, but did alter the binary load module on disk, which could be
reloaded. Kinda
like patching a DLL in Windows, although MS never developed a utility to do
them,
although such programs are common in the Unix world. (Superzap dates to
about
'65 or '66).

I worked for most of my IBM career with the system that served as the
central repository
for such fixes. It was called RETAIN (REmote Technical Assistance
Information Network).

Yes, IBM had plenty of bugs, if it didn't, I might not have had a career
there (almost 27 years). :-)

Having said that, I will assert, though, that IBM was much more open and
forthright about its bugs
than most other companies I see today, including you-know-who. We provided
on-site
technical support for many years in the mainframe world (I believe they
still do). Many of those
SUPERZAP fixes were originally conceived and written by people in the field
who were working
with customers.

Nearly every bug report (called APARs) was made visible to customers via
RETAIN, except for
detailed information about security/integrity exposures that had been
discovered. Those were opened
up, too, when a fix was made available.

A lot of fixes were distributed in Superzap form because there was no source
code in the field from which
to compile a fixed module, although there were source-code listings on
microfiche, which is what
we consulted to come up with the 'ZAPs.

IBM is (or was) also very good about carefully documenting programming
interfaces, so you
could code a program from scratch without having to find out now the system
works by trial
and error, something which I find I have to do all too often with MS
products.

IBM is also downright masterful at the art of adding features to a platform
without breaking old code.
MS could learn a lot by studying their techniques, if they wanted to. The
difference is that, in the
heyday of the mainframe, application software (as distinguished from the
"platform") was not
written by IBM, but only by _customers_, who were not viewed as competitors.
Now the whole
set of incentives has shifted, and Microsoft releases details about both
bugs and interfaces with
a certain amount of (somewhat understandable) reluctance. It's a conflict of
interest.

The court-ordered breakup of MS is designed to restore that kind of
beneficial incentive structure to the
software industry. Whether it actually works is anybody's guess. In the
end, it may be "paradise lost".

[norm]

"Phil Weber" <pweber@devx.com> wrote:
> > May I take exception to your statement? Where I come
> > from, EVERY bug is serious. It's very sad how some bugs
> > are "acceptable" as they are not "showstoppers". :(
>
>Sheldon: If a company decided not to ship its applications until EVERY bug
>had been identified and eliminated, we would see very few products from
that
>company. The realities of business and the software development process
>require companies to make cost/benefit analyses and decide when a product
is
>"good enough."
>---
>Phil Weber
>
>Phil: When I purchased Windows 98 SE I was really POd that my computer
frequently locks when I shut it down. Then I find a zillion messages in
the MS knowledgebase recommending another zillion checks. Give me a break.
Didn't Microsoft ever shut down their computers when they were developing
Oin 98 SE. There is absolutely no excuse for these types of bugs. Microsoft
does a lousy job of quality control. VB6 was so bad when it was first released
I took it off my computer. Then there is USB.

In spite of this I still truly love Microsoft, however, I will never don't
understand why they don't take a few more months and spend 1% of Bill's billions
to at least work off the major bugs. It seems to me that they just don't
care.