Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Quality Control Testing with Win2000 Service Packs

0 views
Skip to first unread message

John Olbert

unread,
Sep 8, 2003, 11:48:24 PM9/8/03
to
We have a large application (the Exe is about 10 mb
Released) built as a C++ unmanaged Solution under Vs2003.
This App is targeted for Win2000. The latest Service Pack
for Windows 2000 has presented us with some problems.

Because we are an ISO 9000 company supplying software to
the drug industry we have strict requirements on the need
for retesting when any changes may effect the behavior of
our software.

Is there any documentation or tools that would help guide
us in deciding if a particular resolultion of a problem
(usually associated with a Microsoft Q number) in the
Service Pack could require us to retest our software.

Any help or suggestions would be appreciated. The latest
Windows 2000 Service Pack hits many areas and covers many
problems. It could have a very large impact on our
retesting requirements unless we can find a way to focus
only on those changes that effect the OS support functions
we use.

Again, any help or suggestions would be appreciated.

Thanks.

--John Olbert

Ivan Brugiolo [MSFT]

unread,
Sep 9, 2003, 2:32:12 AM9/9/03
to
You can use the approach of the transversed binaries.
If your applicaiotn uses OS-supplied DLLs a.dll, b.dll and c.dll,
then you can calculate the transitive closure of the dependencies,
and from that you can see if the fixes included in the
service pack have touched your set of binaries.
Unfortunately for you almost every service pack touches ntdll.dll,
kernel32.dll, ole32.dll,
that pretty much is equivalent to say that it touches everything you may
care about.

Moreover, there are changes in ceertain components
that expose old problems in others.
For example: an application that used to survive
a failure to call a certian API may suddenly start leaking if
that API actually starts performing some real cleanup.
A heap overrun even of few bytes was almost always fine on Win9x,
but it almost fatal on NT, and NT has kept adding new features
to the heap code that may expose 'forgotten' bugs
in the application or in other parts of the OS.
I could make more concrete examples, but the problem of the dependencies
is really practically impossible to figure-out in any systematic and
dependable way.

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of any included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm


"John Olbert" <John....@perkinelmer.com> wrote in message
news:42cb01c37685$38781e70$a301...@phx.gbl...

0 new messages