2008/09/22 11:20 :: 분류없음
여기서 CVS나 SVN같은 source version control 툴들을 간략히 소개
| 태그 : | bazaar, CVS, GITZO, libresource, mercurial, monotone, SVN, version control |
이 글의 관련글(Trackback) 주소 :: http://raballe.tistory.com/trackback/29
2008/08/26 17:55 :: Programming Skills
memcpy나 strcpy등은 주의깊게 사용하지 않으면 다른 메모리 영역을 overriding하는 등의 부작용이 빈번하게 발생한다. MS에서는 이런 runtime 함수들에 대해서 좀 더 안전해진 별도의 함수들을 제공한다. 이른바 Security Enhancements in the CRT
대략적인 제공 기능은,
이걸 쓸 수 있는 상황이면 한번 적용해 보는것도 나쁘지 않겠다
대략적인 제공 기능은,
- Null check 및 range 검사 등 parameter check
- buffer overflow 검사
- 스트링의 null-termination 검사
- exception 발생시 handler를 사용자가 설정하는 기능 등
이걸 쓸 수 있는 상황이면 한번 적용해 보는것도 나쁘지 않겠다
이 글의 관련글(Trackback) 주소 :: http://raballe.tistory.com/trackback/27
2008/08/12 20:19 :: Programming Skills
WM용 어플을 개발한 후 이를 deploy/실행하면, security warning dialog가 뜨게 된다.
아마도 검증된 모듈이 아닌데 설치된다는 것을 알려주는듯..
개발시 이 dialog를 매번 눌러주는 것도 매우 불편하다.
그래서 warning을 없애는 아래와 같은 방법이 있다.
아마도 검증된 모듈이 아닌데 설치된다는 것을 알려주는듯..
개발시 이 dialog를 매번 눌러주는 것도 매우 불편하다.
그래서 warning을 없애는 아래와 같은 방법이 있다.
- ActiveSync연결
- \Program Files\Microsoft Visual
Studio 8\SmartDevices\SDK\SDKTools 이동후 도스창 띄웁니다
- 도스창에서 아래 명령 실행.
RapiConfig.exe /P /M securitymodels\open.xml - success했다면 성공.
- 이후 부터는 security
warning dialog가 뜨지 않습니다.
| 태그 : | deploy, security warning, Windows Mobile |
이 글의 관련글(Trackback) 주소 :: http://raballe.tistory.com/trackback/25
2008/07/15 19:34 :: Programming Skills
Side by Side Assembly는 dll hell을 해소하기 위해 VS2005부터 지원하기 시작한 개념으로,
한 PC에서도 서로 다른 버전의 dll을 사용하는 어플을 동시에 실행시킬 수 있게 한다.
예를 들어, 버전 1.0.1인 dll A를 사용하는 어플과 1.0.2인 dll A를 사용하는 어플이 있을 때,
dll A를 버전별로 별도로 관리해서 각 어플이 해당 dll을 올바로 런타임에 링크하게 한다.
이 방식은 어떻게 보면 linux에서 so파일을 쓰지만 사실상 버전별로 다른 so파일을 쓰는 것과 유사한 점이 있다.
VS2005부터는 빌드시에 항상 manifest파일이 생성되며 이는 별도 파일로 생성하거나 dll 내부에 포함시키고 있다.
각 manifest파일에는 자신이 빌드시에 사용한 하위 dll들의 버전 정보등이 포함된다.
실행시에는 dll loader가 manifest파일을 보고 어떤 버전의 dll을 쓸지 결정해서 loading한다.
Visual studio에서 제공하는 CRT등의 dll은
%WINDIR%\WinSxS\x86_Microsoft.VC90.CRT_<version>
과 같은 형태의 디렉토리에 각각 저장되며
%WINDIR%\WinSxS\Manifests\x86_microsoft.vc90.crt_<version>.manifest
에 인스톨 정보가 남게 된다. 그리고
%WINDIR%\WinSxS\Policies\x86_policy.9.0.Microsoft.VC90.CRT_<version>.policy
위와 같은 policy 파일을 통해 redirection도 가능하다.
보통의 경우에 VS2005를 설치하지 않은 PC에서 실행하기 위해서는 redistributable package라는 것을 다운받아 설치하면 CRT등의 dll이 해당 디렉토리에 설치되게 된다. 하지만, debug모드용 dll들은 이런 package에 포함되지 않은 듯 하다. 그래서 수동으로 필요한 파일들을 커파해야 하며, dll과 manifest외에 위의 policy와 인스톨 정보도 함께 카피해야 정상적으로 로딩에 성공한다.
그외에 trouble shooting 자료도 참조할것.
한 PC에서도 서로 다른 버전의 dll을 사용하는 어플을 동시에 실행시킬 수 있게 한다.
예를 들어, 버전 1.0.1인 dll A를 사용하는 어플과 1.0.2인 dll A를 사용하는 어플이 있을 때,
dll A를 버전별로 별도로 관리해서 각 어플이 해당 dll을 올바로 런타임에 링크하게 한다.
이 방식은 어떻게 보면 linux에서 so파일을 쓰지만 사실상 버전별로 다른 so파일을 쓰는 것과 유사한 점이 있다.
VS2005부터는 빌드시에 항상 manifest파일이 생성되며 이는 별도 파일로 생성하거나 dll 내부에 포함시키고 있다.
각 manifest파일에는 자신이 빌드시에 사용한 하위 dll들의 버전 정보등이 포함된다.
실행시에는 dll loader가 manifest파일을 보고 어떤 버전의 dll을 쓸지 결정해서 loading한다.
Visual studio에서 제공하는 CRT등의 dll은
%WINDIR%\WinSxS\x86_Microsoft.VC90.CRT_<version>
과 같은 형태의 디렉토리에 각각 저장되며
%WINDIR%\WinSxS\Manifests\x86_microsoft.vc90.crt_<version>.manifest
에 인스톨 정보가 남게 된다. 그리고
%WINDIR%\WinSxS\Policies\x86_policy.9.0.Microsoft.VC90.CRT_<version>.policy
위와 같은 policy 파일을 통해 redirection도 가능하다.
보통의 경우에 VS2005를 설치하지 않은 PC에서 실행하기 위해서는 redistributable package라는 것을 다운받아 설치하면 CRT등의 dll이 해당 디렉토리에 설치되게 된다. 하지만, debug모드용 dll들은 이런 package에 포함되지 않은 듯 하다. 그래서 수동으로 필요한 파일들을 커파해야 하며, dll과 manifest외에 위의 policy와 인스톨 정보도 함께 카피해야 정상적으로 로딩에 성공한다.
그외에 trouble shooting 자료도 참조할것.
| 태그 : | DebugCRT, manifest, msvcr80d.dll, side by side |
이 글의 관련글(Trackback) 주소 :: http://raballe.tistory.com/trackback/23
2008/05/23 10:20 :: Cryptography
IEEE 802.11 wireless network의 인증/보안을 위한 표준의 흐름
- 초기에는 Wired Equivalent Privacy (WEP)를 사용했음
- 이는 RC4 stream cipher를 사용했지만, keystream reuse 문제와 HMAC대신 단순 CRC를 쓰는 문제로 인해 보안상 허점들이 발견됨
- 이에, WEP를 deprecate시키고 802.11i의 subset인 Wi-Fi Protected Access (WPA)를 제안
- 802.11i의 full implementation은 WPA2(혹은 RSN-Robust Security Network)라 불림
- 802.11i는 인증을 위한 802.1X와 confidentiality, integrity를 위한 AES기반 암호화를 사용
- group key도 사용되지만, 갱신시 AP가 1-1로 새 키를 제공하는 기본방식 사용
- 초기에는 Wired Equivalent Privacy (WEP)를 사용했음
- 이는 RC4 stream cipher를 사용했지만, keystream reuse 문제와 HMAC대신 단순 CRC를 쓰는 문제로 인해 보안상 허점들이 발견됨
- 이에, WEP를 deprecate시키고 802.11i의 subset인 Wi-Fi Protected Access (WPA)를 제안
- 802.11i의 full implementation은 WPA2(혹은 RSN-Robust Security Network)라 불림
- 802.11i는 인증을 위한 802.1X와 confidentiality, integrity를 위한 AES기반 암호화를 사용
- group key도 사용되지만, 갱신시 AP가 1-1로 새 키를 제공하는 기본방식 사용
이 글의 관련글(Trackback) 주소 :: http://raballe.tistory.com/trackback/21
2008/03/05 16:13 :: Programming Skills
* scoped locking
- Resource Acquisition Is Initialization (RAII) 디자인 패턴과 auto_ptr(참조)등을 이용해서 리소스 획득 후 release하는 것을 자동화함으로써 버그를 만들 확률을 낮춤
- 기본 방식은 local variable의 lifetime을 가지며 stack에 저장되는 object를 사용.
- 예를 들어, mem allocation의 경우 선언과 초기화 후에 release는 destroy될때 하며, local lifetime을 가지므로 leak없이 delete됨.
- 메모리, FILE, multi-thread환경의 공유 데이터 등의 관리에 사용됨
- exception 처리나, api call/exit logging, api 단위의 access control에도 적용 가능
* double checked locking- 기본 방식은 local variable의 lifetime을 가지며 stack에 저장되는 object를 사용.
- 예를 들어, mem allocation의 경우 선언과 초기화 후에 release는 destroy될때 하며, local lifetime을 가지므로 leak없이 delete됨.
- 메모리, FILE, multi-thread환경의 공유 데이터 등의 관리에 사용됨
- exception 처리나, api call/exit logging, api 단위의 access control에도 적용 가능
- singleton의 getInstance에서는 오직 하나의 instance만 만들어지도록 관리해야 한다.
- 이를 검사하기 위해 locking을 쓰는데, lock되는 scope은 되도록 줄이자는 원칙에 따르고 항상 하나의 instance만 생긴다는 것을 보장하기 위해 두번의 NULL check을 하는 double checked locking을 사용한다.
- compiler/language에 따라 broken되기도 한다(아마도 optimization으로 instruction 순서가 바뀌어서인듯)
- 이를 검사하기 위해 locking을 쓰는데, lock되는 scope은 되도록 줄이자는 원칙에 따르고 항상 하나의 instance만 생긴다는 것을 보장하기 위해 두번의 NULL check을 하는 double checked locking을 사용한다.
- compiler/language에 따라 broken되기도 한다(아마도 optimization으로 instruction 순서가 바뀌어서인듯)
이 글의 관련글(Trackback) 주소 :: http://raballe.tistory.com/trackback/19
2008/02/29 11:11 :: Programming Skills
From MSDN:
For a DLL, the default entry point is _DllMainCRTStartup.
For an EXE, the default entry is wWinMainCRTStartup, the Unicode entry point for an EXE that defines the wWinMain function, or WinMainCRTStartup otherwise.
You can rely on the default entry point that the linker chooses, but the best practice is usually to override the default choice. Instead, specify an entry point with the /ENTRY linker option.
Windows CE supports the following CRT entry points:
mainACRTStartup for applications that define the main function
mainWCRTStartup for applications that define the wmain function
WinMainCRTStartup for applications that define the WinMain function
wWinMainCRTStartup for applications that define the wWinMain function
_DllMainCRTStartup for DLLs
For more information, see the linker topic /ENTRY (Entry-Point Symbol).
Note: if you want to use mainACRTStartup or mainWCRTStartup, you must explicitly state that when you specify the /ENTRY option.
For a DLL, the default entry point is _DllMainCRTStartup.
For an EXE, the default entry is wWinMainCRTStartup, the Unicode entry point for an EXE that defines the wWinMain function, or WinMainCRTStartup otherwise.
You can rely on the default entry point that the linker chooses, but the best practice is usually to override the default choice. Instead, specify an entry point with the /ENTRY linker option.
Windows CE supports the following CRT entry points:
mainACRTStartup for applications that define the main function
mainWCRTStartup for applications that define the wmain function
WinMainCRTStartup for applications that define the WinMain function
wWinMainCRTStartup for applications that define the wWinMain function
_DllMainCRTStartup for DLLs
For more information, see the linker topic /ENTRY (Entry-Point Symbol).
Note: if you want to use mainACRTStartup or mainWCRTStartup, you must explicitly state that when you specify the /ENTRY option.
이 글의 관련글(Trackback) 주소 :: http://raballe.tistory.com/trackback/18
From www.idsolution.co.kr
 |
| 톡톡튀는 참신한 키치 예술 취향 |
|
당신은 새로운 것을 찾고 독특함을 개발하고 싶어합니다. (항상 그런건 아니겠지만) 다들 따라하는 패션, 누구나 흥얼거리는 노래, 너도나도 사보는 베스트셀러, 아줌마들이 떠들어 대는 연속극, 모두 신물 나는 것들입니다. "이상한 나라의 앨리스"
루이스 캐롤의 이 정체불명 괴상한 이야기는 당신의 취향과 일맥상통합니다. 당신은 너무 직관적인 것만 찾을 뿐 도통 좋아하는 것에 기준이 없다는 비난을 들을지도 모르겠습니다. 특이한 걸 좋아하긴 하지만, 뭐가 얼마나 어떻게 특이해야 좋은지 당신도 잘 모를 겁니다.
|
이 글의 관련글(Trackback) 주소 :: http://raballe.tistory.com/trackback/17
2008/01/08 15:29 :: Tools
작성한 코드들이 pointer를 이용한 function call들이 많아서 제대로 call graph를 보기 힘들가.
이를 위해 코드를 분석해주는 툴들을 찾아보았다.
코드를 실행하면서 분석 결과를 알려주는 DevPartner라는 tool의 evaluation 버전을 사용해봤는데,
일단 정품이 아니라 결과가 저장이 안되고 -_-; call graph의 글자가 너무 작고 잘린다.
그래서 코드 실행 없이 static하게 분석하는 tool을 찾아봤다.
SNIFF+이랑 CodeSurfer가 사용하기 적당한 듯해서 찾아봤으나,
SNIFF는 linux용만 찾고 CodeSurfer는 요즘 발매 중지중인듯 -_-
어디 간단하고 좋은 tool없나..
이를 위해 코드를 분석해주는 툴들을 찾아보았다.
코드를 실행하면서 분석 결과를 알려주는 DevPartner라는 tool의 evaluation 버전을 사용해봤는데,
일단 정품이 아니라 결과가 저장이 안되고 -_-; call graph의 글자가 너무 작고 잘린다.
그래서 코드 실행 없이 static하게 분석하는 tool을 찾아봤다.
SNIFF+이랑 CodeSurfer가 사용하기 적당한 듯해서 찾아봤으나,
SNIFF는 linux용만 찾고 CodeSurfer는 요즘 발매 중지중인듯 -_-
어디 간단하고 좋은 tool없나..
| 태그 : | call graph, code analysis, CodeSurfer, sniff+ |
이 글의 관련글(Trackback) 주소 :: http://raballe.tistory.com/trackback/13
2007/12/27 17:23 :: Tools
linux에서 메모리 릭이나 잘못된 메모리 사용을 찾기 위해서라면 valgrind를 사용한다.
사용법 : valgrind --tool=memcheck --leak-check=yes --show-reachable=yes 실행파일
valgrind에는 메모리 검사하는 memcheck외에도 cache 프로파일을 위한 cachegrind, 멀티쓰레드용 helgrind등이 있음.
valgrind의 장점 중 하나는 원본 소스를 리컴파일할 필요없이 바로 사용가능하다는거.
기본 원리는 LD_PRELOAD를 이용해서 valgrind.so를 먼저 링크시키고 가상의 CPU를 사용하게 함으로써 debug정보를 얻는 방식을 사용한다.
자세한 사용법은 HowTO 참조
사용법 : valgrind --tool=memcheck --leak-check=yes --show-reachable=yes 실행파일
valgrind에는 메모리 검사하는 memcheck외에도 cache 프로파일을 위한 cachegrind, 멀티쓰레드용 helgrind등이 있음.
valgrind의 장점 중 하나는 원본 소스를 리컴파일할 필요없이 바로 사용가능하다는거.
기본 원리는 LD_PRELOAD를 이용해서 valgrind.so를 먼저 링크시키고 가상의 CPU를 사용하게 함으로써 debug정보를 얻는 방식을 사용한다.
자세한 사용법은 HowTO 참조
| 태그 : | linux, memory leak, valgrind |
이 글의 관련글(Trackback) 주소 :: http://raballe.tistory.com/trackback/12
