പഴയ 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-ബിറ്റ് പൂർണ്ണസംഖ്യയാക്കി മാറ്റുന്നതോ പാക്ക് ചെയ്ത ലേഔട്ട് നിർബന്ധിക്കുന്നതോ ശരിയായ അറ്റകുറ്റപ്പണിയല്ല.

അറേയിലൂടെ നീങ്ങുമ്പോൾ marshaling-ന് ശേഷമുള്ള ഘടനാ വലിപ്പം ഉപയോഗിക്കുക, ANSI അല്ലെങ്കിൽ Unicode പ്രഖ്യാപനം സ്ഥിരതയോടെ ഒത്തുനോക്കുക, ഓരോ അനുവദനവും വെവ്വേറെ ട്രാക്ക് ചെയ്യുക. ഓപ്ഷൻ ഘടനകളുടെ ബ്ലോക്ക് വിടുവിക്കുന്നത് മറ്റൊരിടത്ത് അനുവദിച്ചതും ആ ഘടനകൾ റഫർ ചെയ്യുന്നതുമായ സ്ട്രിംഗുകൾ സ്വയമേവ വിടുവിക്കുന്നില്ല.

അവസാനം, ക്രമീകരണങ്ങളുടെ പരിധി എന്ന ചോദ്യം മെമ്മറി കൃത്യതയിൽ നിന്ന് വേർതിരിക്കുക. കാസ്റ്റ് നന്നാക്കുന്നത് സഹായി തിരഞ്ഞെടുത്ത WinINet ഓപ്ഷൻ ഒരു നിയന്ത്രണത്തെയോ ഒരു പ്രോസസ്സിനെയോ നിലവിലെ ഉപയോക്താവിന്റെ ക്രമീകരണങ്ങളെയോ മാത്രം ബാധിക്കുന്നു എന്ന് തെളിയിക്കുന്നില്ല. പഴയ മാതൃകയുടെ ബാക്കി ഭാഗം സ്വീകരിക്കുന്നതിന് മുൻപ് ആ API സ്വഭാവം പരിശോധിക്കുക. അത് റിഫ്രെഷ് അറിയിപ്പുകളും അയയ്ക്കുന്നുവെങ്കിൽ, ഉദ്ദിഷ്ട പരിധിക്കായി അവ തിരഞ്ഞെടുക്കുക.