Anders Melander

StretchDraw? That's a horrible solution - to a 4 year old problem.

I would argue that the type of Epsilon depends on the use case; For one an absolute explicit Epsilon is suitable (SameValue(Value, Epsilon)), for another an absolute implicit Epsilon will make sense (SameValue(Value) but with some better defaults), and for yet another a relative magnitude Epsilon would be desirable (let's call it KasObSameValue(Value, Epsilon) since we don't have it in the RTL). FWIW, the same discussion could be had about IsZero. I mostly use it to avoid division by zero and overflow errors caused by division by a very small number. I'm not really comfortable doing it but the alternative is the gazillion sporadic exceptions we had in the old application I'm working on, before we began using it.

Google "manifest cache"

No argument there.

I think you are missing my point. I'm saying that SameValue, with Epsilon specified, is documented to work in the way it does now. If it didn't then that would be a bug. You can argue that it would be better if it worked in another way (e.g. Epsilon relative to the magnitude of value) but that is not how it is documented to work, it is also subjective, and it depends on how one intends to use it. It's like arguing that the right way to index strings is zero based.

Should? As far as I can tell the current implementation matches the documented behavior. Yours doesn't. You might prefer another behavior, which is perfectly reasonable, but it doesn't make the current one wrong. I agree that SameValue without the Epsilon parameter is at best problematic but, with regard to the choice of default Epsilon, we don't know what the criteria was for the values they chose (because it isn't documented) so I can't see how we can say that they are wrong. Again; We might prefer other values but that doesn't make the current values wrong.

Only if you don't specify a tolerance. I can't see anything wrong with it if you specify a tolerance.

Multiply by a 10^"number of decimals", Trunc to convert to integer, Assert on the integer value

As far as I can tell they've been forced to replace their proprietary APIs with standard APIs (in order to avoid vendor lock-in) and to allow competing third party applications access to their map data. Did I understand that right? It seems Google has few friends in the map business; They aren't allowed to link to Google Maps from their Google search results - or even from the search page (which is pretty stupid and doesn't do the users any good), while the same restrictions doesn't apply to Bing. Could it be that Bing map data is provided by Tom-Tom?

Alright then. So you are going to violate the license and don't want that aspect discussed. That's between you, Microsoft, and whatever unfortunate user/client, if any, this involves but maybe you shouldn't ask us to help you do it.

You mean you are "installing the software on a device for use only by remote users"?

No it's not; You are not allowed to use a desktop Windows as a server. What other people that violate the license say about that isn't really relevant.

Exactly. Read the EULA. Search for "server". It's stated pretty clearly what you can and cannot do.

Then I think you need to familiarize yourself with the Windows EULA.

So this is a hobby project. Right?