지금은 오나전 아련한 추억이 됐죠. ㄱ-

1. 포트 충돌이 일어나면 모뎀과 마우스를 동시에 못 쓰던 것. ㄲㄲㄲㄲㄲㄲㄲㄲ
(시스템 종료 후 컴이 자동으로 꺼지기 시작,
마우스 휠과 USB 포트, 키보드와 마우스 단자가 PS 포트로 변경...
한 97~99년을 전후해서 다 그렇게 바뀐 것 같더군요.)

2. 도스를 완전히 못 벗어난 윈도우 9x 특유의 블루 데드 스크린과
64KB 리소스 제약..
이건 지구상의 어떤 운영체제에도 없던 이상한 제약이 아니었나 싶습니다.
16비트에서는 도스, 아니면 풀 32비트에서 유닉스, OS/2급의 빵빵한 운영체제 이런 구도였지, 둘을 저렇게 짬뽕한 OS는 윈도우 9x 부류가 유일했으니까요. MS가 고객 수요에 맞춰 장사를 정말 잘 한 것입니다.

3. 물론 이건 운영체제라기보단 드라이버 탓이 더 크겠지만
윈도우 98 시절까지만 해도 멀티웨이브 안 되던 컴도 많았어요. -_-;;
사운드 카드가 동시에 한 프로그램밖에 쓸 수 없는 자원이었던 캐암울한 시절도 있었습니다. ㄱ-

윈도우 2000/ME로 넘어오면서부터

- 소프트웨어 시뮬만으로 미디 신시사이저 지원
- 멀티웨이브 본격 지원
- 메모리 스틱, 외장하드 등 어지간한 USB 기억장치를 자동 인식. "이 장치를 안전하게 제거" 메뉴 자체가 생김 (98 SE는 아직 그런 거 없음.)

꽤 많은 변화가 생겼던 것 같습니다. 과거의 제약이 차츰 사라졌죠.
윈도우 ME는 비록 악명은 높지만 최신 하드웨어 인식 잘 하는 건 98보다 뛰어나다는 걸 확실히 인정함.

그리고 마우스 포인터.
제 기억이 맞다면, 아마 윈도우 2000은 VGA 640*480 16 컬러에서 돌아갈 때도 마우스 포인터가 그래픽이 바뀌는 곳에서 깜빡거리지 않을 거에요. 그거 보고 무척 놀랐던 기억이 납니다.
XP부터는 이제 안전 모드에서도 VGA 16컬러는 볼 일이 없어졌고... ㄱ-

하드웨어 지원을 받아서 마우스 포인터가 깜빡거리는 게 없어진 것이 한 90년대 중반부터인데, 이때도 지원이 완전하지는 못해서 흑백 monochrome 기본 커서가 아닌 커스텀 포인터는 여전히 깜빡거리기도 했었습니다.

CD롬 부팅 후 곧바로 운영체제 설치가 가능해진 것도 2000부터이죠?
NT에 그런 기능 있었을 리는 없고,
9x 계열에도 그런 거 없습니다. 그래서 vmware에서 세팅할 때도 먼저 도스 + fdisk 파티션부터 만들어야 합니다.

Posted by 사무엘

2010/01/10 23:21 2010/01/10 23:21
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/34

윈도우 운영체제가 NT 초창기 시절 이래로 지금까지 사용해 오고 있는 실행 파일 포맷은 잘 알다시피 portable executable 형식입니다. 헤더도 이니셜인 PE로 시작합니다. 물론 네이티브 EXE이기 때문에 코드 부분은 기계마다 다르겠지만, 헤더 구조체라든가 리소스 같은 공통된 부분은 최대한 일치시켜서 이식성을 고려해서 설계했다는 뜻이지요.

늘 인텔 CPU에서만 돌아가는 EXE만 보다가 MIPS 같은 RISC CPU에서 돌아가는 PE 실행 파일을 헥사 에디터로 들여다보니 진짜로 기계어 코드가 한눈에 보기에도 일정 바이트 간격으로 아주 균일하게 나열돼 있더군요. 그걸 보고 놀랐던 기억이 납니다.

64비트 PE도 일부 구조체만 64비트로 확장되었을 뿐 기본적인 골격은 초창기 32비트 PE와 같습니다. 더구나 윈도우 운영체제가 인식하는 리소스(스트링 테이블, 대화상자, 메뉴 등)의 포맷은 매우 다행스럽게도 32비트 PE와 완전히 일치합니다.

EXE와 DLL은 자신만의 프로세스 공간을 만들어서 단독 실행이 가능하냐의 차이가 존재하는데, 기술적으로는 헤더의 비트 몇 군데만 다르지 똑 같은 PE 바이너리입니다. 이런 바이너리를 ‘모듈’이라고 부릅니다.

c, cpp 같은 소스 코드를 컴파일하면 기계어 코드인 obj 파일이 생깁니다. 이런 obj 파일과 lib를 링크하면 그런 모듈 파일이 결과물로 생성됩니다. lib는 또다른 obj의 묶음일 뿐 obj와 완전히 다른 파일이 아닙니다. 또한 모듈 역시 그런 obj, lib에 들어있는 코드를 PE 규격에 맞게 재배치하고 묶은 파일일 뿐이지 원시 파일과 그렇게 큰 차이가 없습니다.

윈도우 운영체제에서 개발 환경을 만든 사람들의 생각은, 링커가 특별히 할 일이 없게 하는 것이었던 것 같습니다. 물론 요즘은 전역 최적화처럼 링크 타임에도 코드를 생성하는 기술도 도입되어 사정이 그렇게 간단하지만은 않게 됐지요.

PE는 text(실행되는 기계어 코드), rdata(스트링 리터럴처럼 읽기전용 상수나 초기화 값), rsrc(윈도우 리소스 데이터), DLL 심볼 import/export 테이블, reloc(재배치 정보) 등 여러 섹션으로 나뉩니다. 특히 재배치 정보는 Win32s 시절에는 exe에도 필요했지만 지금은 dll에만 넣어 주면 됩니다.

PE의 헤더에는 자신의 기본 어드레스, 자신이 돌아가는 데 필요한 최소한의 운영체제 버전 같은 여러 정보가 들어가고 심지어 자신을 빌드한 링커의 버전을 기입하는 공간도 있습니다. 가령 비주얼 C++로 빌드하면 6.0, 7.1 (닷넷 2003), 8.0 (2005) 같은 번호를 쉽게 식별할 수 있지요.

원래 MS 자체에서 만든 프로그램 바이너리들의 링커 버전은 비주얼 C++의 버전과 거의 일치하지 않았습니다.
가령 윈도우 95는 까마득한 2.5, 그리고 98/ME는 3.1, 윈도우 2000은 5.12, 오피스 XP는 6.2였습니다. 비주얼 C++과는 별도로 자신들만 쓰는 컴파일러/링커가 있었던 것 같습니다.

하지만 이것이 언제부턴가, 한 02~03년부터 버전이 일치하기 시작했습니다. MS에서도 내부적으로 비주얼 스튜디오를 쓰기라도 했는지?
윈도우 XP는 7.0으로 당대의 최신 비주얼 C++이던 닷넷 2002와 일치합니다.
그리고 XP sp2 (sp1은 모르겠음)와 오피스 2003은 비주얼 C++ 닷넷 2003의 버전과 같은 7.1입니다.

그 후 윈도우 비스타와 오피스 2007의 모든 바이너리들은 비주얼 C++ 2005의 버전인 8.0으로 물갈이되어 있습니다. 하지만 CRT 라이브러리는 살짝 다릅니다. 오피스는 msvcr80을 쓰지만 운영체제는 자신만의 msvcrt를 고수하고 있습니다. 하지만 이제는 msvcrt에도 비주얼 C++ 2005에서 새로 추가된 strcpy_s 같은 보안 강화 함수들이 추가되어 있습니다.

msvcrt는 이제 운영체제가 혼자 마음대로 바꿔 쓰는 CRT DLL로 격리시키고 응용 프로그램들은 이제 msvcr??을 알아서 배포해서 쓰든가, 싫으면 스테틱 링크하라는 구도가 된 셈입니다.

Posted by 사무엘

2010/01/10 23:17 2010/01/10 23:17
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/31

« Previous : 1 : ... 14 : 15 : 16 : 17 : 18 : Next »

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2019/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:
1267021
Today:
154
Yesterday:
552