윈도우 11 22H2의 작업 관리자 성능 모니터링 문제

CPU의 스레드별 사용률을 프로그래밍으로 얻기위해 NtQuerySystemInformation 함수로 얻어진 카운터로 사용률 계산해보니 작업 관리자의 성능 모니터 값과 두배 이상 차이나는 현상이 발생하였다.

작업관리자의 프로세스와 성능 화면은 아래와같다.

ConsoleApp1의 사용률 약 42%
성능 모니터의 프로세서 사용률 약 43%
Continue reading 윈도우 11 22H2의 작업 관리자 성능 모니터링 문제

MSVC로 ANGLE 빌드하기

참고내용
환경설정: https://chromium.googlesource.com/angle/angle/+/HEAD/doc/DevSetup.md
depot_tools: https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/depot_tools_tutorial.html#_setting_up
Windows SDK: https://developer.microsoft.com/en-us/windows/downloads/sdk-archive/
빌드 캐시: https://github.com/mozilla/sccache/releases

빌드환경
MSVC 2019 (기본)
Windows SDK 10.0.20348.0 (2022-05-30 기준)
Python 3버전

구성
1. depot_tools 문서의 윈도 번들 파일인 이 링크 다운로드 (D:\OpenSource\depot_tools 로 경로를 가정)
2. 빌드 캐시를 사용할 경우 빌드캐시 링크에서 sccache-vx.y.z-x86_64-pc-windows-msvc.tar.gz 형식의 링크 다운로드 (D:\OpenSource\depot_tools에 sccache.exe를 위치시키는것으로 가정)
3. Windows SDK 설치
4. Python 3 설치
5. 소스코드는 D:\OpenSource\angle로 위치시키는것으로 가정

빌드
1. ‘x64 Native Tools Command Prompt for VS 2019’에서 D:\OpenSource\depot_tools로 이동 후 set PATH=%CD%;%PATH% 실행 (또는 set PATH=D:\OpenSource\depot_tools;%PATH% 실행)
2. set DEPOT_TOOLS_WIN_TOOLCHAIN=0 명령을 실행
3. D:\OpenSourceangle 폴더를 생성하여 이동 후 fetch angle 명령을 실행
4.1. 디버그 빌드는 gn gen out/Debug --sln=angle-debug --ide=vs2019 --args="is_component_build = true is_debug = true" 실행 후 autoninja -C out/Debug 명령을 실행
4.2. 릴리즈 빌드는 gn gen out/Release --sln=angle-release --ide=vs2019 --args="is_component_build = true is_debug = false" 실행 후 autoninja -C out/Release 명령을 실행

사용
1. Include 패스는 D:\OpenSource\angle\out\Debug\include 또는 D:\OpenSource\angle\out\Release\include
2. Lib 패스는 D:\OpenSource\angle\out\Debug 또는 D:\Opensource\angle\out\Release
3. 필요한 링크 파일은 libEGL.dll.lib libGLESv2.dll.lib 등 (상황에 따라 다르겠지만 이것들 외 링크가 필요하다면 이미 각자 필요한 파일이 무엇인지 알듯.)

기타
1. 빌드 캐시를 사용하려면 gn 명령 실행 시 gn gen out/Debug --sln=angle-debug --ide=vs2019 --args="is_component_build = true is_debug = true cc_wrapper = \"sccache\""와 같이 cc_wrapper = “sccache”를 추가하여 실행
2. 아래와같은 오류가 발생 할 경우 선택된 영역을 참고하여 필요한 버전의 SDK를 설치하여 gn 명령을 다시 실행 (환경설정 문서를 참고하면 vs_toolchain.py 파일에서 확인 가능하다고 하지만 그냥 gn 명령을 실행하면 발생하는 오류 메시지로 확인하는게 훨씬 더 편하다.)

CEF(Chromium Embedded Framework) 빌드

풀네임으로는 Chromium Embedded Framework

우연찮게도 DJMAX에서 MSVC 재배포 패키지 설치가 필요하다는 오류가 뜬다는 질문을 보고 몇버전 런타임이 필요할까 하여 리소스를 살펴보다 이건 왜이렇게 용량이 큰거지? 라는 의문으로 구글링하다 알게된 것. 그런데 또 우연스럽게도 며칠 지나지도않아서 이거 관련되어 요청이 하나 들어온게 발생하여 빌드해보았다.

쉬운방법은 cef-project 코드를 받아서 readme 파일대로 cmake만 실행하면된다. 하지만 이건 자동빌드에 의해 먼저 빌드된 엔진을 다운로드하여 부수적인 dll파일만 빌드하는것으로 보였다. 기왕이면 동일한 런타임, 컴파일러로 빌드된 라이브러리를 발드하고싶어 좀 더 보니 cef가 있다. 이쪽은 빌드과정이 흩어져있어서 아래와같이 정리.

Continue reading CEF(Chromium Embedded Framework) 빌드

Visual Studio 2017 Community의 프롬포트 도구모음 스크립트 버그

현재 2018년 4월 19일 겪어서 하루 삽질한 내용.

부스트 라이브러리 경로를 INCLUDE, LIB 환경변수에 설정하고 Qt Creator에서 아무리 들고볶아도(최신버전을 받아서 업데이트 포함) LIB변수는 변하는데 INCLUDE 변수는 전혀 변하지않고 환경변수 값이 반영 안되는 것이였다.

구글링도해보고 뭘 해봐도 다른건 되는데(CL, _CL_변수) 이게 안되어서 IDE에서 헤더를 인식 못하였다. 그렇게 오늘 수 시간을 삽질한 결과 답을 얻었다.

일단 문제의 스크립트 내용은 아래와같다.

1분만에 눈에 들어오는것이 있다면 매의눈이라고 할 수 있겠다. __tmpwinsdk_include 환경변수를 초기화하고 INCLUDE 변수 내용을 담고 그것을 다시 환경변수에 설정하고 __tmpwinsdk_include 변수를 비우는데… 문제는 INCLUDE 환경변수를 수정하는 라인에 있었다. 그쪽만 혼자 __tmp_include변수에 할당하고 그 변수는 그냥 쓰레기가 되어버렸다.

이건 스크립트 흐름으로 보아 분명 버그임에 틀림없으니… 일단 내가 바꿔서 사용해야겠다. -_-;; 이것때문에 오전부터 지금까지 네시간 넘게 내가 왜 삽질을 해야했을까… 암튼 이 포스팅은 이것으로 끝!

아래 스크린샷은 수정한 후의 “C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\vsdevcmd\core\winsdk.bat” 파일의 내용이다.

WinCrypt의 핸들은 스레드 안정성이 보장안되는거같다

영어가 안되어 크롬의 번역으로 https://stackoverflow.com/a/10807684 이 댓글을 읽어보니…

ECB 모드로 동작할때는 상태가 변경되지않아 상관없으나 기본 모드인 CBC 모드는 상태정보가 변경되기때문에 안정적이지 않다고 이해된다.
이걸 사용하면서 로직 손을 보고나서는 왜 자꾸 패킷이 깨지나했더니 이런거였구나(…) 이거때문에 거의 한달을 미궁에 빠져있었네 orz

복잡하게 처리할거는 없으니 Semaphore를 사용해서 해결해야겠다(…)

참고로 WinCrypt의 사용법 글은 이글의 바로 전 글