TextHooker란 프로그램들을 아시나요? 사실 대부분의 일본산 비주얼노벨 게임을 하신 분들이라면 비슷한 프로그램들을 상당히 많이 알고 계실겁니다.

제일 유명한 것이라면 TextHooker중에서 제일 대중에게(?) 퍼진 Oh! TextHooker가 있습니다. 이외에도 4chan에서 만든것으로 추정?되는 AGTH(Anime Game Text Hooker)와 중국에서 만든것으로 보이는 VNR(Visual Novel Reader) 등이 있습니다. 상당히 많은 프로그램들이 있는데 이들의 공통점은 공통적으로 쓰이는 API(대표적인 것이 TextOut())를 후킹해서 문자열을 끌어낸다음 번역기나 사용자사전을 써서 번역된 문장을 출력하는 것이 목적입니다.

각종 TextHooker의 할아버지뻘인 Oh! TextHooker 지금도 돌아가는 게임이 있다! (출처:http://ohhara.sarang.net/ohthk/scrshots.html)

가장 최신의 기술로 무장했고 편의성도 훌륭한 VNR의 모습. 출처 : https://namu.wiki/w/VNR

API후킹 기술은 사실 어둠의 영역에서도 자주 사용되었고 빛의 영역에서도 상당수 이용됩니다. 대표적인 어둠의 영역은 키보드의 이벤트를 후킹해서 키입력 로그를 만들어 해킹하는 곳에 사용되는 것을 말 할 수 있습니다. 하지만 대개 이런 부류는 백신에서 쉽게 잡아냅니다. 빛의 영역은 시각장애인용 TTS프로그램을 들 수 있습니다. 마우스를 움직이면 마우스 아래에 있는 문장을 읽어들여서 TTS로 읽는 것이지요. 이런 프로그램은 상당히 종류가 많습니다. 그런데 리눅스에서는 이런류의 프로그램이 사실상 없습니다. Firefox나 Chrome의 확장에서는 있는 것 같지만 인터넷 웹환경에 한해서만 작동하기 때문에 한계가 있습니다.

애초에 이런 게임들이 당연히 (일본어판) Windows전용이다보니 참 문제가 많습니다. 리눅스에서 굴린다는 것 부터가 이미 글러먹은 것이지요. 그것도 번역기를 통하려고보니 더 엉망진창이고요. Wine은 DLL injection이나 API Table같은 기술이 잘 먹히지 않습니다. 본래의 API와 외부 구조는 비슷하지만 내부 구성이 다르기 때문입니다. (내부 구성까지 같으면 Wine은 Windows의 저작권에 위배되는 프로그램이 됩니다.) 즉 VNR이나 Oh! Text Hooker는 정상적인 동작이 보증되지 않습니다.

애매한 것으로 Mort란 것이 있기는한데 이건 OCR을 쓴 것이니 넘어가도록 합시다.(이전에 제가 Mort의 기술을 써서 리눅스에서 비슷하게 굴린적이 있습니다.)

그런데 API 후킹의 원리는 API의 외부 구성을 그대로 만들고 본래의 API대신 자신이 끼어들어 이리저리 조작한 후 본래의 API를 호출하는 원리입니다. (본래의 API를 호출하지 않으면 프로그램이 정상적으로 돌지는 않을 겁니다. 문자열이 나와야 하는데 안 나온다거나...)그런데 이거 Wine이 하는 짓하고 비슷합니다. http://moordev.tistory.com/83 그래서 저는 여기서 이런 방법은 어떤지 제안을 한 적이 있습니다. 해 본 결과 폭망이었지만 (애초에 구조가 달라서 먹히지 않습니다.) 역으로 리눅스에서 Wine으로 게임을 굴리면서 후킹하는 것은 어렵지 않게 구현할 수 있었습니다. gdi.so소스를 뜯어고치면 TextOut()함수를 내 마음대로 돌아가게 하는 것은 어렵지도 않고 CreateFont()함수도 고쳐버리면 폰트도 내 마음대로 바꿀 수 있게 되는 겁니다.(이건 AppLocale의 원리와 같습니다.)

그래서 sprintf함수로 문장을 처리하는 게임을 타겟으로 삼아 Wine에서 구현한 sprintf함수 조작한 다음 sprintf 출력 문장을 디버그창에 띄우게 했더니...의외로 잘 나오네요.

......이거 잘하면 리눅스용 후커도 만들 수 있을 것 같습니다. 번역 엔진이 문제이기는 한데 그건 그냥 구글번역을 통하면 될 듯하고 Chrome하고 연동하는 방법을 쓰면 구글번역기능도 쉽게 쓸 수 있을 듯 합니다. 하지만 이건 윈도용 게임이야기이고 리눅스용 게임은.....나중에 생각하도록 합시다. 아직 리눅스용 게임은 이러한 물건은 적으니까요.

Linux가 발전한 것은 Opensource라는 것이 매우 중요한 점이었습니다.

BSD계열도 Opensource로 발전했습니다.

Firefox도 Netscape의 소스 공개를 기반으로 약 5년~10년동안 리브랜딩을 했습니다.

Blender는 오픈소스를 무기로 3대 3차원그래픽 모델러의 하나가 되었습니다.(3대 모델러중 유일한 무료 프로그램입니다.)

OSX의 mach커널은 본래 오픈소스였고 지금도 오픈소스입니다.

Wine은 기어코 Windows의 API를 다른 OS에 호환하는데 성공했습니다.

OpenTTD는 본래 Transport Tycoon이란 게임의 리버스 엔지니어링이지만 지금은 다른 게임이라고 해도 될 수준입니다.

Arduino는 소스만 공개한 것이 아니라 하드웨어의 설계도를 공개함으로서 수없이 많은 변종들을 만들어내었습니다.

오픈소스는 이처럼 많은 것들을 이룩했습니다. 심지어 걔중에는 본래 유료 상용프로그램이었지만 오픈소스로 전환해서 성공한 계열도 있습니다. 소스코드의 공개는 정말 무시무시한 파급력을 지녔다고 할 수 있습니다.

위에서 보시면 Wine의 이야기가 있는데 Wine은 정말 무시무시한 결과라고 할 수 있습니다. Microsoft가 공개한 API의 형태(Microsoft 기술 문서 보면 다 나와있습니다. API를 알아야 이걸 쓸지 말지 알 터이니...)와 이를 호환하는 API를 만들어서 X와 콘솔 화면에 뿌린다는 생각으로 출발했습니다. 그리고 지금은 성공한 프로젝트이며 지속적으로 진행되어야 하는 프로젝트가 되었습니다. 지금은 MSOffice 3총사(Word, Powerpoint, Excel)를 별 삽질없이도 굴릴 수 있을 정도로 상당히 안정화 되었고 저도 덕분에 잘 쓰고 있습니다.

Wine으로 실행한 Excel 너무 잘 굴러간다.

다만....Wine은 유닉스 환경에 호환되게 돌아가게 하기 위해 몇가지 변칙이 적용되었습니다. 대표적인 것이 X환경이 기본적으로 돌아가며 GCC기반이어야 한다는 것이 전제입니다. GCC야 본래 C표준을 따르는 것이니 문제가 전혀 없지만(심지어 Clang을 써도 됩니다. C표준이라..) X환경이 전제되기 때문에 Wine은 X가 돌아가야 제대로 돌아간다는 의미가 됩니다. 그리고 단순히 응용프로그램이 굴러가는 것에 의미를 두기 때문에 Windows커널에 직접붙는 장치들은 호환이 되지 않습니다. 대표적인 것이 보안동글입니다. 해당 동글은 값비싼 프로그램에서 주로 사용하는데, 드라이버가 당연히 Windows만 있습니다.(Windows용 프로그램이니 당연히 Windows 드라이버만 있습니다.) 이런 프로그램은 Wine에서 굴릴 때 당연히 문제가 생깁니다. 

그러면 이렇게 생각해 볼 수 있습니다. Wine에 드라이버까지 붙이려면 Windows 커널까지 구현해야하나? 그럼 처음부터 Windows의 호환커널부터 만들면 어떨까?

 네 이런 생각과 가장 흡사한 프로젝트가 ReactOS입니다.

https://reactos.org/

2016년 3월에 0.4버전이 드디어 릴리즈 되었습니다. 0.3버전이 2001 2006년 즈음에 나왔던 것으로 기억되는데 참 오래되었습니다. 사실 이 프로젝트는 98년 시작(!)되었습니다. 네 98년이요. Windows95~98이 나왔던 바로 그 시절입니다. Windows98가 어떤 OS였는지 아신다면 ReactOS가 무엇을 노리고 나왔던 것인지 알 것입니다. Windows95가 일대의 파란을 일으키고 있을 때 호환 OS를 목표로 했던 것입니다. 즉, Wine보다 역사가 더 오래되었습니다. 단순 API호환이 아닌 커널부터 만드는 것을 감안하면 이해가 됩니다.

현재는 NT커널을 호환하는 것을 목표로 하고 있고 0.3버전은 WindowsXP시절에 나왔으니 XP의 드라이버 호환을 목표로 했습니다. 지금은 아마도 Windows커널 6~혹은 Windows커널 10의 호환을 목표로 하고 있을 겁니다.

참고로 0.4버전도 아직은 Alpha 단계입니다. Wine도 beta딱지를 10년동안 달고 있었으니 아직까지도 알파를 달고 있을만합니다. 덕분에 아직도 100% 장치 호환은 꿈도 못 꾸고 있습니다. 하지만 Wine과 같은 일반 응용프로그램 호환은 그럭저럭 가능한 수준까지 올라왔습니다. 그도 그럴것이 API단계에서는 Wine의 코드를 수혈받았다고 하네요. 그래서 DirectX를 직접적으로 구현을 못하고 있고 Wine의 D3DtoOGL기능을 써서 OpenGL로 구현하고 있습니다. 그나마도 드라이버문제로 잘 안 됩니다. 추후 ReactX프로젝트로 DirectX호환 프로젝트도 계획되어있고 0.5버전은 Beta단계로 나아갈 예정이라고 하니 기대되는 대목이라고 할 수 있습니다.

다만 써본 결과...Alpha단계라 아직은 실사용으로는 무리입니다. 하지만 응원할 수 밖에 없는 프로젝트인 것은 확실합니다. 무료버전의 Windows가 나오는 것이라고 봐도 상관 없고 OpenTTD가 새로운 녀석이 된 것처럼 ReactOS도 Windows와 호환성을 갖춘 새로운 물건이 될 테니까요. FreeDos가 MS-Dos와 호환을 갖추었고 Linux가 Unix와 호환을 갖추었듯이 ReactOS도 이런식으로 호환을 갖추어서 발전 할 겁니다.그리고...새로운 OS가 될 수 있을 겁니다. 그러면? IT의 발전이 또 한번 이루어 지는 겁니다. 우리가 지금까지 봐온 것처럼 말이지요.

 MATLAB은 공대에서 제어공학이나 전자공학을 한다면 한번쯤은 써보는 물건입니다. (요새는 영상처리나 음성학에서도 사용하고 경제학에서도 사용합니다. 그냥 수학하고 관련있으면 다 씁니다.)공학에서 사용하는 수학을 미리 함수화해 놓았고 코드도 그리 어렵지 않으며 배우기도 굉장히 쉬워서 여기저기에서 사용하고 있습니다.

 무엇보다 MATLAB은 학생들에 한해 평가판을 쉽게 제공해줍니다. 사실 학생인지 확인도 안하고 그냥 평가판을 제공한다는 느낌이지만 학생들이 졸업하고나서 연구소에서 MATLAB을 쓸 것이라고 예상한다면 이는 좋은 마케팅수단이 될 것이라는 것은 예상이 가능합니다.

 최신의MATLAB은 한글 지원이 상당히 잘 됩니다. 별 다른 설정없이도 한글입력이 되고 한글을 읽는데에 문제가 전혀 없습니다. 2010버전만 하더라도 폰트문제와 인코딩 문제로 황당한 경우를 많이 겪었는데 거의 해결되었더군요. 문제는 이거 윈도우에서는 그동안 이런 문제가 전혀 없었다는겁니다. 사실 대다수 MATLAB사용자들은 윈도우를 사용하니 한글문제에 관해 몰랐을 겁니다. 이런게 있었어? 하는 수준이었겠지요. 하지만 리눅스나 OSX에서는 한글문제로 골치아픈 적이 많았습니다. 게다가 X의 가속문제로 3차원 그래프를 그리는데 애로사항이 꽃피었습니다. 지금도 이 문제는 현재 진행형이라 AMD그래픽사용자들을 소프트웨어 렌더링방식으로 그래프를 표현합니다.

 MATLAB과 언제나 함께하는 Simulink는 MATLAB이 걸어온 길을 아직도 못 왔습니다. 한글문제가 아직도 있더군요. 모델파일 저장하는데 한글이 경로에 끼여 있으면 저장이 안 됩니다. UTF-8인코딩으로 저장하면 보통은 정상적으로 동작해야 정상인데 이 놈의 물건은 그게 안 됩니다. 나보고 어쩌라는 건지... 윈도우에서는 잘 되는 듯 합니다. 혹시모르니 한글을 빼라고는 하지만 유니코드 지원이 이렇게 부실해서야 이거야 원.(원래 유니코드가 나오기 전부터 만들어진 물건이기는 합니다. 그래도 1년에 두 번이나 버전업을 하면서 이렇게 까지 부실한것은 좀...)

리눅스 지원을 해준다는 점은 감지덕지 하지만 계속 이런식이면 Scilab이나 Numpy를 밀어붙여서 가는 수도 있습니다. 사실 이미 Scilab은 고려했다가 ToolBox 일부가 부실해서 MATLAB으로 회귀한건데 호환성면에서는 Scilab이 훨씬 낫네요. 우리나라나 중국,일본도 MATLAB을 많이 쓰는 것으로 알고 있는데 윈도우버전만 이를 제대로 하는 걸 보면 리눅스사용자들은 무시당한다는 느낌이 계속 드네요. 마이너한 나라에서 마이너한 OS 쓰는 서러움이 느껴지네요. 한국지사에서 신경을 써줬으면 좋겠는데 이 나라에서 마이너OS를 신경이나 써줄까요?

정 안 되면 MATLAB을 안 쓰는 것도 방법이 될 수도 있겠네요. scilab이나 배워볼까....