ActiveX Dead? Alternatives?

[Carl Daniel [VC++ MVP]]

Re: ActiveX Dead? Alternatives?

Ioannis Vranos wrote:[color=blue]
> I am not against ActiveX in particular, I do not know much about the
> technology anyway. My guess is, it is using Win32 API and thus it is
> restricted to it.[/color]

Any self-registering COM DLL qualifies as an Active-X control. As such
there's virtually no limit to what such a control might do (including host
the CLR and run managed code).

-cd

[Tommy Vercetti]

Re: ActiveX Dead? Alternatives?

Your client has specified a Microsoft non-.NET non-Java platform.
ActiveX is your only option. From a developer's perspective, it's older,
more complex, and less desirable to work with than .NET. But, it will be
supported and it's an adequate functional solution.

Often there's a conflict when developers want to use the latest and
greatest technology and clients want to stick with older technology
that's more widely deployed and entrenched that requires less upgrades.

It's easy to understand the perspective of each side; unfortunately,
business needs trump developer preference. In a situation like this, the
developers have to use the older and less sexy technology.

Strath-Clyde wrote:[color=blue]
> Thanks for the replies.
>
> 1) Sorry for the vague project outline. I'm afraid if I delve too much into
> it, I'd be violating a few policies. We develop enterprise apps for the
> healthcare industry, therfore, describing the server communication will
> reveal too much as this stage.
>
> 2) I understand the security issues but can not explain them or use them to
> defend my stance (to the team I mean). I know that we will have a problem
> reading/writing to the file system but I need to prove it not rant and and
> rave about it.
>
> 3) Our target audience is very controlled, though it will be phased to a
> more general audience soon. Being so, an activex control with severe
> permissions to the underlying OS "might" be viable but I doubt it. I'm the
> only developer in a group of 6 that has this nagging feeling that we're
> approaching this solution the wrong way.
>
> 4) The .NET Framework is not a viable solution to install for our clients -
> straight from the client's mouth.
>
> To finialize, the pressing issue I have is the direction Microsoft is taking
> regarding ActiveX components as described by my outline. Without using the
> framework, is activex the only way to go (java is not an option).
>
> Thanks again.
>
>
> "Strath-Clyde" wrote:
>
>[color=green]
>>I'm a die hard c# developer, developing win32 and web based enterprise apps
>>for last few years.
>>The development team I'm on is going down a path I feel is wrong.
>>I scoping out the web to knock their solution but of course, an alternative
>>is needed...
>>
>>1) We need a complex client application
>>2) This client app will need to communicate with a local (same box) and
>>remote server
>>3) It will need to read/write to the local file system
>>4) Easy to deploy with little footprint
>>5) Needs to be web based - viewable in a browser
>>
>>The development has decided to create an ActiveX client that they say will
>>meet the above requirements. It'll be developmed in Microsoft Visual C++.NET
>>using UNMANAGED code - as they do not want the .NET framework distrubuted to
>>the clients.
>>
>>I think this is the wrong approach as ActiveX is being phased out.
>>
>>Are they any alternatives?[/color][/color]

[Serge Baltic]

Re: ActiveX Dead? Alternatives?

C> Any self-registering COM DLL qualifies as an Active-X control.

Quite the opposite — any ActiveX control is a COM DLL. Not every COM DLL
is an ActiveX control, though.

--
Serge

[Serge Baltic]

Re: ActiveX Dead? Alternatives?

>> Since ActiveX may be written in unmanaged code, how are you going to[color=blue][color=green]
>> control whether it accesses the file system or not?[/color][/color]
IV> What I meant is that it is a file system of 64-bit OS, and XP x64
IV> unaware applications with such low level access may not work under
IV> XP 64. As you can see in the link provided, antivirus programs do
IV> not work under XP x64 RC2 for example:

Accessing filesystem is not that low level considered in the article. They
talk about the drivers, mostly. Just CreateFile will definitely go on to
live, at least for some time.
[color=blue][color=green]
>> Also, what is the security risk if you are running the ActiveX from a
>> local storage or approve it after downloading from the Internet?[/color][/color]
IV> I am not against ActiveX in particular, I do not know much about the
IV> technology anyway. My guess is, it is using Win32 API and thus it is
IV> restricted to it.

Yes. But WinAPI is no way low-level enough, from this point of view.

--
Serge

[Michael Viking]

Re: ActiveX Dead? Alternatives?


"Tommy Vercetti" <vercetti953@ho tmail.com> wrote in message
news:uIX4EQoHFH A.1500@TK2MSFTN GP09.phx.gbl...
SNIP>[color=blue]
> It's easy to understand the perspective of each side; unfortunately,
> business needs trump developer preference. In a situation like this, the
> developers have to use the older and less sexy technology.[/color]

Actually, it's not unfortunate at all. If developers had their way,
business people wouldn't be able to do anything without a fleet of geek to
help them. This constant "use the sexy new technology" drive does not make
anything better, and if it takes a year or two to really become proficient,
nobody's good at anything because by the time they really understand a
technology, there's a newer, sexier one beckoning. Sexier technology is the
siren song that lures developers into a constant state of mediocrity.

-Michael Viking

[Carl Daniel [VC++ MVP]]

Re: ActiveX Dead? Alternatives?

Serge Baltic wrote:[color=blue][color=green]
>> Any self-registering COM DLL qualifies as an Active-X control.[/color]
>
> Quite the opposite - any ActiveX control is a COM DLL. Not every COM
> DLL is an ActiveX control, though.[/color]

http://msdn.microsoft.com/library/default.asp?url=/workshop/components/activex/controls.asp

<quote>
In other words, a control, at the very least, is some COM object that
supports the IUnknown interface and is also self-registering.
</quote>

You're right, not every COM object is an Active-X control.

I'm also right - every self registering COM object IS an ActiveX control.

Note that to be an OLE Control, which is what most people think of when they
hear "Active X Control" requires much much more.

-cd

[Altman]

Re: ActiveX Dead? Alternatives?

Here is a quote from MS Longhorn site

What is the future of COM, OLE and in-place activation?

All of COM and OLE that you've come to know and love will live on in
Longhorn, although it won't be extended. COM and OLE aren't "dead," but they
are "done."




"Strath-Clyde" <StrathClyde@ho tmail.com> wrote in message
news:85F8117C-916A-4971-AC90-DAC5ED61A499@mi crosoft.com...[color=blue]
> I'm a die hard c# developer, developing win32 and web based enterprise
> apps
> for last few years.
> The development team I'm on is going down a path I feel is wrong.
> I scoping out the web to knock their solution but of course, an
> alternative
> is needed...
>
> 1) We need a complex client application
> 2) This client app will need to communicate with a local (same box) and
> remote server
> 3) It will need to read/write to the local file system
> 4) Easy to deploy with little footprint
> 5) Needs to be web based - viewable in a browser
>
> The development has decided to create an ActiveX client that they say will
> meet the above requirements. It'll be developmed in Microsoft Visual
> C++.NET
> using UNMANAGED code - as they do not want the .NET framework distrubuted
> to
> the clients.
>
> I think this is the wrong approach as ActiveX is being phased out.
>
> Are they any alternatives?[/color]