पुरानो 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 व्यवहार जाँच्नुहोस्। यदि यसले रिफ्रेस सूचनाहरू पनि पठाउँछ भने, तिनीहरूलाई इच्छित दायराका लागि छान्नुहोस्.