>Cetin,
>>- even sometimes using below library for faster execution despite harder to grasp and even buggy for someone else if s/he doesn't know the subtle differences in declare part)
>
>You might check on your machines the execution speed. For DWORD the RtlMoveMemory is not my choice, since it doesn't cover the whole range and is even slightly slower then unrolled versions like the original poster was using. Surprised me a bit<g>. Perhaps replacing the 2**x multiplications with bitshifts might give even slightly faster results, or a direct call into an fll, but for me the RtlMoveMemory is to be avoided <g>, especially as the unrolled versions are easier to read.
>
>regards
>
>thomas

Thomas,
I said it was faster because it was already tested under a real world scenario (took my days to find the fast one as data was on 100+ CDs). In that case I mixed some cpp and vfp code to find out the fastest. However I ended with a trick:) Instead of doing the conversion I directly lowlevel wrote from RAW data to dbfs with minimal preprocessing for byte alignments (integers are stored on disk that way). It was a special case needed once.
Cetin