>>>>According to Calvin, all existing code would break. There would be no backwards compability.
>>>
>>>Aren't you just saying that we would have to recompile our source code for the 64-bit VFP runtime? Otherwise, you are saying that the language itself is changing 100%.
>>>
>>>Your statement would lead me to believe that the following line of code:
>>>
>>>x = 5
>>>
>>>would not be valid any more.
>>
>>Of course that line would work. As for just a recompile, I don't know. I can just tell you what Calvin said.
>
>Hello Craig,
>
>Us non-devCon-ers are keeping you hopping!
>
>I was not merely trying to overstate the obvious. I would think that the list of things that would break in our code would be very small (if anything at all, and again, I'm assuming a recompile). To me, it sounds like most of the Microsoft's VFP source code would be broken--the undertaking of work would be at MS.
>
>I see no why no reason for the syntax of the language to change just because the underlying processing has gone to 64-bit. However, I'm no expert...
>
Steve,

Maybe the following will help folks understand exactly what the Foxteam faces.

First, there have been a bunch of functions in Win2K that have superceded existing ones, which remain for backwards compatiability. In fact, this is not only the case with Win2K, but exists for for versions as close as Win95 OSR1 and OSR2. As an example, consider that the DISKSPACE() function caps the available space at 2gb. Why? Because the function it calls (GetDiskFreeSpace()) does. The function that retrieves the correct value (GetDiskFreeSpaceEx()) didn't come into being until Win95 OSR2. So the team has to code for the different versions of the OS, and decide what to return under OSR1 in this case.

Second, and really a bigger issue has to do with the way VFP interally makes its calculations. For example, while we don't normally think of data typing in variables too much VFP does. Consider that the bitwise functions always return signed 32 bit integers. Do the following:

lnvar = 0xFFFFFFFF
? lnvar && 4294967295
lnvar = BITOR(lnvar, 0)
? lnvar && -1

So the team has to determine the size of the integer it's going to deal with 32 or 64 bit, signed or unsigned.

This isn't even the tip of the iceberg.