ਪੁਰਾਣਾ 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 ਵਿਵਹਾਰ ਦੀ ਜਾਂਚ ਕਰੋ। ਜੇ ਇਹ ਰਿਫ੍ਰੈਸ਼ ਸੂਚਨਾਵਾਂ ਵੀ ਭੇਜਦਾ ਹੈ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ ਲੋੜੀਂਦੇ ਦਾਇਰੇ ਲਈ ਚੁਣੋ।