Slashdot Mirror
Mozilla 1.4 Alpha To Have ActiveX Support
quakeslut writes "According to the newly posted Mozilla Staff Minutes, Moz is set to have initial ActiveX support for the next alpha. ActiveX... be afraid... be very afraid."
← Back to Stories (view on slashdot.org)
If all this should have a reason, we would be the last to know.
OK, this is severly karma-whoring, but let's ask the source: Mozilla ActiveX Project.
There have been plug-ins for Mozilla to run ActiveX controls since before 1.0, so that's not new. I believe this just means that the code for making it possible for Mozilla to be used as an ActiveX control is getting into the trunk.
Among the interesting tidbit: CodeWeavers CrossOver Plugin 1.2 so you can host ActiveX controls in Linux now.
Nothing hugely earth-shattering, though.
Mozilla has had various bits of ActiveX supporting code available to those that want it for some time. There have been plugin wrappers that make ActiveX controls sort of work in Mozilla and Netscape. There has been a Gecko wraper that alows Mozilla's rendering engine to be embedded as an ActiveX control like MSHTML. Various Mozilla contributors have been interested in and working on this stuff for a long time. Some of this support was even available in the Communicator days. None of this is built in the default Mozilla releases and so Mozilla releases do not support ActiveX.
--Asa
This is merely another case of Slashdot editors not even looking at what they post - this is nonsense. For information on what ActiveX work *is* happening within the Mozilla project, visit Adam Lock's (the developer of mozilla ActiveX stuff) site. Try the FAQ.
If all the world's a stage, anyone who says they want better lighting spends far too much time in a dark theatre.
And how about the buffer overrun in programs signed by Microsoft? See http://slashdot.org/articles/02/11/21/1317229.shtm l?tid=172
Signing doesn't solve the problem because there are buggy programs that are signed. So anybody can distribute them and you will happily run it. And revocation doesn't work because nobody really does it.
The only reasonable solution is to have an on-line repository of known checksums. And any time you'd need to run something unknown, you'd check the MD5 sum of the program against the database.
It could be used instead of rpm -Va as well. You wouldn't need to trust the (potential modified) rpm database on your disk, you'd check against central database.
Anybody upto building such a thing?
An ActiveX control (widget) is nothing more than a software module that implements a raft of crufty interfaces (the interfaces are ugly on account of the legacy aspects, and few programmer know what they even are because they use the wizards in whatever development tools they are using to automatically barf out code) based on the COM specification, and an ActiveX container (such as a Visual Basic app or an IE page) is nothing more than a program that supports that raft of interfaces.
An ActiveX control is a Good Thing because it is the closest thing to a "software IC" in the Windows GUI world -- it is amazingly cross-language in the Windows world. The new .NET languages consume and produce ActiveX controls with ease. It is not such a good thing because an ActiveX control kinda assumes it has access to the entire Windows API, so it is really locked in to Windows.
Also, an ActiveX control on a Web page is typically a client-side thing, think Java applet only without the sandboxing, so besides MS-lockin, you completely blow security, and the MS answer to security is this lame signing business (Scouts honor, this control is secure!). But since it lacks sandboxing, it is really quite capable and powerful -- it is like running little Windows apps inside your browser.
Part of Miguel de Icaza's deal with his Mono initiative is that he would like to see the Open Source world have something as software IC-like as the ActiveX control, and he things that his clone of .NET is the way to do it with some degree of sandboxing by using .NET widgets as the standard instead of ActiveX.