헤더에서 _WIN32_WINNT 정의가 변경되었는데, 이것이 바이너리 비 호환성을 유발합니까?

VS2010에서 _WIN32_WINNT가 적어도 0x501이 필요하지만 새 바이너리 공유 라이브러리를 제공하는 타사 공유 라이브러리는 0x500으로 정의 된 타사 라이브러리의 새 버전으로 응용 프로그램을 업데이트하고 있습니다. 응용 프로그램에 포함되어 있습니다.헤더에서 _WIN32_WINNT 정의가 변경되었는데, 이것이 바이너리 비 호환성을 유발합니까?

수정 된 경우 이진 호환성이 없거나 별 차이가 없습니까? 이 라이브러리를 0x500으로 정의하는 새 바이너리를 요청해야합니까? 나는 이것이 새로운 쓰레기통을 필요로하는지 알 수 없다. 어떤 클래스/구조체의 크기 나 이름이 바뀌거나 메소드/함수 서명이 변경되면 새로운 컴파일이 필요하다고 생각한다.

출처

2015-01-20 iminyourbrain

Windows 2000 또는 XP의 RTM 버전을 부팅하는 시스템에서 프로그램이 실행될 가능성은 +/- 0.01 %입니다. 실제 문제는 아닙니다. –

제 3 자 공유 라이브러리가 더 이상 지원되지 않는 0x501 이전의 Windows 버전 기능을 목표로하지 않는다면 바이너리 호환이 가능합니까? 그것은 최소한의 버전으로 사용되는 것으로 보인다. – iminyourbrain

'_WIN32_WINNT'를 정의한 라이브러리가 처음에는 그렇게하지 않았습니다. 기껏해야 이것이 적절하게 정의되었는지 확인해야합니다. 그게 무슨 라이브러리 야?즉, 인라인 코드에서 불쾌한 일을하지 않는 한 헤더 파일을 수정하는 것이 좋습니다. 단, 나중에 더 크거나 같은 것으로 정의해야합니다. –

짧은 대답 : 아마도 그렇지는 않지만, 그렇다면 당신은 귀여운 피클에 있습니다.

긴 대답 : 코드를 사용하려고하는 WinAPI를 (및 MFC 같은 관련 라이브러리)의

_WIN32_WINNT 컨트롤 버전. 목적은 Windows 버전 이후에 소개 된 Windows 기능을 사용하는 경우 컴파일러 오류가 생성되도록하는 것입니다.

대부분이 기능, 구조체 등을 볼 수 있습니다. 이 부분은 대상이 아닌 Windows 버전을 제외하고는 바이너리 비 호환성을 일으킬 수 없습니다. 그러나 ...

Windows의 수명 동안 확장 된 WinAPI에는 몇 가지 구조체가 있습니다. OPENFILENAME의 정의에서, 예를 들어 살펴 보자 :

typedef struct tagOFN { 
    DWORD   lStructSize; 
    HWND   hwndOwner; 
    HINSTANCE  hInstance; 
    LPCTSTR  lpstrFilter; 
    LPTSTR  lpstrCustomFilter; 
    DWORD   nMaxCustFilter; 
    DWORD   nFilterIndex; 
    LPTSTR  lpstrFile; 
    DWORD   nMaxFile; 
    LPTSTR  lpstrFileTitle; 
    DWORD   nMaxFileTitle; 
    LPCTSTR  lpstrInitialDir; 
    LPCTSTR  lpstrTitle; 
    DWORD   Flags; 
    WORD   nFileOffset; 
    WORD   nFileExtension; 
    LPCTSTR  lpstrDefExt; 
    LPARAM  lCustData; 
    LPOFNHOOKPROC lpfnHook; 
    LPCTSTR  lpTemplateName; 
#if (_WIN32_WINNT >= 0x0500) 
    void   *pvReserved; 
    DWORD   dwReserved; 
    DWORD   FlagsEx; 
#endif 
} OPENFILENAME, *LPOPENFILENAME;

마지막에 마지막 비트를 참조하십시오? 그게 잠재적 인 문제를 불러옵니다. 코드의 한 부분은 _WIN32_WINNT을 0x400으로 설정하고 다른 하나를 0x500으로 컴파일하면이 구조체가 다른 구조체보다 작다고 가정합니다.

WinAPI 디자이너는이 문제에 대해 생각해 보았습니다. OPENFILE의 첫 번째 구성원은 lStructSize입니다. 이것을 sizeof(OPENFILE)으로 초기화해야합니다. 당신을 위해, sizeof(OPENFILE)은 컴파일 타임 상수입니다. Windows 런타임 라이브러리의 함수들에 대해서는, 당신이 그것을 전달할 OPENSTRUCT 구조체의 버전을 결정하는 태그입니다.

이 하나 개의 시나리오에서 잠재적 인 문제가 주문 : 그 종류 0x500와 0x501 사이에 연장 된 경우 바이너리 라이브러리와 같은 유형의 코드 교환 WinAPI를 유형 또는 포인터의 나머지 부분, 그리고 다음 일이 폭발하기 위하여려고하는 경우 . 다행히도, 버전 범위가 매우 좁기 때문에 그러한 구조체가 많이있을 것이라고는 기대하지 않습니다. 그러나 걱정이된다면 새로운 바이너리를 요청해야합니다. 실수를 저지를 기회가 많으므로 작업이 어렵고 지루할 것입니다.

그 외에도, 나는 (아마도) 안전하다고 생각합니다.

출처

2015-01-20 19:15:09 Wintermute

좋은 정보와 나쁜 상황이 발생할 수있는 상황을 제공 해주셔서 감사합니다! – iminyourbrain

헤더에서 _WIN32_WINNT 정의가 변경되었는데, 이것이 바이너리 비 호환성을 유발합니까?

답변

관련 문제