>I'm converting a program originally written in Foxpro 2.5 for DOS into Visual Foxpro 6.0. One maddening idiosyncrosy I've encountered is the following:
>
>There are an encryption and decryption routines used for storing user passwords to a database. These routines work just fine in the DOS version. However when I use the IDENTICAL code in Visual Foxpro, I get erratic results. Occasionally, the encrypted password will decrypt just fine. But most of the time, at least one of the characters in the password will decrypt incorrectly. I have pulled these functions out of the program and run them independently of the larger program just to be sure there is nothing in the program which might be distorting this process.
>
>The encryption/decryption routine operate by the relatively common method of manipulating ASCII values via an algorythm. In DOS, everything works great, in Windows/Visual Foxpro, most of the time it doesn't. I have been unable to discern whether it is the encryption or decryption which is malfunctioning.
>
>Does Visual Foxpro/Windows handle ASCII values differently that DOS? If so, is there a Foxpro function which creates a compatibility between Windows and Foxpro ASCII handling?
>

It's possible that the VFP database is using a DBWCS (two bytes/character) codepage rather than the default DOS/ANSI codepage, which migght affect your algorithm, and there are casting issues with large positive and negative integer values (FPDOS did not have an INTEGER data type internally, so that coverting a large hexadecimal value may result in a different representation. In some cases where the integer representation is an issue, adding a BITOR(large hexadecimal value,0) rather than just large hexadecimal value in the code may fix the differences in internal data representation.

The situation where this is most likely to occur involves a hexadecimal value greater than or equal to 0x80000000, which internally needs to be represented as a large negative value rather than a large positive value.

>Confidentiality issues prevent me from posting the source code of these routines publicly, so I hope there is a generic answer which will rectify this idiosyncrosy.
>
>TIA
>
>Richard Bates
>Denver, CO