I don't know why the rounding would be different from one computer to another, but to revisit VB's rounding methods...

you probably know that when working with calculations of numeric datatype variables, vb's implicit rounding uses "the computer's rule" (computer in this case is a person like an accountant, not a hardware computer), which is this weird rule that it will round down a digit that is 5 if the next significant digit is an even number, and round the digit up if the next significant digit is an odd number. Here is the MSDN on it:

When you convert a decimal value to an integer value, Microsoft® Visual Basic® for Applications (VBA) rounds the number to an integer value. How it rounds depends on the value of the digit immediately to the right of the decimal place — digits less than 5 are rounded down, while digits greater than 5 are rounded up. If the digit is 5, then it is rounded down if the digit immediately to the left of the decimal place is even, and up if it is odd. When the digit to be rounded is a 5, the result is always an even integer.

For example, running the following line of code from the Immediate window prints "8," because VBA rounds down when the number immediately to the left of the decimal is even:

? CLng(8.5)

However, this code prints "10," because 9 is odd:

? CLng(9.5)

This can often give you results that you do not expect. Normally, I expect that if I have a number:

33.125

and I want to round this to 2 decimal postions, then I would expect it to go to 33.13. The only way that I can reliably do this is to use the Format statement, which will use the rouding rule that digits equal to 5 round to the next higher number. So, if I have a variable with 3 decimal positions and I want to round it to 2 decimal positions, I have to go through this painful process:

Dim x as single

x = 33.125

x = CSng(Format(x, "##.00")

This will turn x into 33.13 as I would expect.

My only guess for your problem is that under XP, perhaps, some intrinsic datatypes have different numbers of bytes associated with them than under W2K, and with these extra bytes, a number that might have been:

33.45676544556654322

Under W2K might look like this under XP

33.45676544556654322987665

If the combination of digits is just right, the XP number might round differently than the W2K. This is a pretty wild guess, but you might want to examine each intermediate result in your calculation to see if the calculation is rounding the way that you would expect it to. Then, if you can run the same test on an XP development machine, you might find that some intermediate result is rounding differently. This is a painful process, as you have to check each part of a single calculation:

x = (((Y * Z) / Q) * 3.5)

Here, you'd have to check the result of Y * Z and then check the result of that result / Q and then check the result of that result * 3.5 etc.