오늘날 PC의 GUI 환경에서 돌아가는 거의 모든 프로그램들은 F1을 누르면 도움말이 나온다.
윈도우는 운영체제 차원에서 표준 도움말 규격이 있는 것으로 예로부터 유명했다. 아예 운영체제의 API에 WinHelp 같은 함수가 정식으로 등재되어 있다. -_-
맥 OS는 모르겠고, 리눅스는 그런 시스템이 없다고 들었다(쉘부터가 GNOME이 뭔지 KDE가 뭔지 사실 아직도 알쏭달쏭... ㄲㄲ).
그 원조는 바로 WinHelp와 그 기반의 HLP 도움말 파일이다. 20년 전의 윈도우 3.0때 처음으로 도입된 이 기능은 나름 굉장히 유용했다. 다양한 서식을 적용한 텍스트 + 이미지 + 하이퍼링크 + 팝업창은 일종의 인터넷 WWW와도 비슷한 수준의 인터페이스였다. WinHelp는 의외로 기능이 다양해서 도움말에다 색인도 넣고, 도움말 창의 버튼도 customize 가능했다.
당시 WinHelp를 설계한 엔지니어가 누군지는 모르겠지만, 도움말이라는 간단한 주제 하나만으로 굉장한 대작을 만들어 냈다. 윈도우 3.1 때 도움말 시스템이 소폭 업그레이드되긴 했으나, 아직까지는 대동소이하고 하위 호환성 정도는 유지되었던 걸로 본인은 기억한다.
도움말은 기본적으로 오늘날 워드패드가 사용하는 RTF(서식 있는 텍스트) 기반이었다. 문서 파일에다가 각종 도움말 메타정보를 WinHelp 스펙대로 넣어 준 후, 이들 파일과 그림들을 Help Compiler로 컴파일하고 압축하면 HLP 파일이 생성되었다. 하지만 이건 대단히 번거롭고 까다로운 일이었기 때문에, 그 절차를 간소화해 주는 위지윅 도움말 저작 도구도 응당 개발되어 나오곤 했다.
16비트 윈도우용 SDK를 보면 도움말 컴파일러가 HC30 (윈 3.0 공용), HC31 (윈 3.1 전용)이 따로 있었다.
이 WinHelp는 윈도우 95에서는 4.0으로 버전이 올라가고 기능이 훨씬 더 강화되었다. 계층 구조의 목차가 따로 추가되어서(*.CNT) 도움말의 첫 화면에다 번거롭게 목차를 본문 형태로 넣을 필요가 없어졌으며, What's this?라는 풍선 도움말이 추가되었다. 창도 더욱 아담해지고 응용 프로그램과 통신만 잘 주고받으면 거의 CBT 수준의 인터렉티브한 도움말을 만들 수도 있게 됐다.
윈도우 3.x 시절에는 매 대화상자마다 한쪽 끝에 ‘도움말’ 버튼이 있는 게 유행이었는데 그게 95부터는 다 사라졌다. 그 대신 X 버튼 왼쪽에 [?] 버튼이 생겼다.
그리고 또 여기서 주목할 점은, 도움말 시스템이 16비트(winhelp.exe)와 32비트(winhlp32.exe)로 완전히 분리되었다는 것이다. 왜 그럴까?
윈도우 운영체제의 도움말은 단순히 하이퍼링크가 달린 RTF 문서 뷰어 수준을 훨씬 더 능가하는 방대한 시스템이었기 때문이다.
HLP 파일은 윈도우 API를 호출하는 건 물론이고 WinHelp 규격대로 만들어진 플러그 인 DLL들을 붙여서 도움말 화면을 사실상 마음대로 제어할 수 있었다. 나만의 버튼을 추가하고, 확장 기능을 넣고... DLL이 들어간 이상 16비트와 32비트의 분리는 불가피해진 것이다. 지금 같으면 32비트와 64비트의 분리가 필요하겠지.
얼마나 customize가 가능하냐 하면, HLP 파일에다가 마치 오늘날의 HTML 도움말(CHM)처럼 목차 탭을 도움말 내부에다 보조 윈도우로 집어넣을 수 있었다. 도움말이 WinHelp에다가 아예 없던 기능을 추가할 수 있을 정도였던 것이다.
과거 본인이 즐겨 이용하던 Paint Shop Pro 7은 Robo HelpOffice라는 저작 도구로 만들어진 HLP 도움말을 제공했는데, 정말 기능이 상상을 초월하게 화려했다.
이게 웹으로 치면 ActiveX이다. 도움말 세계의 ActiveX인 셈인 것이다. -_-;;
그랬는데, 윈도우 98 + 인터넷 익스플로러 4가 되면서 새로운 도움말 시스템이 또 등장했다. 서식 있는 텍스트+하이퍼텍스트의 진수는 바로 웹이 아니던가. RTF가 아니라 아예 IE의 엔진을 쓰는 도움말이 생긴 것이다. 이것이 오늘날까지 전해져 오는 HTML 도움말이며, 파일의 확장자는 CHM이다. Compiled HTML.
HTML 도움말은 내부적으로 IE를 쓰는 관계로 과거의 WinHelp보다 훨씬~ 더 덩치 크고 무거웠다.
IE 4를 얹지 않은 옛날 윈도우 95 시절의 탐색기 vs 오늘날 탐색기의 덩치 및 구동 시간은
과거 WinHelp 도움말 vs 오늘날 HTML 도움말의 덩치 및 구동 시간
이건 비슷한 구도이다. -_-;;;
하지만 웹에서 쓰이는 각종 자바스크립트+다이나믹 비주얼 효과를 도움말에서도 그대로 재활용 가능하다는 점을 감안하면, 웹 기술을 도움말에다 활용하겠다는 발상 자체는 훌륭하다고 볼 수 있다. WinHelp 기술은 윈도우 밖에서는 아무 쓸모도 없는 테크닉이지 않은가.
개발자의 입장에서야 RTF보다야 HTML이 훨씬 더 친근하니 예전보다 도움말 만들기가 쉬워진 것도 아주 좋다. 본인도 HLP 도움말은 만들 엄두를 못 냈었는데 CHM 도움말은 나모나 프런트페이지만으로도 비교적 손쉽게 만들 수 있었다.
홈페이지 만드는 데 쓰이는 파일을 그대로 모아서 컴파일만 하면 끝. 그러니 CHM 파일은 웹 문서 아카이브를 만드는 데도 아주 유용했다.
일반 웹에는 존재하지 않지만 도움말에는 필요한 기능이 있다. 가령, 팝업 메뉴를 띄운다거나 외부 프로그램을 실행하는 기능은 소스를 보면 MS가 자체적으로 ActiveX처럼 비표준 확장 태그를 써서 구현해 놓은 걸 볼 수 있다.
CHM 도움말은 장기적으로 기존 HLP 도움말 시스템을 대체할 목적으로 만들어졌기 때문에, HLP로 할 수 있는 일은 CHM으로도 다 할 수 있게 돼 있다. 가령, CHM으로도 풍선 도움말을 구현 자체는 할 수 있다. 하지만 그 쬐그만 풍선 도움말이 웹 페이지 내용이라는 건 영 안 어울린다. 실제로, 비스타부터 풍선 도움말은 윈도우 운영체제 내부에서는 완전히 사라졌다.
윈도우 98부터 XP까지 운영체제의 도움말은 WinHelp와 HTML 도움말이라는 양분된 구도를 유지하고 있었다. 그러다 윈도우 비스타는 과감하게 WinHelp를 없애 버렸다. HLP 도움말을 열면 ‘이 도움말은 옛날 버전으로 만들어져서 이제는 더 지원되지 않습니다’만 뜬다. (단, 16비트용 WinHelp는 남아있음)
원래 마소는 과거 호환성을 극도로 존중해 주는 집단이다. 그런데 왜 이런 조치를 취한 것일까?
오늘날 과거 호환성보다 더 중요한 건 보안이기 때문이다.
HLP와 CHM 모두 단순히 read-only 하이퍼텍스트 문서만 취급하는 게 아니다. 사용자의 컴퓨터에 있는 응용 프로그램을 실행할 수 있고, DLL의 코드를 불러와서 실행할 수 있다. 따라서 잠재적 보안 위험성도 충분하다.
마소는 21세기부터 자사 소프트웨어에 있는 이스터 에그를 모두 없앴으며, 이미 짜 놓은 수많은 코드에 대해서도 대대적인 보안 강화 리팩터링을 시작했다. 비주얼 C++ 2005부터는 잘 알다시피 비표준 오명을 감수하고라도 C 라이브러리까지 뜯어고쳐서 *_s 함수를 도입할 정도였다.
그랬는데 그렇잖아도 구닥다리 WinHelp의 코드를 보니까, 이건 기능도 카오스 그 자체이지, 앞으로 지원도 안 할 건데 리팩터링을 할 필요를 못 느낀 것이다. 그러니 철도 당국이 수익 안 나는 간이역을 폐역하듯이 지원 중단 결정을 내렸다. WinHelp 함수 지못미.
이런 보안 강화 정책으로 인해, 윈도우 비스타부터는 탐색기에 16비트 윈도우 실행 파일들이 아이콘이 그려져 나오지 않는다. 웹페이지의 파비콘을 추출하고 그리는 코드의 허점을 이용해서도 악성 코드를 주입하고 실행할 수 있을 정도이니 말 다 했다. -_-;; 비슷한 이유로, 워드패드에서 과거 wri 파일 포맷을 읽는 기능도 삭제되었다. 구닥다리 코드는 이제 와서 보안을 강화하는 작업을 하기 귀찮으니까 그냥 무시하기. ㄲㄲ
사실은, CHM 파일마저도 이제 MS가 더 적극적으로 개발을 안 하기는 마찬가지이다. 요즘 MS가 만드는 프로그램들은 CHM 안 쓰고 또 자기만의 다른 도움말 시스템을 쓴다. 비록 내용 렌더링이 HTML 기반인 건 동일하지만, CHM은 아니라는 뜻. 그 때문인지는 모르겠지만 HTML 도움말을 보면, 도구상자의 아이콘은 10년 전이나 지금이나 아직까지도 16컬러 그대로이다. ㄲㄲㄲ
아울러, CHM 역시 보안 위협을 많이 받는 관계로, 웹에서 받아서 바로 실행한 녀석은 내용이 표시되어 나오지 않는다. 반드시 로컬 환경에다 저장해서 ‘속성 -> 제한 해제’를 해 줘야 내용을 볼 수 있다.
앞으로 윈도우 운영체제의 도움말 시스템이 어떻게 변모할지는 알 수 없는 노릇이다. 하지만 설마 CHM이 HLP처럼 그렇게 갑작스럽게 호락호락 없어지지는 않을 듯하다.
하긴, 예전엔 아래아한글도 언어(한국어든 영어든)와 플랫폼(3.1/95/NT)을 불문하고 동일하게 표시되는 GUI 엔진을 표방하고서, 도움말조차 자체 포맷을 만들었던 적이 있다. 97까지만 해도 윈도우 3.1 도움말 스타일의 자체 도움말을 썼었는데 워디안/2002 이후부터는 싹 잊혀지고 그냥 CHM을 쓰기 시작했다.
도스용 프로그램 개발할 때 도움말 기능을 구현하던 추억이 아직도 새록새록하다. ^^
※ 잡설: 응용 프로그램의 보안 문제
유명한 국산 압축 프로그램인 빵집의 구버전에서, 악의적으로 일부 내용이 조작된 zip 파일을 열자 엉뚱하게도 내가 지정해 준 프로그램이 실행된다. 프로그램의 보안 취약점을 시연하는 동영상을 보니 신기하기 그지없었다.
프로그램의 소스로는 제각각의 이름으로 구분되는 수많은 변수와 함수의 명칭들이, 빌드 후에는 그저 아무 의미 없는 오프셋 내지 메모리 주소로 바뀐다. 그러니 이런 정교한 숫자가 조금이라도 바뀌면 프로그램은 전혀 다른 동작을 하게 된다. 그런 조작은 입력 파일의 조건 검사를 허술하게 하는 프로그램의 허점을 이용해서 가능하다. 더구나 zip은 프로그램 실행과는 전혀 관계없는 데이터 파일일 뿐인데, 하물며 대놓고 프로그램 실행 기능이 있는 파일은 얼마나 위험하겠는가?
사용자의 입장에서는 각종 보안 업데이트가 귀찮기 그지없다. 하지만 개발자의 입장에서는 보안 업데이트를 안 하면 어떻게 되는지를 너무 자세하게 설명해 줄 수도 없다. 그러니 서로 답답한 노릇이다.
“모방 범죄 예방을 위하여 더욱 정확한 후레쉬 조작법... 이 아니고 더욱 정확한 악성 코드 삽입 방법은 알려드리지 못하는 점 양해 바랍니다.” ㅋㅋㅋㅋ
Posted by 사무엘
