Alec
Mon Jan 30 09:08:13 CST 2006
Its client side requirements are: you are running 32-bit Windows and IE
5.x/6.x (and probably 7.x).
And of course .NET framework can be installed in such environment (but
not required to be pre-installed).
Security is an issue, right, and I know that. :)
There are two additional files required to be on the server side (IIS,
Apache, or any other web server),
one of them is a 7z decompressor dll packed in a cab, and the other is
"DotNetHost.7z", less than 300KB.
The 7z archive is always asked to be in the same web directory of the
ActiveX control, and the ActiveX control
doesn't work alone.
As my sample page contains a demo version of LagLoader.NET to do speech
to text smart client demo,
that demo version comes with a DotNetHost.7z which is functional only
at my own web sites.
So even if you get all the server side LagLoader.NET files from my
sample page, it won't work other where else.
So is the trial version, which is functional only at your local file
system or
http://localhost (but with full trust mode on).
Only if .NET assemblies come from my web sites (in the demo case) or
from your local side (in the trial version case),
LagLoader.NET will run the smart client code.
The lite edition provides only partial trust mode, like Microsoft's
sandbox plus .NET check/install functionaility
and scripting (for .net 2.0), so it harms nothing.
The real concern is the professional edition, which gives you the power
of fully trusted.NET smart clients.
LagLoader.NET will check codebase attribute of the OBJECT tag and the
path of the .NET assembly
containing the requested WinForm control class.
If they are not from the same web site or not both from your local file
system, it will stop to work.
There is no back door or undocumented MS tricks used.
Raymond Chen told, we can't host an ActiveX container in an ActiveX
control hosted in an ActiveX container,
and we can't host multiple .NET framework runtime versions in the same
executable instance.
What he told is theoratically true, and I am not going to fight against
that theorem by back doors.
I work around these issues by Win32 API SetParent(HWND),
making ActiveX control LagLoader.NET the parent window of .NET WinForm
control running in my Win32 hosting exe.
Why should it stop working in the future?
If you use WebBrowser control in your application, while the control an
ActiveX one,
there is an iexplore.exe started up for that control.
For Raymond Chen's theorem to hold,
the WebBrowser control and LagLoader.NET should work in the same way.
The hosting exe at the client side comes with the 7z archive downloaded
by the ocx.
It is the hosting exe deciding whether your smart client may be run
fully trusted or partial trusted,
just as Microsoft's ieexec.exe decided to run every smart client in a
partial trust sandbox.
I decided that partial trust is simply not enough for many works to be
done,
so I created a full trusted environment for smart clients.
If somebody thinks LagLoader.NET will do anything harmful to their
security,
they have the choice to refuse to install it when IE prompts them to
install the ActiveX control.
I am planing an update to my LagLoader.NET product activation process,
you may choose to lock your purchased copy of LagLoader.NET to your web
sites,
so that nobody else can pirate them and deploy them somewhere else.
Also, I am going to give a later version of LagLoader.NET the
capability to determine
if DirectX runtime or other system COM stuffs are installed.