|
Hi, Alan. No problem with the inline comments. I'm going to do the same with my response. Alan McGovern wrote: Hi,I don't buy the purported security of .Net, not at least as proposed by Microsoft. As for MONO, I cannot testify, but regarding Win.Net, here goes... One obvious security vulnerability (assumably of all .Net implementations, because all implementations generate IL), is that the very IL will regularly pave the way to security breaches. Likewise, IL makes it very difficult if not impractical to protect intellectual property. An example of the former for instance would be an enterprise application submitting password access for whatever purpose. Even if encryption libraries are called, if the IL falls into the wrong hands, the data processed by IL calls into encryption libraries make it a relatively easy matter to break the ostensible security of the system. The .Net environment imposes relatively basic security measures. Yet keys can be stolen, signatures can be impersonated, new assemblies can be distributed to impersonate others... etc.. I don't think any .Net engineer claims the security is invulnerable to a variety of possible schemes. I don't believe it can be truly said that malware of any kind, or even flaws of any kind, are wholly obstructed from affecting our systems. The best applications I use have rarely been updated. They sit behind a firewall. I fully trust them because any problems would be adverse to the purposes of the vendor, and because the integrity of the applications is a long proven matter. I don't see how you can better, more practical security than that. None of these require _javascript_. Reliance [even] on _javascript_ renders the site dysfunctional if the visitor is running tight security to protect themselves from the probable dangers we are aware of. Even privacy is a worthy reason to disable _javascript_. The person who deploys [even] _javascript_ therefore risks or causes the dysfunctionality of their content in so many browser configurations. A good example of the consequences is the imperative disabling of ActiveX. Even out of the box, Internet Explorer regularly fails to render content or processes on Microsoft sites. Crank up the security to where you should really have it, and good luck. GetPixel() and SetPixel() have to be used for some purposes, but so far I have never had to use them in performance critical code. Unsafe code is another thing to stay away from however if end users are to enforce in-house restrictions based on security claims made for .Net. By "natively" (in the .Net sense), you mean the code runs in an environment which relates to the native system. IL *does not* compile into native calls of the OS. .Net implementations on Windows are far slower than their native-compiled counterparts. Some claims are made that .Net math operations are something like 80% as fast as native operations, but these claimed cases are only possible if no boxing or unboxing are involved. Still, that's a substantial performance disadvantage. But if of course any boxing or unboxing are required, then of course the disparities are going to be huge. This nonetheless is in regard just to math operations. Graphics processes and IO can be orders of magnitude slower. There are net BrowseForFolder dialogs in Visual Studio which, on my brand new Vista system, take 9 seconds to display file content. This is a huge delay, and something I certainly would never care to suffer in my own applications. The early days of Delphi 1 had dialogs which were instantaneous on Win95. So many years and orders of hardware efficiency later, to suffer these delays is to me, incredible.
Well thanks for the tip, but imho, "managed" is quite an overstated virtue or advantage. Few C# developers probably truly know for instance what the best way is to implement dispose patterns. There is conflicting information on it. Visual Studio doesn't agree with Richter. Richter doesn't agree with another source I rely on. Then again, how many can expertly reply when and how to implement finalize? What was the ostensible technical challenge implementing Free or FreeAndNil in C++Builder or Delphi? There was no challenge or mystery when and how to use them. When you freed an object the memory was instantly available to other processes. FreeAndNil obviously freed the memory and wrote null/nil to it. When you wrote an aggregate component/class, you routinely moved to your destructor and freed subcomponents in the reverse order you created them. These things were routine. What is the ostensible advantage of ForEach? Underneath your call to ForEach is an iterative process which has to make the well known, routine call to iterate count minus 1. The same thing has to be done. There's nothing managed for you at this level. If the count changes before iteration is complete, the only thing you can hope to account for that is the compiler -- and I think it should be clear that isn't necessarily anything that the compiler should assume. If this can happen in your case, it is your responsibility to anticipate that and use an appropriate structure. Now, if you're trying to tell me MONO runs as fast as Cocoa on OS X, I can be made a believer of that part of your assertion. "Managed" code little convenience -- but in many cases it certainly is one. In the case of dispose or finalize patterns, ambiguities can lead to further problems, and incomplete familiarity with these ambiguities can lead to inferior design and poor performance. If we have to breech the barriers of ostensibly "safe" code to *hope* to achieve ostensibly comparable speed, hardly is it the case then that .Net delivers what I consider to be acceptable performance. Your remarks about GetPixel() and SetPixel(), I take to be agreement. As to your final remarks, you do not understand me. Assemblies call into .Net libraries. What I am proposing is to map those calls into libraries supporting the .Net calls, but compile the output into native calls into the operating system -- using native OS dialogs, whatever. Unless GetPixel() and SetPixel() deliver that kind of performance and potential security, certainly this is *not* something .Net provides. If that's the case, it makes alternatives the only option if performance matters. I won't have my users waiting 9 seconds for a BrowseForFolder or BrowseForFile dialog to display content. I would even anticipate getting support calls for that. Regards, mike
|
_______________________________________________ Mono-list maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-list
