Зошто стар 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 однесување пред да го прифатите остатокот од стариот пример. Ако испраќа и известувања за освежување, изберете ги за предвидениот опфат.