Ինչու է հին WinINet պրոքսի օգնականը կոտրվում 64-բիթանոց կառուցվածքում

Մեկ cast կարող է թվացյալ սովորական պրոքսիի կարգավորումների օգնականը վերածել ճարտարապետությունից կախված խափանման:

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 հայտարարությունը և յուրաքանչյուր հատկացում հետևեք առանձին: Ընտրանքների կառուցվածքների բլոկի ազատումը ինքնաշխատ չի ազատում այլ տեղ հատկացված և այդ կառուցվածքներից հղված տողերը:

Վերջապես, կարգավորումների շրջանակի հարցը առանձնացրեք հիշողության ճշգրտությունից: Cast-ի վերանորոգումը չի ապացուցում, որ օգնականի ընտրած WinINet ընտրանքը ազդում է միայն մեկ կառավարման տարրի, մեկ գործընթացի կամ ընթացիկ օգտվողի կարգավորումների վրա: Ստուգեք այդ API վարքը նախքան հին օրինակի մնացած մասը ընդունելը: Եթե այն նաև թարմացման ծանուցումներ է ուղարկում, ընտրեք դրանք նախատեսված շրջանակի համար: