원하는 위치에서 Command 창 띄우기

1. windows explorer을 연다.
2. "도구"의 "폴더 옵션"을 실행한다.
3. "파일 형식" 탭을 선택한다.
4. "폴더" 파일 형식을 선택한 후, "고급" 버튼을 누른다.
5. "새로 만들기"를 누른 후, "명령"에는 context menu에 나타날 이름을 입력하고, "명령을 실행할 응용프로그램"에는 "c:\windows\system32\cmd.exe"을 입력한다.

위와 같은 과정을 거친 후, windows explorer에서 폴더의 context menu를 펼친 후 추가한 메뉴를 선택하면, 선택한 폴더의 "부모" 폴더를 시작점으로 한 command 창이 열리게 된다.

running scratchbox under Ubuntu 8.04

Scratchbox를 Ubuntu 8.04에 설치해 보았다. 설치는 잘 진행이 되었지만, 실행시 다음과 같은 error가 발생하였다.

Inconsistency detected by ld.so: rtld.c: 1192: dl_main: Assertion ‘(void *) ph->p_vaddr == _rtld_local._dl_sysinfo_dso’

이를 해결하기 위해서는 vdso를 disable 시켜줘야 하는데, 가장 확실한 방법은 kernel recompile이다. 하지만, 귀차니즘 때문에 좀 더 간단한 방법을 찾아보았다.

echo 0 | sudo tee /proc/sys/vm/vdso_enabled

임시로, vdso를 disable시켜주는 방법이다. 부팅할 때마다 다시 해줘야 하지만, 간단하게 해결할 수 있는 방법이다.

compile vmware-tools on Ubuntu 8.04

Ubuntu 8.04가 아직 정식 release되지는 않았지만, beta버젼을 사용할 수 있어서, vmware에 설치해 보았다. 하지만, vmware-tools가 compile되지 않는 문제가 발생하여서, 몇가지 시도를 통해서 compile하는 방법을 찾아보았다.

일단 open vmware tools에서 소스를 받아서, 컴파일이 되도록 dependencies가 걸린 라이브러리를 모두 설치한다. 여기서 주의할 점은 dnet이라는 라이브러리를 찾는데, 실제로 ubuntu에서는 dumbnet이라는 이름으로 쓰이므로, dumbnet-dev 패키지를 설치하여야 한다. 또한, configuration을 통과 하더라도, dnet.h 파일을 찾을 수 없다는 error 메시지가 나오며, compile이 안되는데, 컴파일이 안되는 해당 파일을 열어서 dnet.h를 include하는 것을 dumbnet.h를 include하도록 변경해 주면, compile이 잘 진행될 것이다 (make 뿐만 아니라, make modules도 실행하여서, module의 compile에도 문제가 없는지 확인하여야 한다).

이렇게, open vmware tools의 compile의 compoile이 모두 잘 되면 open vmware tools를 대신 사용할 수 있지 않겠냐는 생각이 들겠지만, 이상하게도 open vmware tools에서는 installation script를 제공하지 않는다. mailing list를 확인해본 결과, vmware의 product에 포함되어 있는 vmware tools에 open vmware tools를 compile해서 나온 module를 붙여서 설치를 하여야 한다 (이런 삽질을 왜 시키는지 모르겠다... 이 것 때문에 전혀 이해 안되는 이후의 과정을 진행하여야 한다ㅡㅡ;)

vmware 메뉴에서 install vmware tools를 선택하여, vmware tools 파일을 복사한 후, .../vmware-tools/distrib/lib/modules/source 디렉토리를 확인한다. 해당 디렉토리 내에, module들이 tar로 묶여 있는 것을 볼 수 있을 것이다. 해당 tar파일을 풀어보면, {module}-only라는 디렉토리가 생기는데, 실제로 풀어볼 필요는 없다. open vmware tools의 .../open-vm-tools-.../modules/linux/ 디렉토리를 열어보면, 각 module의 이름으로 된 디렉토리를 확인 할 수 있을 것이다. 이 각 {module} 디렉토리를 {module}-only로 바꾸어서 tar로 묶어준다. 그리고, 이렇게 묶은 파일을 vmware tools의 module source 디렉토리에 복사하여 기존의 파일에 덮어씌워준다.

이제, 원래 하던데로, vmware tools의 설치를 진행하고, module의 compile을 진행하면 정상적으로 vmware tools의 설치가 종료될 것이다.

Human Energy

SBS에서 재미있는 다큐맨터리 하나를 방영했다. 사람의 운동 에너지를 전기 에너지로 바꿀 수 있다면, 단순히 전기료를 아끼는 것 뿐만 아니라, 사람들의 건강이 나아지고, 환경이 좋아질것이라는 내용이다. 나 역시 이런 생각을 해본적이 있지만, 이러한 생각을 본격적으로 실천에 옮기고 있는 사람들이 그렇게 많으며, 이러한 실천이 상당한 결과를 내고 있다는 것이 정말로 놀라웠다. 아버지께서 말씀하신 것 처럼 "상활과학"이 앞으로 상당히 재미있는 분야가 될 듯하다^^

C++ method to C function

Bjarne Stroustrup이 처음 C++를 개발하고, 만든 컴파일러는 C++ 코드를 C로 변환한 후, 이를 다시 C컴파일를 이용하여 기계어로 번역하는 방식이었다. 그리고 이러한 방식은 현재의 컴파일러에서도 변하지 않고 사용되고 있다.
C++의 method는 C의 function으로 다음과 같이 변환된다.

CClass::Method(TYPE parma1, TYPE parma2); // C++ method
Method(CClass *thisptr, TYPE param1, TYPE param2); // converted C function

Bjarne Stroustrup

Bjarne Stroustrup은 덴마크 사람으로 C++를 만든 사람이다.
발음은 찾아본 바로는 대략 "뷔야(른)ㅡㄴ 스트루스트럽 (r 발음은 빠른 발음 때문에 거의 묵음화)" 정도 인듯 하다 (발음 듣기).
가장 많이 사용하는 C++를 누가 만들었는지 정도는 알아두자.

Name Mangling

function, structure, class, variable의 이름이 같은 경우 생길 수 있는 문제점을 방지하기 위해서 이름과 추가적인 정보를 encoding하여 내부적으로 사용되는 이름을 생성하는 방법이다. Name Decoration이라고도 불리며, C에서는 이를 사용하지 않지만, C++에서는 이를 사용한다. 예를 들어, C++에서 polymorphism이 적용된 함수의 경우, 이름은 같지만 파라미터가 다르낟. C에서는 이러한 함수의 식별이 불가능하지만, C++에서는 Name Mangling을 이용하여, 서로다른 함수로 십결이 가능하다.

Name Mangling에는 표준이 없고, 컴파일러 나름대의 방법을 사용한다. 그러므로, 컴파일러가 동일하다면, Name Mangling을 통해서 encoding된 이름이 동일하지만, 그렇지 않을경우 이름이 동일하다는 보장을 할 수 없다 (DLL에서 extern "C"를 사용하는 이유).