Kial malnova WinINet-prokura helpilo rompiĝas en 64-bita konstruo
Rekonu montrilan tranĉadon en C#-prokuraj interop-ekzemploj kaj reviziu strukturaranĝon kaj memorkposedon antaŭ ol reuzi ilin.
Unu konverto povas ŝanĝi ŝajne ordinaran prokuran agordhelpilon en arkitektur-dependan fiaskon:
current = (IntPtr)((int)current + optionSize);Tiu kodo mallarĝigas indiĝenan adreson al 32-bita entjero antaŭ ol aldoni la grandecon de la sekva strukturo. 64-bita procezo povas teni adresojn, kiuj ne enketas. Depende de la konverto kaj valoro, la rezulto povas esti superflua escepto aŭ malvalida adreso. Reŝalti la konstruon al x86 povas kaŝi la eraron, sed ĝi lasas la interop-implementon dependa de tiu laborvojo.
Tenu adresojn en montrila grandeco. Ekzemple, por antaŭeniri tra jam asignita tabelo eblas uzi:
IntPtr item = IntPtr.Add(buffer, checked(index * optionSize));La deŝovo restas entjero; la adreso mem ne estas premata tra unu. La asigngrandeco kaj indekso ankoraŭ devas esti validaj.
Poste ekzamenu la ĉirkaŭajn deklarojn
La WinINet-opcioj por konekto enhavas unuon, kies membroj inkluzivas DWORD, ĉenmontrilon kaj FILETIME. Montrilaj kampoj bezonas IntPtr; DWORD-kampoj restas 32-bitaj. Indiĝena ĝisrandigo gravas, do anstataŭigi ĉiun entjeron per 64-bita entjero aŭ trudi pakititan aranĝon ne estas solida riparo.
Uzu la grandecon de la strukturaro post marshaling dum vi trapasas la tabelon, konsiste kongruu la ANSI- aŭ Unicode-deklaron, kaj spuru ĉiun asignon aparte. Liberigi la blokon de opci-strukturoj ne aŭtomate liberigas ĉenojn asignitajn aliloke kaj referencitajn de tiuj strukturoj.
Finfine, tenu la demandon pri agorda amplekso aparte de memora ĝusteco. Ripari konverton ne pruvas, ke elektita WinINet-opcio influas nur unu regilon, unu procezon aŭ la agordojn de la nuna uzanto. Kontrolu tiun API-konduton antaŭ ol adopti la reston de malnova ekzemplo. Se ĝi ankaŭ sendas refreŝigajn sciigojn, elektu ilin por la celita amplekso.