Post by Alexander GrigorievPost by Hector SantosIn fact, we put out a notice for ALL our customers to begin calling
MICROSOFT for any issue they see related to OS updates. We are not going
to swallow the cost on this and if this continues I am seriously
contemplating contacting the FCC for antitrust violations. This is not a
laughing matter. While no one here needs to know any of this, MS
increasing behavior of breaking well established applications in the name
of solving their own security problems problems and possibly using the
opportunity to break WIN32 compatibility to force customers to upgrade is
unacceptable.
--
HLS
Microsoft goes to great lengths to avoid breaking application, even buggy
ones. But it can't do that for all buggy apps. Programmers make all kinds of
wrong assumptions, that only hold true in the particular OS version. And
sometimes they have to break compatibility because of security concerns. I
suspect your RPC issue is because of that.
I remember CEO of RealMedia testified at antitrust hearing that MS
intentionally broke their software. In the end it was found that the issue
was in the app in question. Go figure.
I agree.
However, and I am speaking only with the hope that it may trickle some
synergism with perhaps a MS lurker and in some Quality Circle meeting
he/she says:
"You know, we need to do a better job here. We should
not break the Good will of our long time ISV and
customer base.
Our Win32 RPC client/server application has been in the market since
1996. Highly engineered by top notch system engineers, and must say
pragmatic and conservative bunch who will do nothing that is
questionable or not well understood. This is not open source people
with poor coding habits based on the theory "others" will fix problems.
In addition, we have millions of hours of field operations across all
market segments and WIN32 operating systems. Installed on over
hundreds of thousands of in every market segment, thousands of which
are 24x7x265 critical mission operations, many of which had Microsoft
themselves test it to resolve issues, like in one case last year with
a EICON/DIVA virtual comm port driver found as the source creating
intermittent blue screens. Our input to was provide technical
operation information, a free enterprise copy and the WIN32 com
properties and timeout settings used. Microsoft found that problem on
behalf of this major corporation and that is just one case I happen to
remember. Microsoft is very aware of our software - or was.
But consider the dilemma:
14+ years of successful RPC server operations on all versions of
WIN32, finely tuned, no stupid assumptions, suddenly breaking with new
OS patches, then as the CTO and chief engineer, that begins to worry
you - anyone or should.
Outside of application specific changes, fixes, enhancement over the
years, nothing at the OS WIN32 level was at issue BY design again
because we want no surprises. We don't use anything that is "new per
se" or specific to one OS. This is not .NET. It is still VS 6.0
compiled code - again, on purpose. .NET dependency has too much
overhead, variant OS dependency and .NET is still a moving target. We
do have a .NET rebuilt version for over a year now - no need to
introduce it. Why cause more support issues when you don't have to
when the demand was not there for it.
We only had to make one change to the RPC server in its 14 years
related to the 2005/2006? DCOM fix MS made that restricted remote
(LAN) RPC clients. We don't use DCOM for server discovery, our
proprietary protocol predated DCOM, yet we still had to make a server
change to get around the new restriction to resolve a buffer overrun
issue in their DCOM protocol that had nothing to do with us.
I seriously doubt there is any "buggy" code or "wrong assumptions"
here at the RPC level, If you want to suggest a CHANGE in OS Win32
RPC interface consideration like there was for DCOM caused fix we had
to make, that would be different, but then again that is the sort of
the material for anti-trust.
The issue is the "behavior" that is increasingly becoming one, not
technical, but strategic with an increasingly obvious lower regard to
breaking existing, trusted and *installed* (again, INSTALLED)
applications in the presumed name of security in their belief the
industry mindset has changed enough over the years that this once
unacceptable practice would be acceptable today. It is not, but
unfortunately, the "scare of security threats" has been molded in a
way that it now sounds it is NOT OS related at all but rather a
natural phenomenon of life. Case in point? Your response and the
acceptance that its FINALLY OK to break software in the name of
security even when the software MAY not be related to the problem the
OS fix attempts to resolve.
There is one fortunate good thing here. So far it one report. We have
to pay more attention here in coming weeks/months to come. One thing
about our system is that you only hear from customers when something
happens. But we never known if an IT admin found a problem by updating
the OS and really don't have a choice by to revert because of the
critical operation need. They can't afford any down time. They know
MS screwed up their critical operation that was working perfectly fine
before a OS patch. So its many times its an easy choice for them.
Many times the IT admin knows NOTHING about our software other than
that it MUST be running on the box. We would love to get reports, but
that is not always the case. We did get one this week.
So we will have to see in weeks and months to come.
Finally, I understand the MS pressures here. But there is a
compromise. Microsoft SHOULD definitely consider to include within
the OS patching for security related issues, a AUTOMATIC White list
for INSTALLED applications. That is a far better solution than to
blindly *break* installed and trusted applications.
--
HLS