The CLR and ECMA are standards so this means anyone can implement C# and the CLR freely. The libraries are not standards which means MS could (theoretically) sue claiming intellectual property or something like that. However, MS and Novel have agreements on this (they even contribute code to each other on .Net iirc) and it's unlikely that Microsoft would profit anything from this thus unlikely they'll want to sue/block it anytime soon.

I'm not too familiar with Wine but my guess is that since Wine is a purely reverse engineer effort they're right in the gray area without any sort of protection from law or otherwise. But since Microsoft has everything running for them (they release new APIs much faster than Wine can keep up) they simply don't bother with it.

Mono does have a solution. There is a flag you can turn on so make it happen. It's just not on by default because it affects performance for obvious reasons (attempting to find a match). But of course my point is a simple as, if you code it right you don't need to!

Jesus. All I said is, people sometimes do stupid things like hardcoding paths into the application. .Net provides API to get directory separators and such, but if people don't use them it can't simply make it work by magic.

The more common problem is hardcoded file names being case sensitive in most *unix file systems. Surely your precious Java can't fix that can it? If not why don't you apply for a job at Sun and show them how trivial it is to fix everything for every one.

Of that example is very trivial. Not everyone is a programmer so I didn't want to go into details but you need to consider there is more to it than simply replacing C: with /.

The CLR is a standard as well as the C# language. Which means that except for a very few set of very core libraries/classes (like String) the majority of APIs aren't standardized.

Yes, Mono tries to keep up, but not everything is like you lay it down. For instance, the C# 3.0 and 4.0 standard was implemented before the respective releases from Microsoft. As soon as the standard is out Mono starts implementing it and tries to keep up with any changes the beta releases do. Usually it's up to date by the time the final release is out.

As for newer APIs someone needs to implement the changes/new ones. Some APIs aren't ever implemented for the lack of interest. But the point is, if you want to be cross platform with C#, you can. ASP.Net, Linux, Windows, OS X and even stuff like iPhone and Android.

Mono can run way more apps than Wine, specially if you include ASP.Net sites.

Of course, most programmers do stupid mistakes that make it impossible to run in another environment than Windows. The most common one is handling paths like "C:\..." in which case there's nothing Mono can do.

The sources for the main libraries are available from Microsoft and they even include installers so you can see them while debugging an application. I said kinda because the Microsoft license isn't exactly compatible with everything else out there and it isn't exactly built around a community you can simply commit a patch.

Don't talk about you know nothing about. Wine is an effort to reverse engineer something that is ill documented, not a standard and huge moving target. It might never worked or work well in every scenario though.

Mono on the other hand is based on the standards which makes it much easier to implement, make it compatible and test. Not every API is ported though, but I can tell you from experience you can create well performing apps that run cross platform with Mono and .Net without a single source code changes (or binary for that matter). Even ASP.Net runs out the box.

If the submitter wishes to learn C# (and I think he should) I even go as far as suggesting he does it on Mono/Linux. Not because I think Linux is great but because it will help you understand the implications of cross platform development which in some little cases the .Net platform did a poor job although it's a primary objective of the whole framework.

Oh, and btw the .Net source code for the core APIs is kinda open source so you can read it too.

That's true if you're the casual finder, but not if you live of security research.

I do know it isn't as simple as looking at the code and sometimes you don't even do that, the point was that finding a bug on something as widely tested and used and a browser isn't as simple as proof-reading a book.

Finding a bug in a book is a matter of reading, proof reading and testing every example on the book to see if it works well. You could say it's an exact science because you can simply define a couple rules and follow them until you find a small mistake.

Finding a bug on a software isn't that simple. For starters there are millions of lines of code and unlike books a single line can affect millions of other line's logic paths/assumptions/etc. There is no single method you can apply to find a bug and that's why security research is so hard.

No matter how good a security researcher you are, you can never be 100% sure before hand that you can find a bug. Add that to the fact that the rules usually are something like "Critical Bugs only" and you've very few chances of success.

If you're not being paid a steady check to work on something like Mozilla or Chrome, chances are that 500$ isn't enough to make you learn their code, test and find something that you might never even find.

If you work on something you usually like to get paid. It's considered insulting to pay just 500$ for a bug simply because you can get a much higher paycheck if you sell it on the black market. So, if you're into security research to make money, 500$ is an insult to people's time.

Personally I've always believed that from a Darwinist point of view the only logical explanation is that the Egg comes first. From the summary of the story they're making it sound like, it it lays eggs then it's a chicken, which is not always the case. The truth is that genetically you usually have mutations before being born, so any creature that laid an egg (or even without eggs, e.g. mammal) gave birth to to a mutant freak that so happened to be a chicken.

Hi, if you work on the field I could use some input on the "state of the art" techniques used so I can create meaningful benchmarks. Let me know at alexmipego at gmail dot com

One more note, some people ask the usefulness of the algorithm and if it's 10% improvement then it's not worth it. The algorithm to calculate distances between points can be used not too often on certain devices or apps, however, there are systems like Google Maps or 4Square that have to compute the distance between a point and millions of other points in real time, often hundreds servers are used solely for this. If you could improve that step in 1% it would represent 1 less server in 100.

Do not quote me on this yet, but from initial benchmarks (with a unfinished version) I estimate between 100-200% improvement.

Thanks all for all the nice comments so far ;) The list is growing faster than I can keep up with but here are some remarks I would like to add:

I do not wish to patent it and I plan on making sure there will be material enough to be considered prior art in case of patent trolling. I'm also a open source contributor and I'm sure if I needed I could forward them the work so they could protect it (e.g. add it to their defensive patent poll). All in all, I'm not looking for profit, yet a job would be welcome lol

As for the new algorithm I think was I was maybe a bit too vague on the story. So, to put it simple and short, afaik there are 3 major formulas used nowadays: great circle distance, haversine and vincenty's. In order, they each offer more accuracy than the previous at the expense of more computation power needed for the calculations. While I didn't even try to replace Vincenty's formula yet (but it might be possible) my solution improves on the others because they all require a lot of trigonometry functions (cos, sin, etc..). On the simplest of those, you have to call 6 trig functions, while with my method I only need 1 (so far) to achieve the same end result as the haversine's formula.

I'm not sure if such formula and the methods needed to make this work are even patentable anyway.