Чаму стары памочнік проксі WinINet ламаецца ў 64-бітнай зборцы

Адно прывядзенне тыпу можа ператварыць звычайны памочнік налад проксі ў збой, залежны ад архітэктуры:

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

Гэты код звужвае натыўны адрас да 32-бітнага цэлага перад даданнем памеру наступнай структуры. 64-бітны працэс можа ўтрымліваць адрасы, якія не змяшчаюцца. У залежнасці ад пераўтварэння і значэння вынікам можа быць выключэнне перапаўнення або несапраўдны адрас. Вяртанне зборкі на x86 можа схаваць памылку, але пакідае рэалізацыю interop залежнай ад гэтага абыходнага рашэння.

Трымайце адрасы ў форме памеру ўказальніка. Напрыклад, для праходу па ўжо выдзеленым масіве можна выкарыстоўваць:

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

Зрух застаецца цэлым; сам адрас не праціскаецца праз яго. Памер выдзялення і індэкс па-ранейшаму павінны быць сапраўднымі.

Затым праверце навакольныя аб'явы

Параметры WinINet для кожнага злучэння змяшчаюць аб'яднанне, члены якога ўключаюць DWORD, указвальнік на радок і FILETIME. Палям-указальнікам патрэбен IntPtr; палі DWORD застаюцца 32-бітнымі. Натыўнае выраўноўванне мае значэнне, таму замена кожнага цэлага на 64-бітнае цэлае або прымусовая ўпакаваная разметка не з'яўляецца слушным рамонтам.

Выкарыстоўвайце памер структуры пасля маршалінгу, праходзячы па масіве, узгадняйце аб'яву ANSI або Unicode паслядоўна і адсочвайце кожнае выдзяленне асобна. Вызваленне блока структур параметраў не вызваляе аўтаматычна радкі, выдзеленыя ў іншым месцы і на якія спасылаюцца гэтыя структуры.

Нарэшце, аддзяляйце пытанне абсягу налад ад карэктнасці працы з памяццю. Выпраўленне прывядзення не даказвае, што абраны параметр WinINet уплывае толькі на адзін элемент кіравання, адзін працэс або наладкі бягучага карыстальніка. Праверце такія паводзіны API, перш чым прымаць астатнюю частку старога прыкладу. Калі ён таксама дасылае апавяшчэнні аб абнаўленні, выберыце іх для патрэбнага абсягу.