에러블로그

자랑은 아니지만... 크랙찾다가 -_-;;

이런 바이러스에 걸렸다.

현상 :

아직 국내에서 유명하지 않은지 알약은 못잡드라...
NOD32 Trial 깔아봤는데 못잡드라... (저 웹페이지 차단은 해준다.)

검색하다가 FxIeDef 란 전용 클리너를 찾아서 해결했다..
http://downloads.malwareteks.com/FixIEDef.exe

혹시 링크가 깨질까봐 첨부.

Microsoft의 OS는 크게 3가지로 나뉜다.

-----------------------------------------------
.Net Micro Framework

OS는 아니다. (하지만 무려 Thread도 지원한다.)
AVR등이 주로 쓰이고 있는 환경을 .NET 으로 도배할 야심찬 계획. (센서노드가 분명 계산에 들어갔을거다)

WPF, XML도 지원한다.
HTTP Client 도 들어있던가? 하지만 가장 기대했던 Web Service Client는 없었다. 쳇.

Windows Vista 탑재 노트북의 SideShow 기능, 조금 더 Smart한 기능을 지원하는 시계서비스 (SPOT)등에 도입되어있다.

현재 지원 CPU는 ARM7, 9

물론 HAL은 하드웨어 제조사에서 자신들의 보드에 맞춰 직접 개발해야 한다.

-----------------------------------------------

Windows CE 계열
수도 없이 이름을 바꾸고는 있지만 -_-;

현재는 Windows Embedded CE로 부르고 있다. (곧 또 바꾼단다.)
이 계열에는
Windows Mobile / for XXX Edition s (예전의 Pocket PC)
과 Windows CE가 있다.

Windows Mobile은 PDA나 핸드폰에 탑재된다.
ARM9, MIPS 이상의 CPU가 필요하다.
Pocket PC 2002, 2003 은 Windows CE 3.X
Windows Mobile 5(?),6 는 Windows CE 5.X 의 커널을 사용.

Windows CE는 POS(마트 계산대)나 조금 대형 사이즈 PDA (PMP, 네비) 등에 많이 들어간다.

OS 포팅 과정은 PC처럼 표준화된 환경에 단순히 설치하는 작업이 아니다.
하드웨어에 맞추어 초기화과정, 인터럽트 세팅 등이 기본적으로 필요하며,
각 장치드라이버들을 구현 해주어야 한다. (이런 것들은 리눅스도 마찬가지.)

주로 OAL이라고 부르는 영역을 개발해주어야 하며,
거기에 더해 쉘을 자기가 원하는대로 바꾸고 싶다거나 한다면
엄청난 리소스노가다가 따라온다는 것을 잊지말자.

...그래도 CE에서는 .net 이 되잖아 *-_-*


-----------------------------------------------

PC 용 Windows

x86, x86 64bit CPU를 지원한다.
Windows XP, Windows Vista 등등
알다시피.

변종으로 컴포넌트들을 맘대로 세팅할 수 있는 Windows Embedded XP 와 곧 나올 Embedded Vista 가 있다.
오락실의 pump/ez2dj, 공장, POS 등에 활용된다.

가격도 일반 OS에 비해 저렴하고 pc windows 와 거의 완벽히 호환되는 게 장점이다.
-----------------------------------------------

공통점은 .net 으로 대동단결이 되며, 개발툴은 visual studio을 이용한다는거다.

학생들에게 무료로 개발툴을 지원하는 프로그램(일종의 행사?)이다.

공부하는 학생개발자들에게 자기네 플랫폼에 완전히 물들게 하기 위한?

뭐... 일단 좋다. (난 학생이 아니라 안좋다 ㅜㅜ)


굳이 불법 CD 다운받지 않고도 쓸 수 있게 되었으니 등록해서 써보자..

이 프로그램에 등록하여 혜택을 받기 위해선 국제학생증이 필요하다.

자세한 내용은 나중에 덧붙이겠음.


...

그나저나 Microsoft는 신흥 종교라도 되고 싶은건지..-_-;;

evangelist는 뭐냐고! -_-;;

두가지 컴포넌트가 포함된 project의 sdk가 필요로 할 수 있다.
AYG Shell 과 Network..뭐더라 -_-

Standard SDK 소스와 custom sdk를 비교해 봤을 땐 거의 무조건 있어야 되는 것으로 보인다.

AYG Shell 은 라이센스가 Professional 라서 Core를 쓰고자 한다면 골치가 좀 아플 듯.

Windows Embedded CE 6.0 부터는 아예 MFC 컴포넌트가 제외되어서 직접 라이브러리를 추가해야하는 걸로 봐선...

마소에서 '이제 MFC 그만 좀 쓰셈!' 하는 것으로 보인다. (MFC 좋은데... 우쒸... 버그가 꽤 있어서 그렇지..)

그런데 확실히 .net 의 퍼포먼스가 많이 좋아졌다.(컴퓨터가 좋아진건가?) 쉽고. 편하고.

.Net Micro Framework 도 써보고픈데..

보드 안사고 회사 보드에서 써볼라믄 이거 또 내가 포팅해야될까봐서리... 시간도 없는데 귀찮아서 -_-;

Windows 에서 Wide Character 는 UNICODE 를 의미한다.

--------------------------------

매크로
_T("ABC")
TEXT("ABC")

"ABC" 대신 위에 것들을 쓰자.
UNICODE로 컴파일하면 UNICODE문자열로, ASCII로 컴파일하면 ASCII 문자열로 인식한다.

--------------------------------

windows (ce포함)용 c/c++의 string 처리에서 알아두면 좋은 거.

문자열의 길이를 재는 함수라면?
strlen() : ASCII용 문자열 길이 쟤는 함수
wcslen() : UNICODE용 문자열 길이 쟤는 함수
_tcslen() : 환경에 맞추어지는 매크로

뭐 일단 _mcslen() 도 있긴하다. (MB환경에서 strlen을 호출하면 이쪽으로 연결할걸?)

다른 함수들도 마찬가지다.

strXXXX() 함수들이 wcsXXXX()로, tcsXXXX() 로 바꾸어 쓰면 된다.

strtol : ASCII 문자열에서 long 값으로 변환 (atoi와 비슷하지만 진수 지정 가능)
wcstol : UNICODE ~~~
_tcstol : 환경 ~~~

-------------------------------

그럼 다 지원하려면 가장 깔끔한 방법은?
tcsXXXX() 시리즈를, char 대신 매크로 TCHAR 쓰는거.

물론 덕분에 골치아픈 문제도 가끔 발생한다는거..

-------------------------------

WideCharToMultiByte() : UNICODE -> ASCII

MultiByteToWideChar() : ASCII -> UNICODE

--------------------------------

char : ASCII
wchar_t : UNICODE
TCHAR : 환경 따라가는 매크로

--------------------------------

CString은 내용이 wchar일 수 도, char일 수 도 있음에 유의할 것.

--------------------------------

eVC++ 이나 SmartDevice(WinCE)용으로 사용하는 Visual Studio 시리즈는 기본설정이 UNICODE 환경으로 되어있다.
ASCII를 쓰고 싶다면 컴파일설정 (프로젝트 속성?) 을 바꾸어 주어야한다.

--------------------------------

아... Windows Embedded CE 6.0 부터는 기존 문자열 함수들에 문제가 있을 수 있다고 해서...
safe 시리즈를 선보였다. 젠장.

예를들어 strcpy 라면 strcpy_s 이런식이었던 듯...
대충 봤을 때 문자열 종료 문자 '\0'가 문제가 있다고 파악한 모양이다.

platform : BSP
project : BSP로 만들어낸 project

bib
TAB name : MODULES

Name : 파일명.
커널의 Windows 디렉토리에 이 파일명으로 적재된다.

Path : 가져올 파일
$(_FLATRELEASEDIR) 은
(your workspace)\~~\RelDir\~~_Release 이다. (혹은 Debug)


Memory Type : 타입
NK : 커널에 적재함
S : 뭐더라?
H : Hidden (파일이 안보인다.)
K : 커널모드 (권한이 커널 권한이 필요한 드라이버나.. 그런 거...)


dat
파일을 배치한다.

Directory("\Windows\LOC_DESKTOP_DIR"):-Directory("Example")
 
"\Windows\바탕 화면"에 "Demo" 디렉토리를 만든다.
여기서 LOC_DESKTOP_DIR 는?
"바탕 화면"을 말하는 locale 단어들. 영문판이라면 Desktop

Directory("\Windows\LOC_DESKTOP_DIR\Example"):-File("Test1.lnk","\Windows\Test1.lnk")
\Windows\Test1.lnk 파일을 \Windows\LOC_DESKTOP_DIR\Example 에 Test1.lnk 라는 이름으로 배치한다.

GPLR (Level)
Read Only
해당 핀의 High/Low 상태 확인 (해당 비트가 1이면 High)

GPDR (Direction)
Read/Write
핀의 경로 설정. 0이면 Input, 1이면 Output.

GPSR (Set) / GPCR (Clear)
Write Only (Read도 되던가?ㅡ.ㅡ;)
GPSR - 핀에 High를 Set함(1로 만듬), GPCR의 반대 기능
GPCR - 핀을 Low로 떨어뜨림(0으로 만듬), GPSR의 반대 기능

GRER (Rising Edge) / GFER (Falling Edge)
Write Only (Read도 되던가?ㅡ.ㅡ;)
핀 레벨엣지 감시. GRER의 해당 비트를 1로 만들면 Rising을, GFER의 해당 비트를 1로 만들면 Falling을 감시한다. 검출된 결과는 GEDR의 해당 비트가 1로 됨으로 써 알 수 있다.

GEDR (Edge Detect)
Read/Write
GRER/GFER에서 지정한 핀에서 Edge가 확인하면 해당 비트가 1로 바뀐다.
해당 핀의 비트에 1을 주면 Edge가 검출되었다고 1로 세팅되었던 비트가 0으로 clear된다.

GAFR (Alternate Function)
Write Only
이놈만 한 핀당 2비트다.
회로 설계에 따라 어찌할지 정해야한다.
(초짜 SW쟁이라 잘 모르겠다 -_-; 그냥 HW팀에서 해달라는대로 해줬다.)

00 : General Purpose I/O
01 : alternate function 1
10 : alternate function 2
11 : alternate function 3


---------------------------------------------
example.

GPIO핀 하나에 LED를 물렸다.
이 LED를 켜려면?
GPDR의 해당 비트는 1로 되어있어야한다.
그리고 해당 GPSR에 1을 준다.
끄려면?
GPDR의 해당 비트는 1로 되어있어야한다.
그리고 해당 GPCR에 0을 준다.

장치로부터 Level Edge 인터럽트를 받고자 하며, Rising과 Falling 둘다 필요한데 상황에 따라 처리할 내용이 다르다. 구분은 어떻게?
일단 GRER과 GFER을 모두 세팅해놓는다.
GEDR 감시로 인터럽트 발생을 확인한다.
Edge가 발생되면 GPLR로 핀레벨을 확인하여 확인된 Edge가 Rising인지 Falling인지 알 수 있다.

---------------------------------------------

오늘의 잡템.

급조한거지만 비트를 한 눈으로 못읽는 나같은 이들을 위해 만든(사실을 나를 위해-_-;)
2가지 기능을 가진 잡템 -_-;

(GPLR을 예로 들면 GPLR0은 0~31, GPLR1은 32~63을 담당한다.)
핀번호 넣고 gen을 눌러주면 된다.

현재 세팅하는 값을 알기 위한 기능으로 Reg2GPIO -_-;;
GPLR2에서 읽힌 값이 0x80000000 이었다면 이게 몇번 핀들을 의미하는지 알기 위한 기능 ㅡ.ㅡ;;


나말고 다른 사람에게 쓸모가 있을지는 모르겠다 -_-;

----------------------------

아래는 내가 쓰려고 대충 만든것보다 좋아뵈는거 있어서 퍼왔다. ㅎㅎ




(1)해당 비트에 마우스를 가져다가 클릭해 보세요. 값이 변화를 보일 것입니다.
(2)직접 값을 입력하고 싶을 때는 HEX 창이나 DEC창에 값을 입력 한 이후 TEST 버튼을 눌러보세요.
(3)해당 값의 반전(NOT) 을 취하고 싶을 경우 해당 버튼을 누르세요
(4)해당 값을 원하는 수만큼 쉬프트 시키고 싶을 경우 쉬프트 할 비트수를 입력하고 좌/우 화살표(<<, >>)을 눌러 보세요.
(5)두개의 이진값을 &(AND), |(OR), ^(XOR) 합니다.
(6)To Result 버튼은 연산의 결과를 (1)번의 비트표시창으로 연동시켜 줍니다. 눌러보세요. 1번 윈도우의 비트값이 변화를 보일 것입니다.
(7)어드레스 베이스 값에 원하는 오프셋값을 더하고 빼는 것을 도와 줍니다.
(8)연산의 바로 직전 값을 확인 할 수 있도록 해 줍니다.
(9)Mapping Bits 버튼은 비트 값을 파일로 만들어서 INPUT 시킬 수 있는 기능 인데 사용법을 모르겠습니다.

http://www.hongikcom.com/zb/view.php?id=technote&page=2&sn1=&divpage=1&sn=off&ss=on&sc=on&select_arrange=headnum&desc=asc&no=28

A 알파(alpa)
B 브라보(bravo)
C 찰리(charlie)
D 델타(delta)
E 에코(echo)
F 폭스트롯(foxtrot)
G 골프(golf)
H 호텔(hotel)
I 인디아(india)
J 줄리엣(juliett)
K 킬로(kilo)
L 리마(lima)
M 마이크(mike)
N 노벰버(november)
O 오스카(oscar)
P 파파(papa)
Q 퀘백(quebec)
R 로미오(romeo)
S 세라또는 시에라(sierra)
T 탱고(tango)
U 유니폼(uniform)
V 빅터(victor)
W 위스키(whiskey)
X 엑스레이(x-ray)
Y 양키(yangkee)
Z 줄루(zulu)

Edward C. Bailey, "Maximum RPM" :
RPM을 다룬 문서(책) 중 가장 상세함... 하지만 좀 오래됨...
http://www.redhat.com/docs/books/max-rpm/max-rpm-html/index.html
http://www.rpm.org/max-rpm/

Eric Foster-Johnson, "RPM Guide" :
좀더 쉽게 쓰여진 편이고 예제도 풍부함
Python-RPM 모듈을 사용할 때도 좋음...
http://fedora.redhat.com/docs/drafts/rpm-guide-en/

Paul Nasrat, "RPM Python(and friends)" :
Python-RPM 모듈과 펄등에서의 활용을 다룬 문서
http://people.redhat.com/pnasrat/rpm-python/rpm-python-slides/frames.html

Source RPM 을 재 패키징하려는 경우 :
그냥 막연히 src.rpm이니 rpm -Uvh xxx.src.rpm을 해줬더니 진짜 설치가 되더라. -_-;
/usr/src/redhat에서.
SOURCE에는 tarball소스와 적용된 패치, 추가로 필요한 파일들이 들어가있다.
SPECS에는 .spec로 끝나는 rpm설정(?)파일이 들어가 있다.
tar.gz같은 소스가 rpm으로 바뀌는데 가장 중요한 녀석이라고 생각한다.
----------
새로운 RPM을 만들어내려는 경우 :
SPEC파일을 직접 만들어야한다.
이에 대한 내용은 KLDP의 RPM_Guide 를 참고하면 된다.
아니면 다른 spec파일(src.rpm에 포함된)을 참고해도 좋다.

SOURCES디렉토리에는 프로그램의 소스인 tar.gz를 비롯한 파일들을 넣으면 된다.
SPECS에 xxx.spec파일을 만들어서 넣는다.


-----------------------------------------------

위와 같은 준비가 되었으면 빌드하자.

rpmbuild -ba xxx.spec

spec에 작성한대로 컴파일되고 지지고 볶아서 xxx.i386.rpm과 xxx.src.rpm, xxx-debuginfo.i386.rpm등이 생성된다.

xxx.src.rpm은 SRPMS에 생성된다
xxx.rpm과 debuginfo.rpm은 RPMS/i386에 생성된다.

이제 SRPMS만 있으면 나중에 또 할 수 있다.
- 나머진 버려도 되는건가?

------------------------------------------------
기타 :
debuginfo는 뭔지 모르겠다.

spec에서 define한 릴리즈와 버전대로 파일명이 생성된다.
예를 들어
%define name xxx
%define version 1.1.0
%define release fz1-0
으로 했다면
xxx-1.1.0-fz1-0.i386.rpm
으로 생성될 것이다.
------------------------------------------------
기타 2 :
rpmbuild시 --target=옵션을 추가로 사용할 수 있다.
ex) rpmbuild -ba --target=i686 xxx.spec
이렇게하면 RPMS/i686안에 rpm파일들이 생길 것이다.
------------------------------------------------
기타 3 :
KLDP의 RPM_Guide에 따르면 rpmrc에서 빌드디렉토리도 설정한다고 하는데 안보인다.
어디에 숨었니 -_-;;
그리고 여러가지 타겟들이 적혀있다.
- 설마 정의된 타겟이라면 별다른 과정없이 타겟지정만으로 크로스컴파일도 지원하는걸까?
-> 설마가 사람잡았다. target=arm-linux라고 줬더니 arm.rpm이 생성됐다. -_-;;
--> 빌드메세지를 캡쳐해보니 이런 메세지가 나왔다. checking target system type... i686-pc-linux-gnu
---> 그러므로 엉터리였다. 당연히도 spec파일을 크로스컴파일용으로 작성해야겠지...

----> 그렇다면 i686 같은 패키지를 만들려고 해도 마찬가지라는 것??
------------------------------------------------

어지간히 정리되면 문서도 정리해야겠다.
언제 정리하나...