By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,680 Members | 1,500 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,680 IT Pros & Developers. It's quick & easy.

Microsoft Discouraging .Net use?

P: n/a
Yet another hotfix alert (http://www.kbalertz.com/Feedback_823535.aspx) that
states "To resolve this problem immediately, contact Microsoft Product
Support Services to obtain the hotfix."

Whatever happened to automatic updates? Doesn't Microsoft know that
developers are busy people.....too busy to be stopped by this type of crap
every time Microsoft is alerted to something they missed in the software by
another developer (note: Microsoft rarely finds their own mistakes) ?

If it is a question of stopping unauthorized use of pirated .Net versions,
just have the upgrade functionality pass in the license info when it
requests a patch. Info no good? Then, no patch.

Get with the program Microsoft! You're supposed to make things easier, not
waste our time waiting on the phone for your off-shore "help".

When freeware routinely updates itself without user intervention, and for a
company that pushes things like webservices, this is really pathetic.

Jim Hubbard

Jul 21 '05 #1
Share this Question
Share on Google+
29 Replies


P: n/a
Jim Hubbard wrote:
Yet another hotfix alert (http://www.kbalertz.com/Feedback_823535.aspx) that
states "To resolve this problem immediately, contact Microsoft Product
Support Services to obtain the hotfix."
I've seen this before in other areas, like SQL server hotpatches.

In effect, they are saying that it's not totally QC'd and tested widely,
and it addresses specific needs -- but, if it's important to *you*, we
will make it available.


Whatever happened to automatic updates? Doesn't Microsoft know that
developers are busy people.....too busy to be stopped by this type of crap
every time Microsoft is alerted to something they missed in the software by
another developer (note: Microsoft rarely finds their own mistakes) ?

If it is a question of stopping unauthorized use of pirated .Net versions,
just have the upgrade functionality pass in the license info when it
requests a patch. Info no good? Then, no patch.

Get with the program Microsoft! You're supposed to make things easier, not
waste our time waiting on the phone for your off-shore "help".

When freeware routinely updates itself without user intervention, and for a
company that pushes things like webservices, this is really pathetic.

Jim Hubbard

Jul 21 '05 #2

P: n/a

"Moe Green" <mo*@vegas.west> wrote in message
news:33*************@individual.net...
Jim Hubbard wrote:
Yet another hotfix alert (http://www.kbalertz.com/Feedback_823535.aspx)
that states "To resolve this problem immediately, contact Microsoft
Product Support Services to obtain the hotfix."


I've seen this before in other areas, like SQL server hotpatches.

In effect, they are saying that it's not totally QC'd and tested widely,
and it addresses specific needs -- but, if it's important to *you*, we
will make it available.


While I understand what you are saying, I say if it's broken it's important
to all developers - so let us get the danged hotfixes automatically.

If you look at the .Net hotfixes on KB Alrtz
(http://www.kbalertz.com/sresults.asp...2&stec=3&pNo=1)
that deal specifically with .Net Framework 1.1 issues, you will see that
there are a LOT of them.

Do you need all of these fixes today or for your current project? Probably
not. But, how would you know - unless you subscribe to KB Alertz and call
Microsoft several times a week to keep your system up to date.

And what about all of the "FIXES" you haven't called Microsoft for? Making
customers wait until something that is supposed to work fails, and then
hoping they will find the proper Microsoft release and CALL Microsoft for a
patch is NOT the way to run a serious business.

When you are the largest provider of programming software, does that mean
that you have a right to treat your customers like they don't really matter?

We all know Microsoft is not a monopoly (in the strictest sense of the
word), but they sure act like it when it comes to customer service.

Automatic updates are very important to what few fixes will be released
after version 2.0 is released. Microsoft, like most companies, will focus
its efforts and resources on the newest version of the framework - leaving
those calling for a 1.1 "fix" on the line even longer.

And, what programmer knows what s/he will be called on next week to code?
Therefore, it is a requirement of the job to have a coding system (including
the programming software) that is ready to assist you in handling any coding
job that is placed on your plate. Only self-updating software can give you
that.

I sincerely hope that this is not an indication of the level of commitment
that Microsoft is placing on the .Net platform. Hopefully they will not be
as lax with version 2.0. But, then again........where's any indication that
the current level of commitment(?) will not continue or (God forbid) worsen?

Jim Hubbard
Jul 21 '05 #3

P: n/a
"Jim Hubbard" <re***@groups.please> wrote in message
news:A4********************@giganews.com...

"Moe Green" <mo*@vegas.west> wrote in message
news:33*************@individual.net...
Jim Hubbard wrote:
Yet another hotfix alert (http://www.kbalertz.com/Feedback_823535.aspx)
that states "To resolve this problem immediately, contact Microsoft
Product Support Services to obtain the hotfix."


I've seen this before in other areas, like SQL server hotpatches.

In effect, they are saying that it's not totally QC'd and tested widely,
and it addresses specific needs -- but, if it's important to *you*, we
will make it available.


While I understand what you are saying, I say if it's broken it's
important to all developers - so let us get the danged hotfixes
automatically.


So, Jim, you want to automatically get these fixes before they're fully
tested, or afterwards?

John Saunders
Jul 21 '05 #4

P: n/a
Some of these fixes for VS.NET 2003 are more than one year old and for
VS.NET 2002, it's more than two years. With these kind of delays, I don't
think it's only a question of taking sufficient time for testing.

Also, if some of these fixes were relevant about the .NET Framework itself
and may have been corrected with the SP1 for the .NET Framework; many other
are clearly affecting only the Visual Studio itself, are around for more
than 6 months, 1 year or even 2 years and have never been included into some
sort of service pack or being publicly available for downloading somewhere
or even simply to be grouped into an easy to consult information page. Not
only they are not easy to get but they are also very hard to find and even
harder to be analysed and evaluated.

S. L.

"John Saunders" <johnwsaundersiii at hotmail.com> wrote in message
news:et**************@tk2msftngp13.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:A4********************@giganews.com...

"Moe Green" <mo*@vegas.west> wrote in message
news:33*************@individual.net...
Jim Hubbard wrote:
Yet another hotfix alert (http://www.kbalertz.com/Feedback_823535.aspx)
that states "To resolve this problem immediately, contact Microsoft
Product Support Services to obtain the hotfix."

I've seen this before in other areas, like SQL server hotpatches.

In effect, they are saying that it's not totally QC'd and tested widely,
and it addresses specific needs -- but, if it's important to *you*, we
will make it available.


While I understand what you are saying, I say if it's broken it's
important to all developers - so let us get the danged hotfixes
automatically.


So, Jim, you want to automatically get these fixes before they're fully
tested, or afterwards?

John Saunders

Jul 21 '05 #5

P: n/a
What he said....

Jim Hubbard

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:uc**************@TK2MSFTNGP11.phx.gbl...
Some of these fixes for VS.NET 2003 are more than one year old and for
VS.NET 2002, it's more than two years. With these kind of delays, I don't
think it's only a question of taking sufficient time for testing.

Also, if some of these fixes were relevant about the .NET Framework itself
and may have been corrected with the SP1 for the .NET Framework; many
other are clearly affecting only the Visual Studio itself, are around for
more than 6 months, 1 year or even 2 years and have never been included
into some sort of service pack or being publicly available for downloading
somewhere or even simply to be grouped into an easy to consult information
page. Not only they are not easy to get but they are also very hard to
find and even harder to be analysed and evaluated.

S. L.

"John Saunders" <johnwsaundersiii at hotmail.com> wrote in message
news:et**************@tk2msftngp13.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:A4********************@giganews.com...

"Moe Green" <mo*@vegas.west> wrote in message
news:33*************@individual.net...
Jim Hubbard wrote:
> Yet another hotfix alert
> (http://www.kbalertz.com/Feedback_823535.aspx) that states "To resolve
> this problem immediately, contact Microsoft Product Support Services
> to obtain the hotfix."

I've seen this before in other areas, like SQL server hotpatches.

In effect, they are saying that it's not totally QC'd and tested
widely, and it addresses specific needs -- but, if it's important to
*you*, we will make it available.

While I understand what you are saying, I say if it's broken it's
important to all developers - so let us get the danged hotfixes
automatically.


So, Jim, you want to automatically get these fixes before they're fully
tested, or afterwards?

John Saunders


Jul 21 '05 #6

P: n/a
"Jim Hubbard" <re***@groups.please> wrote in message
news:Fd********************@giganews.com...
What he said....


Ok, but you were talking about automatic distribution, and didn't answer my
question. There's got to be some (tested) package to be automatically
distributed.

BTW, passage of time does not imply that the fix has been tested - as a
service pack. The fact that the individual hotfixes may have been tested
does not in any way imply that they will work if packaged together with
other fixes. Also, a service pack will get testing on multiple OS versions
and in many different situations. It's a lot more testing than just testing
an individual fix.

John Saunders
Jul 21 '05 #7

P: n/a
Microsoft writes all of the operating systems you mention. Microsoft writes
the coding tools we are talking about. Microsoft writes the "hotfixes".

Shouldn't Microsoft know what the "hotfixes" will affect? If you have all
of the source code, isn't it incumbent on YOU to do the testing of your
latest patches?

That has always been the case in every software shop I have worked in. We
wrote the code. We made the mistakes. We cleaned them up.

With $50 BILLION in cash reserves and investing over $400M in Indian
programmers at once.....don't you think Microsoft should know it's own
code.....or at least be able to test it's own software?

Microsoft cannot, obviously, guarantee the hotfixes to work with all 3rd
party software. But, they don't have to.....they just need to make sure
that hotfixes don't break their codebase and alert the programmers to the
affected modules so the programmers can change their code if needed.

And, yes.....I do think that programmers paying $2500 for a year's
subscription are entitled to tested hotfixes.

Jim Hubbard

"John Saunders" <johnwsaundersiii at hotmail.com> wrote in message
news:u3**************@TK2MSFTNGP14.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:Fd********************@giganews.com...
What he said....


Ok, but you were talking about automatic distribution, and didn't answer
my question. There's got to be some (tested) package to be automatically
distributed.

BTW, passage of time does not imply that the fix has been tested - as a
service pack. The fact that the individual hotfixes may have been tested
does not in any way imply that they will work if packaged together with
other fixes. Also, a service pack will get testing on multiple OS versions
and in many different situations. It's a lot more testing than just
testing an individual fix.

John Saunders

Jul 21 '05 #8

P: n/a
"Jim Hubbard" <re***@groups.please> wrote in message
news:jN********************@giganews.com...
Microsoft writes all of the operating systems you mention. Microsoft
writes the coding tools we are talking about. Microsoft writes the
"hotfixes".

Shouldn't Microsoft know what the "hotfixes" will affect? If you have all
of the source code, isn't it incumbent on YOU to do the testing of your
latest patches?
Yes. That's the testing they do on a service pack. The testing that they
don't do on a hot fix.
That has always been the case in every software shop I have worked in. We
wrote the code. We made the mistakes. We cleaned them up.

With $50 BILLION in cash reserves and investing over $400M in Indian
programmers at once.....don't you think Microsoft should know it's own
code.....or at least be able to test it's own software?
No, I don't.

Besides, they not only have to know their own code, they have to know all
the crazy things their customers will do with their code. And Microsoft has
a rather large number of customers doing crazy things.
Microsoft cannot, obviously, guarantee the hotfixes to work with all 3rd
party software. But, they don't have to.....they just need to make sure
that hotfixes don't break their codebase and alert the programmers to the
affected modules so the programmers can change their code if needed.
Few of the hotfixes break existing code (except to the extent that the code
may depend on the bug being fixed).

This will absolutely guarantee that the hotfixes will cause random problems
on random customers' systems, because they were not all tested together, and
weren't tested in that customer's configuration, and because the customer
didn't get a chance to go through a proper test cycle.
And, yes.....I do think that programmers paying $2500 for a year's
subscription are entitled to tested hotfixes.


Again, Jim, it is my understanding that the hot fixes _are_ tested. They are
tested individually, not in all permutations. A Service Pack takes a number
of hot fixes and puts them together in a single package which can be
thoroughly tested. The fixes in a Service Pack can be tested as a group, and
can be tested in many different environments, and can then be released to
customers for Beta testing. How long was the Beta period of XP SP2?

John Saunders
Jul 21 '05 #9

P: n/a

"John Saunders" <johnwsaundersiii at hotmail.com> wrote in message
news:Oj*************@TK2MSFTNGP11.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:jN********************@giganews.com...
< snip >
That has always been the case in every software shop I have worked in.
We wrote the code. We made the mistakes. We cleaned them up.

With $50 BILLION in cash reserves and investing over $400M in Indian
programmers at once.....don't you think Microsoft should know it's own
code.....or at least be able to test it's own software?


No, I don't.


Why not?

Besides, they not only have to know their own code, they have to know all
the crazy things their customers will do with their code. And Microsoft
has a rather large number of customers doing crazy things.
Microsoft cannot, obviously, guarantee the hotfixes to work with all 3rd
party software. But, they don't have to.....they just need to make sure
that hotfixes don't break their codebase and alert the programmers to the
affected modules so the programmers can change their code if needed.


Few of the hotfixes break existing code (except to the extent that the
code may depend on the bug being fixed).

This will absolutely guarantee that the hotfixes will cause random
problems on random customers' systems, because they were not all tested
together, and weren't tested in that customer's configuration, and because
the customer didn't get a chance to go through a proper test cycle.
And, yes.....I do think that programmers paying $2500 for a year's
subscription are entitled to tested hotfixes.


Again, Jim, it is my understanding that the hot fixes _are_ tested. They
are tested individually, not in all permutations. A Service Pack takes a
number of hot fixes and puts them together in a single package which can
be thoroughly tested. The fixes in a Service Pack can be tested as a
group, and can be tested in many different environments, and can then be
released to customers for Beta testing. How long was the Beta period of XP
SP2?


The very nature of the .Net framework invalidates your arguments for
Microsoft's failure to test.

According to Microsoft, many different versions of .Net (both the framework
and code) should be able to reside on a single machine and run side-by-side.

So, what's to stop Microsoft from making a change to the version of the .Net
framework with each hotfix? Are they going to run out of numbers? If so, I
have some numbers I can let them borrrow. (For a monthly fee, of course.)

The whole idea behind the .Net framework was to allow different versions of
the framework and code to run side-by-side. Since I have only been
addressing the .Net framework in my posts, I fail to see any validity in
your arguments.

Please let me know if I misunderstand the nature of .Net or there are
reasons for not issuing incrementing versions of .Net with each hotfix.

Jim Hubbard
Jul 21 '05 #10

P: n/a
Jim Hubbard wrote:
Microsoft writes all of the operating systems you mention. Microsoft
writes
the coding tools we are talking about. Microsoft writes the "hotfixes".
Situation:

A problem happens.

A young intern, goes and writes a hotfix to address the problem.

He hands it to his boss, then leaves to go party in Daytona.

This is one hotfix, among 10,000 others.

It only affects version n.nn.nn, and has only been tested with computer y in
configuration z.

If a customer should call having that problem, it's made available.

Otherwise, there's no idea of the implications the fix might cause for other
configurations, and there's not enough resources to test it.


Shouldn't Microsoft know what the "hotfixes" will affect? If you have all
of the source code, isn't it incumbent on YOU to do the testing of your
latest patches?

That has always been the case in every software shop I have worked in. We
wrote the code. We made the mistakes. We cleaned them up.

With $50 BILLION in cash reserves and investing over $400M in Indian
programmers at once.....don't you think Microsoft should know it's own
code.....or at least be able to test it's own software?

Microsoft cannot, obviously, guarantee the hotfixes to work with all 3rd
party software. But, they don't have to.....they just need to make sure
that hotfixes don't break their codebase and alert the programmers to the
affected modules so the programmers can change their code if needed.

And, yes.....I do think that programmers paying $2500 for a year's
subscription are entitled to tested hotfixes.

Jim Hubbard

"John Saunders" <johnwsaundersiii at hotmail.com> wrote in message
news:u3**************@TK2MSFTNGP14.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:Fd********************@giganews.com...
What he said....


Ok, but you were talking about automatic distribution, and didn't answer
my question. There's got to be some (tested) package to be automatically
distributed.

BTW, passage of time does not imply that the fix has been tested - as a
service pack. The fact that the individual hotfixes may have been tested
does not in any way imply that they will work if packaged together with
other fixes. Also, a service pack will get testing on multiple OS
versions and in many different situations. It's a lot more testing than
just testing an individual fix.

John Saunders


--
"The Bush administration aims in its 2005 budget to cut by $1 billion the
$18 billion fund that helps about 2 million Americans--generally the poor,
elderly, and disabled--pay their rent."
-Mother Jones
http://www.motherjones.com/news/dail...05/05_520.html

Jul 21 '05 #11

P: n/a
"Jim Hubbard" <re***@groups.please> wrote in message
news:ys********************@giganews.com...

"John Saunders" <johnwsaundersiii at hotmail.com> wrote in message
news:Oj*************@TK2MSFTNGP11.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:jN********************@giganews.com...


< snip >
That has always been the case in every software shop I have worked in.
We wrote the code. We made the mistakes. We cleaned them up.

With $50 BILLION in cash reserves and investing over $400M in Indian
programmers at once.....don't you think Microsoft should know it's own
code.....or at least be able to test it's own software?


No, I don't.


Why not?


Because there's too much of it to go test for every hotfix.
Besides, they not only have to know their own code, they have to know all
the crazy things their customers will do with their code. And Microsoft
has a rather large number of customers doing crazy things.
Microsoft cannot, obviously, guarantee the hotfixes to work with all 3rd
party software. But, they don't have to.....they just need to make sure
that hotfixes don't break their codebase and alert the programmers to
the affected modules so the programmers can change their code if needed.


Few of the hotfixes break existing code (except to the extent that the
code may depend on the bug being fixed).

This will absolutely guarantee that the hotfixes will cause random
problems on random customers' systems, because they were not all tested
together, and weren't tested in that customer's configuration, and
because the customer didn't get a chance to go through a proper test
cycle.
And, yes.....I do think that programmers paying $2500 for a year's
subscription are entitled to tested hotfixes.


Again, Jim, it is my understanding that the hot fixes _are_ tested. They
are tested individually, not in all permutations. A Service Pack takes a
number of hot fixes and puts them together in a single package which can
be thoroughly tested. The fixes in a Service Pack can be tested as a
group, and can be tested in many different environments, and can then be
released to customers for Beta testing. How long was the Beta period of
XP SP2?


The very nature of the .Net framework invalidates your arguments for
Microsoft's failure to test.

According to Microsoft, many different versions of .Net (both the
framework and code) should be able to reside on a single machine and run
side-by-side.

So, what's to stop Microsoft from making a change to the version of the
.Net framework with each hotfix? Are they going to run out of numbers?
If so, I have some numbers I can let them borrrow. (For a monthly fee, of
course.)

The whole idea behind the .Net framework was to allow different versions
of the framework and code to run side-by-side. Since I have only been
addressing the .Net framework in my posts, I fail to see any validity in
your arguments.

Please let me know if I misunderstand the nature of .Net or there are
reasons for not issuing incrementing versions of .Net with each hotfix.


You haven't caught my point.

A great amount of testing is necessary before you release a fix to a
customer for use in a production environment. That testing takes too long to
do it for each hotfix. Instead, hotfixes are grouped together to create a
Service Pack, which is tested appropriately.

Jim, are you thinking about a production environment, or a development
environment?

John Saunders
Jul 21 '05 #12

P: n/a

"John Saunders" <johnwsaundersiii at hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:ys********************@giganews.com...

"John Saunders" <johnwsaundersiii at hotmail.com> wrote in message
news:Oj*************@TK2MSFTNGP11.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:jN********************@giganews.com...
< snip >
That has always been the case in every software shop I have worked in.
We wrote the code. We made the mistakes. We cleaned them up.

With $50 BILLION in cash reserves and investing over $400M in Indian
programmers at once.....don't you think Microsoft should know it's own
code.....or at least be able to test it's own software?

No, I don't.


Why not?


Because there's too much of it to go test for every hotfix.


Maybe it's time to start cutting out the fat. When you can't fix one part
of your code because it may break another part, that's just poor design.
And, in a company the size and importance of Microsoft to daily business,
it's dangerous and borders on crimminal misconduct by a corporation.
Besides, they not only have to know their own code, they have to know
all the crazy things their customers will do with their code. And
Microsoft has a rather large number of customers doing crazy things.

Microsoft cannot, obviously, guarantee the hotfixes to work with all
3rd party software. But, they don't have to.....they just need to make
sure that hotfixes don't break their codebase and alert the programmers
to the affected modules so the programmers can change their code if
needed.

Few of the hotfixes break existing code (except to the extent that the
code may depend on the bug being fixed).

This will absolutely guarantee that the hotfixes will cause random
problems on random customers' systems, because they were not all tested
together, and weren't tested in that customer's configuration, and
because the customer didn't get a chance to go through a proper test
cycle.

And, yes.....I do think that programmers paying $2500 for a year's
subscription are entitled to tested hotfixes.

Again, Jim, it is my understanding that the hot fixes _are_ tested. They
are tested individually, not in all permutations. A Service Pack takes a
number of hot fixes and puts them together in a single package which can
be thoroughly tested. The fixes in a Service Pack can be tested as a
group, and can be tested in many different environments, and can then be
released to customers for Beta testing. How long was the Beta period of
XP SP2?


The very nature of the .Net framework invalidates your arguments for
Microsoft's failure to test.

According to Microsoft, many different versions of .Net (both the
framework and code) should be able to reside on a single machine and run
side-by-side.

So, what's to stop Microsoft from making a change to the version of the
.Net framework with each hotfix? Are they going to run out of numbers?
If so, I have some numbers I can let them borrrow. (For a monthly fee,
of course.)

The whole idea behind the .Net framework was to allow different versions
of the framework and code to run side-by-side. Since I have only been
addressing the .Net framework in my posts, I fail to see any validity in
your arguments.

Please let me know if I misunderstand the nature of .Net or there are
reasons for not issuing incrementing versions of .Net with each hotfix.


You haven't caught my point.

A great amount of testing is necessary before you release a fix to a
customer for use in a production environment. That testing takes too long
to do it for each hotfix. Instead, hotfixes are grouped together to create
a Service Pack, which is tested appropriately.


I agree with these points. The fact is that Microsoft is not doing what you
are suggesting. There are hotfixes for the .Net framework (1.1) that have
been available for months but have not been placed into any released service
packs. I can list some of them if you like.

Jim, are you thinking about a production environment, or a development
environment?


Production. Programmers don't pay $2500 for beta code. I expect it to
work. I expect problems in the framework to be fxed. And I expect the fix
to actually fix things....not break new stuff. That's what Microsoft should
test for. That *is* what I paid for isn't it? Is expecting working code in
exchange for some of the highest software prices in the industry so
unreasonable?

It seems that you glossed over entirely the easy solution to this problem.
When Microsoft fixes the framework, simply increase the version number of
the framework and release the newest version! Is that so hard to
comprehend? Isn't that one main goal of the .Net framework....to be able to
run several different versions on the same machine WITHOUT corrupting each
other?

Let's imagine for a moment that Microsoft used their own technology as they
said it was designed to work and issued new versions of .Net with each new
service pack (or even hotfix). Let's also say they screw up something new
with the latest service pack or hotfix. According to them, this would not
break or interfere with the old code you had written in a previous version
of the framework. So where's the harm?

If it screws up your code, either change your code or drop back and punt
from the previous version of .Net that didn't screw up your code.

This isn't that difficult to understand. I'm not talking over anybody's
head here. They just don't want to do it.

Hell, short of that you *could* make the hotfixes save their changes so that
you could apply them one at a time, test your code and roll back any
hotfixes that screwed up your programs. Microsoft doesn't even do that.

The sad but obvious fact is that they don't care about making your life
easier, it's all about making their lives easier. That was the original
premise of .Net in the first place. If not, they'd use the technology they
built to enhance it's effectiveness instead of hobbling it.

Jim Hubbard
Jul 21 '05 #13

P: n/a
"Jim Hubbard" <re***@groups.please> wrote in message
news:af********************@giganews.com...

"John Saunders" <johnwsaundersiii at hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:ys********************@giganews.com...

"John Saunders" <johnwsaundersiii at hotmail.com> wrote in message
news:Oj*************@TK2MSFTNGP11.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:jN********************@giganews.com...

< snip >

> That has always been the case in every software shop I have worked in.
> We wrote the code. We made the mistakes. We cleaned them up.
>
> With $50 BILLION in cash reserves and investing over $400M in Indian
> programmers at once.....don't you think Microsoft should know it's own
> code.....or at least be able to test it's own software?

No, I don't.

Why not?
Because there's too much of it to go test for every hotfix.


Maybe it's time to start cutting out the fat. When you can't fix one part
of your code because it may break another part, that's just poor design.
And, in a company the size and importance of Microsoft to daily business,
it's dangerous and borders on crimminal misconduct by a corporation.
Besides, they not only have to know their own code, they have to know
all the crazy things their customers will do with their code. And
Microsoft has a rather large number of customers doing crazy things.

> Microsoft cannot, obviously, guarantee the hotfixes to work with all
> 3rd party software. But, they don't have to.....they just need to
> make sure that hotfixes don't break their codebase and alert the
> programmers to the affected modules so the programmers can change
> their code if needed.

Few of the hotfixes break existing code (except to the extent that the
code may depend on the bug being fixed).

This will absolutely guarantee that the hotfixes will cause random
problems on random customers' systems, because they were not all tested
together, and weren't tested in that customer's configuration, and
because the customer didn't get a chance to go through a proper test
cycle.

> And, yes.....I do think that programmers paying $2500 for a year's
> subscription are entitled to tested hotfixes.

Again, Jim, it is my understanding that the hot fixes _are_ tested.
They are tested individually, not in all permutations. A Service Pack
takes a number of hot fixes and puts them together in a single package
which can be thoroughly tested. The fixes in a Service Pack can be
tested as a group, and can be tested in many different environments,
and can then be released to customers for Beta testing. How long was
the Beta period of XP SP2?

The very nature of the .Net framework invalidates your arguments for
Microsoft's failure to test.

According to Microsoft, many different versions of .Net (both the
framework and code) should be able to reside on a single machine and run
side-by-side.

So, what's to stop Microsoft from making a change to the version of the
.Net framework with each hotfix? Are they going to run out of numbers?
If so, I have some numbers I can let them borrrow. (For a monthly fee,
of course.)

The whole idea behind the .Net framework was to allow different versions
of the framework and code to run side-by-side. Since I have only been
addressing the .Net framework in my posts, I fail to see any validity in
your arguments.

Please let me know if I misunderstand the nature of .Net or there are
reasons for not issuing incrementing versions of .Net with each hotfix.


You haven't caught my point.

A great amount of testing is necessary before you release a fix to a
customer for use in a production environment. That testing takes too long
to do it for each hotfix. Instead, hotfixes are grouped together to
create a Service Pack, which is tested appropriately.


I agree with these points. The fact is that Microsoft is not doing what
you are suggesting. There are hotfixes for the .Net framework (1.1) that
have been available for months but have not been placed into any released
service packs. I can list some of them if you like.


I don't see what that has to do with my point. They happen not to have
scheduled a service pack. This could be due to lack of QA resources. For
instance, if they were working on a major new release, then some of the
resources which would have been used to test service packs might instead be
working on testing the new release. BTW, I'm sure you're aware that they are
working on both SQL Server 2005 and VS.NET 2005 and Framework 2.0?

Jim, are you thinking about a production environment, or a development
environment?


Production. Programmers don't pay $2500 for beta code. I expect it to
work. I expect problems in the framework to be fxed. And I expect the
fix to actually fix things....not break new stuff. That's what Microsoft
should test for. That *is* what I paid for isn't it? Is expecting
working code in exchange for some of the highest software prices in the
industry so unreasonable?


Actually, some programmers pay $2700 anually for an MSDN Universal
subscription, and that's what I thought you might have meant.

If you expect humans to produce perfection, make sure you don't accidentally
pinch yourself and wake up.
It seems that you glossed over entirely the easy solution to this problem.
When Microsoft fixes the framework, simply increase the version number of
the framework and release the newest version! Is that so hard to
comprehend? Isn't that one main goal of the .Net framework....to be able
to run several different versions on the same machine WITHOUT corrupting
each other?
Versioning isn't the issue. The quality of releases is the issue.

You also seem to be assuming that fixes are sequential, and that each hotfix
can be associated with a single version number.
Let's imagine for a moment that Microsoft used their own technology as
they said it was designed to work and issued new versions of .Net with
each new service pack (or even hotfix). Let's also say they screw up
something new with the latest service pack or hotfix. According to them,
this would not break or interfere with the old code you had written in a
previous version of the framework. So where's the harm?

If it screws up your code, either change your code or drop back and punt
from the previous version of .Net that didn't screw up your code.
How often do you plan to do this? And how much do you plan to test your code
for each new hotfix?
This isn't that difficult to understand. I'm not talking over anybody's
head here. They just don't want to do it.


No, you just don't seem to be too clear on how a production operation works.
The very idea of having so many versions around on a set of production
machines scares the hell out of me.

John Saunders
Jul 21 '05 #14

P: n/a

"Section 8" <ro***@moore.bond.007> wrote in message
news:pV***************@newsread1.news.pas.earthlin k.net...
Jim Hubbard wrote:
Microsoft writes all of the operating systems you mention. Microsoft
writes
the coding tools we are talking about. Microsoft writes the "hotfixes".
Situation:

A problem happens.

A young intern, goes and writes a hotfix to address the problem.

He hands it to his boss, then leaves to go party in Daytona.

This is one hotfix, among 10,000 others.

It only affects version n.nn.nn, and has only been tested with computer y
in
configuration z.

If a customer should call having that problem, it's made available.

Otherwise, there's no idea of the implications the fix might cause for
other
configurations, and there's not enough resources to test it.


You also choose to ignore the ability to run multiple versions of the
framework side-by-side.

There is no excuse for not alerting developers to hotfixes as they become
available and allowing developers to download and test patches without a
*ing phone call to Microsoft......other than just not giving a damn.

Should I also rehash the ability to roll-back patches that Microsoft also
ignores in many cases?

Jim Hubbard

"The Bush administration aims in its 2005 budget to cut by $1 billion the
$18 billion fund that helps about 2 million Americans--generally the poor,
elderly, and disabled--pay their rent."
-Mother Jones
http://www.motherjones.com/news/dail...05/05_520.html


Expand your horizons....read a little more current "news" -
http://harkin.senate.gov/news.cfm?id=225889.

And, in the interest of full disclosure, you *should* mention that the
webmaster of this liberal website (masquerading as a journalism site) is on
the payroll of MoveOn.org. Not exactly an impartial view of the subject.
Jul 21 '05 #15

P: n/a
You also choose to ignore the ability to run multiple versions of the
framework side-by-side.

There is no excuse for not alerting developers to hotfixes as they become
available and allowing developers to download and test patches without a
*ing phone call to Microsoft......other than just not giving a damn.

Should I also rehash the ability to roll-back patches that Microsoft also
ignores in many cases?

Jim Hubbard


I agree on this one. There should, at the very least, exist some kind of
hotfix mailing list that you could subscribe to.
/ Fredrik
Jul 21 '05 #16

P: n/a

"Fredrik Wahlgren" <fr****************@mailbox.swipnet.se> wrote in message
news:Oq**************@tk2msftngp13.phx.gbl...
You also choose to ignore the ability to run multiple versions of the
framework side-by-side.

There is no excuse for not alerting developers to hotfixes as they become
available and allowing developers to download and test patches without a
*ing phone call to Microsoft......other than just not giving a damn.

Should I also rehash the ability to roll-back patches that Microsoft also
ignores in many cases?

Jim Hubbard


I agree on this one. There should, at the very least, exist some kind of
hotfix mailing list that you could subscribe to.
/ Fredrik


Subscribe to KBAlertz.....it's free. http://www.kbalertz.com/

Dave Wanta and Scott Cate are the responsible parties for the website.
THANKS GUYS!

Again, KBAlertz is something Microsoft should have done. You *should* warn
your subscribed users when you find a problem, shouldn't you? Maybe
Microsoft could do the right thing and buy it from them.

Be forewarned......Microsoft issues a LOT more warnings than you might
expect so be choosy about which technologies you pick.

Jim Hubbard

Jul 21 '05 #17

P: n/a

"Jim Hubbard" <re***@groups.please> wrote in message
news:RO********************@giganews.com...

"Fredrik Wahlgren" <fr****************@mailbox.swipnet.se> wrote in message news:Oq**************@tk2msftngp13.phx.gbl...
You also choose to ignore the ability to run multiple versions of the
framework side-by-side.

There is no excuse for not alerting developers to hotfixes as they become available and allowing developers to download and test patches without a *ing phone call to Microsoft......other than just not giving a damn.

Should I also rehash the ability to roll-back patches that Microsoft also ignores in many cases?

Jim Hubbard
I agree on this one. There should, at the very least, exist some kind of
hotfix mailing list that you could subscribe to.
/ Fredrik


Subscribe to KBAlertz.....it's free. http://www.kbalertz.com/

Dave Wanta and Scott Cate are the responsible parties for the website.
THANKS GUYS!

Again, KBAlertz is something Microsoft should have done. You *should*

warn your subscribed users when you find a problem, shouldn't you? Maybe
Microsoft could do the right thing and buy it from them.

Be forewarned......Microsoft issues a LOT more warnings than you might
expect so be choosy about which technologies you pick.

Jim Hubbard


Well, I haven't. Is there any way I can get hotfix alerts for say, SQL
Server only. If not, like you said, I will get lots of emails. That's why I
haven't subscribed.

/ Fredrik
Jul 21 '05 #18

P: n/a
Also, it's not all hotfixes that got annonced into the knownledge base
article. Others are available but will be found only after a direct
discussion with the technical support on a paid call while others are simply
put into some *limbo* cybernetic space.

S. L.

"Fredrik Wahlgren" <fr****************@mailbox.swipnet.se> wrote in message
news:OP**************@TK2MSFTNGP14.phx.gbl...

"Jim Hubbard" <re***@groups.please> wrote in message
news:RO********************@giganews.com...

"Fredrik Wahlgren" <fr****************@mailbox.swipnet.se> wrote in

message
news:Oq**************@tk2msftngp13.phx.gbl...
>
>> You also choose to ignore the ability to run multiple versions of the
>> framework side-by-side.
>>
>> There is no excuse for not alerting developers to hotfixes as they become >> available and allowing developers to download and test patches without a >> *ing phone call to Microsoft......other than just not giving a damn.
>>
>> Should I also rehash the ability to roll-back patches that Microsoft also >> ignores in many cases?
>>
>> Jim Hubbard
>>
>>
>
> I agree on this one. There should, at the very least, exist some kind
> of
> hotfix mailing list that you could subscribe to.
> / Fredrik


Subscribe to KBAlertz.....it's free. http://www.kbalertz.com/

Dave Wanta and Scott Cate are the responsible parties for the website.
THANKS GUYS!

Again, KBAlertz is something Microsoft should have done. You *should*

warn
your subscribed users when you find a problem, shouldn't you? Maybe
Microsoft could do the right thing and buy it from them.

Be forewarned......Microsoft issues a LOT more warnings than you might
expect so be choosy about which technologies you pick.

Jim Hubbard


Well, I haven't. Is there any way I can get hotfix alerts for say, SQL
Server only. If not, like you said, I will get lots of emails. That's why
I
haven't subscribed.

/ Fredrik

Jul 21 '05 #19

P: n/a

"Fredrik Wahlgren" <fr****************@mailbox.swipnet.se> wrote in message
news:OP**************@TK2MSFTNGP14.phx.gbl...

"Jim Hubbard" <re***@groups.please> wrote in message
news:RO********************@giganews.com...

"Fredrik Wahlgren" <fr****************@mailbox.swipnet.se> wrote in

message
news:Oq**************@tk2msftngp13.phx.gbl...
>
>> You also choose to ignore the ability to run multiple versions of the
>> framework side-by-side.
>>
>> There is no excuse for not alerting developers to hotfixes as they become >> available and allowing developers to download and test patches without a >> *ing phone call to Microsoft......other than just not giving a damn.
>>
>> Should I also rehash the ability to roll-back patches that Microsoft also >> ignores in many cases?
>>
>> Jim Hubbard
>>
>>
>
> I agree on this one. There should, at the very least, exist some kind
> of
> hotfix mailing list that you could subscribe to.
> / Fredrik


Subscribe to KBAlertz.....it's free. http://www.kbalertz.com/

Dave Wanta and Scott Cate are the responsible parties for the website.
THANKS GUYS!

Again, KBAlertz is something Microsoft should have done. You *should*

warn
your subscribed users when you find a problem, shouldn't you? Maybe
Microsoft could do the right thing and buy it from them.

Be forewarned......Microsoft issues a LOT more warnings than you might
expect so be choosy about which technologies you pick.

Jim Hubbard


Well, I haven't. Is there any way I can get hotfix alerts for say, SQL
Server only. If not, like you said, I will get lots of emails. That's why
I
haven't subscribed.

/ Fredrik


Yes. Simply select only the SQL Server 2000 and SQL Server 7.0 checkboxes.
Then you'll only get Knowledge Base alerts for those Microsoft Technologies.

You only get what you check. No spam.

And, it's easy to unsubscribe if it's not all that you thought it would be.

Jim Hubbard
Jul 21 '05 #20

P: n/a

"Sylvain Lafontaine" <sylvain aei ca (fill the blanks, no spam please)>
wrote in message news:ex**************@tk2msftngp13.phx.gbl...
Also, it's not all hotfixes that got annonced into the knownledge base
article. Others are available but will be found only after a direct
discussion with the technical support on a paid call while others are
simply put into some *limbo* cybernetic space.

S. L.


That's scary. With all of the hotfixes announced in the knowledge base, I
wonder how many we are missing out on because they don't get announced
there?

Jim Hubbard
Jul 21 '05 #21

P: n/a

"John Saunders" <johnwsaundersiii at hotmail.com> wrote in message
news:OK**************@tk2msftngp13.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:af********************@giganews.com...

"John Saunders" <johnwsaundersiii at hotmail.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:ys********************@giganews.com...

"John Saunders" <johnwsaundersiii at hotmail.com> wrote in message
news:Oj*************@TK2MSFTNGP11.phx.gbl...
> "Jim Hubbard" <re***@groups.please> wrote in message
> news:jN********************@giganews.com...

< snip >

>> That has always been the case in every software shop I have worked
>> in. We wrote the code. We made the mistakes. We cleaned them up.
>>
>> With $50 BILLION in cash reserves and investing over $400M in Indian
>> programmers at once.....don't you think Microsoft should know it's
>> own code.....or at least be able to test it's own software?
>
> No, I don't.

Why not?

Because there's too much of it to go test for every hotfix.
Maybe it's time to start cutting out the fat. When you can't fix one
part of your code because it may break another part, that's just poor
design. And, in a company the size and importance of Microsoft to daily
business, it's dangerous and borders on crimminal misconduct by a
corporation.
> Besides, they not only have to know their own code, they have to know
> all the crazy things their customers will do with their code. And
> Microsoft has a rather large number of customers doing crazy things.
>
>> Microsoft cannot, obviously, guarantee the hotfixes to work with all
>> 3rd party software. But, they don't have to.....they just need to
>> make sure that hotfixes don't break their codebase and alert the
>> programmers to the affected modules so the programmers can change
>> their code if needed.
>
> Few of the hotfixes break existing code (except to the extent that the
> code may depend on the bug being fixed).
>
> This will absolutely guarantee that the hotfixes will cause random
> problems on random customers' systems, because they were not all
> tested together, and weren't tested in that customer's configuration,
> and because the customer didn't get a chance to go through a proper
> test cycle.
>
>> And, yes.....I do think that programmers paying $2500 for a year's
>> subscription are entitled to tested hotfixes.
>
> Again, Jim, it is my understanding that the hot fixes _are_ tested.
> They are tested individually, not in all permutations. A Service Pack
> takes a number of hot fixes and puts them together in a single package
> which can be thoroughly tested. The fixes in a Service Pack can be
> tested as a group, and can be tested in many different environments,
> and can then be released to customers for Beta testing. How long was
> the Beta period of XP SP2?

The very nature of the .Net framework invalidates your arguments for
Microsoft's failure to test.

According to Microsoft, many different versions of .Net (both the
framework and code) should be able to reside on a single machine and
run side-by-side.

So, what's to stop Microsoft from making a change to the version of the
.Net framework with each hotfix? Are they going to run out of numbers?
If so, I have some numbers I can let them borrrow. (For a monthly fee,
of course.)

The whole idea behind the .Net framework was to allow different
versions of the framework and code to run side-by-side. Since I have
only been addressing the .Net framework in my posts, I fail to see any
validity in your arguments.

Please let me know if I misunderstand the nature of .Net or there are
reasons for not issuing incrementing versions of .Net with each hotfix.

You haven't caught my point.

A great amount of testing is necessary before you release a fix to a
customer for use in a production environment. That testing takes too
long to do it for each hotfix. Instead, hotfixes are grouped together to
create a Service Pack, which is tested appropriately.


I agree with these points. The fact is that Microsoft is not doing what
you are suggesting. There are hotfixes for the .Net framework (1.1) that
have been available for months but have not been placed into any released
service packs. I can list some of them if you like.


I don't see what that has to do with my point. They happen not to have
scheduled a service pack. This could be due to lack of QA resources. For
instance, if they were working on a major new release, then some of the
resources which would have been used to test service packs might instead
be working on testing the new release. BTW, I'm sure you're aware that
they are working on both SQL Server 2005 and VS.NET 2005 and Framework
2.0?

Jim, are you thinking about a production environment, or a development
environment?


Production. Programmers don't pay $2500 for beta code. I expect it to
work. I expect problems in the framework to be fxed. And I expect the
fix to actually fix things....not break new stuff. That's what Microsoft
should test for. That *is* what I paid for isn't it? Is expecting
working code in exchange for some of the highest software prices in the
industry so unreasonable?


Actually, some programmers pay $2700 anually for an MSDN Universal
subscription, and that's what I thought you might have meant.

If you expect humans to produce perfection, make sure you don't
accidentally pinch yourself and wake up.


Wow.....no need to continue this thread......
It seems that you glossed over entirely the easy solution to this
problem. When Microsoft fixes the framework, simply increase the version
number of the framework and release the newest version! Is that so hard
to comprehend? Isn't that one main goal of the .Net framework....to be
able to run several different versions on the same machine WITHOUT
corrupting each other?
Versioning isn't the issue. The quality of releases is the issue.

You also seem to be assuming that fixes are sequential, and that each
hotfix can be associated with a single version number.


Not neccesarily. Why not have the avilable hotfixes load like Windows
security updates with a roll-back feature in case it screws something up?
Let's imagine for a moment that Microsoft used their own technology as
they said it was designed to work and issued new versions of .Net with
each new service pack (or even hotfix). Let's also say they screw up
something new with the latest service pack or hotfix. According to them,
this would not break or interfere with the old code you had written in a
previous version of the framework. So where's the harm?

If it screws up your code, either change your code or drop back and punt
from the previous version of .Net that didn't screw up your code.
How often do you plan to do this? And how much do you plan to test your
code for each new hotfix?


Not often. Mainly in between builds. No programmer in his right mind would
update the production or development machines while still coding the
application.

Testing is mostly automated. We're talking the .Net framework here. A
bunch of pre-compiled classes that you use in your code and a JIT compiler
to make it all come together. Either a class works with the implemented
interfaces or it doesn't. Either the JIT consumes the COM objects correctly
or it doesn't.
This isn't that difficult to understand. I'm not talking over anybody's
head here. They just don't want to do it.
No, you just don't seem to be too clear on how a production operation
works.


Sadly, I am all too aware of how common production operations work. That's
why I don't code for people like Bellsouth, Porsche, Qwest etc, anymore and
started my own company. They are so frigid in their thought processes
concerning development that precious little actual work gets done.

The shops that get the least amount of work done seem to be those blindly
following the Microsoft SDLC. If it doesn't work for Microsoft.....why in
hell would you put your company on it?
The very idea of having so many versions around on a set of production
machines scares the hell out of me.


But, it shouldn't. That's how .Net was written to work. They all use thier
own framework (whatever version they were coded with) and, according to
Microsoft, they will not step on each other's toes.

Jim Hubbard
Jul 21 '05 #22

P: n/a
"Jim Hubbard" <re***@groups.please> wrote in message
news:ys********************@giganews.com...
The whole idea behind the .Net framework was to allow different versions of the framework and code to run side-by-side.


You'll be lucky. It's DLL hell all over again. This is why internet Java was
such a disaster. I remember the banks using it and then spending all day
trying to troubleshoot end-users broken and disparate JVMs.

..NET is just as bad. "Which version of .NET are my 200,000 customers using",
"oops it won't work on that one". "Oh you've got XP gold", "You need
Longhorn for that one", "You're on Win98SE". That's before you even get to
service packs on hotfixes on the client's machine.

The whole thing is a mess, and can only get worse with Longhorn. They claim
Longhorn will embrace .NET, but so far we have no credible DirectShow
assemblies, and even if we did they'll fall way short of the capabilities of
COM. Do they have an LSA in managed code yet? What about the LDAP API? Where
is WinFS? Where are the native UNIX and Fibre SAN connectors?

All we've seen so far is the step backwards known as "Avalon" where current
W3C UI markup will be replaced by proprietary "Windows Only" code, and how
exactly will this help the Enterprise? "View your sales figures in a
rotating 3D DirectX cube", LOL!

Gerry Hickman
SSRU SysAdmin
Jul 21 '05 #23

P: n/a

"Gerry Hickman" <ge******@netscape.net> wrote in message
news:en**************@TK2MSFTNGP14.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:ys********************@giganews.com...
The whole idea behind the .Net framework was to allow different versions of
the framework and code to run side-by-side.


You'll be lucky. It's DLL hell all over again. This is why internet Java
was
such a disaster. I remember the banks using it and then spending all day
trying to troubleshoot end-users broken and disparate JVMs.

.NET is just as bad. "Which version of .NET are my 200,000 customers
using",
"oops it won't work on that one". "Oh you've got XP gold", "You need
Longhorn for that one", "You're on Win98SE". That's before you even get to
service packs on hotfixes on the client's machine.


Damned right! In another thread, I had asked the question "Why is .Net an
optional download?" If .Net is so important to the future of Microsoft
products, the .Net frameworks should be downloaded and installed
automatically along with security updates and such. It should be core to
the OS.

Even if one .Net framework is shipped with the OS, what about the next
version? These things have to be required (at least highly recommended)
updates to the OS.

Now, I know each .Net framework is a bloated, massive amount of code for
most people to download - so, the next question is why Microsoft didn't use
the technology built into .Net to make .Net exe's download only the portions
of .Net that they need to run, if those portions don't exist on the machine
the exe is being launched on? If a .Net application can tell it doesn't have
the DLLs required for a function and will request those downloads from the
server hosting the program's exe, why couldn't each exe contain similar code
for the .Net framework?

Beats the hell out of me.

The whole thing is a mess, and can only get worse with Longhorn. They
claim
Longhorn will embrace .NET, but so far we have no credible DirectShow
assemblies, and even if we did they'll fall way short of the capabilities
of
COM. Do they have an LSA in managed code yet? What about the LDAP API?
Where
is WinFS? Where are the native UNIX and Fibre SAN connectors?
I SO wish you weren't right......unfortunately, you are.

All we've seen so far is the step backwards known as "Avalon" where
current
W3C UI markup will be replaced by proprietary "Windows Only" code, and how
exactly will this help the Enterprise? "View your sales figures in a
rotating 3D DirectX cube", LOL!


And Microsoft rolls on......

We've conqured all of these problems by just sending out one EXE that wraps
all of the code (DLLs, EXEs, etc.) into a single executable that doesn't
need any installed .Net frameworks (if that is what we choose to code the
app in) or any dependencies apart from Windows itself.

If you use .Net for your apps, the EXE is still really big, but if you use
something like C++ or even VB 6 your resulting exe is much smaller.

Since we are wrapping everything, .Net really has no advantages other than
webservice ease of use. And, we get to continue using our old skillset and
thousands of dollars on third party controls without worrying about .Net COM
interop screwing it up. (The Dart/PowerTCP activeX controls will not work
with .Net 1.1 - Studio 2003 Architect.)

No control installations, no registry mess, no DLL hell, no .Net framework
hell. Just a larger exe and no worries.

Jim Hubbard
Jul 21 '05 #24

P: n/a
Jim, could you possibly tell me what you are using to wrap everything up in
one exe? If it is a commercial product (or free one) please let me know at:

john [at] fluidnature dot com? thanks so much (especially if its something i
can use!)
> you said: >>>>>
We've conqured all of these problems by just sending out one EXE that wraps
all of the code (DLLs, EXEs, etc.) into a single executable that doesn't
need any installed .Net frameworks (if that is what we choose to code the
app in) or any dependencies apart from Windows itself.

If you use .Net for your apps, the EXE is still really big, but if you use
something like C++ or even VB 6 your resulting exe is much smaller.

Since we are wrapping everything, .Net really has no advantages other than
webservice ease of use. And, we get to continue using our old skillset and
thousands of dollars on third party controls without worrying about .Net COM
interop screwing it up. (The Dart/PowerTCP activeX controls will not work
with .Net 1.1 - Studio 2003 Architect.)

No control installations, no registry mess, no DLL hell, no .Net framework
hell. Just a larger exe and no worries.
"Jim Hubbard" wrote:

"Gerry Hickman" <ge******@netscape.net> wrote in message
news:en**************@TK2MSFTNGP14.phx.gbl...
"Jim Hubbard" <re***@groups.please> wrote in message
news:ys********************@giganews.com...
The whole idea behind the .Net framework was to allow different versions

of
the framework and code to run side-by-side.


You'll be lucky. It's DLL hell all over again. This is why internet Java
was
such a disaster. I remember the banks using it and then spending all day
trying to troubleshoot end-users broken and disparate JVMs.

.NET is just as bad. "Which version of .NET are my 200,000 customers
using",
"oops it won't work on that one". "Oh you've got XP gold", "You need
Longhorn for that one", "You're on Win98SE". That's before you even get to
service packs on hotfixes on the client's machine.


Damned right! In another thread, I had asked the question "Why is .Net an
optional download?" If .Net is so important to the future of Microsoft
products, the .Net frameworks should be downloaded and installed
automatically along with security updates and such. It should be core to
the OS.

Even if one .Net framework is shipped with the OS, what about the next
version? These things have to be required (at least highly recommended)
updates to the OS.

Now, I know each .Net framework is a bloated, massive amount of code for
most people to download - so, the next question is why Microsoft didn't use
the technology built into .Net to make .Net exe's download only the portions
of .Net that they need to run, if those portions don't exist on the machine
the exe is being launched on? If a .Net application can tell it doesn't have
the DLLs required for a function and will request those downloads from the
server hosting the program's exe, why couldn't each exe contain similar code
for the .Net framework?

Beats the hell out of me.

The whole thing is a mess, and can only get worse with Longhorn. They
claim
Longhorn will embrace .NET, but so far we have no credible DirectShow
assemblies, and even if we did they'll fall way short of the capabilities
of
COM. Do they have an LSA in managed code yet? What about the LDAP API?
Where
is WinFS? Where are the native UNIX and Fibre SAN connectors?


I SO wish you weren't right......unfortunately, you are.

All we've seen so far is the step backwards known as "Avalon" where
current
W3C UI markup will be replaced by proprietary "Windows Only" code, and how
exactly will this help the Enterprise? "View your sales figures in a
rotating 3D DirectX cube", LOL!


And Microsoft rolls on......

We've conqured all of these problems by just sending out one EXE that wraps
all of the code (DLLs, EXEs, etc.) into a single executable that doesn't
need any installed .Net frameworks (if that is what we choose to code the
app in) or any dependencies apart from Windows itself.

If you use .Net for your apps, the EXE is still really big, but if you use
something like C++ or even VB 6 your resulting exe is much smaller.

Since we are wrapping everything, .Net really has no advantages other than
webservice ease of use. And, we get to continue using our old skillset and
thousands of dollars on third party controls without worrying about .Net COM
interop screwing it up. (The Dart/PowerTCP activeX controls will not work
with .Net 1.1 - Studio 2003 Architect.)

No control installations, no registry mess, no DLL hell, no .Net framework
hell. Just a larger exe and no worries.

Jim Hubbard

Jul 21 '05 #25

P: n/a
Here's a link to Chris Sells' blog (that links to my blog) about the
program. It's called Thinstall, and it rocks!

Let me know if there is anything I can do to help.

Jim Hubbard
"fuul" <fu**@discussions.microsoft.com> wrote in message
news:66**********************************@microsof t.com...
Jim, could you possibly tell me what you are using to wrap everything up
in
one exe? If it is a commercial product (or free one) please let me know
at:

john [at] fluidnature dot com? thanks so much (especially if its something
i
can use!)
>> you said: >>>>>

We've conqured all of these problems by just sending out one EXE that
wraps
all of the code (DLLs, EXEs, etc.) into a single executable that doesn't
need any installed .Net frameworks (if that is what we choose to code the
app in) or any dependencies apart from Windows itself.

If you use .Net for your apps, the EXE is still really big, but if you use
something like C++ or even VB 6 your resulting exe is much smaller.

Since we are wrapping everything, .Net really has no advantages other than
webservice ease of use. And, we get to continue using our old skillset
and
thousands of dollars on third party controls without worrying about .Net
COM
interop screwing it up. (The Dart/PowerTCP activeX controls will not work
with .Net 1.1 - Studio 2003 Architect.)

No control installations, no registry mess, no DLL hell, no .Net framework
hell. Just a larger exe and no worries.
"Jim Hubbard" wrote:

"Gerry Hickman" <ge******@netscape.net> wrote in message
news:en**************@TK2MSFTNGP14.phx.gbl...
> "Jim Hubbard" <re***@groups.please> wrote in message
> news:ys********************@giganews.com...
>
>> The whole idea behind the .Net framework was to allow different
>> versions
> of
>> the framework and code to run side-by-side.
>
> You'll be lucky. It's DLL hell all over again. This is why internet
> Java
> was
> such a disaster. I remember the banks using it and then spending all
> day
> trying to troubleshoot end-users broken and disparate JVMs.
>
> .NET is just as bad. "Which version of .NET are my 200,000 customers
> using",
> "oops it won't work on that one". "Oh you've got XP gold", "You need
> Longhorn for that one", "You're on Win98SE". That's before you even get
> to
> service packs on hotfixes on the client's machine.


Damned right! In another thread, I had asked the question "Why is .Net
an
optional download?" If .Net is so important to the future of Microsoft
products, the .Net frameworks should be downloaded and installed
automatically along with security updates and such. It should be core to
the OS.

Even if one .Net framework is shipped with the OS, what about the next
version? These things have to be required (at least highly recommended)
updates to the OS.

Now, I know each .Net framework is a bloated, massive amount of code for
most people to download - so, the next question is why Microsoft didn't
use
the technology built into .Net to make .Net exe's download only the
portions
of .Net that they need to run, if those portions don't exist on the
machine
the exe is being launched on? If a .Net application can tell it doesn't
have
the DLLs required for a function and will request those downloads from
the
server hosting the program's exe, why couldn't each exe contain similar
code
for the .Net framework?

Beats the hell out of me.
>
> The whole thing is a mess, and can only get worse with Longhorn. They
> claim
> Longhorn will embrace .NET, but so far we have no credible DirectShow
> assemblies, and even if we did they'll fall way short of the
> capabilities
> of
> COM. Do they have an LSA in managed code yet? What about the LDAP API?
> Where
> is WinFS? Where are the native UNIX and Fibre SAN connectors?


I SO wish you weren't right......unfortunately, you are.
>
> All we've seen so far is the step backwards known as "Avalon" where
> current
> W3C UI markup will be replaced by proprietary "Windows Only" code, and
> how
> exactly will this help the Enterprise? "View your sales figures in a
> rotating 3D DirectX cube", LOL!


And Microsoft rolls on......

We've conqured all of these problems by just sending out one EXE that
wraps
all of the code (DLLs, EXEs, etc.) into a single executable that doesn't
need any installed .Net frameworks (if that is what we choose to code the
app in) or any dependencies apart from Windows itself.

If you use .Net for your apps, the EXE is still really big, but if you
use
something like C++ or even VB 6 your resulting exe is much smaller.

Since we are wrapping everything, .Net really has no advantages other
than
webservice ease of use. And, we get to continue using our old skillset
and
thousands of dollars on third party controls without worrying about .Net
COM
interop screwing it up. (The Dart/PowerTCP activeX controls will not
work
with .Net 1.1 - Studio 2003 Architect.)

No control installations, no registry mess, no DLL hell, no .Net
framework
hell. Just a larger exe and no worries.

Jim Hubbard

Jul 21 '05 #26

P: n/a
Not more than 4 hours sleep @ night all week......it's catching up to me.

Here's that
link.....http://www.sellsbrothers.com/news/sh...x?ixTopic=1646 .

Jim Hubbard

"Jim Hubbard" <re***@groups.please> wrote in message
news:2e********************@giganews.com...
Here's a link to Chris Sells' blog (that links to my blog) about the
program. It's called Thinstall, and it rocks!

Let me know if there is anything I can do to help.

Jim Hubbard
"fuul" <fu**@discussions.microsoft.com> wrote in message
news:66**********************************@microsof t.com...
Jim, could you possibly tell me what you are using to wrap everything up
in
one exe? If it is a commercial product (or free one) please let me know
at:

john [at] fluidnature dot com? thanks so much (especially if its
something i
can use!)
>>> you said: >>>>>

We've conqured all of these problems by just sending out one EXE that
wraps
all of the code (DLLs, EXEs, etc.) into a single executable that doesn't
need any installed .Net frameworks (if that is what we choose to code the
app in) or any dependencies apart from Windows itself.

If you use .Net for your apps, the EXE is still really big, but if you
use
something like C++ or even VB 6 your resulting exe is much smaller.

Since we are wrapping everything, .Net really has no advantages other
than
webservice ease of use. And, we get to continue using our old skillset
and
thousands of dollars on third party controls without worrying about .Net
COM
interop screwing it up. (The Dart/PowerTCP activeX controls will not
work
with .Net 1.1 - Studio 2003 Architect.)

No control installations, no registry mess, no DLL hell, no .Net
framework
hell. Just a larger exe and no worries.
"Jim Hubbard" wrote:

"Gerry Hickman" <ge******@netscape.net> wrote in message
news:en**************@TK2MSFTNGP14.phx.gbl...
> "Jim Hubbard" <re***@groups.please> wrote in message
> news:ys********************@giganews.com...
>
>> The whole idea behind the .Net framework was to allow different
>> versions
> of
>> the framework and code to run side-by-side.
>
> You'll be lucky. It's DLL hell all over again. This is why internet
> Java
> was
> such a disaster. I remember the banks using it and then spending all
> day
> trying to troubleshoot end-users broken and disparate JVMs.
>
> .NET is just as bad. "Which version of .NET are my 200,000 customers
> using",
> "oops it won't work on that one". "Oh you've got XP gold", "You need
> Longhorn for that one", "You're on Win98SE". That's before you even
> get to
> service packs on hotfixes on the client's machine.

Damned right! In another thread, I had asked the question "Why is .Net
an
optional download?" If .Net is so important to the future of Microsoft
products, the .Net frameworks should be downloaded and installed
automatically along with security updates and such. It should be core
to
the OS.

Even if one .Net framework is shipped with the OS, what about the next
version? These things have to be required (at least highly recommended)
updates to the OS.

Now, I know each .Net framework is a bloated, massive amount of code for
most people to download - so, the next question is why Microsoft didn't
use
the technology built into .Net to make .Net exe's download only the
portions
of .Net that they need to run, if those portions don't exist on the
machine
the exe is being launched on? If a .Net application can tell it doesn't
have
the DLLs required for a function and will request those downloads from
the
server hosting the program's exe, why couldn't each exe contain similar
code
for the .Net framework?

Beats the hell out of me.

>
> The whole thing is a mess, and can only get worse with Longhorn. They
> claim
> Longhorn will embrace .NET, but so far we have no credible DirectShow
> assemblies, and even if we did they'll fall way short of the
> capabilities
> of
> COM. Do they have an LSA in managed code yet? What about the LDAP API?
> Where
> is WinFS? Where are the native UNIX and Fibre SAN connectors?

I SO wish you weren't right......unfortunately, you are.

>
> All we've seen so far is the step backwards known as "Avalon" where
> current
> W3C UI markup will be replaced by proprietary "Windows Only" code, and
> how
> exactly will this help the Enterprise? "View your sales figures in a
> rotating 3D DirectX cube", LOL!

And Microsoft rolls on......

We've conqured all of these problems by just sending out one EXE that
wraps
all of the code (DLLs, EXEs, etc.) into a single executable that doesn't
need any installed .Net frameworks (if that is what we choose to code
the
app in) or any dependencies apart from Windows itself.

If you use .Net for your apps, the EXE is still really big, but if you
use
something like C++ or even VB 6 your resulting exe is much smaller.

Since we are wrapping everything, .Net really has no advantages other
than
webservice ease of use. And, we get to continue using our old skillset
and
thousands of dollars on third party controls without worrying about .Net
COM
interop screwing it up. (The Dart/PowerTCP activeX controls will not
work
with .Net 1.1 - Studio 2003 Architect.)

No control installations, no registry mess, no DLL hell, no .Net
framework
hell. Just a larger exe and no worries.

Jim Hubbard


Jul 21 '05 #27

P: n/a
Thanks! I would loan you some sleep if I had any...

"Jim Hubbard" wrote:
Not more than 4 hours sleep @ night all week......it's catching up to me.

Here's that
link.....http://www.sellsbrothers.com/news/sh...x?ixTopic=1646 .

Jim Hubbard

"Jim Hubbard" <re***@groups.please> wrote in message
news:2e********************@giganews.com...
Here's a link to Chris Sells' blog (that links to my blog) about the
program. It's called Thinstall, and it rocks!

Let me know if there is anything I can do to help.

Jim Hubbard
"fuul" <fu**@discussions.microsoft.com> wrote in message
news:66**********************************@microsof t.com...
Jim, could you possibly tell me what you are using to wrap everything up
in
one exe? If it is a commercial product (or free one) please let me know
at:

john [at] fluidnature dot com? thanks so much (especially if its
something i
can use!)

>>>> you said: >>>>>
We've conqured all of these problems by just sending out one EXE that
wraps
all of the code (DLLs, EXEs, etc.) into a single executable that doesn't
need any installed .Net frameworks (if that is what we choose to code the
app in) or any dependencies apart from Windows itself.

If you use .Net for your apps, the EXE is still really big, but if you
use
something like C++ or even VB 6 your resulting exe is much smaller.

Since we are wrapping everything, .Net really has no advantages other
than
webservice ease of use. And, we get to continue using our old skillset
and
thousands of dollars on third party controls without worrying about .Net
COM
interop screwing it up. (The Dart/PowerTCP activeX controls will not
work
with .Net 1.1 - Studio 2003 Architect.)

No control installations, no registry mess, no DLL hell, no .Net
framework
hell. Just a larger exe and no worries.
"Jim Hubbard" wrote:
"Gerry Hickman" <ge******@netscape.net> wrote in message
news:en**************@TK2MSFTNGP14.phx.gbl...
> "Jim Hubbard" <re***@groups.please> wrote in message
> news:ys********************@giganews.com...
>
>> The whole idea behind the .Net framework was to allow different
>> versions
> of
>> the framework and code to run side-by-side.
>
> You'll be lucky. It's DLL hell all over again. This is why internet
> Java
> was
> such a disaster. I remember the banks using it and then spending all
> day
> trying to troubleshoot end-users broken and disparate JVMs.
>
> .NET is just as bad. "Which version of .NET are my 200,000 customers
> using",
> "oops it won't work on that one". "Oh you've got XP gold", "You need
> Longhorn for that one", "You're on Win98SE". That's before you even
> get to
> service packs on hotfixes on the client's machine.

Damned right! In another thread, I had asked the question "Why is .Net
an
optional download?" If .Net is so important to the future of Microsoft
products, the .Net frameworks should be downloaded and installed
automatically along with security updates and such. It should be core
to
the OS.

Even if one .Net framework is shipped with the OS, what about the next
version? These things have to be required (at least highly recommended)
updates to the OS.

Now, I know each .Net framework is a bloated, massive amount of code for
most people to download - so, the next question is why Microsoft didn't
use
the technology built into .Net to make .Net exe's download only the
portions
of .Net that they need to run, if those portions don't exist on the
machine
the exe is being launched on? If a .Net application can tell it doesn't
have
the DLLs required for a function and will request those downloads from
the
server hosting the program's exe, why couldn't each exe contain similar
code
for the .Net framework?

Beats the hell out of me.

>
> The whole thing is a mess, and can only get worse with Longhorn. They
> claim
> Longhorn will embrace .NET, but so far we have no credible DirectShow
> assemblies, and even if we did they'll fall way short of the
> capabilities
> of
> COM. Do they have an LSA in managed code yet? What about the LDAP API?
> Where
> is WinFS? Where are the native UNIX and Fibre SAN connectors?

I SO wish you weren't right......unfortunately, you are.

>
> All we've seen so far is the step backwards known as "Avalon" where
> current
> W3C UI markup will be replaced by proprietary "Windows Only" code, and
> how
> exactly will this help the Enterprise? "View your sales figures in a
> rotating 3D DirectX cube", LOL!

And Microsoft rolls on......

We've conqured all of these problems by just sending out one EXE that
wraps
all of the code (DLLs, EXEs, etc.) into a single executable that doesn't
need any installed .Net frameworks (if that is what we choose to code
the
app in) or any dependencies apart from Windows itself.

If you use .Net for your apps, the EXE is still really big, but if you
use
something like C++ or even VB 6 your resulting exe is much smaller.

Since we are wrapping everything, .Net really has no advantages other
than
webservice ease of use. And, we get to continue using our old skillset
and
thousands of dollars on third party controls without worrying about .Net
COM
interop screwing it up. (The Dart/PowerTCP activeX controls will not
work
with .Net 1.1 - Studio 2003 Architect.)

No control installations, no registry mess, no DLL hell, no .Net
framework
hell. Just a larger exe and no worries.

Jim Hubbard



Jul 21 '05 #28

P: n/a
Well the problem is not with the hotfix concept for nontotally QA'd fixes,
but with MSFT thinking that offshore help desks provide the level of service
that their customers are entitled to. At least Dell finally (partially) got
the message. I fear that Gates and crew never will.

"Jim Hubbard" wrote:
Yet another hotfix alert (http://www.kbalertz.com/Feedback_823535.aspx) that
states "To resolve this problem immediately, contact Microsoft Product
Support Services to obtain the hotfix."

Whatever happened to automatic updates? Doesn't Microsoft know that
developers are busy people.....too busy to be stopped by this type of crap
every time Microsoft is alerted to something they missed in the software by
another developer (note: Microsoft rarely finds their own mistakes) ?

If it is a question of stopping unauthorized use of pirated .Net versions,
just have the upgrade functionality pass in the license info when it
requests a patch. Info no good? Then, no patch.

Get with the program Microsoft! You're supposed to make things easier, not
waste our time waiting on the phone for your off-shore "help".

When freeware routinely updates itself without user intervention, and for a
company that pushes things like webservices, this is really pathetic.

Jim Hubbard

Jul 21 '05 #29

P: n/a

Dear Friends:

Please advise if Microsoft visual.net 2003 active x GUI is compatible with
windows 98 and 2000. My programmer says it is compatible only with XP, I dont
think so....can someone please help.

Thanks a lot
Jul 21 '05 #30

This discussion thread is closed

Replies have been disabled for this discussion.