※ QuickBasic
아래의 PB와 더불어 제 인생에서 거의 최초로 접한 “EXE 생성기”가 아니었나 싶습니다. 중학교 시절 저의 주된 장난감이었습니다. 특히 가장 대중적인 베이직 컴파일러였던지라 한글 입출력/그래픽/사운드/마우스/메모리 등 갖가지 분야의 공개/상용 라이브러리로 기능을 확장해서 프로그램을 만들던 기억이 납니다.
MS는 오로지 고객 편의 위주로 기존 관행을 확 깨는 새로운 제품 만드는 데는 정말 비상한 재주가 있다는 걸 인정해야겠습니다. 그래서 윈도우 9x 같은 타협안으로 소비자 시장을 우려먹기도 했고, 베이직 개발 환경만 해도 저런 대화형 구조에다가 라이브러리까지 특수한 EXE로 링크해서 ‘퀵라이브러리’(QLB)라는 개념을 발명하여, IDE에서 빌드도 없이 바로 프로그램을 실행시킨 것도 정말 대단하다고밖에 말할 수 없군요.
QB는 최종 버전이 4.5였고 그로부터 몇 년 뒤에 소위 MS Basic이라 불린 Basic PDS (전문 개발 시스템)가 7.0/7.1 (VS .NET 같군)라는 QB 후속 버전이 나오긴 했습니다. 하지만 차이를 전혀 모르겠어요. 오히려 기능 확장의 생명인 라이브러리가 호환이 안 되고 불편해서 널리 사용되지는 않았습니다. PDS 이후 MS는 비주얼 베이직으로 넘어갑니다. 마치 MS C 7 이후로 비주얼 C++이 나온 것처럼.
※ PowerBasic
볼랜드에서 Turbo Basic을 잠시 만들던 전 직원이 볼랜드를 나와서 따로 창조한 브랜드이죠. 베이직만으로 QB보다 월등히 빠르고 거의 C/C++ 수준의 효율적인 네이티브 코드를 만들어 준 덕분에 QB와는 별개 영역에서 사용자를 구축하고 있습니다. 저는 3.1을 써 봤습니다.
단점으로는 QB에 비해 역시 라이브러리 캐부족, 일부 QB와 호환되지 않는 문법, QB보다는 다루기 불편한 IDE. 그리고 PB도 아예 Win32 콘솔 프로그램은 만들어도 32비트 도스 익스텐터와의 연계는 없었던 걸로 압니다.
또한 QBasic도 지원하는 스크린 mode 13H (VGA 320x200 256색) 모드를 지원 안 하는 것도 너무너무 아쉬운 점.
세상에 베이직처럼 Dialect가 많은 언어도 별로 없는 것 같습니다. 요즘 베이직은 그냥 스크립트 언어처럼 쓰거나 아니면 .NET 구도에 맞춰서 문법 다 뜯어고쳐서 쓰는데, PB는 베이직으로 하드코어 네이티브 코드를 지향했다고 볼 수 있습니다. 참고로 베이직을 거의 어셈블리 수준으로 짬뽕시킨 언어 내지 툴로 ASIC이라는 녀석도 있었습니다.
※ Visual Basic
GUI 바로 만들고 거기에다 코드를 즉시 갖다붙이는 형태가 무척 재미있어서 잠시 갖고 놀아 봤습니다. 하지만 런타임 DLL이 필요한 EXE밖에 못 만든다는 걸 알고서 이내 좌절함. 그나마 5.0 이전 버전은 EXE 자체도 자바 내지 닷넷 같은 슈도코드 기반이지 네이티브 코드는 지원도 안 하고 있었고요.
아울러, 닷넷부터는 IDE가 언어 불문하고 한데 통합되었기 때문에 VB 특유의 그 개성 넘치는 IDE를 볼 수 없게 된 것이 좀 아쉽습니다.
※ Borland Pascal
언어 특성상 C/C++과는 비교가 안 될 정도로 빌드 속도가 월등히 빠르고 라이브러리 오버헤드도 훨씬 작아서(Hello, world! 프로그램의 exe 크기) 굉장히 좋은 인상을 받았습니다. 16비트 도스용 네이티브 컴파일러로는 그야말로 최고봉이 아닌가 싶습니다. 파스칼 언어도 제가 베이직에서 C/C++로 전환할 때의 과도기 컨셉 역할을 잘 해 주었습니다. 이걸로 뭔가 걸출한 프로젝트를 진행해 봤으면 하는 아쉬움도 있습니다.
파스칼은 교육용으로 무척 훌륭한 언어이고 간단한 문법 덕분에 빌드하기는 간편하나, C/C++보다 함축성이 굉장히 떨어져서 코딩하기는 번거롭습니다. 가령 정수 나누기 정수도 결과가 무조건 실수가 되고 일일이 형변환을 해야 하는 건 기계 입장에서는 직관적이지 못하죠. 또한 단축연산이란 것도 없고.
※ Turbo C/C++
고등학교 때 정보 올림피아드 준비하던 시절에 잠시 다뤘을 뿐, 제품 자체의 왕년의 영향력에 비해서 얘를 써 본 경험은 거의 없습니다. 본격적인 응용 프로그램 개발을 위해 필요한 프로젝트 세팅, 메모리 모델 설정 같은 것도 전혀 해 본 적 없습니다. 저는 16비트 C/C++과는 도스/윈도우 공히 인연이 없는 셈입니다.
※ Delphi
놀랍게도 제가 얘를 다뤄 본 건 95년에 나온 초창기, 그것도 16비트 버전인 1.0뿐입니다. 오브젝트 파스칼 언어로 비주얼 베이직 같은 프로그래밍을 할 수 있구나 하는 인상만 받고 더 진척된 건 없습니다.
델파이는 런타임 DLL이 필요한 EXE를 만드는 옵션 자체가 없고 기본적으로 EXE 크기가 2~300KB대 이상은 먹고 들어가는 걸로 알고 있습니다.
※ C++ Bulder
비베, 델파이 수준의 RAD 환경을 C++로도 만들어 버렸으니 대단하다는 인상을 받았음. 물론 다른 건 다 델파이를 따라해도 빌드 속도를 따라할 수는 없지요.
버전 3을 써 봤습니다. 골치아프게 Win32 GDI API 쓸 필요 없이 캔바스 객체에 접근하여 프로퍼티를 바꾸는 것만으로 선과 면 색을 바꾸는 것도 흥미로웠습니다.
하지만 RAD 용도로는 어차피 델파이가 한 역할 담당하고 있었고, C++ 빌더는 상대적으로 존재감이 덜했던 것 같습니다.
MFC도 지원은 하지만, 빌드 속도 내지 빌드된 코드의 성능이 MFC의 본고장인 VC로 빌드한 것보다 무척 뒤쳐졌던 걸로 기억합니다. 빌드 속도는 흠, pre-compiled header 설정을 안 해서 그런 걸까?
델파이와는 달리 C++ 빌더의 EXE는 기본적으로 VCL.DLL이던가 컴포넌트 DLL이 필요한 형태입니다. 스테틱 링크가 가능한지는 기억이 안 납니다.
※ Watcom C/C++
MS와 볼랜드 컴파일러의 공통점은 32비트 도스 익스텐더 기반 코드 생성을 지원하지 않았다는 것입니다. 자기네 컴파일러들이나 겨우 몇 MB 정도 추가 메모리 확보를 위해, 286용 16비트 도스 익스텐더 정도를 사용한 게 고작입니다.
그러던 차에, 상용 게임들 덕분에 유명하던 DOS4GW 기반 코드 생성을 지원하던 왓콤 컴파일러는 정말 신선한 충격이었습니다. sizeof(int)도 말로만 듣던 4바이트로 나왔죠.
최적화 성능도 매우 뛰어났던 걸로 기억합니다. 익스텐더는 다르지만 도스용 아래아한글 386 에디션도 왓콤 기반이었던 것으로 유명합니다.
하지만 라이브러리가 부족하고 IDE도 없는 이 컴파일러로 본인이 당장 할 수 있는 일이 별로 없었던 게 아쉽습니다.
※ DJGPP
자유 소프트웨어 진영의 위력을 보여준 불세출의 32비트 도스 컴파일러입니다. 소스까지 공짜, DOS4GW보다 stub 크기가 훨씬 작고 더구나 DPMI가 기제공되는 환경에서는(윈도우 도스박스 같은) 필요하지도 않은 CWSDPMI.
거기에다 rhide 같은 IDE와 알레그로 같은 무지막지한 게임 라이브러리.
빌드 속도가 좀 느리고 exe 크기가 살짝 좀 큰 게 압박인데, 그 정도는 좀 대형 프로그램 작성하다 보면 아무것도 아닙니다. 도스가 살아 있다면 계속해서 쓰고 싶습니다. 물론 윈도우용 GCC도 있다고는 들었지만.
※ Visual C++
여러 개발툴들을 거쳐 이제 최종적으로 정착한 도구는, 그 이름도 유명한 비주얼 C++입니다. 더 설명이 필요없으리라 믿습니다. 닷넷이고 뭐고 많이 나와도 역시 한글 IME를 직접 개발하다 보니 제게는 네이티브 말고 다른 계층은 필요하지가 않네요.
Posted by 사무엘
