vim/gvim에 대한 몇가지 의문

vim은 애초의 vi를 개량한 버전으로 알고 있습니다.
현재 널리 사용되는 vim의 홈페이지는 http://www.vim.org 입니다.

현재 Ubuntu 10.04 환경에서 사용하던 중에 이상한 부분을 발견하였습니다.
vim과 gvim이 하나의 실행파일이라는 점이고, 그럼에도 불구하고 ps에 보이는 결과는 또 다르다는 것이었습니다.

일단은 설치된 vim/gvim의 실행 파일이 하나라는 점은 다음에서 확인이 됩니다.

vim/gvim은 모두 /usr/bin/vim.gnome에 연결되어 있습니다.

gvim을 실행 한 후, "ps -aux"를 실행한 결과 화면

gvim을 실행한 결과, vim.gnome이 아닌 gvim으로 표시된다.

vim을 실행 한 후, "ps -aux"를 실행한 결과 화면

vim을 실행한 결과, vim.gnome이 아닌 vim으로 표시된다.

실행 파일 하나로 콘솔버전과 GUI버전을 통합한 것은 충분히 이해가 가능하지만, process 이름을 다르게 보이게 하는 신기합니다.

Appler 디버깅하기 ___ 6

마지막 포스팅에서 해결할 수 있는 방안은 제시했지만,
- 미해결 상태로 남겨둔 것이 찜찜하기도 했구요,
- 어셈블리 공부도 해야겠다 생각도 했구요,
- 또...Appler를 적극적으로 활용할 필요도 있고 해서 손을 대 보았습니다.

단지
1) 문자열의 마지막에 백슬래쉬가 있는지 여부를 검사하고
2) 없으면 백슬래쉬를 추가해주고
3) 있으면 그냥 놔둔다
는 단순한 루틴인데도 어셈블러로 짤 엄두가 잘 나지 않더군요.

그래서 비교적(?) 무대뽀 정신으로 해결해 보고자, 인터넷을 뒤졌습니다.
문자열 두개를 붙이는 strcat() 같은 어셈블리 소스코드를 찾으면 쉽게 변형해서 적용이 될 거 같았습니다.

http://assembly.happycodings.com/ : 별로 체계는 없지만 간단하고 유용한 샘플코드를 제공합니다.

http://cs.smith.edu/~thiebaut/ArtOfAssembly/artofasm.html : 뭔가 유명할 것 같은 이름이네요. The Art of Assembly Language Programming. PDF 도 존재하고 내용도 매우 충실해 보입니다. 컴퓨터의 구조에 대해서도 좋은 참고 자료가 되겠네요.

마침 두번째 사이트에서 strcat를 포함한 string 함수에 대한 부분이 있었습니다.
http://cs.smith.edu/~thiebaut/ArtOfAssembly/CH15/CH15-5.html#HEADING5-48

그런데 이건 해당 기능을 구현하는 것이 아니라 이용하는 겁니다.
UCR Standard Library라는 것이 존재하는데, 이 Library에 각종 string 함수들도 포함되어 있다고 하더군요.

해서 찾은 것이,
http://net.pku.edu.cn/~course/cs201/2003/mirrorWebster.cs.ucr.edu/Page_asm/ucrlib/stdlibv2.html
여기에 어셈블리 소스 코드도 모두 포함이 되어 있습니다.

strcat.asm이라는 파일이 있어서 찾아 보니,

strcat 프로시져

strcatx 호출하고 끝입니다.
그래서 strcatx 찾아 봤습니다.

strcatx 프로시져

알고 보면 별로 어렵지 않은데, 초짜인 저에겐 그저ㅠㅠ
그래도 어셈블리 명령어 찾아가며 가까스로 이해하고
이 부분을 변형해서 사용하기로 했습니다.
cld : Clear Direction
repne : Repeat while not equal
scasb : scan string(byte)
lodsb : load string(byte)
stosb : store string(byte)
대충 이런 의미들이더군요.
어셈블리 언어가 어려운 이유 가운데 하나가, 저런 명령어들이 묵시적으로 사용하는 레지스터/플래그 등을 기억해야 한다는 점인 거 같습니다.


이젠 DOSBox에서 Appler 소스를 고치겠습니다.
예전에 많이 보았던 DM.ASM의 ReadDirectory 부분을 다음과 같이 고쳤습니다.

DM.ASM

그리고 make

(사실은 이거 성공하기까지 한 5번은 고치고 디버깅하고를 반복했을 겁니다.)

make

Appler 실행하고 F3 눌러서 Disk Manager 실행하면 Path와 Directory 모두 잘 나옵니다.

Appler의 Disk Manager

허접하지만, 위에 소스를 보시면 무작정 마지막에 Backslash를 붙이는 게 아니라
마지막 문자가 Backslash가 아닐 때에만 붙이도록 고쳤습니다.

따라서 나중에 DOSBox가 문제점이 개선되어 나오더라도 Appler의 소스를 다시 건드리지 않아도 정상 작동할거라는 겁니다.^^


나이가 들어서 그런지, 저 짧은 루틴 분석하는 데에도 중간에 졸리고 귀찮고...그렇네요.
역시 프로그램은 만드는 것보다 분석하는 게 더 힘드네요.
그래서인지 다른 사람이 만든 소스를 분석해 보는 정성과 노력을 하는 사람은 틀림없이 성공할 수 있지 않을까 싶습니다.

이 일을 하면서 Appler를 수정했다는 자기 만족 보다는 UCR Standard Library라는 게 있다는 걸 배운 게 더 큰 성과가 아니었나 싶습니다.

Pentagram - Ultima8

Ultima의 여러 시리즈들이 remake 되고 있습니다.

이전에도 xu4라는 Ultima4의 리메이크 버전을 포스팅한 적이 있습니다.
http://re-coder.blogspot.com/2012/11/xu4-ultima4-recreated.html

우연히 이번에 접하게 된 것은 Pentagram이라는 것으로 Ultima8의 remake 버전입니다.

이런 프로그램들을 단순히 remake라고 부를 수는 없을 것 같은데,
딱히 뭐라고 불러야 할 지 모르겠습니다.

암튼... 이전의 xu4와는 달리 pentagram은 빌드에 별 문제도 없고, 실행에도 문제가 없었습니다. 포스팅을 해서 후일의 삽질을 방지할 필요는 없지만 그냥 화면만 보고 기분 전환이나 해 보겠습니다.

인트로

타이틀 Ultima8 Pagan

첫 장면

pentagram.ini를 수정하면 게임의 해상도, 배율, 화면의 크기 등을 조정할 수 있습니다.
위의 화면은 해상도 320x240, 배율 2, 화면 크기 640x480
다음의 화면은 해상도 640x480, 배율 1, 화면크기 640x480 입니다.

640x480 화면

홈페이지는 http://pentagram.sourceforge.net/

Appler 디버깅하기 ___ 5

앞 선 포스팅에서 대략의 결론을 내렸지만,
디버깅을 하는 또 다른 방법이 있기에 번외편으로 간략하게 소개하고자 합니다.

예전에 DOSBox의 내장 디버거에 대한 소개를 한 적이 있습니다.
http://re-coder.blogspot.kr/2013/06/dosbox.html

이 내장 디버거를 사용하여 디버깅을 하는 방법입니다.

먼저 내장 디버거를 사용하는 경우의 장점은,
- 소스가 없어도 됩니다.
- 소스가 있다고 해도 디버그 모드로 다시 빌드할 필요도 없습니다.
- 터보디버거와 같은 별도의 디버거가 필요 없습니다.

반면에 단점은,
- 소스가 있어도 소스레벨 디버깅이나 소스와 연계된 디버깅이 불가능 합니다.
- 내장 디버거의 제한된 기능을 이용해야 하기에 비효율적일 수 있습니다. (아무래도 전문 디버거보다야 기능과 편의성이 떨어집니다.)
- 어셈블리어/로우레벨 디버깅/리버스엔지니어링과 관련된 일정한 수준 이상이 되어야 디버깅이 가능합니다.

저의 경우엔 마지막 조건에 부합하지 못하는 관계로 엄두를 내지는 못 할 상황이지만, 이번 Appler의 경우에만 가까스로 디버깅이 가능했던 듯 합니다.

먼저 내장 디버거가 활성화된 DOSBox를 실행시킵니다.

DOSBox의 실행과 함께 표시된 디버거 화면

이제 디버깅을 하고자 하는 Appler를 실행시킵니다.

Appler 실행

DOSBox 화면에서 Alt-Pause를 누르면 실행이 중단되고 디버거에 입력이 가능하게 됩니다.
앞선 포스팅에서 알아낸 대로, 디버깅을 하기 위해 breakpoint로 지정할 부분이 INT 21 (AH=60h)입니다. 디버거에서 help를 입력하면 내장 디버거에서 사용할 수 있는 키와 명령어가 있습니다. 여기에 있는 대로 "bpint 21 60"을 입력 합니다.

INT 21 (AH=60h)에 대해 Breakpoint를 설정합니다.

"bplist"를 입력하면 breakpoint가 설정이 되었는지 확인이 가능합니다.

breakpoint가 설정되었음을 확인

이제 내장 디버거에서 F5를 눌러서 Appler가 계속 실행을 하도록 해 줍니다.


적당한 시점에 문제가 되는 화면으로 진입하도록 Appler에서 F3 키를 눌러 줍니다.

idle 상태에서 F3을 눌러 Disk Manager로 진입 시도

이제 바로 실행이 멈추고 디버거가 활성화 되었습니다.
실행이 멈춘 곳은 breakpoint로 설정한 int 21 입니다.

INT 21h에서 멈춘 상황

디버거에서 F10(Step Over)로 int 21을 수행 한 후, Alt-D를 눌러 DS:SI의 메모리 내용을 확인해 봅니다. 역시나 마지막에 Backslash가 없음을 알 수 있습니다.

INT 21h을 실행 후 메모리 확인

SM 명령어를 이용하여 마지막에 Backslash(5C)를 넣어 줍니다.

Set Memory로 backslash 추가

마지막에 Backslash가 추가되었음을 확인할 수 있습니다.

메모리 변경 확인

이제 다시 F5를 눌러 실행을 계속 하도록 합니다.
아마 2~3번 정도 같은 부분에서 멈출 것이고, 그 때마다 위의 과정을 반복해야 합니다.
(Step Over, Memory 확인, Memory 수정)

이렇게 하고 나면 정상적인 화면이 나오는 것을 볼 수 있습니다.

정상 화면

만약에 소스를 가진 DOS용 프로그램을 DOSBox의 내장 디버거로 디버깅을 하려면, 소스빌드시에 Map 파일과 Assembly Listing 파일을 만들도록 하면 디버깅에 조금 도움이 되지 않을까 싶습니다.

Appler 디버깅하기 ___ 4

터보디버거가 어째 좀 불안해서 디버깅을 하다가 새로 시작하곤 해야 하는 문제가 있었기에 의욕이 급속히 감소 되었더랬습니다. (지난 포스팅 말미에 썼던 문제점입니다.)

거기에 레퍼런스로 사용하던 Oracle의 VirtualBox도 말썽을 부렸습니다.

4.2.14 버전으로 업데이트하고 나니 키보드도 제대로 작동하지 않는 문제가 발생하더군요.

처음엔 제가 사용하는 리눅스의 사양이 너무 딸려서 시스템의 오작동이 아닌가 생각 했는데, 윈도우즈용도 마찬가지인 것을 확인하고는 참...어이가 없었습니다.

Oracle이 겨우 이런 회사인가....

며칠후에 4.2.16으로 업뎃하고 나니 다행히 정상으로 돌아오긴 했습니다.

암튼 이래저래 시간은 흘러가고 디버깅은 지연되고....하다가 겨우 다시 붙잡았습니다.

첫번째 디버깅 타겟으로 잡은 것은 Path&Filter 부분이었습니다.

Path&Filter 부분에서 Path와 Filter 사이에 backslash가 없었던 문제부터 디버깅을 해 보기로 했습니다.

찾아보니 Path, Filter, PathFilter라는 변수가 있었고, 이 변수를 채우는 프로시져로 ReadDirectory가 있었습니다.

먼저 VirtualBox에서 이 부분을 디버깅하면서 나온 정상적인 결과를 보겠습니다.

int 21h(ah=60h)를 호출한 후

Path 변수를 확인해 보니 문자열의 마지막에 Backslash가 있습니다.

터보디버거에서는 어쩐 일인지 Path 문자열을 Watch에 등록했는데, 앞 두글자만 보여주더군요. 그래서 Data Inspecting으로 주소를 확인하고 View-Dump로 메모리를 확인해 보니 문자열 모두를 볼 수 있었습니다.

VirtualBox에서는 정상으로 작동하고 있었기에 이걸 정상적인 결과로 가정했습니다.

소스에서 보는 DOS interrupt인 int 21h에 대한 자료를 찾아보았습니다.

Ralf Brown이라는 분이 정리한 자료가 있는데, 얼핏 보았는데 상당히 자세한 듯 합니다.

http://www.cs.cmu.edu/~ralf/files.html

우선 2개의 interrupt에 대한 것만 보면,

INT 21h(AH=60h) TRUENAME

INT 21h(AH=1Ah) Set DTA

그러면 같은 부분을 DOSBox에서 실행했을 때는,

DOSBox에서 디버깅한 경우, Backslash 없음.

어느쪽이 맞는건지 모르겠지만 VirtualBox와 DOSBox가 서로 다르게 작동한다는 것은 확실합니다. 그리고 Appler가 실제 MS-DOS를 기반으로 개발된 것을 감안한다면 VirtualBox의 작동방식이 맞다고 보는 것이 타당할 것입니다.

근본적으로 저 문제를 해결하려면 DOSBox를 수정하는 것이 맞을테고, 수정의 용이함이나 Side Effect를 최소화하면서 Appler를 제대로 구동하려면 Appler를 수정하면 될 것입니다.

어셈블리 프로그래밍에 능숙하지 않은 관계로 소스의 수정은 뒤로 미루고,

다음 문제를 디버깅해 보기로 했습니다.

디렉토리 내의 파일이름들 리스팅에도 문제가 있었고, 사실은 이게 제일 큰 문제였습니다.

처음엔 조금 막막했지만, 흔히들 디렉토리 내의 파일 이름들을 얻어 오는 C의 함수로 FindFirst()와 FindNext()를 사용했던 기억이 났습니다.

그리고 소스내에서 동일한 이름의 매크로가 있는 것을 찾아냈습니다.

FindFirst, FindNext 매크로

매크로 무지 간단합니다.

그냥 DOS Interrupt 호출이네요.

아까 보았던 자료에서 위의 Interrupt에 관한 부분을 찾아 보았습니다.

INT 21h(AH=4Eh) FindFirst

INT 21h(AH=4Fh) FindNext

그런데...정말 혹시나 하는 생각이 들었습니다.

앞서 디버깅한 Path&Filter의 문제로 디렉토리의 파일 이름들도 문제가 생긴게 아닐까 하고..

그래서 디버깅 하면서 바로 수정해서 확인 해 보았습니다.

Path의 마지막에 Backslash(5Ch) 넣어주기

Backslash가 들어갔습니다.

Path&Filter 뿐 아니라 Directory 부분도 정상적으로 나옵니다.

Disk Manager 화면으로 진입하면 ReadDirectory라는 프로시져가 2번 호출이 됩니다.

두번 모두 마지막에 Backslash(5Ch)를 넣어주면 모든게 정상이 됩니다.

이젠 DOSBox의 개발진에게 이 문제를 리포트하든지,

내가 직접 DOSBox를 수정하든지, Appler를 수정하든지...하면 되겠네요.

DOSBox의 디버거

DOSBox는 다른 에뮬레이터와 같은 내장 디버거가 없는걸까? 했던 의문을 풀어야 겠습니다.
문득 DOSBox의 소스 빌드 방법을 읽어보니, 디버거를 사용하기 위해서는 빌드할 때 옵션을 새로 넣어 주어야 하는군요.

INSTALL에 디버그 옵션에 대한 설명이 있습니다.

configure에서 enable-debug를 찾으면 enable_debug 값을 바꾸고,
enable_debug를 찾아보면 C_DEBUG나 C_HEAVY_DEBUG를 헤더에 정의하게 합니다.

먼저 *_DEBUG 상수가 정의된 적이 있는지 확인해 보니 없습니다.

--enable-debug를 어디에 넣어줘야 하나 고민하다가 커맨드 라인에 넣어 봤습니다.

configure가 끝나고 확인해보니 C_DEBUG가 정의 되어 있습니다.

맨 처음의 사진에 있는 INSTALL의 설명을 읽어 보면,
DOSBox를 xterm에서 실행해야 하고, DOSBox의 sdl-window가 열린 후에 Alt + Pause를 누르면 디버거로 진입한다고 되어 있습니다.

DOSBox를 실행하자 터미널이 이렇게 바뀝니다.

Alt + Pause를 누르니 화면이 약간 바뀌면서 여기 저기 깨집니다.

화살표를 위,아래로 움직이니 Code Overview 부분이 스크롤 되는데,
위의 3줄과 아래의 1줄은 움직이질 않습니다. (번지수 확인)

help를 타이핑하니 프롬프트의 위쪽에 찍힙니다.

아직 제대로 구현이 안된걸까요?
혹시 저 터미널이 Gnome Terminal이라 xterm과 차이가 있는 걸까요?

별 기대를 하지는 않지만, heavy debug를 확인해 보기로 했습니다.

--enable-debug=heavy로 빌드한 경우의 화면

화면 깨짐이 하나도 없습니다.
Code의 스크롤도 정상이고, 레지스터도 모두 잘 보이며, 명령어 입력도 제대로 됩니다.

노멀의 DOSBox와 함께 heavy debug 버전도 하나 만들어 보관하고 있다가 필요할 때에 사용하는 것이 좋지 않을까 합니다.

Appler 디버깅하기 ___ 3

이제 빌드가 다 되었으니 디버깅을 하기 전에, 정상적으로 작동을 하는지는 확인해 봐야겠죠?
필요한 파일들(*.rom, *.dsk 등등)을 빌드한 폴더에 복사해 넣고서 확인해 보았습니다.

초기화면

데모화면

로드런너

디스크매니저. 문제도 그대로...

디버거