Vì sao một trợ giúp proxy WinINet cũ hỏng trong bản dựng 64-bit
Nhận diện việc cắt cụt con trỏ trong các ví dụ interop proxy bằng C# và xem lại bố cục cấu trúc và quyền sở hữu bộ nhớ trước khi dùng lại.
Một phép ép kiểu có thể biến một trợ giúp cài đặt proxy trông bình thường thành sự cố phụ thuộc kiến trúc:
current = (IntPtr)((int)current + optionSize);
Đoạn mã đó thu hẹp một địa chỉ gốc thành số nguyên 32-bit trước khi cộng kích thước của cấu trúc tiếp theo. Tiến trình 64-bit có thể chứa những địa chỉ không vừa. Tùy theo phép chuyển đổi và giá trị, kết quả có thể là ngoại lệ tràn hoặc địa chỉ không hợp lệ. Quay lại dựng cho x86 có thể che lỗi, nhưng để phần triển khai interop phụ thuộc vào cách né đó.
Giữ địa chỉ ở dạng kích thước con trỏ. Ví dụ, để duyệt qua một mảng đã cấp phát có thể dùng:
IntPtr item = IntPtr.Add(buffer, checked(index * optionSize));
Độ lệch vẫn là số nguyên; bản thân địa chỉ không bị ép qua nó. Kích thước cấp phát và chỉ số vẫn phải hợp lệ.
Sau đó xem xét các khai báo xung quanh
Các tùy chọn WinINet theo từng kết nối chứa một union mà các thành viên gồm DWORD, con trỏ chuỗi và FILETIME. Trường con trỏ cần IntPtr; trường DWORD vẫn là 32-bit. Căn chỉnh gốc quan trọng, nên thay mọi số nguyên bằng số nguyên 64-bit hoặc áp đặt bố cục đóng gói không phải là cách sửa đúng.
Dùng kích thước cấu trúc sau khi marshal khi duyệt mảng, khớp khai báo ANSI hoặc Unicode một cách nhất quán và theo dõi từng lần cấp phát riêng. Việc giải phóng khối cấu trúc tùy chọn không tự động giải phóng các chuỗi được cấp phát ở nơi khác và được các cấu trúc đó tham chiếu.
Cuối cùng, tách câu hỏi về phạm vi cài đặt khỏi tính đúng đắn của bộ nhớ. Sửa một phép ép kiểu không chứng minh rằng tùy chọn WinINet được chọn chỉ ảnh hưởng đến một điều khiển, một tiến trình hay cài đặt của người dùng hiện tại. Hãy kiểm tra hành vi API đó trước khi áp dụng phần còn lại của một mẫu cũ. Nếu nó cũng gửi thông báo làm mới, hãy chọn chúng cho phạm vi dự định.