ActiveX Dead? Alternatives?

[Strath-Clyde]

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?

[Arnaud Debaene]

Re: ActiveX Dead? Alternatives?

Strath-Clyde wrote:[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[/color]
"Communicat e with a server" is so vague that we can't say anything about it.
What kind of communication? With what technology/abstraction level ?
[color=blue]
> 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[/color]

Whatever choice you make, 3 and 5 are antagonist IMHO. Although it is
possible to circumvent the browser's default security policy, it will get
you in endless distribution trouble unless you are in a very limited,
controled distribution system (but in that case, what is the use of
web-based app?). More important, it is against all and every principles of
security, and as a knowledgeable user, I would distrust strongely this kind
of solution.

Apart from that, I do not believe much in that kind of differences (You may
consider ActiveX as being "phased out"if you wish, it won't stop a correctly
written ActiveX do to it's job nicely). The most important point IMHO is the
level of expertise of the developement team, and with which technology they
are most at ease.

Arnaud
MVP - VC

[Carl Daniel [VC++ MVP]]

Re: ActiveX Dead? Alternatives?

Strath-Clyde wrote:[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]

Practially speaking, no. They could always make it a Java applet instead,
but that's a far worse choice IMO. If you're targeting IE only, it's
possible to host a .NET control in the browser, but then that requires the
framework.

Personally, I think they made the right call, given what you've outlined.

The path to a different solution is likely through challenging the
requirements. Who doesn't want the .NET framework on the clients? Is that
the end-users speaking, or is it the developer who already chose the
Acitve-X solution?

-cd

[Strath-Clyde]

RE: ActiveX Dead? Alternatives?

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=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]

[Withheld]

Re: ActiveX Dead? Alternatives?


For what it's worth, I know of several companies in different
industries that refuse to allow .Net on their corporate machines.
There is resistance, although I wouldn't presume to try to quantify it.


"Strath-Clyde" <StrathClyde@ho tmail.com> wrote in message
news:070F283C-55C0-4708-8800-C20D9198C4F3@mi crosoft.com...[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
> lients -
> 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]

[Ioannis Vranos]

Re: ActiveX Dead? Alternatives?

Withheld wrote:
[color=blue]
> For what it's worth, I know of several companies in different
> industries that refuse to allow .Net on their corporate machines.
> There is resistance, although I wouldn't presume to try to quantify it.[/color]


Well I guess after Longhorn and WinFX they will have to live with it. :-)



--
Ioannis Vranos

[Ioannis Vranos]

Re: ActiveX Dead? Alternatives?

Carl Daniel [VC++ MVP] wrote:
[color=blue]
> Practially speaking, no. They could always make it a Java applet instead,
> but that's a far worse choice IMO. If you're targeting IE only, it's
> possible to host a .NET control in the browser, but then that requires the
> framework.
>
> Personally, I think they made the right call, given what you've outlined.
>
> The path to a different solution is likely through challenging the
> requirements. Who doesn't want the .NET framework on the clients? Is that
> the end-users speaking, or is it the developer who already chose the
> Acitve-X solution?[/color]


How is ActiveX doing with upcoming Windows XP x64 (currently RC2) and
the 64-bit IE that it contains?


Still a .NET approach sounds a more reasonable solution to me, given the
..NET x64.



--
Ioannis Vranos

[Ioannis Vranos]

Re: ActiveX Dead? Alternatives?

Ioannis Vranos wrote:
[color=blue]
> Still a .NET approach sounds a more reasonable solution to me, given the
> .NET x64.[/color]


If such an approach exists.



--
Ioannis Vranos

[Carl Daniel [VC++ MVP]]

Re: ActiveX Dead? Alternatives?

Ioannis Vranos wrote:[color=blue]
> Carl Daniel [VC++ MVP] wrote:
>[color=green]
>> Practially speaking, no. They could always make it a Java applet
>> instead, but that's a far worse choice IMO. If you're targeting IE
>> only, it's possible to host a .NET control in the browser, but then
>> that requires the framework.
>>
>> Personally, I think they made the right call, given what you've
>> outlined. The path to a different solution is likely through challenging
>> the
>> requirements. Who doesn't want the .NET framework on the clients? Is
>> that the end-users speaking, or is it the developer who already
>> chose the Acitve-X solution?[/color]
>
>
> How is ActiveX doing with upcoming Windows XP x64 (currently RC2) and
> the 64-bit IE that it contains?[/color]

No idea.

I wouldn't be surprised to find a 32 bit x86 version of IE on 64 bit Windows
just for compatibility with all the IE plugins out there...

-cd

[Ioannis Vranos]

Re: ActiveX Dead? Alternatives?

Carl Daniel [VC++ MVP] wrote:
[color=blue]
> No idea.
>
> I wouldn't be surprised to find a 32 bit x86 version of IE on 64 bit Windows
> just for compatibility with all the IE plugins out there...[/color]


Yes, perhaps there will be one. For backwards compatibility with all the
vulnerabilities out there. :-)



--
Ioannis Vranos

[Tom Widmer]

Re: ActiveX Dead? Alternatives?

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.[/color]

You can read/write to the file system (I have an IE hosted activeX
control that does just that). You'll just have that annoying "Allow
Blocked Content" thing every time it comes up, thanks to the new
security in Windows XP SP2. You may also have to mark safe (e.g. LIE
about) the ActiveX control with a registry key to prevent a second
annoying dialog. You may have some security zone problems as well; the
websites in question will probably have to be added to the local
machines trusted sites list.

But, as I said, I have full file system access from an ActiveX control,
so unfortunately for you I have to report that it is possible, even
under XPSP2. Who knows about Win64 and Longhorn though?
[color=blue]
> 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).[/color]

Java would be nicer than ActiveX IMHO (having developed the heinous
application I mention above), but I doubt you'd be able to access the
file system at all in any case.

Given your requirements, ActiveX is the only possibility I can think of.

Tom

[Altman]

Re: ActiveX Dead? Alternatives?

From what I heard windows 64 bit has both the 32 and 64 bit versions of IE
on it.



"Carl Daniel [VC++ MVP]" <cpdaniel_remov e_this_and_nosp am@mvps.org.nos pam>
wrote in message news:%233i2zWgH FHA.896@TK2MSFT NGP10.phx.gbl.. .[color=blue]
> Ioannis Vranos wrote:[color=green]
>> Carl Daniel [VC++ MVP] wrote:
>>[color=darkred]
>>> Practially speaking, no. They could always make it a Java applet
>>> instead, but that's a far worse choice IMO. If you're targeting IE
>>> only, it's possible to host a .NET control in the browser, but then
>>> that requires the framework.
>>>
>>> Personally, I think they made the right call, given what you've
>>> outlined. The path to a different solution is likely through challenging
>>> the
>>> requirements. Who doesn't want the .NET framework on the clients? Is
>>> that the end-users speaking, or is it the developer who already
>>> chose the Acitve-X solution?[/color]
>>
>>
>> How is ActiveX doing with upcoming Windows XP x64 (currently RC2) and
>> the 64-bit IE that it contains?[/color]
>
> No idea.
>
> I wouldn't be surprised to find a 32 bit x86 version of IE on 64 bit
> Windows just for compatibility with all the IE plugins out there...
>
> -cd
>
>[/color]

[Ioannis Vranos]

Re: ActiveX Dead? Alternatives?

Altman wrote:
[color=blue]
> From what I heard windows 64 bit has both the 32 and 64 bit versions of IE
> on it.[/color]


Yes it is included. However I was not sure ActiveX could still run on it
, especially an ActiveX with file system access since this is a
relatively low level functionality, and do not know what also happens
with IE 64 vs ActiveX.


More info on the latest Windows XP RC2:

http://www.winsupersite.com/reviews/windowsxp_x64_preview2.asp

--
Ioannis Vranos

[Serge Baltic]

Re: ActiveX Dead? Alternatives?

>> From what I heard windows 64 bit has both the 32 and 64 bit versions[color=blue][color=green]
>> of IE on it.[/color][/color]
IV> Yes it is included. However I was not sure ActiveX could still run
IV> on it , especially an ActiveX with file system access

Since ActiveX may be written in unmanaged code, how are you going to control
whether it accesses the file system or not?

Also, what is the security risk if you are running the ActiveX from a local
storage or approve it after downloading from the Internet?

--
Serge

[Ioannis Vranos]

Re: ActiveX Dead? Alternatives?

Serge Baltic wrote:
[color=blue]
> IV> Yes it is included. However I was not sure ActiveX could still run
> IV> on it , especially an ActiveX with file system access
>
> Since ActiveX may be written in unmanaged code, how are you going to
> control whether it accesses the file system or not?[/color]


What I meant is that it is a file system of 64-bit OS, and XP x64
unaware applications with such low level access may not work under XP
64. As you can see in the link provided, antivirus programs do not work
under XP x64 RC2 for example:

"n addition to presenting this small subset of available x86
applications, I should note that XP x64 is incompatible with entire
classes of applications, including antivirus applications and security
suites (but not, curiously, antispyware solutions). Microsoft tells that
these antivirus applications won't work in XP x64 because they access
the system's kernel, which is 32-bit code in XP 32-bit but 64-bits in
x64. However, all major AV vendors, including Symantec and McAfee, are
allegedly working on x64-compatible upgrades."

[color=blue]
> 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]


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.



--
Ioannis Vranos