2026년의 끝을 앞두고 날개셋 브랜드 프로그램이 소폭 버전업됐다. 늘 그렇듯이 유용하게 사용하시기 바란다.
입력기에 ARM64EC 지원이 추가됐다는 소식은 예전에 귀가 따갑도록 전했으니 그 얘기는 또 하지 않겠다. 그것 말고 또 바뀌거나 달라진 내역은 다음과 같다.

1. 스크롤바 개선

이 프로그램에서 자체 구현하여 제공하는 스크롤바의 아주 아주 오랜 고질병을 고쳤다. 이 스크롤바는 문자표, 부수 한자 입력 같은 입력 도구에도 있고, 외부 모듈의 한자 변환 UI에서도 볼 수 있다.

◀▶▲▼ 같은 thumb이나, 막대 자체를 아주 잠깐만 클릭하고 뗐는데도 스크롤이 기본적으로 2단계씩 되던 것,
그리고 정작 그것들을 오랫동안 누르고 있으면 스크롤 속도가 너무 느리던 것 말이다.
이를 드디어 개선하여 운영체제의 표준 스크롤바와 거의 동일하게 동작하게 했다. 짧게 눌렀다 떼면 한 단계만 스크롤되고, 오래 누르고 있으면 빠르게 스크롤된다.

그리고 운영체제의 스크롤바는 막대를 shift+클릭하면 그 지점으로 바로 이동하는 기능이 있다. 이것도 내 한글 입력기의 스크롤바에서 지원되게 했다.
요 기능을 넣는 과정에서 저 고질병도 이번 기회에 조치를 취했다. 너무 늦은 감이 있지만 유의미한 개선이다.

2. 편집기에서 글꼴 목록을 표시하는 방식을 개선

사용자 삽입 이미지

날개셋 편집기의 '편집 화면 설정'에서 볼 수 있는 요 글꼴 목록 말이다.
일단, 예문을 나타내는 회색이 기존 일반적인 검정색과 잘 구분돼 보이지 않아서 색을 더 약하게 바꿨다. 이건 Windows 10/11에서 system color값이 바뀌어서 발생한 현상이다. (왜 이렇게 바꿨는지..)

그리고 예문에서 '아래아 한'이 옛한글 지원 글꼴을 나타내듯, 그 다음 '굩'이라는 글자는 KS X 1001 완성형에 없는 글자이다. 완성형 글꼴의 예문에서는 이 글자가 표시되지 않게 함으로써 자연스럽게 글꼴의 한계를 알 수 있게 했다.

끝으로, 위의 스크린샷에서 볼 수 있듯..
글꼴 이름이 너무 길어서 예문까지 한 줄에 모두 표시할 수 없을 때 말이다.
일반적인 경우라면 글꼴 이름을 다 표시하기 위해 예문을 저렇게 밀어내고 짜른다.
그러나 글꼴 이름에 해당 문자가 충분히 들어있지 않으면.. 반대로 글꼴을 짜르고 예문을 원래 있던 곳에 변함없이 표시하게 했다.

한글 글꼴의 이름이 영문이 잔뜩 들어있고 길기까지 하다면.. 이건 굳이 이 자리에서 표시할 필요가 없다고 간주되기 때문이다. 영문 글꼴의 이름에 영문 이외의 문자가 많이 들어있는 경우에도 마찬가지이다.
물론 프로그램에서 기본 제공되는 글꼴만으로는 이 로직이 동작하는 것을 볼 일이 없다. 하지만 저런 경우에 더 똑똑하게 대비하는 로직이 미리 구현되었다.

3. 나머지 정말 사소하고 자잘한 것들

- 상태 표시줄에 '블록 n개'라는 표시는 블록을 2개 이상 만들었을 때만 표시하게 했다. 1개만 만들었을 때는 그냥 가만히 있는 게 더 나아 보인다.

- 파일명이 없는(= 아직 저장을 한 적 없는) 빈 문서에서 저장 옵션(인코딩 등)만 변경했는데도 그 창을 닫을 때 저장 확인 질문이 나오던 것을 수정했다. ㄲㄲㄲ

- 편집기의 열기-저장 대화상자에 기본적으로 뜨는 확장자 필터가 다음과 같이 바뀌었다. 일반 텍스트, 정형화된 데이터, 웹 관련, 명령 스크립트 이렇게 카테고리를 4개로 나눠서 자주 쓰이는 확장자를 신속하게 고를 수 있게 했다.
다만, 날개셋 편집기는 전문적인 프로그래머용 에디터가 아닌 관계로, 프로그래밍 언어들의 확장자를 이런 식으로 일일이 나열은 일부러 하지 않았다.

- 세로쓰기 상태에서 90도로 돌려져서 표시되는 전각 부호를 10여 종류 더 추가했다.
- 프로그램 도움말에는.. 프로그램 설치와 관련하여 스마트 앱 컨트롤을 꺼 보라는 말을 추가했다.

- 프로그램의 설정 저장과 관련하여 일단 일반적인 사용자에게는 거의 존재감이 없을 논리 불일치 버그가 하나 있었는데.. 코딩 AI가 의심해서 찾아준 게 맞았다. 하나 잡았다.

- About처럼 내용 결과를 보고 닫는 버튼 하나밖에 없는 대화상자에 대해서 내 프로그램은 전통적으로 버튼 이름을 '닫기'라고 붙이곤 했는데.. 이것을 도로 '확인'으로 변경했다. 영문으로는 어차피 똑같이 OK이기도 하니..

4. 타자연습 4.01

타자연습은 작년 여름에 오랜만에 4.0이 나왔었다. 64비트로 포팅, 굴림체 UI 탈피 같은 최소한의 구색내기를 했다.
이번 새 버전에서는 프로그램이 영문 Windows에서 실행될 때 자잘한 glitch가 있던 것을 주로 해결했다. 과거 3.x 버전에서는 존재하지 않다가 코드 리팩터링과 포팅 과정에서 재발했던 문제를 다시 해결한 것에 가깝다.

- 기본 코드페이지가 cp949가 아닌 곳에서 콤보박스의 내장 데이터값이 깨지는 거,
- 기본 언어가 한국어가 아닌 곳에서 프로그램 창이 맑은 고딕 대신 다른 폰트로 지정되어서 한글이.. 깨지지는 않지만 너무 작고 알아보기 힘들게 찍히는 것,
- 150% hdpi 환경에서 좌우 대조 긴글 연습 대화상자의 아래쪽이 살짝 깨지는 것, '통계'의 그래프 숫자들이 아래가 짤리는 것 (폰트 폭 계산이 맑은 고딕 특유의 줄 간격을 반영하지 못해서)

요것들을 말끔히 해결했다. 원래부터 100% dpi에 한글 Windows를 사용해 오신 분은 업데이트할 필요가 별로 없으실지도 모르겠지만ㅠㅠ, 그 외에도..

- 날개셋 편집기에서 글꼴 목록 콤보박스의 로직이 개선된 것 역시.. 타자연습에도 동일하게 적용됐다.
- 도움말의 세벌식 FAQ에 신세벌식이나 3-18Na처럼 중-종성 절충 세벌식에 대한 설명을 더 추가했다.

- 이 프로그램은 날개셋 한글 입력기 없이 단독으로 설치해도 글꼴만 기본 내장 글꼴로 고정될 뿐 사용은 가능하다. 단, 기본 내장 글꼴은 16픽셀 것만 제공된다. 이게 없으면 까마득히 높은 dpi 환경에서도 프로그램이 16픽셀 형태로만 실행된다.
24픽셀 글꼴을 사용하려면 결국 글꼴 파일이 온전히 들어있는 한글 입력기 본체를 설치해야 하는데.. 이에 대한 설명이 별로 없어서 도움말과 프로그램 메시지 상으로도 추가했다.
날개셋 한글 입력기 없이 타자연습만 설치해서 쓰는 건.. 뭔가 테란 스타포트를 지어 놓고 컨트롤 타워 애드온 없이 그냥 레이쓰만 뽑는 것과 비슷하게 보일 수 있다.;;;

그나저나, 타자연습도 마음만 먹으면 ARM64 전용 에디션을 만들 수는 있지만 아직 보류했다.
ARM64 기기에서도 사용하는 데 아무 불편이 없고, 이런 x64용 프로그램에서는 날개셋 한글 입력기도 ARM64EC 에디션이 잘 돌아가고 있기 때문이다. 당분간 타자연습은 x64만 밀고 나갈 것이다.

6. 타자연습 게임의 글자 투명색 버그

끝으로, 날개셋 타자 게임에서 떨어지는 단어들이 투명 배경색이 제대로 처리되지 못하고 이렇게 표시되는 걸... 목격하신 분이 혹시 계신가?

사용자 삽입 이미지

타자 게임은 주요 로직이 20년 넘게 전에 완성돼서 지금까지 이어지고 있는 엄청난 고인물이다. 그런데 저런 오동작이 발생하는 걸 본인은 요 근래에 직장의 PC에서 난생 처음으로 구경했다.
그래서 언제 날잡아서 디버깅 좀 해야겠다고 마음먹었는데.. 그만 PC가 바뀌어 버렸고, 새 컴에서는 애석하게도 그 문제가 더 재연되지 않았다;;;;;

그렇잖아도 이번 타자연습 4.01에서는 자잘하게 버그가 고쳐진 게 많은데, 이 참에 저 버그도 같이 좀 고쳐졌으면 좋겠다 싶었는데..ㅠㅠㅠ
다행히 ARM64 환경 개발용으로 사용하던 MS 서피스 장비에서도 놀랍게도 똑같은 문제가 발생했다. 그래서 이걸 기준으로 버그를 고쳤다. 만세~! 서피스가 정말 유용하게 쓰이고 있다.
그래픽 알고리즘이나 픽셀 format에 문제가 있는 건 아니었다. 2020년대 이후의 그래픽 드라이버의 동작이 살짝 달라진 듯.. ㄲㄲㄲㄲ 호환성 관련 플래그만 하나 추가하니 저 현상이 사라졌다.

Posted by 사무엘

2026/10/15 08:35 2026/10/15 08:35
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/2472

※ 10.0 (2010)

사용자 삽입 이미지

2008 이후 2010도 참 걸출한 작품이었다.
IDE가 MS Office 엔진이 아닌 WPF 기반으로 다시 만들어졌으며, 프로젝트 파일은 현재처럼 확장자에 x자가 붙고 내부 형식이 미묘하게 달라졌다. IDE와 툴체인 및 SDK 간의 분리가 가능해지고 융통성이 생겼다.
인텔리센스 엔진이 구닥다리 ncb 파일을 버리고, 전문적인 백그라운드 컴파일러와 DB 엔진을 기반으로 전면 개편됐다. 덕분에 정확도가 6.0이나 200x 시절보다 훨씬 더 향상됐다. 그리고 이제 #include 헤더 파일에 대해서도 우클릭해서 '요 파일 열기'가 가능해졌다.

CRT와 MFC DLL에 대해 side-by-side assembly 강제 정책은 철회됐으며... C++11 문법이 초보적인 수준으로나마 도입됐다. R-value 참조자 &&라든가 auto 람다 함수를 쓸 수 있게 됐다.
다만, 내 개인적으로는 시퍼런 IDE 외형이 좀 구리고 이질적으로;; 느껴진다. 그리고 UI 요소를 customize할 때 toolbar의 폭을 마우스 드래그가 아니라 픽셀수 숫자로 입력한다던가(뜨악~);; 몇몇 UI 기능은 200x시절보다 불편해졌다.
그게 오늘날 202x까지 개선 없이 그대로 이어지고 있다. 개발 우선순위가 낮아서 그런지 이런 것까지 살펴볼 여유가 없는가 보다.

※ 2012 (버전 11)

사용자 삽입 이미지

얘는 일단 IDE의 외형이.. 그 시절 유행하던 Windows 8 metro 디자인 물을 먹었는지 아주 새끈한 은백색 풍으로 바뀌었다. 프로그램 창에서 caption이나 border 같은 non-client 영역까지 전부 운영체제의 표준 외형을 벗어난 첫 버전이 바로 2012이다.

개발툴로서는 같은 최적화 세팅에서 컴파일 속도가 2010보다 더 빨라졌고.. 정적 분석이 bundle로 제공되기 시작했다.
신택스 컬러링도 예전보다 더 컬러풀해져서 #define, typedef, num 등이 모두 구분되어 나오기 시작했다.
#if에 걸려서 컴파일되지 않는 부분이 흐려지기 시작한 건 2010부터인지 2012부터인지 모르겠다. 200x는 확실히 아니었음..

그리고 이 버전부터 서비스 팩이라는 게 없어지고 update N 이렇게 명칭이 바뀌었다. 마소 제품들은 2010년을 전후한 Windows 7, Office 2010, Visual Studio 2010이 서비스 팩이란 게 존재했던 마지막 버전이었다.
로컬 하드에 설치 저장되던 방대한 규모의 MSDN 레퍼런스도 이때부터 사실상 없어졌다.

※ 2013 (버전 12)

2012 이후로 겨우 1년 남짓 만에 메이저 버전이 또 올라갔다. 마치 Windows 8과 8.1의 관계인 것 같은데..

얘는 C++11 문법 지원이 더 강화된 것, 그리고 무엇보다 Express 에디션 대신, 개인/인디 개발자를 위한 Community 에디션이 도입된 것이 크게 기억에 남는다.
Community 에디션은 5인 이하, 매출 얼마 이하의 소규모 인디 개발자이기만 하면 무료로 사용 가능하다. Express에서는 봉인돼 있던 MFC고 x64고 다 사용 가능하다. 2010년대의 컴퓨팅 환경에서 MFC는 몰라도 이제 x64 타겟을 만들 수 없다는 건 어불성설이 됐으니까..

뭐, Visual Studio만 그런 건 아니겠지만 요즘 버전들은 시리얼 번호 입력이란 게 없이 바로 설치 가능하다. 그 대신 실행 후에 마소 계정 로그인이 필요해졌을 뿐이다. 선설치, 후접속 결제인 듯..

※ 2015 (버전 14)

얘는 CRT 체계가 Windows 10 스타일로 전면 개편된 것이 가장 중요하다. 이때부터 지금까지 툴체인의 메이저 버전이 14, _MSC_VER 값도 19xx대로 변함없이 유지되고 있기 때문이다. vcruntime140, mfc140, msvcp140 말이다. Visual Studio의 버전만 올라가지, 툴체인은 메이저 버전이 올라가지 않기 시작했다.

그리고 2010 시절에 전면 개편됐던 인텔리센스 겸 심벌 browse DB의 내부 구조도 2015의 어느 업데이트 때부터 야금야금 바뀌었다. 원래 *.sdf 파일을 쓰던 게 *.VC.db 라고 바뀌었으며, DB 엔진도 자기네 Microsoft SQL Server Compact edition을 쓰던 게 SQLite로 교체됐다. 이것도 오늘날까지 이어지는 꽤 중요한 변화이다.
2015 이전 버전은 Visual Studio를 설치하면서 MS SQL server 2008이니 어쩌구가 야금야금 같이 설치됐던 반면, 현재는 그런 관행이 없어졌다.

※ 2017 (버전 15)

사용자 삽입 이미지

얘는 프로그램의 설치 및 업데이트 시스템이 현재 형태로 전면 개편된 최초의 버전이다. 소규모 업데이트도 워낙 잦아지니 지금처럼 버전 번호에 숫자를 하나 더 추가하는 형태로 바꿨다. (그러므로 Update N라는 표기는 2012부터 2015까지만 사용된 셈..)
IDE의 기본 색상도 흰색이 아니라 약간 연보라색 같은 파란색.. 지금과 비슷해졌다. 이렇게 2010년대 전반부 버전과 후반부 버전 사이의 차별화가 진행됐다.

세월이 세월이니 C++14 문법과 라이브러리도 야금야금 도입됐다. 가령, unique_ptr뿐만 아니라 make_unique도 사용할 수 있게 됐다. 일반적인 함수뿐만 아니라 매크로 함수나 람다에다가도 가변인자를 넣을 수 있게 됐다.

※ 2019 (버전 16)

사용자 삽입 이미지

IDE의 색상에 연보라색이 2017보다 더 가미되어 채도가 올라갔다. 2017은 제목 표시줄에 Visual Studio라는 이름이 있었지만 2019부터는 그게 빠지고 최상단에 메뉴가 바로 표시되기 시작했다.
2019의 초창기 버전은 내 기억으로 win32 대화상자 리소스를 편집하던 중에 IDE가 잘 뻗기도 했었다. 여러 업데이트를 거치면서 그 버그는 다행히 고쳐졌다.

아 참, 이 2019 시기에.. 마소의 C++ 라이브러리에 꽤 흥미로운 변화가 생겼다.
Visual C++은 200x 시절부터 전통적으로 Dinkumware 사의 STL을 라이선스 받아 공급해 왔으며, 이 때문에 헤더 파일의 뒷부분에 언제나 P. J. Plauger라는 제작자와 제작사 이름이 들어가 있었다. 그랬는데 마소에서는 2019 하반기부로 이 라이브러리를 오픈소스화하고 자체 관리하기 시작했다. 그러면서 Dinkumware 관련 copyright 문구가 사라졌다.
사실, C++ 라이브러리는 갈수록 언어 구조에 종속적이고 내부 구현도 컴파일러 제조사의 재량에 종속적인 형태로 바뀌어 가는 게 요즘 추세라고 한다.

※ 2022 (버전 17)
IDE 자체가 드디어 64비트로 포팅됐다...!! 이걸로 끝..???

※ 2026
테마가 자매품인 Visual Studio Code 급으로 엄청 다양해지고 휘황찬란해졌다는 것밖에 아직 확인을 못 했다.;;

이상이다.
개인적으로 날개셋 한글 입력기의 개발이나 직장 현업 용도로 진지하게 오래 써 본 버전은 6.0, 2003, 2010, 2012, 2019, 2022 정도이다.

(1) Browse info에 대해

Visual C++은 아주 초창기 시절부터, 빌드 때 겸사겸사 browse info를 같이 생성하는(.sbr, .bsc) 기능이 있었다.
물론 이건 빌드 시간과 디스크 공간을 추가로 소모하는 작업이기 때문에 사용자가 원해서 옵션으로 지정했을 때만 수행한다. 지금도 프로젝트 설정 대화상자를 열어보면 C/C++의 아래에 Browse info라는 카테고리로 당당히 남아있다.

하지만 오늘날은 매번 빌드하지 않고도 IDE에서 소스 코드의 심벌을 실시간으로 조회하는 기술이 눈부시게 발달했다. 그렇기 때문에 이 browse info 기능은 완전히 과거 레거시가 돼서 거의 쓰이지 않는 기능이 됐다. 다만, 업계에서 이 sbr/bsc 파일을 이용해서 다른 분석을 하는 3rd-party 툴 제품이 있기는 하다고 한다.
오늘날은 소스코드를 컴파일하는 과정에서 '덤'으로 할 만한 작업은 정적 분석인 듯하다. 허나, 이젠 그마저도 on-the-fly로 수행돼서 의심 지점을 소스코드의 밑줄로 쫙 쳐서 표시하는 경지에 이르렀다.

(2) 버전 체계에 대해

Visual C++은 버전 관리 체계가 생각보다 복잡하다. 크게 세 가지 버전 시스템이 있다.

- Visual Studio IDE 자체의 버전: Help - About 대화상자에서 볼 수 있는 그 버전이다. 새로운 연도 브랜드가 출시될 때마다 메이저 버전 번호가 1씩 올라간다. 6.0 이후로 2010의 버전은 10이었고, 2015는 14, 2022의 버전은 17까지 올라갔다. 버전 13은 건너뛰었다.

- 툴체인의 버전: 오랫동안 Visual C++ IDE의 버전과 동일하다가(13을 skip한 것까지) 2015 및 Windows 10 때부터 14에서 멈췄다. CRT/MFC DLL의 ABI와도 버전이 연계되는지, 현재는 마이너 버전만 쭉 올라가고 있다. 프로젝트 세팅의 '플랫폼 도구 집합'에 해당한다.

- 컴파일러의 버전: cl.exe를 실행했을 때, 또는 소스 코드에서 _MSC_VER의 값을 넣어서 확인 가능한 버전이다. 얘는 Visual C++의 전신인 Microsoft C/C++의 버전값을 승계했기 때문에 Visual C++ 1.0 시절에 이미 800부터 시작됐다. MS C/C++의 마지막 버전이 7이었고, VC++ 1은 MS C/C++ 8과 같다고 간주됐기 때문이다.
다만, Visual C++ 2에서 4로 넘어갔을 때는 값이 200이 아니라 100만 늘었다. VC++ 6의 컴파일러 버전은 500이 아니라 400이 증가한 1200이었다. (12.0)

그 뒤 IDE의 버전이 14인 2015에서는 800이 아니라 700이 증가한 19.0에 도달했고(13 skip이 없으므로), 이때부터는 툴체인의 버전과 마찬가지로 메이저 버전의 번호가 오르지 않고 있다.

Posted by 사무엘

2026/10/11 08:35 2026/10/11 08:35
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/2471

* 무려 2010년쯤에, 2008 버전이 최신이었던 시절에 썼던 글을 내용을 보강하고 업데이트 하여 다시 올렸다. 심지어 분량이 엄청나게 늘어나서 글을 둘로 나눴다.

※ 1.0

사용자 삽입 이미지
(스샷의 출처는 Malcolm Smith (malxau)이라는 분의 유명 홈페이지)

1993년에 출시된 Visual C++ 1.0은 Microsoft C/C++ 7.0의 차기 버전 겸 Windows NT 전속 개발툴 역할을 하기 시작했다. 이웃 BASIC 팀에서 MS Basic PDS 7의 다음 버전이 Visual Basic이라고 선례를 남겼으니, C/C++ 팀도 비슷한 작명을 도입했던 게 아닌가 싶다. BASIC은 RAD 툴로 바뀌었고 C/C++은 32비트로 갈아탔다.

물론 이때는 16비트에서 32비트로 한창 넘어가는 과도기였기 때문에 Win32s 타겟이 지원되기도 했다. 그리고 Win32s가 아닌 순수 16비트용 에디션도 나중에 출시되기는 했다. (VB 1도 Windows용 이후에 DOS용이 따로 출시됐듯이..) 하지만 VC++ 16비트용은 개발 계보가 32비트 에디션과는 상이했다.

32비트 환경에서는 메모리 모델 구분이 없는 대신, CRT에 링크 방식(static/DLL)과 멀티스레드 지원 여부라는 속성이 새로 도입되었다.
참고로 Visual Basic은 1996년엔가, 버전 4에서야 32비트가 도입됐다는 것도 기억할 점이다. 16/32비트 에디션이 따로 나왔으며, VB5부터는 32비트 전용으로 바뀌었다.

※ 1.52

얘는 16비트 Windows를 정식 지원하는 마지막 버전이어서 매우 중요하다.
프론트 엔드 IDE는 모두 16비트 Windows 프로그램인 반면, 커맨드 라인에서 동작하는 컴파일러, 링커 같은 주요 툴들은 도스 익스텐더 stub을 내장하고 있는 32비트 PE 포맷인 점이 무척 인상적이다.

※ 2.0

이제부터 완전히 32비트 전용으로 바뀌었다. 하지만 이때는 아직 Windows 95가 나오기도 전이고 NT는 인지도와 점유율이 아주 미미했었다. 그래서 VC++ 역시 아직까지는 별 존재감이 없고 주목을 못 받았다. 아직까지는 16비트 Windows에서 볼랜드의 OWL 라이브러리도 쌩쌩히 현역이었다.

Windows 95의 워드패드가 바로 듣보잡 MFC 3.0 기반이었는데, 이게 Visual C++ 2.0의 흔적이다.
그리고 이 시절 Visual C++ RISC edition 어쩌구 하던 건 Windows CE가 아니라 NT를 염두에 둔 타겟이었다. 이건 eMbedded Visual C++과는 다른 제품군이었다.

※ 4.0

사용자 삽입 이미지

DirectX에는 4라는 버전이 없듯, Visual C++에는 3.x대 버전이 없다. 내부적으로 꾸준히 버전업이 돼 온 MFC의 버전 번호에 맞춰 곧바로 4.0으로 건너뛰게 된다.
VC++ 4.0은 Windows NT뿐만 아니라 정통 95용 32비트 프로그램을 만들 수 있다는 이점으로 인해 인지도가 급격히 올라갔다. IE가 넷스케이프를 제쳤듯이 Visual C++이 Borland C++을 제치기 시작했다.

4.0에 와서야 비로소 IDE가 오늘날의 Visual C++과 비슷한 골격이 갖춰졌다. 즉 코딩, 리소스 편집, 클래스 마법사, 도움말 열람을 모두 한 프로그램에서 할 수 있는 진정한 통합 환경 Developer Studio가 이 버전부터 생겼다.
msdev.exe라는 프로그램 이름은 훗날 6.0까지 이어졌다. MFC ClassWizard라든가, ClassView도 이때 도입됐다.

※ 4.2

4.1을 거쳐 4.0이 마이너 업그레이드된 버전으로, 제법 인지도를 얻었다. ActiveX 컨트롤, STL 같은 기능이 추가되고 MFC DLL의 이름도 이때부터 MFC42로 이름이 바뀌어 큰 뼈대의 변경 없이 훗날의 6.0까지 이어졌다. MFC42는 윈도우 98 이래로 운영체제가 이제 known DLL로 인정하는 마지막 버전 숫자이기도 하니 더욱 의미가 있다.

4.2에서부터 Win32s의 지원이 중단되었다. 오죽했으면 설치할 때 “이 버전부터 Win32s를 더 지원하지 않으니, 그 환경 개발하고 싶으면 이거 설치하지 말고 옛날 버전 쓰셈!”이란 경고문까지 나온다.

※ 5.0

사용자 삽입 이미지

얘와 6은 도구모음줄과 메뉴가 MS Office 97 스타일로 바뀌었다. 다만, 5는 도움말은 여전히 RTF 기반이고 인텔리센스도 아직 없었다.
외형뿐만 아니라 내부 기능도.. 한번에 여러 프로젝트들을 담을 수 있는 workspace 개념이 이때 도입됐다. 단, dsw/dsp라는 파일 포맷 자체는 5와 6 두 버전에서만 쓰이고 이후 버전에서는 또 바뀌게 되었다.

몇몇 C++ 최신 표준이 반영되어 bool이 built-in type으로 지원되기 시작했다. 그리고 이때부터 빌드하는 EXE 파일에 PE 재배치 정보가 기본적으로 생략되었으며.. 그 유명한 Rich 시그니처가 슬쩍 들어가기 시작했다.
다만, 이 5.0은 이듬해에 나온 6.0에 밀려 존재감을 완전히 상실했다. 뭔가 아래아한글 97이 나오기 전의 96이 묻혀 버린 것과 비슷하달까?

※ 6.0

개발툴계의 Windows XP 같은 만수장세 결정판이었다. 이 버전 이후로 거의 4년 가까이 버전업이 없었고, 다음 버전인 닷넷이 변화폭이 너무 크기도 했기 때문이다.

6에서는 인텔리센스(초보적인 수준), edit and continue, delay-loaded DLL 같은 획기적인 기능이 처음으로 추가되고 도움말이 별도의 MSDN 라이브러리로 독립함과 동시에 HTML 기반으로 모두 바뀌었다.
이 버전은 윈도우 9x에서 설치 가능한 마지막 버전임과 동시에 MSVCRT, MFC42 같은 known DLL만 사용하는 바이너리를 생성할 수 있는 마지막 버전이기도 하다. 주요 라이브러리를 DLL 링크하고도 DLL 배포 걱정을 할 필요가 전혀 없다는 장점이 있다.

4.2 때는 ClassView에 있는 각종 클래스, 변수 정보가 소스 파일을 매번 저장할 때에만 업데이트됐다. 이것이 내용이 바뀔 때마다 실시간으로 바뀌기 시작한 것도 5.0은 아니고 6.0부터인 걸로 기억한다.
Visual C++이 C++ 표준을 준수하지 않는다고 비판이 많긴 했지만, 라이브러리의 헤더 파일에서 .h 확장자가 없어지고 namespace std가 도입된 건 6.0부터였지 싶다.

※ 7.1 (2003)

사용자 삽입 이미지

Visual C++의 다음 버전은 처음엔, 버전 번호나 연도가 아닌 닷넷이라는 브랜드로 출시되었다.
MFC를 써서 개발된 VC 특유의 전통적인 msdev.exe는 퇴출되고 devenv라는 MS Office 내지 VB 스타일의 IDE가 등장했됐다. 이는 완전히 새로운 것이라기보다는 예전에 Visual Studio에 있던 Visual InterDev와 비슷한 형태였다. 단지 거기에다 외형만 MS 오피스 XP 스타일 UI를 그대로 물려받았다.

덕분에 Visual C++과는 영 인연이 없고 VB만의 전유물인 것 같던 Property grid가 도입되어 Visual C++ IDE 특유의 납작한 등록정보 대화상자를 대체했다. 클래스 마법사도 이 형태로 대체됐다. 도움말은 5.0 시절처럼 IDE 내부에 띄울 수도 있고 6.0처럼 외부에 띄울 수도 있는 융통성 있는 형태로 바뀌었다.
dsw/dsp 대신, sln(솔루션)과 vcproj 요렇게 프로젝트 파일의 확장자와 포맷이 바뀌었다.

이제 주류로 내세운 게 C#, 공용 언어 런타임 같은 닷넷 환경이긴 했지만 네이티브 C/C++ 쪽도 크게 향상되었다. 네이티브 wchar_t 형식이 지원되기 시작했다.
6에서 첫 도입됐던 인텔리센스도 굉장히 강력해져 특히 #define 매크로 심볼에 대해서도 동작하기 시작했다. 별도의 browse info를 만들지 않아도 선언/정의로 가기 기능을 바로 사용할 수도 있게 됐다. 닷넷 정도만 써 보면 이제 6.0은 충분히 열악함을 느끼기에 충분할 것이다.

64비트 크로스컴파일은 불가능하지는 않으나 불편하고 디버깅도 되지 않고 IDE 차원의 적극적인 보조는 못 받는 어정쩡한 위상을 차지하고 있다. 이 불완전한 면모들은 후속 버전인 8에서 보완되었다.

참고로.. 2003 이전, 2002년에 Visual Studio .NET이라는 이름으로 먼저 출시된 버전 7.0은 정말 놀라울 정도로 존재감 없이 신속히 잊혀졌다.
글쎄, 6.0 이후로 오랫동안 버전업이 없다가 닷넷과 CLR이라는 걸 도입한 첫 버전이니 너무 불안정하고 버그가 많았던 걸까? 저 제품에 대해서는 내가 아는 게 없다. 금세 .NET 2003 (7.1)으로 대체됐다.

※ 8.0 (2005)

얘도 생각해 보니 변화가 굉장히 많았다.
for 문의 변수 scope처럼 그동안 Visual C++ 컴파일러가 표준을 어기고 있던 문법을 교정했으며.. 멀티코어를 표방했는지 빌드 로그에 코어 번호가 왼쪽에 표시되기 시작했다.
CRT의 보안이 이때 크게 강화됐다. strcpy_s와 gets_s(대상 버퍼 크기), qsort_s(콜백 함수에 데이터 전달 가능), strtok_s(토큰 중복 호출 가능) 같은 함수가 새롭게 등장하고 strchr 같은 경우, C++에서는 const 포인터를 되돌리는 버전과 비const 포인터를 되돌리는 함수가 오버로딩으로 분리해 나갔다. 무척 신선한 변화라 느껴진다. STL 디버깅도 훨씬 더 편해졌다.

이 버전부터 별도의 플랫폼 SDK를 설치할 필요 없이 IDE 차원에서 x64 타겟 빌드와 디버깅이 정식 지원되기 시작했다.
그리고 이때 MSVCR80, MFC80의 배포 방식이 side-by-side assembly 방식으로 완전히 바뀌었다. 이와 덩달아, 리소스 편집기로 수동으로 해야 하던 메니페스트 생성/편집 기능도 상당 부분 자동화됐다.
이 버전부터는 생성하는 프로젝트의 디폴트 기반 인코딩이 드디어 유니코드로 바뀌었다.

UI 상으로도 이제 MS 오피스 스타일에서 독립한 새로운 외형 비주얼을 갖기 시작했으며, 도구모음줄 아이콘도 256색으로 더 화려해졌다. 전통적으로 ClassView에 클래스와 멤버들이 한 트리에 쫙 나열되던 것이 멤버는 별도의 리스트에 뜨도록 바뀌기도 했다. 도킹 창을 드래그할 때 나타나는 도킹 다이아몬드도 2005에서 첫 도입된 물건이다.
Visual Studio의 무료 에디션인 Express 에디션이 이때 첫 도입됐다. (무료이지만 MFC 없고 64비트 타겟도 미지원)

※ 9.0 (2008)

8이 질적으로 많이 바뀌었다면 9는 Windows Vista의 등장처럼 8 출시 이후에 생긴 변화를 IDE나 MFC 라이브러리 같은 데에 적극 반영하여 양적인 향상을 꾀했다. 일단 MS Office 스타일의 GUI를 손쉽게 만들 수 있는 feature pack을 MFC에 드디어 도입했다.
그리고 2005는 설치하려면 sp1에, Vista 지원 패치.. 등 덕지덕지 땜빵을 해야 할 게 많았는데 2008은 그걸 당연히 모두 기본 접수했다.

Windows Vista에서 도입된 시작 주소 랜덤화 기능이 요 2008에서 정식 추가됐다. 2008에서는 이 보안 기능을 사용하는 EXE를 만들 수 있다는 뜻이다.
10여 년 전, 5.0에서 누락되기 시작한 EXE의 재배치 정보가 2008부터는 기본적으로 다시 들어가기 시작했다. 옛날에는 fixed address를 지원하지 않는 win32s와의 호환 때문에 그게 필요했었지만, 지금은 보안 기능 때문에 필요해진 것이다.

2008은 설치하기 위해 Windows XP 이상을 요구하며(2000 지원 중단), 지원하는 타겟 플랫폼에서도 Windows 9x는 공식적으로 완전히 제외됐다. 링커 옵션에서 바이너리의 최소 요구 운영체제 버전이 4에서 5로 껑충 뛰었고, 이보다 낮은 값은 지정 자체가 안 된다.
또한 single threaded CRT 라이브러리 옵션도 없어졌다. C 라이브러리는 이제부터 무조건 multi threaded이다.

Posted by 사무엘

2026/10/07 19:35 2026/10/07 19:35
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/2470

1. 클래식 16비트 DOS 기반 Windows: x86 하에서 여러 모드 존재

초창기 16비트 Windows는 DOS로 부팅된 컴퓨터에서 추가로 실행되던 운영환경 프로그램이었다. 자신만의 하드웨어 인식 모델, 자신만의 API, 자신만의 실행 파일 포맷이 있었지만 자체적으로 컴퓨터를 부팅시킬 능력은 없었다.
그 MS-DOS가 x86 전용이었으니 Windows도 자연스럽게 x86 전용으로 출발했다. 그 대신 그때는 x86 계열 CPU 자체가 시시각각 성장하고 변모하고 있었던지라, Windows도 그에 맞춰 다양한 실행 모드를 지원했다.

8086 real mode, 80286 standard 모드, 그리고 80386 enhanced 모드.
1.0이야 당연히 8086 real에서 시작했다. 주 메모리 최대 640KB밖에 지원을 못하는 초 열악 모드.
그러다가 Windows 2.x 시절에는 Windows/286, Windows/386 에디션이 추가로 도입됐는데.. 이거 마치 옛날에 아래아한글이 1.x 시절에 도트 프린터 에디션, 레이저 프린터 에디션을 세분화했던 것과 비슷한 느낌이 든다.;;; (폰트)

그러다가 Windows 3.0에서는 한 프로그램에서 세 에디션이 모두 같이 제공되기 시작했다.
286 표준 모드에서는 80286에서 추가된 보호 모드를 활용하여, 컴터의 메모리를 더 많이(최대 24비트, 16MB) 끌어다 쓸 수 있었다. 그리고 도스창을 연 상태에서도 백그라운드에서 딴 프로그램과의 멀티태스킹이 가능해졌다.
386 확장 모드에서는 그에 덧붙여 가상 메모리(스왑 파일 페이징)까지 더 끌어다 쓰고, 도스창을 여러 개 동시에 만들 수도 있게 됐다.

즉, Windows 3.x의 386 확장 모드는 여전히 16비트 코드 기반이지만 80386 CPU의 기능을 일부 활용했던 모드였다.
여기에다가 Win32s가 도입되고 커널이 통째로 Windows 9x로 바뀐 과정은 참 드라마틱하게 그지없다. DOS는 Windows를 띄워 주는 하부 인프라가 아니라, Windows 안에서 돌아가는 샌드박스로 위상이 바뀌었다.
수많은 DOS용 프로그램과의 호환성을 최대한 유지하면서, 또 저사양 똥컴에서의 성능도 최대한 살리면서 DOS를 도태시키는 길은 멀고도 험난했다;;

2. 1990년대 Windows NT: x86 + MIPS, Alpha, PowerPC

저런 클래식 Windows와 달리, Windows NT는 DOS와는 완전히 동떨어진 별세계 신세계 이상향을 추구했다.
x86은 지원하는 여러 CPU 중 하나일 뿐이며, 처음부터 100% 32비트 기반으로 동작했다. 지저분한 DOS나 16비트 호환성 따위는 우선적으로 고려하지 않았다.
실행 파일 포맷도 Portable Executable이라고 새로 제정하고.. 노는 물이 정말 완전히 달랐다.

Windows NT는 초창기에 x86뿐만 아니라 MIPS와 DEC Alpha를 추가로 지원해서 UNIX 일색이던 워크스테이션 시장에 도전장을 내밀었다. 원래 제일 처음 계획은 인텔 i860을 지원하는 것이었으나, 이건 모종의 사정으로 인해 이뤄지지 못했다.
NT 3.51부터 4.0 sp2까지 잠깐 동안은 PowerPC까지 추가로 지원했다. 그 당시 매킨토시가 돌아가던 그 CPU가 맞다. 물론 PC와 맥은 CPU 말고도 컴퓨터 하드웨어 규격이 매우 달랐기 때문에, 저런다고 맥에서 Windows NT PPC 에디션을 돌릴 수는 없었다.

Windows가 x86과는 특성이 상극인 RISC 구조에, 심지어 big endian인 CPU에서도 이식되어 돌아간 적이 있었다니.. 지금으로서는 참 믿어지지 않는다.
Windows NT의 개발 본진은 DEC Alpha에 가까웠다. 심지어 Alpha는 64비트 CPU이기도 했으나.. NT 3~4는 그냥 32비트 ABI를 그대로 사용했다. 이 Alpha의 후대 버전은 Windows가 진짜 64비트로 포팅되던 시절에 테스트 장비로도 쓰였다고 한다.

물론 이상향을 추구한 것에는 댓가가 따랐다. 1993~95년 사이, 어지간한 가정용 컴퓨터들이 램이 2MB~8MB 이러던 시절에 NT는 이미 12~16MB 이상을 요구했다. 그것도 한글 한자 지원 없이 오리지날 영문판이 말이다.
그 시절엔 CPU와 메모리 가격이 지금으로서는 상상하기 어려울 정도로 희귀하고 비쌌었다. 이러니 NT는 초창기엔 가정용 PC 생태계에서 도저히 발을 들일 수 없었다.

마소에서 개발하던 프로그래밍 언어/개발툴 중에 BASIC은 RAD로 지향점이 바뀌면서 Visual이라는 브랜드가 먼저 붙었다. (1991년) 그 반면, MS C는 7.0 버전에서 C++ 지원이 추가되면서 C/C++이 됐고, 그 다음 Windows NT용 32비트 타겟 빌드가 추가되면서 Visual C++ 1.0으로 다시 태어났다. 거기에다 IDE도 Programmer's workbench라고 언어 공용이던 게 Windows용 자체 에디터로 덤으로 바뀌었으니 겸사겸사 Visual이라는 단어를 붙인 듯하다.

이때는 크로스 컴파일이라는 개념이 약했는지 VC++이 x86용, MIPS용, Alpha용, PowerPC 용으로 제각기 따로 출시됐다.
아~ 그래서.. 개인적으로는 VC++ 4 시절에 PowerPC 타겟 흔적을 많이 봤던 것 같다. 그건 Windows NT를 염두에 둔 기능이지, CE용이 아니었다. 나중에 VC++ 6 IDE를 기반으로 출시됐던 eMbedded Visual C++와는 다른 제품군이었다.

3. Windows 2000: x86 단일 황금기

그 뒤.. 세기말이 되자 Windows 2000이라는 걸출한 제품이 Windows NT 5.0을 표방하며 출시됐다. 얘는 연도 숫자로나, 기술 계보로나 정말 너무 절묘한 교차점에 놓였다.
NT는 전통적으로 OpenGL이 있을지언정 DirectX 따위는 없던 운영체제였다. 그러나 2000은 일단 표면적으로는 NT 계열과 9x 계열의 통합을 추구했다. 그래서 DirectX라든가 plug & play, USB처럼 9x에 먼저 들어갔던 기능들을 대거 수용했다.

이제는 가정용 컴터들도 많이 빨라지고 램 용량도 크게 늘어서 NT 커널을 돌릴 수 있다고 여겨졌기 때문이다. 둘을 통합할 때가.. 아니, 구닥다리 DOS와 9x 커널을 퇴출시킬 때가 됐다.
이 참에, NT 구버전이 지원하던 타 CPU들은 미래가 없다고 여겨져서 때문에 지원을 끊었다. 그 대신 마소에서는 인텔의 새 밀레니엄 64비트 CPU로 여겨지던 Itanium을 지원하겠다고 벼르고 있었는데.. 이게 사실상 베이퍼웨어 나가리로 끝나 버렸다.

이런 이유로 인해 Windows 2000은 NT 계열임에도 불구하고 마치 9x처럼 사실상 x86 전용 운영체제로 출시됐다. 그리고 2000년대 초, 2000과 그 다음 XP 시기가 어찌 보면 32비트 x86의 황금기였다.
램은 128~256MB대.. 주소 공간이 부족하지 않고 32비트로 적당히 커버 가능해서 정수도 4바이트, 포인터도 4바이트.. 딱딱 절묘하게 떨어졌기 때문이다.
컴퓨터 클럭 속도는 기하급수적으로 증가하던 무어의 법칙의 끝물 상태였고, CPU도 x86 only에 가까운 상황.. 얼마나 깔끔하냐? 그 와중에 구닥다리 9x는 역사 속으로 사라져 가고.. 모든 게 파편화 없이 한데 집중됐었다. 새천년에 말이다.

4. 2000년대: Itanium과 x64의 명암

Windows의 역사상 어떤 형태로든 64비트 ABI라는 게 등장한 게 저 1990년대 중후반, Itanium 포팅을 할 때였다. PE 실행 파일의 포맷을 확장하고, 플랫폼 SDK에 INT_PTR이라든가 GetWindowLongPtr 이런 게 등장한 게 그 때라는 뜻이다.

하지만 IA64라고 불리는 Itanium은 처절한 실패로 끝났고, 21세기 초부터는 x64라는 x86 호환 CPU가 64비트 PC 시대를 주도하기 시작했다. 얼리어답터 컴덕이 아닌 일반인들은 컴퓨터 램의 용량이 실질적으로 4GB를 넘어선 2000년대 중후반, Windows Vista나 7쯤부터 64비트를 체감한 듯하다.

Windows는 일반인 클라이언트 제품군에서는 XP에서 딱 한 번 IA64를 지원하고는 학을 뗐다.
서버 제품군에서는 Vista에 대응하는 Server 2008까지 IA64를 조금 더 지원했고, 그 다음부터 지원을 끊었다.
그 대신 서버 제품군은 32비트 x86 전용 에디션을 클라보다 훨씬 일찍 끊었다.

클라에서는 Windows 10까지만 해도 x86 전용 에디션도 출시해 오다가 2020년대 11에 와서야 중단했다.
그러나 서버에서는 IA64를 약간 더 오래 지원한 대신, 그 Server 2008부터 x86을 끊고 x64로 완전히 갈아탔다. 클라와 서버의 컴퓨터 특성이 서로 다르기 때문일 것이다.
개발툴인 Visual C++은 2005부터 x64로 크로스 컴파일을 정식 지원하기 시작했다.

5. 2010년대 말: ARM64의 추가 도입

그 뒤, 마소는 2010년대 중반엔 경영진이 싹 바뀌었다. 새 경영진은 기존 CE나 폰/모바일 제품군을 포기하고 정리했다. Android/iOS와의 경쟁에서는 승산이 전혀 없다는 결론을 내렸으며, Windows 8 시절 같은 삽질은 더 하지 않기로 했다.
그 대신 Windows on ARM이라 해서 데스크톱용 기존 운영체제를 ARM64로 그대로 포팅해서 오늘에 이르고 있다.

너무 자명한 얘기지만, ARM64는 클라 제품군 한정이다. 서버 제품군을 그렇게 포팅하지는 않는다.
얘는 마소에서 ARM64EC니, ARM64X니 하는 온갖 하이브리드 규격도 만들어서 x64와 최대한 같이 포용하려 애쓰는 중이다.
예전의 Itanium처럼 호환성 없는 별개 취급을 하지 않고 있다.

2010년대 초, Windows RT 시절에 잠깐 나돌았던 ARM32는.. 2000년대 초 IA64와는 좀 다른 의미로 낙동강 오리알로 전락하고 역사 속으로 사라졌다. 한쪽이 64비트 삽질이었다면 다른 쪽은 모바일 삽질이라 하겠다.

이상이다.
한때는 온갖 CPU들이 난립하다가 x86으로 천하통일 되는 것 같았는데.. 지금은 그 뒤에 x64와 ARM64가 올라타서 상황이 좀 더 복잡해졌다. 날개셋 한글 입력기 작업을 하다가 이 이야기를 하고 싶어서 이렇게 글을 써 보았다.

한때, 1990년대부터 2000년대 초까지는 (1) 컴퓨터의 단일 코어 속도가 크게 증가했었다..
그 다음으로 1990년대 중후반부터는 (2) RAM이건 디스크건 메모리가 용량이 크게 증가하고 가격이 싸졌다. 이때쯤부터 C드라이브 디렉터리와 파일 구조를 DOS 시절처럼 몽땅 한데 조회하는 게 거의 무의미해지고 불가능해졌다.
끝으로, 2000년대부터는 (3) 인터넷 속도가 급격히 빨라지고 심지어 무선화까지 됐다.

이런 기술이 발달하고 저렴하게 널리 보급된 덕분에 일반 사용자들도 과거에 상상도 할 수 없었던 방대한 규모의 소프트웨어를 컴퓨터로 아무렇지 않게 돌릴 수 있게 됐다.

* 덧붙임: Windows CE

1990년대 중반, 가정용 PC에서는 Windows 95가 이제 막 정착했고 NT는 아직 별나라이던 시절에.. 마소에서는 PC보다 작은 기기에다가도 win32 API를 심어서 Windows 생태계를 가꿀 생각을 했다. 이름하여 Windows CE라는 게 이때 태동했다.

CE가 지원했던 CPU 중에는 NT에서 지원했던 MIPS, PowerPC 같은 것도 있었고 심지어 ARM32에다 x86도 있었다.
하지만 컴퓨터에 오로지 CPU만이 구성요소의 전부인 게 아니고, CE는 근본적으로 ‘임베디드’ 환경을 추구했다. CPU의 특성이나 메모리, 파일 시스템, 비디오, 소프트웨어 환경 등이 범용 컴퓨터와는 완전히 딴판이다. 그렇기 때문에 일반적인 Windows 프로그램을 돌리지는 못한다.

Windows CE용 프로그램을 개발하는 환경은 기존 Visual C++에다가 해당 플랫폼용 툴키트를 구매해서 추가로 설치하는 형태로 세팅했다. 2000년대 초에는 eMbedded Visual C++라고 IDE가 통째로 새로 나오기도 했었으나.. 그건 얼마 못 가 단종됐다.

Windows 9x가 21세기로 진입하지 못하고 세기말에 맥이 끊겼다면.. CE는 2010년 초쯤에 명맥이 끊겼다.
CE 커널은 9x와 달리 wide char로 대표되는 유니코드 버프는 당연히 받은 채로 시작했다. 하지만 2000년대 말의 트렌드이던 64비트 환경으로 포팅되지는 못했다. 동작 환경의 특성상, Itanium이나 DEC Alpha와도 접점이 당연히 없었다.

그 대신, 마소에서는 CE 커널을 스마트폰에다 얹을 생각을 했다. CE 커널이 한때는 PDA에도 쓰였으니 이는 자연스러운 귀결이었다. 그래서 통상적인 임베디드용 CE는 Windows Embedded Compact라는 이름으로 제품을 유지하고, CE를 기반으로 Windows Mobile을 만들고 나중엔 이름을 Windows Phone으로 대놓고 바꿨다.

나중에 마소는 Windows Phone을 CE가 아니라 NT 커널을 기반으로 다시 만드는 무리수까지 둬 봤지만.. 안드로이드나 iOS 같은 신흥 모바일 강자를 꺾을 수는 없었고 실패했다.
이런 사건을 거쳐 오늘날, 2020년대 기준으로 CE는 원래의 나와바리이던 임베디드 제품들의 유지보수 이상으로 신규 개발은 끝나고 성장이 멈춘 플랫폼이 됐다. 시장이 특수하기 때문에 무슨 Windows 9x가 사라진 것처럼 사라지지는 않겠지만.. 그야말로 고인물로 전락한 셈이다.

Posted by 사무엘

2026/10/03 08:35 2026/10/03 08:35
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/2469


블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2026/10   »
일 월 화 수 목 금 토
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

Site Stats

Total hits:
4160021
Today:
1410
Yesterday:
3370