떨어져 사는 부모님댁에 컴퓨터와 관련된 문제가 일어날 때가 종종 있다.
컴퓨터는 아버지께서만 사용하시니, 문제가 생기거나 하면 아버지께서 내게 도움을 요청하시곤 한다.
하지만...여러 가지로 도움을 드리긴 어렵다.
어떤 문제는 대체 왜 그런 일이 일어났는지 경험도 못 해 본 일인 경우도 있고,
대략 몇가지 가능성을 예상할 수 있는 경우도 있고,
명확하고 자주 겪는 문제인 경우도 있다.
마지막의 경우에도 전화통화만으로 쉽게 해결되지 않는 경우가 있으니,
나는 너무도 당연하게 생각하는 일이 칠순 노인인 아버지께는 그러하지 않은 경우가 많기 때문이다.
일일이 과정 과정을 설명하고, 과정마다의 결과를 확인하고 하면 진이 빠지는 경우도 많다.
그나마 이건 다행인 경우이고,
몇가지 원인이 가능한 경우에는, 각각의 원인을 확인해서 문제의 원인을 밝혀 내야 하는데, 다시 위와 같은 과정을 몇번씩 반복해야 하며, 만일에 말로 설명하기 곤란하거나 확인하기 곤란하다면 이건 그야말로 인내심의 바닥을 확인하게 되기도 한다.
차라리 상상도 못할 문제가 일어난 경우에는 A/S를 부르시라고 권하고, 애초에 포기해 버리니 오히려 부담도 없다.
이런 문제들의 원인은 여러가지가 있으나,
모르는 사람에게 지시를 내리기 어렵다는 것이 근본적인 한계가 아닌가 싶다.
이런 어려움을 피하기 위해서 Remote Desktop을 가능하도록 몇가지 설정이나 툴을 아버지의 컴퓨터에 설치해 두었으나 이를 사용하는 것에도 어려움이 많았다.
가령, 문제가 발생한 경우에, Remote Desktop으로 연결하기 위해서는 IP address를 알아야 가능한데, 아버지께 IP address가 무엇인지 알아내는 방법을 설명하는 것 조차 쉽지 않은 일이다.
여기에, 문제가 쉽게 해결이 되면 좋겠으나, 비교적 장시간이 소요될 수도 있다. 그러면 아버지께 시간이 걸리니 다른 일 보시라 말씀을 드리고 싶으나, rebooting이 필요한 작업의 경우에는 rebooting 후에 다시 IP address가 무엇인지 알아내는 과정부터 반복을 해야 하는 고로 이만 저만 귀찮은 일이 아니다.
무언가 간단하게 상대방과 연결하여 조치를 하거나 확인할 수 있는 방법은 없는걸까?
2012년 7월 24일 화요일
6502 CPU의 Instruction Set
Apple II, Commodore64 등에 사용된 MOS Technology의 6502 CPU의 Instruction Set에 대한 문서입니다.
http://www.6502.org/tutorials/6502opcodes.html
Instruction은 56개밖에 안됩니다.
operand type에 따라 code가 달라져서 Instruction Code의 수는 훨씬 많지만요.
Flag라던지 Operand의 형식에 관한 설명이 없고 이에 대한 별도의 문서도 눈에 띄지 않습니다.
구닥다리라 이제는 사용되지도 않는 CPU의 Instruction을 참조하는 이유는, 에뮬레이터에 대한 궁금증 때문입니다. 과연 에뮬레이터는 어떤 식으로 에뮬레이션을 구현하는지 알고 싶어서 입니다.
http://www.6502.org/tutorials/6502opcodes.html
Instruction은 56개밖에 안됩니다.
operand type에 따라 code가 달라져서 Instruction Code의 수는 훨씬 많지만요.
Flag라던지 Operand의 형식에 관한 설명이 없고 이에 대한 별도의 문서도 눈에 띄지 않습니다.
구닥다리라 이제는 사용되지도 않는 CPU의 Instruction을 참조하는 이유는, 에뮬레이터에 대한 궁금증 때문입니다. 과연 에뮬레이터는 어떤 식으로 에뮬레이션을 구현하는지 알고 싶어서 입니다.
+-+GVIM.png) |
| 에뮬레이터의 레지스터 구조체 및 함수들 |
 |
| ADC Instruction의 예 |
 |
| 어드레싱모드에 관한 매크로 |
 |
| ADC Instruction에 관한 매크로 |
2012년 7월 19일 목요일
진화(進化)의 계단
이전에도 간혹 어렴풋이 들던 생각이,
최근에 다시, 좀 더 또렷하게 들고 있습니다.
프로그래밍 언어들에 대한 구분이 저수준(Low-Level)과 고수준(High-Level)이 되는 경우가 있는데, 이런 구분은 그 언어의 역할 및 용도를 보다 명확히 해 줍니다.
저수준의 언어는 근본적으로 프로그램이 작동하게 될 컴퓨터의 구조와 밀접하게 연관이 되며 군더더기 없고 간결하며 빠르게 작동하는 장점을 가집니다.
반면에 고수준의 언어는 컴퓨터의 구조에 대한 고민을 많이 줄여주고 인간의 복잡한 논리를 구현하는데 더 적합한 장점을 지니게 됩니다.
리버스 엔지니어링을 하다보면, 고수준의 언어로 작성된, 복잡한 알고리즘의 프로그램은 그 자체가 안티-리버싱의 역할도 하지 않나 생각될 정도입니다.
이런 프로그래밍 언어의 고수준화는 하나의 "진화의 계단" 역할을 합니다.
복잡하고 까다로운 논리를 저수준의 언어로 작성하는 것은 무척이나 어려웠을 것입니다.
기본적으로 저수준의 언어를 사용하는 프로그래머의 머리에는 컴퓨터의 구조, 레지스터, 스택, 메모리 사용 등에 대한 지식과 고려가 가득 차 있었을 것이므로 새로운 생각을 할 여유가 그 만큼 적었을 것이기 때문입니다.
비슷한 예로,
플랫폼 또한 하나의 "진화의 계단" 역할을 했을 겁니다.
'플랫폼'이라는 단어 자체가 무언가를 딛고 올라설 수 있는 평평한 곳을 의미하니 너무도 당연하기도 합니다.
많이 알려진 자바가 그렇고, 브라우저도 하나의 플랫폼이며, 플래쉬 또한 하나의 플랫폼이 됩니다.
좀 더 위로 올라가 보면,
MS-Office도 하나의 "계단"이 되지 싶습니다.
LaTex이나 PostScript도 제한적이지만 "계단"이 될 수 있으며,
PhotoShop이나 그림판도 "계단"이 될 수 있지 않을까요?
어쩌면 모든 프로그램은 하나의 "계단"이 아닐까 싶습니다.
무언가를 만들거나 만드는게 도움이 되는...
...
다시 아래로 내려가 볼까요?
Operating System은 확실하게 "진화의 계단" 역할을 했습니다.
이만큼 광범위하고 다양하게 컴퓨터의 자원과 기능들을 사용할 수 있는 편의장치(facility)를 제공해 주는 건, 확실히 쉽지 않은 일입니다.
좀 더 내려가 보면,
컴퓨터의 모든 부품들과 컴퓨터 그 자체 또한 너무나도 당연히 "진화의 계단"입니다.
초기의 컴퓨터를 설계한던 사람들은 그들이 만든 이 "계단"이 지금 이만큼까지 올라올걸 상상이나 했을까요?
아마도 이만큼은 절대 상상하지 못했을 겁니다.
단지 그들은 좀 더 위로 올라가기 위한 하나의 "계단"을 만들었을 뿐이겠죠.
그리고 하나의 계단을 딛고 올라선 사람들은 다시 또 하나의 계단을 만들었을 것입니다.
좀 엉뚱한 상상이지만,
진화론의 측면에서 바라보면, 인간 또한 하나의 "계단"은 아닐까요?
최근에 다시, 좀 더 또렷하게 들고 있습니다.
프로그래밍 언어들에 대한 구분이 저수준(Low-Level)과 고수준(High-Level)이 되는 경우가 있는데, 이런 구분은 그 언어의 역할 및 용도를 보다 명확히 해 줍니다.
저수준의 언어는 근본적으로 프로그램이 작동하게 될 컴퓨터의 구조와 밀접하게 연관이 되며 군더더기 없고 간결하며 빠르게 작동하는 장점을 가집니다.
반면에 고수준의 언어는 컴퓨터의 구조에 대한 고민을 많이 줄여주고 인간의 복잡한 논리를 구현하는데 더 적합한 장점을 지니게 됩니다.
리버스 엔지니어링을 하다보면, 고수준의 언어로 작성된, 복잡한 알고리즘의 프로그램은 그 자체가 안티-리버싱의 역할도 하지 않나 생각될 정도입니다.
이런 프로그래밍 언어의 고수준화는 하나의 "진화의 계단" 역할을 합니다.
복잡하고 까다로운 논리를 저수준의 언어로 작성하는 것은 무척이나 어려웠을 것입니다.
기본적으로 저수준의 언어를 사용하는 프로그래머의 머리에는 컴퓨터의 구조, 레지스터, 스택, 메모리 사용 등에 대한 지식과 고려가 가득 차 있었을 것이므로 새로운 생각을 할 여유가 그 만큼 적었을 것이기 때문입니다.
비슷한 예로,
플랫폼 또한 하나의 "진화의 계단" 역할을 했을 겁니다.
'플랫폼'이라는 단어 자체가 무언가를 딛고 올라설 수 있는 평평한 곳을 의미하니 너무도 당연하기도 합니다.
많이 알려진 자바가 그렇고, 브라우저도 하나의 플랫폼이며, 플래쉬 또한 하나의 플랫폼이 됩니다.
좀 더 위로 올라가 보면,
MS-Office도 하나의 "계단"이 되지 싶습니다.
LaTex이나 PostScript도 제한적이지만 "계단"이 될 수 있으며,
PhotoShop이나 그림판도 "계단"이 될 수 있지 않을까요?
어쩌면 모든 프로그램은 하나의 "계단"이 아닐까 싶습니다.
무언가를 만들거나 만드는게 도움이 되는...
...
다시 아래로 내려가 볼까요?
Operating System은 확실하게 "진화의 계단" 역할을 했습니다.
이만큼 광범위하고 다양하게 컴퓨터의 자원과 기능들을 사용할 수 있는 편의장치(facility)를 제공해 주는 건, 확실히 쉽지 않은 일입니다.
좀 더 내려가 보면,
컴퓨터의 모든 부품들과 컴퓨터 그 자체 또한 너무나도 당연히 "진화의 계단"입니다.
초기의 컴퓨터를 설계한던 사람들은 그들이 만든 이 "계단"이 지금 이만큼까지 올라올걸 상상이나 했을까요?
아마도 이만큼은 절대 상상하지 못했을 겁니다.
단지 그들은 좀 더 위로 올라가기 위한 하나의 "계단"을 만들었을 뿐이겠죠.
그리고 하나의 계단을 딛고 올라선 사람들은 다시 또 하나의 계단을 만들었을 것입니다.
좀 엉뚱한 상상이지만,
진화론의 측면에서 바라보면, 인간 또한 하나의 "계단"은 아닐까요?
2012년 7월 12일 목요일
Time Wave Zero
2012년 지구의 종말? 대변혁? 과 함께 자주 언급되는 Time Wave Zero.
언제나 그래프가 그려진 화면만을 접하기에,
내가 보고 싶은 부분을 확인하고픈 욕구가 생겼다.
인터넷 검색을 하면 가장 먼저 검색되는 사이트는
Terrence McKenna라는 사람이 운영하는 것으로 보이는 사이트이다.
Terrence McKenna's Timewave Zero
Timewave Zero and the Fractal Time Software
온통 영어니 그 내용이 얼마나 유용한지는 필요한 사람이 직접 알아보길....
두번째 링크의 좌측 메뉴에
online timewave calculator를 이용하면 제한적이나마
자신이 원하는 부분의 Time Wave Zero 그래프를 볼 수 있다.
그러나 이 또한 기능의 제약이 많아서,
1개월 혹은 1년 단위의 그래프만 가능하다.
결국, 원래의 프로그램을 구하고 싶어 다시 인터넷 검색을 한 결과
아래의 사이트에서 프로그램을 구하게 되었다.
http://deoxy.org/download/software/timewavezero/
이 프로그램은 MS-DOS상에서 작동되도록 만들어진 프로그램으로
Math Co-Processor가 없는 경우, CGA 카드가 장착되지 않은 컴퓨터를 위한 고려까지 된 아주 오래된 프로그램이었다.
따라서 저 프로그램을 바로 구동하기 위해서는 DOSBox와 같은 MS-DOS 에뮬레이터가 필요하다.
Time Wave Zero에 대한 이론적 배경이 없다면 이 그래프가 무엇을 의미하는지에 대한 정확한 이해도 불가능하다.
위의 화면에서 우측에 있는 item들 가운데, B.Zero Date, P.Wave Factor 등은 중요한 요소이나 아직 이해는 부족하다.(나 또한...)
다운로드 받은 파일 중, frt.zip에는 FRT.EXE라는 실행 파일 하나 뿐이지만 보기에는 좀 더 편하다.
FRT는 Fractal Time이라는 이름의 프로그램인데,
Time Wave Zero보다 깔끔하다는 점 외에도,
우측의 item에서 D.Number Set에서 선택 가능한 Data Set이 4가지가 있었다.
다운로드 받은 파일 중, 저자의 웹사이트가 소개된 부분들이 있었으나
워낙에 많은 시간이 지난지라 모두 폐쇠되거나 없어진 상태였다.
따라서, Time Wave Zero의 이론적인 배경이나 의미를 제대로 이해하기는 어려우며,
Wave Factor나 Data Set의 활용도 또한 어려운 상황이다.
언제나 그래프가 그려진 화면만을 접하기에,
내가 보고 싶은 부분을 확인하고픈 욕구가 생겼다.
인터넷 검색을 하면 가장 먼저 검색되는 사이트는
Terrence McKenna라는 사람이 운영하는 것으로 보이는 사이트이다.
Terrence McKenna's Timewave Zero
Timewave Zero and the Fractal Time Software
온통 영어니 그 내용이 얼마나 유용한지는 필요한 사람이 직접 알아보길....
두번째 링크의 좌측 메뉴에
online timewave calculator를 이용하면 제한적이나마
자신이 원하는 부분의 Time Wave Zero 그래프를 볼 수 있다.
 |
| Timewave Calculator |
그러나 이 또한 기능의 제약이 많아서,
1개월 혹은 1년 단위의 그래프만 가능하다.
결국, 원래의 프로그램을 구하고 싶어 다시 인터넷 검색을 한 결과
아래의 사이트에서 프로그램을 구하게 되었다.
http://deoxy.org/download/software/timewavezero/
이 프로그램은 MS-DOS상에서 작동되도록 만들어진 프로그램으로
Math Co-Processor가 없는 경우, CGA 카드가 장착되지 않은 컴퓨터를 위한 고려까지 된 아주 오래된 프로그램이었다.
따라서 저 프로그램을 바로 구동하기 위해서는 DOSBox와 같은 MS-DOS 에뮬레이터가 필요하다.
 |
| DOSBox에서 파일 확인. TWZERO87.EXE를 실행시킨다. |
 |
| TWZERO87.EXE 실행 첫 화면 |
 |
| 아무 키나 눌러 진입한 화면 |
 |
| 'F'키를 눌러 그래프를 그린다 |
Time Wave Zero에 대한 이론적 배경이 없다면 이 그래프가 무엇을 의미하는지에 대한 정확한 이해도 불가능하다.
위의 화면에서 우측에 있는 item들 가운데, B.Zero Date, P.Wave Factor 등은 중요한 요소이나 아직 이해는 부족하다.(나 또한...)
다운로드 받은 파일 중, frt.zip에는 FRT.EXE라는 실행 파일 하나 뿐이지만 보기에는 좀 더 편하다.
 |
| Fractal Time, 컬러풀^^ |
 |
| TWZ와 비슷하지만 조금 다른 FRT |
Time Wave Zero보다 깔끔하다는 점 외에도,
우측의 item에서 D.Number Set에서 선택 가능한 Data Set이 4가지가 있었다.
다운로드 받은 파일 중, 저자의 웹사이트가 소개된 부분들이 있었으나
워낙에 많은 시간이 지난지라 모두 폐쇠되거나 없어진 상태였다.
따라서, Time Wave Zero의 이론적인 배경이나 의미를 제대로 이해하기는 어려우며,
Wave Factor나 Data Set의 활용도 또한 어려운 상황이다.
2012년 7월 7일 토요일
Basilisk II
우분투에 Macintosh 에뮬레이터인 Basilisk II를 설치하기
Ubuntu 10.04
Basilisk II 0.91
Basilisk II의 공식 홈페이지는 http://basilisk.cebix.net/ 입니다.
글을 쓰는 현재의 최종 버전은 2001년 5월 31일에 만들어진 0.91입니다.
일단 다운로드 받아서
tar xvf BasiliskII_src_31052001.tar.gz
을 하면
BasiliskII-0.9라는 폴더 밑에 소스가 풀립니다.
README는 별거 없고 INSTALL이라는 파일을 읽어 보면 설치하는 방법이 나옵니다.
유닉스에서는 X11R6, make, pthread, GTK+ 1.2이상
여기에 리눅스인 경우는 glibc 2.0 이상이 필요하다고 합니다.
설치 방법은,
cd src/Unix
./configure
make
make install
간단하죠?
실제로 해보니 처음부터 막히는군요.
./configure 의 결과 입니다.
뭔가 no가 많네요.
그래도 다음 절차로 넘어갑니다.
make의 결과
소스를 보았는데, 이상한 상수가 정의된 경우인 부분을 컴파일 합니다.
그게 어디에서 정의가 된건지 찾을 수도 없고....
이정도 잘못된 건, 소스 자체의 문제가 아니라 시작부터 뭔가가 어긋난 결과인 듯 합니다.
이런 문제를 소스 코드를 통해 원인을 찾아나가도 결국에는 미궁으로 빠지는 경우가 대부분입니다.
우선은 아까의 ./configure 부분으로 돌아가겠습니다.
결과에서는 no가 있어도 깨끗해 보였지만 사실 중간에 오류 메시지가 있었습니다.
GTK에 문제가 있음을 알 수 있습니다.
시냅틱 패키지 관리자에서 대충 찾아서 설치했습니다.
하지만 설치 후에도 결과는 마찬가지....
(확인해 보니 제 시스템에는 GTK는 2.0이 이미 설치되어 있었습니다.)
잠시 고민하고 잠자고 일어나서 인터넷 검색을 해 보았습니다.
비슷한 문제들이 있었군요.
http://www.linuxquestions.org/questions/linux-software-2/gtk-source-install-doesnt-give-gtk-config-333626/
GTK 1.x에서는 gtk-config라는 스크립트사 제공되었는데,
그 이후 버전에서는 gtk-config가 사라졌답니다.
이마도 GTK 1.x 버전을 기준으로 만들어진 프로그램들은 gtk-config를 사용하도록 만들어진 거 같습니다.
Basilisk II도 2001년에 만들어진 프로그램이니 그럴 가능성이 높겠죠.
그래서 GTK 1.x 버전을 설치하기로 결정....
공식 사이트에서 구할 수 있는 버전은 GTK 1.2.10이 1.x의 최종 버전입니다.
가볍게 성공하겠지 생각하고 다운받아
압축 풀고
./configure하니....결과가....
이번에는 GLIB 1.2.8이 필요ㅠ.ㅠ
현재 시스템에는 GLIB 2.0이 설치되어 있는데....
GLIB 또한 같은 사이트에서 배포하는 라이브러리이므로 1.x 버전 다운로드.
1.x의 최종 버전은 1.3.15
하지만 GLIB 1.3.15를 다 빌드해 보아도 glib-config는 없었습니다.
다시 GLIB 1.2.10을 받아서 빌드해 보니 다시 에러....
문득 회의가 들었습니다.
설령 모든게 성공해서 Basilisk를 빌드하고 설치하는 데 성공한데 해도,
그 Basilisk가 구동되는 환경은 downgrade된 GTK와 GLIB 환경에서만 가능한게 아닐까?
그렇다면 상위버전의 GTK와 GLIB을 사용하는 다른 많은 프로그램들은 어떻게 된단 말인가?
어려운 길이지만 Basilisk가 상위의 GTK와 GLIB을 사용할 수 있도록 수정하는게 올바른 방향이 아닐까?
====================================
문제를 해결하기 위해 찾아 본 결과,
현재 봉착한 문제는 compile의 문제와 GTK의 문제가 별개였습니다.
위에서 make 수행 시 나온 오류 메시지는 syscall5라는 매크로의 문제인 것으로 보입니다. 궁극적으로는 llseek()라는 함수를 사용하기 위한 방법인데, Basilisk에서 특이하게 사용한 것이 아니라, 통상적으로 사용되는 코드였으나, 어찌된 영문인지 제 시스템에서 오류가 나고 있는 것으로 보입니다.
구글에서 syscall5로 검색해 보아도 비슷한 문제들이 많이 나옵니다.
그 중 하나,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392236
GTK의 문제는, 좀 더 찾아 봐야 하겠지만,
1.x와 그 이후 버전 간에 많은 차이가 있다면 두개의 버전이 하나의 시스템에서 동시에 운용이 가능하지 않을까 하는 생각이 듭니다.
그렇지 않다면 일단 downgrade한 후에, 빌드 후 다시 upgrade하는 것도 한가지 방법이 아닌가 합니다. 물론 빌드가 성공했어도 upgrade후에는 동작이 정상일지 장담할 수는 없지만 말입니다.
Ubuntu 10.04
Basilisk II 0.91
Basilisk II의 공식 홈페이지는 http://basilisk.cebix.net/ 입니다.
글을 쓰는 현재의 최종 버전은 2001년 5월 31일에 만들어진 0.91입니다.
일단 다운로드 받아서
tar xvf BasiliskII_src_31052001.tar.gz
을 하면
BasiliskII-0.9라는 폴더 밑에 소스가 풀립니다.
README는 별거 없고 INSTALL이라는 파일을 읽어 보면 설치하는 방법이 나옵니다.
유닉스에서는 X11R6, make, pthread, GTK+ 1.2이상
여기에 리눅스인 경우는 glibc 2.0 이상이 필요하다고 합니다.
설치 방법은,
cd src/Unix
./configure
make
make install
간단하죠?
실제로 해보니 처음부터 막히는군요.
./configure 의 결과 입니다.
 |
| ./configure 수행 결과 |
그래도 다음 절차로 넘어갑니다.
make의 결과
 |
| make 수행 결과 |
소스를 보았는데, 이상한 상수가 정의된 경우인 부분을 컴파일 합니다.
그게 어디에서 정의가 된건지 찾을 수도 없고....
이정도 잘못된 건, 소스 자체의 문제가 아니라 시작부터 뭔가가 어긋난 결과인 듯 합니다.
이런 문제를 소스 코드를 통해 원인을 찾아나가도 결국에는 미궁으로 빠지는 경우가 대부분입니다.
우선은 아까의 ./configure 부분으로 돌아가겠습니다.
결과에서는 no가 있어도 깨끗해 보였지만 사실 중간에 오류 메시지가 있었습니다.
 |
| ./configure 과정 메시지 |
시냅틱 패키지 관리자에서 대충 찾아서 설치했습니다.
(확인해 보니 제 시스템에는 GTK는 2.0이 이미 설치되어 있었습니다.)
잠시 고민하고 잠자고 일어나서 인터넷 검색을 해 보았습니다.
비슷한 문제들이 있었군요.
http://www.linuxquestions.org/questions/linux-software-2/gtk-source-install-doesnt-give-gtk-config-333626/
GTK 1.x에서는 gtk-config라는 스크립트사 제공되었는데,
그 이후 버전에서는 gtk-config가 사라졌답니다.
이마도 GTK 1.x 버전을 기준으로 만들어진 프로그램들은 gtk-config를 사용하도록 만들어진 거 같습니다.
Basilisk II도 2001년에 만들어진 프로그램이니 그럴 가능성이 높겠죠.
그래서 GTK 1.x 버전을 설치하기로 결정....
공식 사이트에서 구할 수 있는 버전은 GTK 1.2.10이 1.x의 최종 버전입니다.
가볍게 성공하겠지 생각하고 다운받아
압축 풀고
./configure하니....결과가....
 |
| GTK 1.2.10의 ./configure |
현재 시스템에는 GLIB 2.0이 설치되어 있는데....
GLIB 또한 같은 사이트에서 배포하는 라이브러리이므로 1.x 버전 다운로드.
1.x의 최종 버전은 1.3.15
하지만 GLIB 1.3.15를 다 빌드해 보아도 glib-config는 없었습니다.
다시 GLIB 1.2.10을 받아서 빌드해 보니 다시 에러....
문득 회의가 들었습니다.
설령 모든게 성공해서 Basilisk를 빌드하고 설치하는 데 성공한데 해도,
그 Basilisk가 구동되는 환경은 downgrade된 GTK와 GLIB 환경에서만 가능한게 아닐까?
그렇다면 상위버전의 GTK와 GLIB을 사용하는 다른 많은 프로그램들은 어떻게 된단 말인가?
어려운 길이지만 Basilisk가 상위의 GTK와 GLIB을 사용할 수 있도록 수정하는게 올바른 방향이 아닐까?
====================================
문제를 해결하기 위해 찾아 본 결과,
현재 봉착한 문제는 compile의 문제와 GTK의 문제가 별개였습니다.
위에서 make 수행 시 나온 오류 메시지는 syscall5라는 매크로의 문제인 것으로 보입니다. 궁극적으로는 llseek()라는 함수를 사용하기 위한 방법인데, Basilisk에서 특이하게 사용한 것이 아니라, 통상적으로 사용되는 코드였으나, 어찌된 영문인지 제 시스템에서 오류가 나고 있는 것으로 보입니다.
구글에서 syscall5로 검색해 보아도 비슷한 문제들이 많이 나옵니다.
그 중 하나,
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392236
GTK의 문제는, 좀 더 찾아 봐야 하겠지만,
1.x와 그 이후 버전 간에 많은 차이가 있다면 두개의 버전이 하나의 시스템에서 동시에 운용이 가능하지 않을까 하는 생각이 듭니다.
그렇지 않다면 일단 downgrade한 후에, 빌드 후 다시 upgrade하는 것도 한가지 방법이 아닌가 합니다. 물론 빌드가 성공했어도 upgrade후에는 동작이 정상일지 장담할 수는 없지만 말입니다.
vim의 환경 설정
현재 사용 중인 환경, Ubuntu 10.04에서의 환경 설정을 기준으로 설명한다.
vim의 설치는,
vim 공식 사이트를 통해서 다운로드 받아서 직접 설치하는 것도 가능하지만
우분투 소프트웨어 센터를 통해서도 설치하는 것을 권장하고 싶다.
매뉴얼 파일 등록이나 전역 설정 파일의 위치 문제를 겪을 수 있기 때문이다.
vim이 설치된 위치는 /usr/bin이다.
주로 사용되는 vim의 실행 파일들은 이 곳에 모두 있다.
재미있는 사실은 별도의 윈도우로 실행되는 gvim과 터미널에서 실행되는 vim이 하나의 프로그램이라는 사실.
두 프로그램은 심볼릭 링크인데 이를 따라가면 /usr/bin/vim.gnome에 연결되어 있다.
그럼에도 불구하고 gvim을 타이핑하면 GUI 환경으로, vim을 타이핑 하면 터미널 환경으로 실행이 된다.
그렇다면, vim.gnome을 직접 실행하면? 터미널 환경으로 실행이 된다.
다시 본론으로 돌아가서,
vim의 다른 파일들은 별도의 위치에 설치된다.
전역 설정 파일들은 /etc/vim/에 존재하지만 특별한 설정은 눈에 띄지 않는다.
또 기타 문서나 매크로 스펠체커 등등은 /usr/share/vim/에 설치된다.
여기에 유용한 파일들이 많으니 관심이 있으면 살펴보면 큰 도움이 된다.
환경 설정 파일의 샘플이 2개 있다.
/usr/share/vim/vim72/에 있는 것으로 vimrc_example.vim과 gvimrc_example.vim이다.
개인별 환경 설정을 위해서 사용할 때에는, 각각을 홈디렉토리에 .vimrc와 .gvimrc로 복사해서 사용하면 된다.
.gvimrc의 처음 두줄은 각각 윈도우의 폭과 높이를 지정한 것이다.
vim의 경우는 터미널의 크기를 따라야 하므로 필요가 없는 부분이다.
다음은 순서대로 라인번호표시(nu), 라인번호표시를 위한 넓이(nuw=5), 탭넓이(ts=2), 줄바꿈시 들여쓰기할 넓이(sw=2), 탭을 공백으로 바꿈(et) 이다.
컬러스킴을 메뉴에서 지정해도 저장이 되지 않기에 .gvimrc에 다음과 같이 추가를 했다.
P.S.
MS-Windows의 경우에는 vim이 설치된 디렉토리의 _vimrc에 추가하면 된다.
vim의 설치는,
vim 공식 사이트를 통해서 다운로드 받아서 직접 설치하는 것도 가능하지만
우분투 소프트웨어 센터를 통해서도 설치하는 것을 권장하고 싶다.
매뉴얼 파일 등록이나 전역 설정 파일의 위치 문제를 겪을 수 있기 때문이다.
vim이 설치된 위치는 /usr/bin이다.
주로 사용되는 vim의 실행 파일들은 이 곳에 모두 있다.
재미있는 사실은 별도의 윈도우로 실행되는 gvim과 터미널에서 실행되는 vim이 하나의 프로그램이라는 사실.
두 프로그램은 심볼릭 링크인데 이를 따라가면 /usr/bin/vim.gnome에 연결되어 있다.
그럼에도 불구하고 gvim을 타이핑하면 GUI 환경으로, vim을 타이핑 하면 터미널 환경으로 실행이 된다.
그렇다면, vim.gnome을 직접 실행하면? 터미널 환경으로 실행이 된다.
다시 본론으로 돌아가서,
vim의 다른 파일들은 별도의 위치에 설치된다.
전역 설정 파일들은 /etc/vim/에 존재하지만 특별한 설정은 눈에 띄지 않는다.
또 기타 문서나 매크로 스펠체커 등등은 /usr/share/vim/에 설치된다.
여기에 유용한 파일들이 많으니 관심이 있으면 살펴보면 큰 도움이 된다.
환경 설정 파일의 샘플이 2개 있다.
/usr/share/vim/vim72/에 있는 것으로 vimrc_example.vim과 gvimrc_example.vim이다.
개인별 환경 설정을 위해서 사용할 때에는, 각각을 홈디렉토리에 .vimrc와 .gvimrc로 복사해서 사용하면 된다.
 |
| .gvimrc에 추가한 부분 |
 |
| .vimrc에 추가한 부분 |
vim의 경우는 터미널의 크기를 따라야 하므로 필요가 없는 부분이다.
다음은 순서대로 라인번호표시(nu), 라인번호표시를 위한 넓이(nuw=5), 탭넓이(ts=2), 줄바꿈시 들여쓰기할 넓이(sw=2), 탭을 공백으로 바꿈(et) 이다.
컬러스킴을 메뉴에서 지정해도 저장이 되지 않기에 .gvimrc에 다음과 같이 추가를 했다.
 |
| 컬러스킴 추가 |
MS-Windows의 경우에는 vim이 설치된 디렉토리의 _vimrc에 추가하면 된다.
2012년 7월 3일 화요일
LeakDiag
메모리 누수 탐지 프로그램 : Memory Leakage Detection Program
ftp://ftp.microsoft.com/PSS/Tools/Developer Support Tools/LeakDiag
1. 원하는 프로세스를 선택
2. 원하는 메모리 할당자 유형을 선택
3. Start
시험해 본 프로세스에 문제가 없어서 그런 것일까?
아무런 반응도 없고,
아무런 로그도 남지 않는다.
...ㅠ.ㅠ
임의의 프로그램을 대상으로 사용하는 프로그램이라기 보다는,
스스로 제작한 프로그램에 대한 검증에 적합하다 하겠다.
구체적인 작동 방식을 알지 못한다면,
어떤 유형의 메모리 할당자를 사용하는지 알 수 없을테니 말이다.
하지만 그 보다 궁금한 건,
어떤 원리로 메모리 누수를 탐지하는가 이다.
[실전 윈도우 디버깅]에는 이와 같이 설명하고 있다.
ftp://ftp.microsoft.com/PSS/Tools/Developer Support Tools/LeakDiag
 |
| [LeakDiag 실행 화면] |
2. 원하는 메모리 할당자 유형을 선택
3. Start
시험해 본 프로세스에 문제가 없어서 그런 것일까?
아무런 반응도 없고,
아무런 로그도 남지 않는다.
...ㅠ.ㅠ
임의의 프로그램을 대상으로 사용하는 프로그램이라기 보다는,
스스로 제작한 프로그램에 대한 검증에 적합하다 하겠다.
구체적인 작동 방식을 알지 못한다면,
어떤 유형의 메모리 할당자를 사용하는지 알 수 없을테니 말이다.
하지만 그 보다 궁금한 건,
어떤 원리로 메모리 누수를 탐지하는가 이다.
[실전 윈도우 디버깅]에는 이와 같이 설명하고 있다.
"LeakDiag는 메모리 관련 행위를 수집하는 방식에 있어서 많은 메모리 누수 탐지 툴과 아주 다르다. LeakDiag는 메모리 할당 스택 트레이스를 기록함에 있어서 운영체제의 지원에 의존하기 보다는 메모리 할당자에 대한 호출을 가로채기 위해 마이크로소프트의 디투어(Detours) 기술을 사용한다. 이렇게 함으로써 LeakDiag는 운영체제의 스택 트레이싱 지원 기능을 활성화할 필요가 없다."또, 디투어에 대해서는 따로 이렇게 설명하고 있다.
" 바이너리 수준에서 기존의 코드를 조율하고 향상시키는 데 있어서 마이크로소프트 디투어(Detours)는 혁신적인 해결책이다. ...중략... 마이크로소프트 디투어를 통해 바이너리 함수를 가로채 원래의 함수를 완전히 대체하거나 일부 코드를 추가한 다음 원래의 코드를 호출할 수도 있는 독자 자신의 디투어 함수를 제공할 수 있다. 디투어는 원래 함수의 최초 몇가지 명령을 새로운 함수로의 무조건 분기로 대체해 마술처럼 보이게 이것을 처리한다. 이 처리가 런타임 시에 일어나며 지속되지 않는다는 사실을 반드시 숙지해야 한다. 이 사실은 동일한 애플리케이션의 다른 인스턴스를 서로 독립적으로 우회할 수 있음을 의미한다."
"마이크로소프트 디투어에 관한 더 많은 정보는 http://research.microsoft.com/en-us/projects/detours/ 를 참조하자."
피드 구독하기:
글 (Atom)