Wouldn't personal encryption be great? If we encrypt all our traffic, everything, on top of services such as AIM, ICQ, and anything else? That way when a coorporation or government breaks our encryption to monitor our traffic, we can sue them under the DMCA. =)
Not true..NET is an entirely new foundation. It is not based on OLE or any previous technology. It is an entirely new VM. It has no reliances on COM or Win32. Now, Microsoft's version of.net has extensible ability to make USE of existing COM objects. This is because Microsoft positions this as a replacement for their current COM/etc mess, and the only way to do this is gradual. So people need the ability to use their existing components..NET Framework is what you make it. If you choose to design your components so they aren't cross platform, then you are more than welcome to. This makes it actually USEFUL. Microsoft provides System.Data.OleDbClient and System.Data.SqlClient for dataaccess by default. I already know there are System.Data.Odbc classes floating around. Obviously SqlClient will only work with pure MS-SQL, OleDb will only run on a platform where OleDb is available. MS hasn't locked you into these, it's just the only ones they feel they should spend their engineers time on.
This virus does not effect.net applets. First, it operates by overwriting the 5 byte native win32 stub. This stub is ONLY used to make the exe work in the existing windows environment. Compare it to #!/bin/bash. The stub calls the framework, pointing back to itself, and the framework loads everything after the stub. If the code were distributed over the internet, it wouldn't be in the form of an exe, but rather that of pure IL (bytecode for all you Java people, a simple class file... in fact, extension.dll). This.dll would be a pure assembly, with no stub to load the framework. No unmanaged code at all. The browser would have already loaded the framework. Thus this virus DOES NOT EFFECT.net. It effects plain windows.exe's, which is just not something to make a big fuss about. You can do this to ANY.exe. As soon as we see a.net virus that modifies the IL itself to gain unprivedledged access, is when you need to start worrying.
Slashdot Mirror
Wouldn't personal encryption be great? If we encrypt all our traffic, everything, on top of services such as AIM, ICQ, and anything else? That way when a coorporation or government breaks our encryption to monitor our traffic, we can sue them under the DMCA. =)
Not true. .NET is an entirely new foundation. It is not based on OLE or any previous technology. It is an entirely new VM. It has no reliances on COM or Win32. Now, Microsoft's version of .net has extensible ability to make USE of existing COM objects. This is because Microsoft positions this as a replacement for their current COM/etc mess, and the only way to do this is gradual. So people need the ability to use their existing components. .NET Framework is what you make it. If you choose to design your components so they aren't cross platform, then you are more than welcome to. This makes it actually USEFUL. Microsoft provides System.Data.OleDbClient and System.Data.SqlClient for dataaccess by default. I already know there are System.Data.Odbc classes floating around. Obviously SqlClient will only work with pure MS-SQL, OleDb will only run on a platform where OleDb is available. MS hasn't locked you into these, it's just the only ones they feel they should spend their engineers time on.
This virus does not effect .net applets. First, it operates by overwriting the 5 byte native win32 stub. This stub is ONLY used to make the exe work in the existing windows environment. Compare it to #!/bin/bash. The stub calls the framework, pointing back to itself, and the framework loads everything after the stub. If the code were distributed over the internet, it wouldn't be in the form of an exe, but rather that of pure IL (bytecode for all you Java people, a simple class file... in fact, extension .dll). This .dll would be a pure assembly, with no stub to load the framework. No unmanaged code at all. The browser would have already loaded the framework. Thus this virus DOES NOT EFFECT .net. It effects plain windows .exe's, which is just not something to make a big fuss about. You can do this to ANY .exe. As soon as we see a .net virus that modifies the IL itself to gain unprivedledged access, is when you need to start worrying.