পুরনো WinINet প্রক্সি হেল্পার 64-বিট বিল্ডে কেন ভাঙে

একটি কাস্ট একটি সাধারণ দেখতে প্রক্সি-সেটিংস হেল্পারকে আর্কিটেকচার-নির্ভর ব্যর্থতায় পরিণত করতে পারে:

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

ওই কোড পরের স্ট্রাকচারের আকার যোগ করার আগে নেটিভ ঠিকানাকে 32-বিট পূর্ণসংখ্যায় সংকুচিত করে। 64-বিট প্রক্রিয়া এমন ঠিকানা রাখতে পারে যা ফিট করে না। রূপান্তর ও মানের উপর নির্ভর করে ফলাফল ওভারফ্লো ব্যতিক্রম বা অবৈধ ঠিকানা হতে পারে। বিল্ডটি x86-এ ফিরিয়ে নিলে ভুলটি লুকিয়ে যেতে পারে, কিন্তু ইন্টারঅপ বাস্তবায়ন সেই সমাধানের উপর নির্ভরশীল থেকে যায়।

ঠিকানাগুলো পয়েন্টার-আকারে রাখুন। উদাহরণস্বরূপ, আগেই বরাদ্দ করা অ্যারের মধ্য দিয়ে এগোতে এটি ব্যবহার করা যায়:

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

অফসেট পূর্ণসংখ্যা থাকে; ঠিকানা নিজে তার মধ্য দিয়ে চেপে যায় না। বরাদ্দের আকার ও সূচক এখনও বৈধ হতে হবে।

তারপর আশপাশের ঘোষণাগুলো পরীক্ষা করুন

WinINet-এর প্রতি-সংযোগ অপশনে একটি ইউনিয়ন থাকে যার সদস্যদের মধ্যে DWORD, স্ট্রিং পয়েন্টার ও FILETIME আছে। পয়েন্টার ফিল্ডে IntPtr দরকার; DWORD ফিল্ড 32-বিট থাকে। নেটিভ অ্যালাইনমেন্ট গুরুত্বপূর্ণ, তাই প্রতিটি পূর্ণসংখ্যাকে 64-বিট পূর্ণসংখ্যা দিয়ে বদলানো বা প্যাকড লেআউট চাপিয়ে দেওয়া সঠিক মেরামত নয়।

অ্যারের মধ্য দিয়ে যাওয়ার সময় marshaling-পরবর্তী স্ট্রাকচার আকার ব্যবহার করুন, ANSI বা Unicode ঘোষণা ধারাবাহিকভাবে মেলান, এবং প্রতিটি বরাদ্দ আলাদাভাবে ট্র্যাক করুন। অপশন স্ট্রাকচারের ব্লক মুক্ত করলে অন্যত্র বরাদ্দ করা ও সেই স্ট্রাকচার দ্বারা উল্লিখিত স্ট্রিং স্বয়ংক্রিয়ভাবে মুক্ত হয় না।

সবশেষে, সেটিংসের পরিধির প্রশ্নটি মেমরি শুদ্ধতা থেকে আলাদা রাখুন। কাস্ট মেরামত করা প্রমাণ করে না যে হেল্পারের বাছাই করা WinINet অপশন কেবল একটি নিয়ন্ত্রণ, একটি প্রক্রিয়া বা বর্তমান ব্যবহারকারীর সেটিংসকে প্রভাবিত করে। পুরনো নমুনার বাকি অংশ গ্রহণের আগে সেই API আচরণ যাচাই করুন। যদি এটি রিফ্রেশ বিজ্ঞপ্তিও পাঠায়, সেগুলোকে অভীষ্ট পরিধির জন্য বাছুন।