CreateProcess and error 740 (requires elevation)

[rogero]

I've been moving a program suite to Windows 7 and had failures from
CreateProcess() returning error 740 (process requires elevation)

After a bit of poking around this simply seems to be related to the
*name* of the target executable.

For example "dispatch.exe", which I think fails because it
contains the string 'patch'.

Does anyone know whether there is a list of *which* file names
are affected like this?

Regards,
Roger.

[Jochen Kalmbach [MVP]]

Hi rogero!

No, there is no "offical" list.. or at least I am not aware of any...

But you can take a look into the shim-database via the
Application-Compatibility-Toolkit.

But it is a very huge list and it makes almost no sence to look into it...

I made a short list here:
http://blog.kalmbach-software.de/2009/06/09/custom-installer-without-warning-dialog-trustedinstallerexe/

Here is an exerpt of the "possible" match:

<EXE typ="LIST">
<NAME typ="STRINGREF">*patch*</NAME>
<WILDCARD_NAME typ="STRINGREF">*patch*</WILDCARD_NAME>
<APP_NAME typ="STRINGREF">Patch</APP_NAME>
<VENDOR typ="STRINGREF">UNKNOWN</VENDOR>
<EXE_ID typ="BINARY" len="0x10"
guid="F1BB3897-95C4-044A-A21750356014B307" />
<APP_ID typ="BINARY" len="0x10"
guid="77314417-F36B-D848-AB3B42FA07284C82" />
<MITIGATION_OS typ="NULL" />
<MATCH_MODE typ="WORD" />
<MATCHING_FILE typ="LIST">
<NAME typ="STRINGREF">*</NAME>
</MATCHING_FILE>
<FLAG_REF typ="LIST">
<NAME typ="STRINGREF">GenericInstaller</NAME>
<FLAG_TAGID typ="DWORD">0x2d7b8</FLAG_TAGID>
</FLAG_REF>
</EXE>

--
Greetings
Jochen

My blog about Win32 and .NET
http://blog.kalmbachnet.de/

[Paul Baker [MVP, Windows Desktop Experience]]

If the process is written by you, you could include a manifest to control
the elevation requirement. This will override the guessing:
http://channel9.msdn.com/posts/jmazner/How-To-Tell-Vistas-UAC-What-Privelege-Level-Your-App-Requires/

I have seen it happen with applications called Setup.exe and an application
with "install" in the FileDescription in the VERSIONINFO resource, these are
already both mentioned in Jochen's blog.

Paul

"Jochen Kalmbach [MVP]" <nospa...@kalmbach-software.de> wrote in message
news:eqrgs7gj...@TK2MSFTNGP05.phx.gbl...

[rogero]

On 5 Jan, 14:06, "Paul Baker [MVP, Windows Desktop Experience]"

<paulrichardba...@community.nospam> wrote:
> If the process is written by you, you could include a manifest to control
> the elevation requirement.

Thanks to you both for the rapid replies.
Looks like a manifest is the best solution in my case.

Regards,
Roger.

[Remy Lebeau]

"rogero" <roge...@gmail.com> wrote in message news:3652c8bf-def1-4c4c...@l30g2000yqb.googlegroups.com...

> After a bit of poking around this simply seems to be related to the
> *name* of the target executable.

It can. UAC performs some heuristic analysis, called "Installer Detection" to determine if an executable might be an installer/uninstaller or updater so it can be elevated. This typically only applies to older apps that have not been updated to be UAC-aware yet.

> Does anyone know whether there is a list of *which* file names
> are affected like this?

Not an official list, no, though a few keywords are mentioned here:

http://msdn.microsoft.com/en-us/library/bb756960.aspx

--
Remy Lebeau (TeamB)

[Hector Santos]

Remy Lebeau wrote:

> "rogero" <roge...@gmail.com> wrote in message news:3652c8bf-def1-4c4c...@l30g2000yqb.googlegroups.com...
>
>> After a bit of poking around this simply seems to be related to the
>> *name* of the target executable.
>
> It can. UAC performs some heuristic analysis, called "Installer Detection" to determine if an executable might be an installer/uninstaller or updater so it can be elevated. This typically only applies to older apps that have not been updated to be UAC-aware yet.

I failed or question to understand the logistics behind all this
"elevation". Obviously, "bad guys" or those who just put a little
sweat into it, can easily circumvent all of this. It can only be
targeted at legacy applications (who those who had no need to change)
and these "GOOD GUYS" are the companies or developers who are hurt.

>> Does anyone know whether there is a list of *which* file names
>> are affected like this?
>
> Not an official list, no, though a few keywords are mentioned here:
>
> http://msdn.microsoft.com/en-us/library/bb756960.aspx
>

Many moons ago when our application was among the "top 100
applications" for windows, MS had contacted us to add our software to
some "installation" compatibility 'shim' or what have you. Something
regarding making it the installer was NT and not 95 when it was being
installed on 2000.

They should of done the same thing today with this DEP stuff.

Although we are not the top 100, but still an established application,
the issue is not that we can update our software, the issue is that
existing customers who update to newer versions of the OS all of a
sudden have problems and we get the support cost to find out what has
happen or to figure out how to mitigate it.

Oh well, times have changed no doubt and these conservative
engineering views don't seem to be important anymore - just DO IT and
let the chips fall where they may.

Don't get me wrong, higher elevation is "GOOD," especially in the USER
world, but sometimes MS does things to resolve their own security
flaws and the resolution hurts us. Like the DCOM exploit forcing MS to
restrict RPC binding across the LAN. We don't use DCOM for discovery.
Our solution predated MS DCOM. But it hurt us anyway.

There has to be a better way then to HURT a huge base of decades of
software products still active under Windows. Maybe there was no
choice, but I can understand it better if it actually SOLVED or CUT
DOWN on the bad guys. It doesn't and it certainly won't because they
can easily circumvent all this. So it only hurts existing GOOD GUYS
applications, who with no fault on there own, supported pure WIN32,
did things as it was expected and now newer WIN32 OSes or supported
WINS32 sub-systems are suspect to problems.

Just my opinion, no need to any debate.

Thanks

--
HLS

[Remy Lebeau]

"Hector Santos" <sant...@nospam.gmail.com> wrote in message news:ubW853mj...@TK2MSFTNGP06.phx.gbl...

> I failed or question to understand the logistics behind all this
> "elevation". Obviously, "bad guys" or those who just put a
> little sweat into it, can easily circumvent all of this.

Not really. Not without hacking into an admin account's password, anyway. UAC really locks things down now to make sure non-admins cannot perform admin tasks anymore, which they should not have been doing in the first place.

> It can only be targeted at legacy applications (who those who
> had no need to change)

Many legacy apps were coded using bad practices, doing things they should never have been doing without any security.administration in mind. UAC really only affects those apps that were badly programmed to begin with, forcing good practices.

> Although we are not the top 100, but still an established application,
> the issue is not that we can update our software, the issue is that
> existing customers who update to newer versions of the OS all of a
> sudden have problems and we get the support cost to find out what
> has happen or to figure out how to mitigate it.

Then you were likely amongst those developers who coded bad practices all along. We've all done it from time to time, and now we have to learn to code better for it.

> I can understand it better if it actually SOLVED or CUT DOWN on
> the bad guys. It doesn't and it certainly won't because they can easily
> circumvent all this.

And how do you think they actually do that?

> So it only hurts existing GOOD GUYS applications, who with no fault
> on there own, supported pure WIN32, did things as it was expected

No, they did not do things that were expected of them, or else they would not be getting bitten by it now as things get continuously locked down.

--
Remy Lebeau (TeamB)

[Alexander Grigoriev]

There is more than that. I've heard that Windows 2008+ (Vista, 7) x64 will
detect if you're trying to run an Install Shield (16 bit) installer, and
substitute a new executable. x64 is not able to run Win3 16 bit programs, so
such hack is necessary.

"Hector Santos" <sant...@nospam.gmail.com> wrote in message
news:ubW853mj...@TK2MSFTNGP06.phx.gbl...

[Hector Santos]

Remy Lebeau wrote:

> "Hector Santos" <sant...@nospam.gmail.com> wrote in message news:ubW853mj...@TK2MSFTNGP06.phx.gbl...
>
>> I failed or question to understand the logistics behind all this
>> "elevation". Obviously, "bad guys" or those who just put a
>> little sweat into it, can easily circumvent all of this.
>
> Not really.

No? Just adding SetProcessDEPPolicy(0) to your code is not a simple
circumvention?

> Not without hacking into an admin account's password, anyway.

> UAC really locks things down now to make sure non-admins cannot
> perform admin tasks anymore, which they should not have been doing
> in the first place.

Thats a different idea. "Breaking software" is another. At the very
least, it should POPUP an information dialog rather than GPF.

>> It can only be targeted at legacy applications (who those who
>> had no need to change)
>
> Many legacy apps were coded using bad practices, doing things they

> should never have been doing without any security.administration in
> mind.

Thats a generalization. This is not about "Bad Practices". Not every
company has unintelligent engineering, lack of security regards or
what I call "Loose" engineering. "legacy" is state of age but
nonetheless time tested, engineered with quality and excellent. In
fact, the better ones survive and don't need revamping - a targeted
goal in lower development cost, lower support cost and reuseability.
Applications don't need to change just for the sake of something "new."

Its about breaking existing applications.

>> Although we are not the top 100, but still an established application,
>> the issue is not that we can update our software, the issue is that
>> existing customers who update to newer versions of the OS all of a
>> sudden have problems and we get the support cost to find out what
>> has happen or to figure out how to mitigate it.
>
> Then you were likely amongst those developers who coded bad

> practices all along. We've all done it from time to time,
> and now we have to learn to code better for it.

Thats not the case. The CODE was solid. It only needed
SetProcessDEPPolicy(0) to resolve it.

>> I can understand it better if it actually SOLVED or CUT DOWN on
>> the bad guys. It doesn't and it certainly won't because they can easily
>> circumvent all this.
>
> And how do you think they actually do that?

At SetProcessDEPPolicy(0) to your code or at the DisableNXxxxxx String
to the registry.

>> So it only hurts existing GOOD GUYS applications, who with no fault
>> on there own, supported pure WIN32, did things as it was expected
>
> No, they did not do things that were expected of them, or else

> they would not be getting bitten by it now as things get
> continuously locked down.

So is that why the ATL virtual class thunking framework borrowed from
the old OWL framework is and was bad code?

The RULES were followed for the established Coding Practices of the
Day. You can't call that "Bad Coding" or not following design
expectations. They were 100% design to the well establishing coding
specifications.

A GPF is not expected and the fact is it all depends on the flavor of
Windows and what patches or updates were done. Where is the
consistency in that?

Anyway my point they could of done better in dealing with established
applications and not passing the buck to users and developers.

Here is a good idea for Microsoft:

When another major DEP Like or security change requirement is forced
upon them, during the OS upgrade process, it should ask the ADMIN or
USER if "SNAPSHOT" of the working system should be white listed.

"Do you want to automatically white list existing
safe applications already installed on the system?"

[ NO ] [ YES, PLEASE DON'T BREAK MY SOFTWARE ]

"NOTE: Only select YES if the machine has been
certified as clean of viruses."

If Yes, it will scan all installed applications and white list them
and/or maybe on a prompt or suspect basis ask the user.

Everyone is a winner and no freaking surprise on anyone. :)

Thanks

--
HLS

[Wilson, Phil]

The issue with installer programs is that you can't fix them. The only way a
company can correct the fact that "Wonderful Software 2.0" (that you bought
in 2005) won't install because of an elevation issue (in its setup.exe) is
to ship you another install image or CD, and that's not realistically going
to happen. The MS solutions to this include things like installer
elevation, and compatibility settings so that, for example, "Wonderful
Software 2.0" thinks it's installing on XP and not Vista.

Security is never about just one thing that could be circumvented. The
overall strategy is about defense in depth, and UAC, DEP, service session
isolation, firewalls, encryption, secure DCOM, and so on are some of the
pieces that help.It's also relevant that the recent Security Intelligence
Report (SIR) shows that the vast majority of attacks are no longer directed
at the OS or the browser, but at 3rd party apps, and that means that the
good guys need to use these tools. I don't know what your app is, but I
assume the that last thing any of us needs is a published security
vulnerability.
--
Phil Wilson
The Definitive Guide to Windows Installer
http://www.apress.com/book/view/1590592972

"Hector Santos" <sant...@nospam.gmail.com> wrote in message
news:ubW853mj...@TK2MSFTNGP06.phx.gbl...

[Remy Lebeau]

"Hector Santos" <sant...@nospam.gmail.com> wrote in message news:eFsJx2pj...@TK2MSFTNGP06.phx.gbl...

> No? Just adding SetProcessDEPPolicy(0) to your code is not a
> simple circumvention?

To circumvent UAC? I doubt that. UAC and DEP are separate and unrelated technologies. UAC protects API functions from performing unauthorized tasks. DEP protects memory blocks from executing unauthorized code. Besides that, SetProcessDEPPolicy() requires the system admin to have configured DEP to allow apps to Opt in/out of DEP protection, which is not always the case.

> So is that why the ATL virtual class thunking framework borrowed from
> the old OWL framework is and was bad code?

Dynamically allocating a thunk is not bad code. There are plenty of valid usages for it (Borland's VCL uses it for its window procedues, for instance). Allocating a memory block that is specicially intended for running executable code (has PAGE_EXECUTE_... flags applied to it) is not disallowed by either UAC or DEP. DEP prevents non-executable memory from running executable code. It does not block intentionally-executable memory.

--
Remy Lebeau (TeamB)

[Hector Santos]

Thanks for your input Phil.

I think a possible solution for MS is to offer an automatic "exempt"
or white list scan for pre-installed applications during any security
hot fix related to DEP, UAC or whatever it is that concerns MS own
products or OS features but the solution may affect other applications.

Do you wish to automatically exempt trusted
installed applications from any security elevation?

The point is that most customers will have established setups and
trusted installed applications AT the moment of an OS upgrade or
security hotfix and that any new OS security measures can hurt some of
the trusted installed applications.

From the USER or ADMIN standpoint, the OS security upgrade process
SHOULD exempt these established installations. Failure of the
established installed application is *not* expected. When that
happens, it is usually the application vendor that gets the support
incident first.

I think this is a reasonable QA compromise to help reduce support cost
on both ends - MS and her tertiary market of vendors.

Thanks

--
HLS

[m]

IMHO, well designed and written software has been immune to these issues;
beyond the obvious interference of security popups.

In my own case, having recently certified our APPs for Windows 7 / Server
2008 R2, there were no code changes necessary and we have not manifests etc.
at all. The principal code base was originally targeted at NT 4, and except
for the change to an MSI installer, has functioned correctly in every
version of Windows since without changes. Now many pieces have changed
since then, but if I want to I can still install and run my circa 1997
version 1.2 (first stable release) on my multi-core Windows 7 desktop.

"Hector Santos" <sant...@nospam.gmail.com> wrote in message

news:OxDLUexj...@TK2MSFTNGP05.phx.gbl...

[Jochen Kalmbach [MVP]]

Hi m!

> pieces have changed since then, but if I want to I can still install and
> run my circa 1997 version 1.2 (first stable release) on my multi-core
> Windows 7 desktop.

Yes, you can!

But:
IF you read registry keys from HKLM, it will sometimes not read the
"correct" value, if you previously wrote to HKLM without a manifest (or
some other programm).
The same is true for files under "Program Files"...

You should at least use a Vista-Manifest to avoid these problems... and
also a manifest is the *only* way to overcome filename-conflicts with
the Shim database...

[Paul Baker [MVP, Windows Desktop Experience]]

Agreed. What everyone else is talking about are defects and hacks :)

Paul

"m" <m@b.c> wrote in message news:eli1HCNk...@TK2MSFTNGP06.phx.gbl...

[Paul Baker [MVP, Windows Desktop Experience]]

Borland Delphi 7 does not mark it's SOAP client code executable, therefore
it violates DEP :) Reports on the Internet suggest this was fixed in Delphi
2009, but I cannot find a record of it in Embarcadero QC.

"Remy Lebeau" <no....@no.spam.com> wrote in message
news:e%23ZzPwvj...@TK2MSFTNGP02.phx.gbl...

[Hector Santos]

Wilson, Phil wrote:

> The issue with installer programs is that you can't fix them. The only
> way a company can correct the fact that "Wonderful Software 2.0" (that
> you bought in 2005) won't install because of an elevation issue (in its
> setup.exe) is to ship you another install image or CD, and that's not
> realistically going to happen. The MS solutions to this include things
> like installer elevation, and compatibility settings so that, for
> example, "Wonderful Software 2.0" thinks it's installing on XP and not
> Vista.
>
> Security is never about just one thing that could be circumvented. The
> overall strategy is about defense in depth, and UAC, DEP, service
> session isolation, firewalls, encryption, secure DCOM, and so on are
> some of the pieces that help.It's also relevant that the recent Security
> Intelligence Report (SIR) shows that the vast majority of attacks are no
> longer directed at the OS or the browser, but at 3rd party apps, and
> that means that the good guys need to use these tools. I don't know what
> your app is, but I assume the that last thing any of us needs is a
> published security vulnerability.

In the past week, we got two reports:

1) Customer having trouble reinstalling from CD in his new Windows 7
machine. His version is OLD which had the old InstallShield 16
bit initial Setup.exe. I think it might still but I don't know
as we use INNO today. We told him to update or CALL MICROSOFT.

2) On Friday, today, a report of a customer updating to XP SP3 that
added two security patches. Once done, our RPC server could no
longer start. He had a 1 year old version of our server with
no expectation of failure related to any RPC issue. We told him
to CALL MICROSOFT! The customer decision was to FIRST revert
to an backed up version of XP before the the update was done.

In 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

[David Craig]

I wonder what the Federal Communications Commission has to do with antitrust
activities other than they claim exclusive rights over all the broadcast
spectrum.

"Hector Santos" <sant...@nospam.gmail.com> wrote in message

news:uYeN8Tml...@TK2MSFTNGP02.phx.gbl...

[Hector Santos]

Touche with the typo.

Bye.

David Craig wrote:

--
HLS

[Alexander Grigoriev]

"Hector Santos" <sant...@nospam.gmail.com> wrote in message

news:uYeN8Tml...@TK2MSFTNGP02.phx.gbl...

>
> In 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.

[Hector Santos]

Alexander Grigoriev wrote:

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

[m]

Should that automatic white list also include the malware that the user has
had installed but hadn't noticed yet? This kind of thing is never as black
and white as it might seem.

As a side note, the fact that you have already needed to patch your code
because of a change to an 'unrelated' component shipped by Microsoft, should
reduce your confidence in your code. It sounds like you have isolated the
problem to a specific hotfix, but I suggest that rather then ranting, you
first find out what the problem actually is (on a binary level) and then
repost so we can better assess whether you have a case.

IMHO, the use of the 'net' .NET framework, or the obsolete VC6 compiler has
no bearing on whether good engineering practices have been employed. All it
indicates, combined with the complaint about Windows 7 behaviour months
after retail release, is that you have chosen a specific technology platform
and are not interested in changing. This is neither good nor bad, but does
have consequences.

"Hector Santos" <sant...@nospam.gmail.com> wrote in message

news:u$7vcExlK...@TK2MSFTNGP05.phx.gbl...

[Pavel A.]

"Hector Santos" <sant...@nospam.gmail.com> wrote in message

news:u$7vcExlK...@TK2MSFTNGP05.phx.gbl...
.............

> Our Win32 RPC client/server application has been in the market since 1996.
> Highly engineered by top notch system engineers, and must say

............

> 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 ........

Ok, then you have a relatively high profile issue.
The MS product support is exactly for this.

Regards,
--pa

[Hector Santos]

m wrote:

> Should that automatic white list also include the malware that the user
> has had installed but hadn't noticed yet? This kind of thing is never
> as black and white as it might seem.

Sure, but using pareto's principle, MOST systems would have more trust
on what is already installed, especially in critical mission
applications setups and operations. You can't presume that ALL
MACHINE are prone to uncertainty and non-understanding by the
administrators.

The bottom line is that any excuse to blindly break working operations
really doesn't hold.

> As a side note, the fact that you have already needed to patch your code
> because of a change to an 'unrelated' component shipped by Microsoft,
> should reduce your confidence in your code.

No it doesn't. Not at all. I think there would be more people than
not to not think that way. Especially in systems that have years of
development into it. Do not assume people are STUPID.

> IMHO, the use of the 'net' .NET framework, or the obsolete VC6 compiler
> has no bearing on whether good engineering practices have been
> employed.

So all those million dollars engineerings investment and years was a
fallacy? It doesn't hold water.

What is a fallacy is the presumption that declaring something obsolete
and adding additional layers of overhead that in many areas is still a
moving target and unsettled is better for you.

The evidence shows the presumption is not very strong at all.

The problem here is long time problem with the MS OS vs MS APPLICATION
integration idea with Microsoft - a basic argument in Anti-trust and
still open idea and need to possibly split the two organizations. A
forgotten issue I must say, that MS seems to be taken advantage.
Maybe a wake up is necessary with the new Administration. A MS
application was broken and increasingly, MS uses the opportunity to
use an OS fix as a way to address the problem and to strategically
force upgrades by breaking existing applications. Thats the problem here.

--
HLS

[Pavel A.]

"Hector Santos" <sant...@nospam.gmail.com> wrote in message

news:ukRaql#lKHA...@TK2MSFTNGP02.phx.gbl...
......

> Especially in systems that have years of development into it. Do not
> assume people are STUPID.

Couple of years ago, I worked in some Monsters Inc, and had to deal with
a very embarrassing bug reported by a major customer.
Until this happened, we believed that the product is stable. It has been
installed in
millions of computers, and tested by a great team, using all the state of
the art
methods. And still this happened, when a new 3rd party component slightly
changed the timing.
After few lessons like this, would never assume anything.

> The problem here is long time problem with the MS OS vs MS APPLICATION
> integration idea with Microsoft - a basic argument in Anti-trust and still
> open idea and need to possibly split the two organizations. A forgotten
> issue I must say, that MS seems to be taken advantage. Maybe a wake up is
> necessary with the new Administration. A MS application was broken and
> increasingly, MS uses the opportunity to use an OS fix as a way to address
> the problem and to strategically force upgrades by breaking existing
> applications. Thats the problem here.

Re. the new Administration: they are planning their own upgrades to The
System...
Possibly, with similar effect on many our apllications...

Regards,
--pa

[Paul Baker [MVP, Windows Desktop Experience]]

I find there to be too much blame in the software industry.

I do not believe that Microsoft is out to break anything, in fact I believe
they have had a pretty good track record of innovating without breaking
stuff. Windows is also full of compatibility shims and old compatibility
hard-code to "unbreak" a popular application for which either there are too
many unpatched installations out there or the vendor was unwilling to fix
it. I have seen some special behaviour targetted at "unbreaking" only
Microsoft applications, but I have seen much more special behaviour
targetted at "unbreaking" badly behaved independant applications as well.

RealMedia should have debugged like Real programmers before taking legal
action. This is incompetence on *RealMedia's* part. Too many times I have
seen support articles on Microsoft's and an ISV's web site that mirror one
another, essentially blaming the other for the incompatibility and passing
the book. Come on, we can do better than that! Don't fall into the same
trap! Usually there are factors on both sides, and both sides need to
contemplate the best possible solution. It may come from one or both. It may
be a software change or merely a documentation change.

There will always be incompatibilities between software, especially if
writte by different vendors. It's inevitable. I am not denying that your
developers are top notch people, but even the most expert of them is not a
mind reader, cannot glean much more than the documentation says and is not
able to predict the future. All we can do is try our best to follow best
practices and write defensive code and the incompatibilities should be rare.

If you choose not to support and debug these incidents, that is certainly an
understandable choice. Believe me, I totally understand from a business
perspective. It could very well be a significant amount of resources you
have to throw at it, or it could not. It may make sense if you can deal with
a relatively low number of affected customers. But understand also that the
cause is unknown and you may never find the real cause, besides "Microsoft
sucks", if you do not look. Taking it to court is a cop out and it will not
stand up without evidence that it lies entirely on Microsoft's side *and*
that it is deliberate. You will need to debug to get the former information
anyway. It would actually be way more resources that way. I hope, for your
sake, that you said that only out of frustration.

Paul

"Hector Santos" <sant...@nospam.gmail.com> wrote in message

news:u$7vcExlK...@TK2MSFTNGP05.phx.gbl...

[m]

Well, industry consensus would be that VC 6 is obsolete. You may have
misunderstood my point, but that isn't necessarily a good reason not to use
it.

Consider for a moment what you are saying. You have told us that your
software, by virtue of its age and the number of dollars / man-hours
invested, is perfect and so any failure must be the fault of Microsoft.
This statement is clearly an overstatement of the synthesis of your remarks,
but, notwithstanding any facetiousness, is accurate (not precise). You have
told us all about what MS has done to break your code, but not about what
you have had to do, or might have to do, to fix it. This indicates, at
least to us, that you don't know what you might have to do to fix it, and
are simply raising hue and cry.

From a probabilistic point of view, the occurrence of a single issue of a
nature, greatly increases the likelihood of discovering another because it
means that the program, either by virtue of its nature, or its environment,
or the means thru which it was constructed, is susceptible to such issues.
This is not programming, nor technical in any way, but simple logic.

Also, to win a lawsuit in the USA you would need to prove either:
1) malice on the part of Microsoft; or
2) anti-trust.

In the fist case, you would need documentary evidence that Microsoft, or its
agents, deliberately sought to undermine your commercial venture by breaking
compatibility with legacy versions of your application - very hard

And in the second case, you would need to demonstrate at least that the
public interest is damaged by not including support for legacy versions of
your application in newer operating systems - nearly impossible.

because the obvious counter argument, supported by your own sentiments, is
that the product, in its existing published form, was designed for a
specific platform and not for an arbitrary future operating system. And
hence one should expect it not to work, but if it does then it is a bonus.

Remember that Truth and Justice do not reign in earth, and content yourself
with the consequences.

"Hector Santos" <sant...@nospam.gmail.com> wrote in message

news:ukRaql#lKHA...@TK2MSFTNGP02.phx.gbl...

[Hector Santos]

m wrote:

> Consider for a moment what you are saying. You have told us that your
> software, by virtue of its age and the number of dollars / man-hours
> invested, is perfect and so any failure must be the fault of Microsoft.

No, that was not stated and people who known me over the years here
know that is FAR from what was stated. You should understand the
points before commenting.

--
HLS

[Hector Santos]

Hector Santos wrote:

If it will help, the question of FAULT is not the issue. MS made a
decision. I question that decision or better said, how it was approached.

Your angle, which I really don't wish to give much attention to, is
based on that if a decision is made it is MORE often based on the
premise that most, if not all, effected software was incorrectly
written in the first place. That many-years of software engineering
where when uncertainty is a TABOO and not part of the equation is a
fallacy and doesn't apply. That people here are really not that
intelligent and you (generally speaking) know better than them. That
14 years of commercial Win32 products design and development means
nothing. I'm not going to fall into this rhetorical judo position that
is akin to the proverbial no-win question of

"When was the last time you beat your wife?"

In short, I will say that the argument falls flat when in fact, a
system was well designed following software practices (which you
probably can't define without argument) and yet a change is required
not on a technical basis, but a subject policy decision.

Veterans of the Microsoft development market knows exactly what is
being pointed out.

Believe it or not, the comments is about hope - that Microsoft, as
they evolved and that evolution increasingly includes a greater need
to break Win32 compatibility, that it is done with a greater regard
and approach that does not put or minimizes the burden on vendors.

I am speaking of integrity and software engineering ethics. As other
as pointed out and it was well understood, MS does not attempt to
break software and has historically done things to circumvent issues.

I'm concern that this mentality is increasingly being disregarded. It
might be due to the new project engineers and management. I
personally began to concern when Ray Ozzie came on board which in
summary, his very nature will naturally create more contention issues
in the area of MS OS vs MS APPLICATION integration, in addition, the
increasing advantage the using "scare of security" as a means to
promote change with less liability when in years past, and still today
when push comes to shove, it as a both a illegal and technical
practice (See UCITA, Article 2B). Before responding, research and
study the points.

--
HLS

[Jonathan de Boyne Pollard]

In the fist case, you would need documentary evidence that Microsoft, or its agents, deliberately sought to undermine your commercial venture by breaking compatibility with legacy versions of your application - very hard

Here's some irony: This (sub-)thread began with M. Santos railing against installer detection and elevation, which is a feature that exists in order to provide compatibility with existing installation programs, and to stop them from breaking.

"Legacy" is not a pejorative, by the way.  M. Santos has not died and left things in xyr will.

[m]

I am sorry that you see it this way. Good luck with your resolution.

"Hector Santos" <sant...@nospam.gmail.com> wrote in message

news:#12PqfZm...@TK2MSFTNGP05.phx.gbl...

[Paul Baker [MVP, Windows Desktop Experience]]

I see both sides, though I tend to be more alligned with "m"'s point of
view.

The thing that is not being said here is that this is largely speculation
unless someone does the debugging work to figure out what the cause of the
problem is. Until you do that, you do not know the cause and cannot make any
assertions about the cause, development skills and ethics, legal
responsibilities, quality, fault (low on your list, I understand), etc....
It might be helpful to do the debugging work and post here what "broke" so
we can debate that.

Paul

"m" <m@b.c> wrote in message news:uPsgZtkm...@TK2MSFTNGP05.phx.gbl...

>I am sorry that you see it this way. Good luck with your resolution.
>
> "Hector Santos" <sant...@nospam.gmail.com> wrote in message
> news:#12PqfZm...@TK2MSFTNGP05.phx.gbl...
>> Hector Santos wrote:
>>
>>> m wrote:
>>>
>>>> Consider for a moment what you are saying. You have told us that your
>>>> software, by virtue of its age and the number of dollars / man-hours
>>>> invested, is perfect and so any failure must be the fault of Microsoft.
>>>
>>>
>>> No, that was not stated and people who known me over the years here know
>>> that is FAR from what was stated. You should understand the points
>>> before commenting.
>>
>> If it will help, the question of FAULT is not the issue. MS made a
>> decision. I question that decision or better said, how it was
>> approached.

[etc]