Adding a reference to a COM in VS2008

[=?Utf-8?B?QnJhc3NpY2FOaWdyYQ==?=]

Greetings,

Recently I upgraded to Windows Vista Ultimate and VS2008 with SQLExpress
2008. For the last several years I have been using Windows XP SP2 and VS2005
with SQLExpress 2005. All of the applications that I have been working on
for my clients have come over beautifully with one exception.

Most of my applications make use of references that are either part of the
CLR or are COMs. One of the COM applications installs fine, I can load and
start the software from the Start menu, but when I try to see the COM in the
Add Reference dialog, it does not appear. It is there on my XP machine.

Why would this program install and work fine and I can't see the COM
interface?

TIA,

Dale

[Mr. Arnold]

Re: Adding a reference to a COM in VS2008


"BrassicaNi gra" <brassica_nigra @community.nosp amwrote in message
news:DFCD2971-6865-4678-825F-4A69E2B3A0B7@mi crosoft.com...

Greetings,
>
Recently I upgraded to Windows Vista Ultimate and VS2008 with SQLExpress
2008. For the last several years I have been using Windows XP SP2 and
VS2005
with SQLExpress 2005. All of the applications that I have been working on
for my clients have come over beautifully with one exception.
>
Most of my applications make use of references that are either part of the
CLR or are COMs. One of the COM applications installs fine, I can load
and
start the software from the Start menu, but when I try to see the COM in
the
Add Reference dialog, it does not appear. It is there on my XP machine.
>
Why would this program install and work fine and I can't see the COM
interface?
>

Maybe, it's due to UAC and Virtualization stepping in and redirecting files
elsewhere, when it comes to C:\Program Files and C:\Windows, which could be
placed in hidden system folders.

http://juice.altiris.com/article/2665/folder-virtualization-concepts-windows-vista

[Mr. Arnold]

Re: Adding a reference to a COM in VS2008


""Jialiang Ge [MSFT]"" <jialge@online. microsoft.comwr ote in message
news:tyzEKrANJH A.8140@TK2MSFTN GHUB02.phx.gbl. ..

<snipped>

You know there are many features Vista has that are not know from a software
developer's or computer user's standpoint on how Vista is protecting the O/S
like Virtualization being one.

Here is another one ASLR as an example, and there are more things being done
under the hood of Vista particularly when UAC is enabled to protect the
machine. For my own personal computer usage, I'll never go back to XP, and I
await to see what else is being implemented in Windows 7.

I also know that nothing is bullet proof as long as human beings are
involved, but XP doesn't have it. And XP will remain a malware magnet, as
most users continue to run on XP with full admin rights on the Internet wide
open to attack, and they are being hammered, because the Limited user
account cannot be used effectively with solutions, as opposed to Vista and
Standard user.

Hopefully, these links will be working again. They were working last week.

<http://www.securitypro news.com/news/securitynews/spn-45-20060601ASLRJoi nsVistasBagOfTr icks.html>

<http://technet.microso ft.com/en-us/magazine/cc162458.aspx>

Address Space Load Randomization

Despite measures like Data Execution Prevention and enhanced compiler error
checking, malware authors continue to find buffer overflow vulnerabilities
that allow them to infect network-facing processes like Internet Explorer®,
Windows services, and third-party applications to gain a foothold on a
system. Once they have managed to infect a process, however, they must use
Windows APIs to accomplish their ultimate goal of reading user data or
establishing a permanent presence by modifying user or system configuration
settings.

Connecting an application with API entry points exported by DLLs is
something usually handled by the operating system loader, but these types of
malware infection don't get the benefit of the loader's services. This
hasn't posed a problem for malware on previous versions of Windows because
for any given Windows release, system executable images and DLLs always load
at the same location, allowing malware to assume that APIs reside at fixed
addresses.

The Windows Vista Address Space Load Randomization (ASLR) feature makes it
impossible for malware to know where APIs are located by loading system DLLs
and executables at a different location every time the system boots. Early
in the boot process, the Memory Manager picks a random DLL image-load bias
from one of 256 64KB-aligned addresses in the 16MB region at the top of the
user-mode address space. As DLLs that have the new dynamic-relocation flag
in their image header load into a process, the Memory Manager packs them
into memory starting at the image-load bias address and working its way
down.

Executables that have the flag set get a similar treatment, loading at a
random 64KB-aligned point within 16MB of the base load address stored in
their image header. Further, if a given DLL or executable loads again after
being unloaded by all the processes using it, the Memory Manager reselects a
random location at which to load it. Figure 7 shows an example address-space
layout for a 32-bit Windows Vista system, including the areas from which
ASLR picks the image-load bias and executable load address.