IE7, Javascript, the WebBrowser control and bugs
Problem
Internet Explorer 7 (IE7) has been released. Applications around the world are breaking. … Well at least mine failed.
If you use the WebBrowser control in .NET applications or shdocwv ActiveX control you may hit this issue.
If you load the html by navigating to “about:blank” and then using DocumentText, AND you are including a script (using for example <script src=”somefile.js” language=”Javascript” type=”text/javascript”></script>) your script will effectively not be included. The main symptom is a “Error: Invalid Character” message or simply script failure.
This means that your other scripts and events in the page will fail. Most probably this is a security measure (I have a theory about it but before that .. the solution).
Solution : embed the Javascript in the HTML. You hoped for something better right ?
Anyway embedding the script in the HTML solves the problem and if you are setting DocumentText from your code chances are it’s either generated by an XSLT (in which you can use either a msxsl javascript to include a file or a couple of xsl:include / xsl:apply-template without many side effects) or from your code (in which case.. well you are the programmer who did it, find a clean solution ;)).
Now, why have they introduced this change?
Probably they fear the scenario where a Javascript injects in some way in the DocumentText the include of a local file (along with some copy of itself) and then uses the data which now is in DocumentText in some .. evil way. I’ll try to forge some proof of concept demo.. if that is possible at all of course.
Edit
I’ve found this discussion [forums.microsoft.com] which propose a number of other interesting solutions.
Another interesting page with registry keys (process wide) for IE7 is here [msdn.microsoft.com].
memcpy in vb.net (x86 only)
This is a small memcpy implementation in VB.Net (x86 only! — x64 version to follow)
#If PLATFORM = “x86″ Then
<system .Runtime.InteropServices.DllImport(”kernel32.dll”)> _
Private Shared Sub RtlMoveMemory(ByVal Destination As Int32, ByVal Source As Int32, ByVal Length As Int32)
End Sub
Public Sub MemCpy(ByVal dstbase As IntPtr, ByVal dstofs As Integer, ByVal srcbase As IntPtr, ByVal srcofs As Integer, ByVal len As Integer)
RtlMoveMemory(dstbase.ToInt32 + dstofs, srcbase.ToInt32 + srcofs, len)
End Sub
Public Sub MemCpy(ByVal dstbase As IntPtr, ByVal srcbase As IntPtr, ByVal len As Integer)
RtlMoveMemory(dstbase.ToInt32, srcbase.ToInt32, len)
End Sub
Public Sub MemCpy(ByVal dstbase As Integer, ByVal srcbase As Integer, ByVal len As Integer)
RtlMoveMemory(dstbase, srcbase, len)
End Sub
#End if
Helper application for COM interop in .NET
A common usage of COM interop in .NET is using Active Scripting (or the Microsoft Script Control) to add scripting to an application. While this seems odd (.NET has powerful scripting capabilities, why not use them?), it’s infact frequently used for its simplicity.
There are a couple of problems, however. The classes must be declared COM visible (or the entire assembly if you prefer) AND overloaded methods and statics are not accessible.
Here is a small C# app (source) which lists all public overloaded and static methods and properties which are in public classes of the assemblies passed in the command line.
nVidia Firewall and VMWare bridging
After some tweaking I found the settings to allow bridging (for example for VMWare or Virtual PC) on a NIC with nVidia Firewall active.
The settings in the image below should be enough to allow it to work.
