ପୁରୁଣା WinINet ପ୍ରକ୍ସି ସହାୟକ 64-ବିଟ୍ ବିଲ୍ଡରେ କାହିଁକି ଭାଙ୍ଗେ

ଏକ କାଷ୍ଟ ସାଧାରଣ ଦେଖାଯାଉଥିବା ପ୍ରକ୍ସି-ସେଟିଂସ୍ ସହାୟକକୁ ସ୍ଥାପତ୍ୟ-ନିର୍ଭରଶୀଳ ବିଫଳତାରେ ପରିଣତ କରିପାରେ:

current = (IntPtr)((int)current + optionSize);

ସେହି କୋଡ୍ ପରବର୍ତ୍ତୀ ସଂରଚନାର ଆକାର ଯୋଡିବା ପୂର୍ବରୁ ମୂଳ ଠିକଣାକୁ 32-ବିଟ୍ ପୂର୍ଣ୍ଣସଂଖ୍ୟାରେ ସଂକୁଚିତ କରେ। 64-ବିଟ୍ ପ୍ରକ୍ରିୟା ଯେଉଁ ଠିକଣା ଫିଟ୍ ହୁଏ ନାହିଁ ତାହା ଧରି ରଖିପାରେ। ରୂପାନ୍ତର ଏବଂ ମୂଲ୍ୟ ଉପରେ ନିର୍ଭର କରି ଫଳାଫଳ ଓଭରଫ୍ଲୋ ବ୍ୟତିକ୍ରମ କିମ୍ବା ଅବୈଧ ଠିକଣା ହୋଇପାରେ। ବିଲ୍ଡକୁ x86 କୁ ଫେରାଇବା ତ୍ରୁଟିକୁ ଲୁଚାଇପାରେ, କିନ୍ତୁ interop କାର୍ଯ୍ୟାନ୍ୱୟନକୁ ସେହି ଉପାୟ ଉପରେ ନିର୍ଭରଶୀଳ ରଖେ।

ଠିକଣାଗୁଡ଼ିକୁ ପଏଣ୍ଟର-ଆକାରରେ ରଖନ୍ତୁ। ଉଦାହରଣ ସ୍ୱରୂପ, ପୂର୍ବରୁ ଆବଣ୍ଟିତ ଆରେୟ ମଧ୍ୟରେ ଆଗକୁ ବଢିବା ପାଇଁ ଏହା ବ୍ୟବହାର କରାଯାଇପାରେ:

IntPtr item = IntPtr.Add(buffer, checked(index * optionSize));

ଅଫସେଟ୍ ପୂର୍ଣ୍ଣସଂଖ୍ୟା ରହେ; ଠିକଣା ନିଜେ ଏହା ମଧ୍ୟରେ ଚାପି ହୁଏ ନାହିଁ। ଆବଣ୍ଟନର ଆକାର ଏବଂ ସୂଚକାଙ୍କ ଏବେ ମଧ୍ୟ ବୈଧ ହେବା ଆବଶ୍ୟକ।

ତାପରେ ଆଖପାଖର ଘୋଷଣାଗୁଡ଼ିକ ଯାଞ୍ଚ କରନ୍ତୁ

WinINet ର ପ୍ରତି-ସଂଯୋଗ ବିକଳ୍ପଗୁଡ଼ିକରେ ଏକ ୟୁନିଅନ୍ ରହିଛି ଯାହାର ସଦସ୍ୟମାନଙ୍କରେ DWORD, ଷ୍ଟ୍ରିଙ୍ଗ ପଏଣ୍ଟର ଏବଂ FILETIME ଅନ୍ତର୍ଭୁକ୍ତ। ପଏଣ୍ଟର ଫିଲ୍ଡଗୁଡ଼ିକୁ IntPtr ଆବଶ୍ୟକ; DWORD ଫିଲ୍ଡ 32-ବିଟ୍ ରହେ। ମୂଳ ସଂରେଖଣ ଗୁରୁତ୍ୱପୂର୍ଣ୍ଣ, ତେଣୁ ପ୍ରତ୍ୟେକ ପୂର୍ଣ୍ଣସଂଖ୍ୟାକୁ 64-ବିଟ୍ ପୂର୍ଣ୍ଣସଂଖ୍ୟାରେ ବଦଳାଇବା କିମ୍ବା ପ୍ୟାକ୍ ହୋଇଥିବା ବିନ୍ୟାସ ବାଧ୍ୟତାମୂଳକ କରିବା ଉଚିତ ମରାମତି ନୁହେଁ।

ଆରେୟ ମଧ୍ୟରେ ଯିବା ସମୟରେ marshaling ପରବର୍ତ୍ତୀ ସଂରଚନା ଆକାର ବ୍ୟବହାର କରନ୍ତୁ, ANSI କିମ୍ବା Unicode ଘୋଷଣାକୁ ସ୍ଥିରଭାବେ ମେଳାନ୍ତୁ, ଏବଂ ପ୍ରତ୍ୟେକ ଆବଣ୍ଟନକୁ ଅଲଗା ଟ୍ରାକ୍ କରନ୍ତୁ। ବିକଳ୍ପ ସଂରଚନାର ବ୍ଲକ୍ ମୁକ୍ତ କରିବା ଅନ୍ୟତ୍ର ଆବଣ୍ଟିତ ଏବଂ ସେହି ସଂରଚନା ଦ୍ୱାରା ସନ୍ଦର୍ଭିତ ଷ୍ଟ୍ରିଙ୍ଗକୁ ସ୍ୱଚାଳିତଭାବେ ମୁକ୍ତ କରେ ନାହିଁ।

ଶେଷରେ, ସେଟିଂସ୍ ର ପରିସର ପ୍ରଶ୍ନକୁ ମେମୋରୀ ଶୁଦ୍ଧତାରୁ ଅଲଗା ରଖନ୍ତୁ। କାଷ୍ଟ ମରାମତି କରିବା ପ୍ରମାଣ କରେ ନାହିଁ ଯେ ସହାୟକ ଚୟନ କରିଥିବା WinINet ବିକଳ୍ପ କେବଳ ଏକ ନିୟନ୍ତ୍ରଣ, ଏକ ପ୍ରକ୍ରିୟା କିମ୍ବା ବର୍ତ୍ତମାନ ବ୍ୟବହାରକାରୀଙ୍କ ସେଟିଂସ୍ ଉପରେ ପ୍ରଭାବ ପକାଏ। ପୁରୁଣା ନମୁନାର ଅବଶିଷ୍ଟ ଅଂଶ ଗ୍ରହଣ କରିବା ପୂର୍ବରୁ ସେହି API ଆଚରଣ ଯାଞ୍ଚ କରନ୍ତୁ। ଯଦି ଏହା ରିଫ୍ରେଶ ବିଜ୍ଞପ୍ତି ମଧ୍ୟ ପଠାଏ, ଉଦ୍ଦିଷ୍ଟ ପରିସର ପାଇଁ ସେଗୁଡ଼ିକୁ ଚୟନ କରନ୍ତୁ।