"Joel" wrote in message
...
Wow! I am somewhat offended at the insinuation that I would do something
like
that. That is absolutely the last thing I would ever do. And, besides, my
question is *way* to specific to even garner wanting to distribute Excel
DLLs
around. I.e. There is much more to Excel than just floating point
operations.

If you want to know why, I can give you some idea. I didn't originally
because I didn't want to get to wordy in my original post.

Basically, if you have heard of Rotor (the shared source implementation of
the CLI), you know you can view the source code of the underlying virtual
machine and see how pretty much everything is working under the covers.
For
some work I am doing, I needed to look at how floating point and decimal
work
from the System.Decimal/System.Single/System.Double libary types down to
what
is called in the implementations of those types. I wanted to see if Excel,
a
program that makes use of FP somewhat heavily, follows the same path as
the
.NET implementations. By path, I wanted to see if there was a convergence
point where both are calling into the same APIs or if they are totally
separated. There is obviously more "why" detail, but I can'r really get
into
it because I am not sure it is appropriate for me to do so.

Does that make sense?


Exce is not based on .NET so I assume there are some differences,. AFAIK
excel uses 8 byte doubles for floating point arithmetic. I seem to remember
that Excel does compress doubles into a 4 byte structure when you save a
file. It's not a float.

I don't think there's much of a common API . My guess is that a
System.Double is pretty much the same as a double in C.
/Fredrik