Kwa nini kisaidizi cha zamani cha WinINet proxy kinavunjika katika build ya 64-bit

Cast moja inaweza kubadilisha kisaidizi cha mipangilio ya proxy kinachoonekana cha kawaida kuwa hitilafu inayotegemea usanifu:

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

Msimbo huo hupunguza anwani asilia hadi nambari kamili ya 32-bit kabla ya kuongeza ukubwa wa muundo unaofuata. Mchakato wa 64-bit unaweza kushikilia anwani zisizotoshea. Kulingana na ubadilishaji na thamani, matokeo yanaweza kuwa hitilafu ya kufurika au anwani batili. Kurudisha build kwenye x86 kunaweza kuficha kosa, lakini kunaacha utekelezaji wa interop ukitegemea suluhisho hilo.

Weka anwani katika umbo la ukubwa wa kielekezi. Kwa mfano, kupita kwenye safu iliyotengwa tayari kunaweza kutumia:

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

Ofseti inabaki nambari kamili; anwani yenyewe haikandamizwi kupitia moja. Ukubwa wa ugawaji na faharisi bado lazima ziwe halali.

Kisha kagua matangazo yanayozunguka

Chaguo za WinINet kwa kila muunganisho zina muungano ambao wanachama wake ni pamoja na DWORD, kielekezi cha mfuatano na FILETIME. Sehemu za vielekezi zinahitaji IntPtr; sehemu za DWORD zinabaki 32-bit. Mpangilio asilia ni muhimu, kwa hivyo kubadilisha kila nambari kamili na nambari kamili ya 64-bit au kulazimisha mpangilio uliofungwa si ukarabati mzuri.

Tumia ukubwa wa muundo baada ya marshaling unapopita kwenye safu, linganisha tangazo la ANSI au Unicode kwa uthabiti, na fuata kila ugawaji kando. Kuachilia kizuizi cha miundo ya chaguo hakuachilii kiotomatiki mifuatano iliyotengwa mahali pengine na inayorejelewa na miundo hiyo.

Hatimaye, tenga swali la wigo wa mipangilio mbali na usahihi wa kumbukumbu. Kurekebisha cast hakuthibitishi kwamba chaguo la WinINet lililochaguliwa linaathiri kidhibiti kimoja, mchakato mmoja au mipangilio ya mtumiaji wa sasa pekee. Kagua tabia hiyo ya API kabla ya kupitisha sehemu iliyobaki ya mfano wa zamani. Iwapo pia inatuma arifa za kuonyesha upya, chagua hizo kwa wigo uliokusudiwa.