ActiveX Dead? Alternatives?

[Guest]

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]

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

"Communicate with a server" is so vague that we can't say anything about it.
What kind of communication? With what technology/abstraction level ?

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

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

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?

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

 

[Guest]

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.

 

[Withheld]

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.

 

[Ioannis Vranos]

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.

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

 

[Ioannis Vranos]

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?

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]

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

If such an approach exists.

 

[Carl Daniel [VC++ MVP]]

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

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]

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

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

 

[Tom Widmer]

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.

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?

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

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]

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

 

[Ioannis Vranos]

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

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

 

[Serge Baltic]

From what I heard windows 64 bit has both the 32 and 64 bit versionsIV> 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?

 

[Ioannis Vranos]

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?

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

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

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.

 

[Carl Daniel [VC++ MVP]]

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.

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]

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.

 

[Serge Baltic]

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

Since ActiveX may be written in unmanaged code, how are you going toIV> 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.
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.

 

[Michael Viking]

SNIP>

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.

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