흠... 이제 대등한 조건에서 윈도우플래폼과 OSX플래폼의 포토샵 성능의
비교가 가능 하겠네요...  ^^  둘아 인텔 프로세스를 사용하므로 하드웨어의 차이는 별로 없는 상황이므로...

그런데... OSX이전의 맥의 운영 환경은 보잘것 없는지 모르지만...
윈도우의 상황은 다소 다를것 같습니다.

윈도우95출시이후~OSX출시이전의 상황을 회상 한다면...

  모두다 코코아로 다시 만들어진게 맞는지 궁금하더군요
포토샵과 에펙, 프리미어는 네이티브 64비트라고 소개되어 있던데
나머지는 어찌된건지 설명이 없더군요
플래시, 드림위버, 인디자인 같은 툴은 슬쩍 그대로 가져가는게 아닐찌

  윈도 95도 좋은 운영체제라고 하기는 어렵다고 봅니다.
본 글에도 잠깐 언급했다시피 어도비에서 프레임웍을 새로 만들었을 정도로 형편없는 운영체제로 기억됩니다. 특히 안정성은 "최소한 5분에 한번 씩 백업하십시요."라고 얘기해주었을 정도로 형편없었습니다. 이는 마치 한/글이 자신의 프레임웍을 만들어 개발했던 것과 같습니다. 윈도 98이 되어서야 겨우 쓸만한 운영체제가 되었고 XP가 나오고서야 완전히 자리 잡았다고 보는 것이 정확하지 않을까 싶습니다.
윈도 98과 OS 9의 안정성을 비교한다면 비슷한 수준이었지만 당시 맥의 가격에 비해 윈도 머신의 가격이 많이 저렴했기 때문에 주머니가 가난한 학생들부터 서서히 윈도용 포토샵이 쓰이기 시작하기는 했지만, XP 후에야 본격적으로 전환이 이루어졌다고 보는 것이 정확하지 않을까요?

  윈도우95는 적어도 클래식 OS보다는 진보된 OS였습니다.

안정성의 문제가 초창기에 특히 두드러 졌음은 사실입니다.
윈도우 95 OSR2 쯤에야 어느정도 안정화 된것은 사실입니다.

그런데.. 인터페이스 방식은 윈95나 윈도우7이나 비슷 합니다.

  뭔가 야리꾸리한 에러가 많았지만, 선점형 멀티태스킹을 지원하는 데스크탑 OS였죠.. 기존에 선점형 멀티태스킹을 지원하는 데시크탑 OS로는 MS와 IBM의 합작품인 OS/2밖에 없었는데, MS의 배신으로 OS/2가 망했죠..

  윈도는 XP 시절에 들어와서도 안정적이지 못했습니다. 특히 보안 부분에서.
모를수록 편하고 알수록 피곤한 OS였다고 생각되네요.
모르면 아는사람 시켜서 재설치 하면 되고, 알면 남의 pc 관리까지... 해야될게 너무 많았지요.
앞으로 남의 윈도 고쳐주면 해당 사람에게 수리비와 MS에 사무관리비 청구하세요.

  흠,.... 매킨토시 운영 환경에 입문하면서 KMUG 에 자주 오게 되는데...
아범 기종이나 윈도우에 대한 터무니 없는 편견이 존재하는 것을
알게 되네요...


예전의 윈도우95 시절을 떠올려 본다면...
NT커널 보다는 덜안정적인 것은 사실이지만.. 별 문제는 없었습니다.

단... 아주 싸구려 메인보드에 비짜램 .. 그리고 윈도우용 드라이브가 없어서
config.sys나 autoexec.bat에 도스용 드라이브를 올려서 사용해야 하는
철지난 하드웨어 사용자가 아닌 경우.... (이경우는 윈도우가 도스 호환모드로
돌아가므로 당연히 불안정해집니다.  인텔 씨피유의 경우 리얼모드와
프로텍티드 모드는 공존할수 없는데... 도스용 드라이브는 리얼모드
드라이브 이고 윈도우95는 프로텍티드 모드 운영 체계이기 때문에...
끊임없이 리얼모드와 프로텍티드 모드를 왔다 갔다 해야 하는 상황이
발생 하게 됩니다.    윈도우용 드라이브가 지원 되는 하드웨어라면...
프로그램 드라이브도 프로텍티드 모드용 드라이브를 사용하므로 이러한
문제점은 없었습니다. )

그리고
윈도우 XP의 안정성은 보안과 별개의 사안입니다.
OS는 비교적 안정적입니다.  단. 액티브X같은 것 때문에 보안에 취약한
점은 사실입니다. 

  제 생각엔 CS5가 비록 코코아를 이용하였다고 해도 오랜 기간동안 일관되게 개발하고 버전업 해온 Windows용 만큼의 최적화가 되어 있지는 않을 것 같습니다.
어쩌면 Windows용과 다른, 상대적으로 더 많은 버그나 문제점들도 나타날 수 있습니다. 또 개발하면서 일정부분 C/C++코드를 단순히 코코아로 감싸서 만들었을 수도 있고 상대적으로 GPU를 잘 이용 못할 수도 있을 것 같습니다.

그리고 Windows는 95 osr2 부터는 꽤 괜찮아지기(비록 DOS의 잔제가 여전히 남아있었지만 전버전에 비하면..) 시작했던 것 같습니다.

  무얼 보셨는지는 모르겠으나 윈도우 API를 공개하지 않았다는건 사실과 다르군요. 맥보다는 훨씬 raw level까지 컨트롤 가능합니다. 그래서 프로그래밍이 어렵긴 합니다만...CS4까지는 시스템 9까지밖에 지원하지 않았다는것도 구체적으로 무슨뜻인지 모르겠고...카본과 코코아를 말씀하시는건지 일단 팩트자체에 논란의 여지가많은 글이군요.

  전 윈도95가 나오던 시절 맥을 써보지 못해서 맥의 안정성을 윈도95와 논하지는 못하겠습니다.
단지 맥의 가격이 거의 손대기 힘든 상황이었던 기억만 납니다. 당시에 그렇게 고가이던 맥이 그래도 사용되었던 것은 순전히 윈도95의 불안정성에 기인합니다.

초기 윈도95는 그냥 아무 것도 설치하지 않은 상태에서도 파란 화면이 떳었습니다. 게다가 한글윈도 95는 정말 극악이었지요. OSR 2부터 꽤 괜찮아졌다고는 해도 어플 몇 개 설치하면 파란 화면과 만나야 했지요. 당시에 윈도95용 프로그램 개발했다가 미치는 줄 알았습니다. 결국 납품한 프로그램 외에 어떠한 프로그램도 설치하지 못하게 하고서야 겨우 안정적으로 작동하기 시작했습니다. 그래도 나타나는 파란 화면은 그냥 리셋하라고 했습니다. 개발하면서 처음에는 하루에 한번도 윈도95를 설치했던 기억도 나는군요. XP 이전에 윈도에서 뽀샵으로 전문적인 일한 사람있으면 나와보라고 하십시요. 없겠지만 만일 있다면 정말 존경스럽네요!

카산드라//
XP가 안정적인 운영체제인 것은 사실이지만 UNIX에 보안 레이어를 빼면 더 안정적이지 않겠습니까? ^_^

  이장환//
CS4까지 '카본'지원이라는 사실을 맥 사용자들은 모릅니다. 아니 알아야 할 필요가 없지요. 몰라도 쓰는데 지장없으니까! 그래서 제가 지금까지 만나본 거의 모든 맥 사용자는 하드웨어나 OS 구조에 대해 모르는 경우가 많았기 때문에 '카본'만 지원하는 것에 대해 "CS4까지 구조적으로는 OS 9밖에 지원하지 않았다."라고 표현한 것입니다.

  이장환//
윈도에서 논란이 되었던 MS-Office에 사용된 API를 공개하지 않는다는 사실을 말한 것입니다.

  ngel//
"오랜 기간동안 일관되게 개발하고 버전업 해온 Windows용" - 운영체제와 관련된 부분은 변화가 없어 손댈게 없는...
'Cocoa'를 이용하면 운영체제와 관련된 부분을 프로그램할 일이 거의 없습니다. 윈도와 달리 OS X는 NextStep으로 부터 이어진 잘 정비된 SDK를 이용해 쉽고 간단하게 작업할 수 있습니다.
단지 스노 레퍼드에 적용된 GCD나 OpenCL을 얼마나 이용했으냐에 따라 다중코어지원의 효율성과 GPU를 활용한 성능 향상의 수준이 결정될 뿐이지요.

  os9과 윈도98을 ....? os9과 윈도 2000 이나 xp sp1정도 비교라면 몰라두요

  윈도95 OSR2 보다는 윈98 SE부터 겠죠.

하지만 그 뒤에 나온 윈미가 도로아미타불 시켰지만.

  "윈도우95는 적어도 클래식 OS보다는 진보된 OS였습니다. "
터무니 없는 편견은 위 문장이 더 한데요?

당시에 나왔던 맥을 써보셨나요? 그랬다면 저런말이 나오지도 않을텐데요?
마치 당시 맥 OS를 시대에 한창 뒤떨어진 엉터리 취급하는 듯 하시는군요.

물론 시스템 7.x이후 코플랜드 프로젝트를 말아먹으면서 OS 8.x부터는 윈도와 맥OS의 격차가 좁혀지고 Win2k에 와서는 추월당한 부분도 많았습니다만 적어도 Win95는 맥OS 흉내내기 수준이었습니다.
어떤 기술이 들어갔고 어떻고를 떠나서 당시에 맥과 윈도를 같이 업무에 써왔었던 사용자로서의 느낌까지도 말입니다.

하여튼 윈도95와 맥OS의 비교에서 옴니아가 특정 스팩이 아이폰에 비해 뛰어나니 아이폰보다 옴니아가 더 낫다 라고 주장하는 것과 비슷한 느낌까지 받아버렸습니다.

  어제 세종문화회관에 갔는데 맥북프로가 보이네요.ㅋㅋ

  클래식 맥 OS는 비선점형 멀티테스킹이 가능한 OS였습니다.
때때로 사용자가 응용 프로그램에 수동으로 메모리를 할당해야 하는 경우도
있었으며... 하나의 응용 프로그램이 다운되면 씨스템 크래시를 의미하는 경우가 대부분입니다.

윈도우 95는 선점형 멀티테스킹을 지원하므로 사용자가 응용프로그램에
수동으로 메모리를 할당해야 하는 경우는 없었으며.. 하나의 응용프로그램이
다운 된다는 것이 시스템 크래시를 의미 하지는 않았습니다.

OSX는 선점형 멀티테스킹을 지원하므로.. 사용자가 응용프로그램에
수동으로 메모리를 할당해야 하는 경우는 없으며.. 하나의 응용프로그램이
다운 된다는 것이 시시탬 크래시를 이미하는 경우는 별로 없습니다.

적어도 윈도우 95가 안정화된 이후에...
클래식 OS를 사용하는 것은... 주로 해당 운영 환경에서 돌아가는 킬러어플
때문이라 보아도 과언이 아닙니다.

누엔도나 쿽익스프레스...어도비의 프로그램들... 그리고 그것에 맞추어져
구축된 출력 인프라와의 호환성...
 

이러한 저의 의견에 오류가 있다면 지적해 보세요...

  CS4버전까지 카본으로 만들어졌다고 구조적으로 OS9밖에 지원한다는 말씀은 적당하지 않다고 생각합니다. 구시대적 언어로 제작이 되었다고 OS 9밖에 지원안한다는 논리가 맞을까요? 참고로 저는 프로그래머가 아니지만 OS9 와 OSX는 태생 부터 다른 아니 완전히 다름 OS라고 보셔야 합니다.
물론 카본이 OS X에 최적화된 툴은 아니라고 볼수 있지만 OS9 에서 작동도 안되는 프로그램을 단지 OS 9시대때 사용되던 툴로 만들어졌다고 OS9밖에  지원안한다는 말씀은 많은 혼란을 가져올수 있는 주장이라고 볼수 있을것 같습니다.
아도비 제품군은 CS이전 버전 모델부터 OS X에서 이미 네이티브로 구동이 되었고 OS9에서는 실행도 안되었습니다. 포토샵 7버전때가 OS9에서 구동되던 마지막 버전인것으로 알고 있습니다. 이후 맥이 인텔로 이주하며 CS3에서 인텔 맥을 지원하기위해 아도비도 고생하기는 했습니다. 카본에서 섣불리 코코아로 이주 못했던 이유이기도 하지요.

마지막으로 윈도우즈 95와 OS9비교는 너무 한것 아닌가요? OS7또는 OS8과 비교는 몰라도 말이죠. 대꾸 가치도 못느끼겠습니다.

  /Thinking

프로그래밍을 하셨다고 하신다면...씨스템의 제반 구조를
파악 하실줄 아시리라 믿으도 되겠지요?

그런 전제하에서 저의 의견을 올리오니 만일 저의 의견이
사실과 다르다면 따끔한 반론을 기대 합니다.

윈도우 95는 두가지 모드로 동작 합니다.

윈도우95가 출시되기 이전에 제작되었으며 윈도우 95용 드라이브가
제공 되지 않는 구형 부품의 경우에도 윈도우95에서 작동 할수
있습니다.

어떤 방식이냐 하면....
도스의 씨스템 설정 화일인...
Config.sys (간혹 Autoexec.bat에서 띄우는 경우도 있음)에
도스용 드라이브를 로드 하면.. 윈도우 95에서 그것을 인식하여
윈도우 95에서 작동 시킵니다.

즉 리얼 모드 도스 드라이브를 사용하는 것이 됩니다.

프로그래밍을 하셔다면 아시겠지만...
X86프로세스는 크게 보아서 두가지 모드로 동작 합니다.

리얼모드와 프로텍티드 모드인데...
두개의 모드는 동시에 존재할수는 없습니다.

(원래는 리얼모드에서 프로텍티드모드로는 갈수 있지만..
 한번 프로텍티드 모드로 가면 다시는 리얼 모드로 돌아올수
 없게 되게 설계 되었는데... X86프로세스의 버그(?) 때문에...
 프로텍티드 모드에서 리얼모드로 돌아돌수도 있는 편법이 존재
 합니다.)

동시에 존재할수 없는 두가지 모드...
그런데 하드웨어 디바이스 드라이브중 일부가 리얼모드 드라이브를 사용하면..
어떤 현상이 일어날까요?

별수없이 프로텍티드와 리얼모드를 끊임없이 왔다 갔다 해야 하는 불상사가
발생 합니다..  당연히 씨스템은 느려질테고 한층 불안정해 질것입니다.
이른바 호환모드라는 것입니다.


그러나 윈도우용 드라이브가 모두 갖춰진 경우는 사정이 다릅니다.
이경우는 프로텍티드와 리얼모드를 왔다갔다 해야할 필요가 없습니다.
오로지 프로텍티므 모드에서만 윈도우가 동작 하므로... 한층 안정적이고
속도가 빨라집니다. (이경우는 도스윈도우나 도스 풀화면에서 조차도
리얼 모드 도스 드라이브가 아닌 프로텍티드 드라이브의 가상 도스디바이스를
사용하게 됩니다.)


윈도우 95가 출시되고... 초기 출시된 OS특유의 버그는 윈도우라고
자유롭지 않습니다.  그점은 OSX도 피해갈수 없는 문제일것 입니다.



매킨토시는 하나의 회사가 독점 공급하는 행태이며 완제품 입니다.
그러나 아범은 다릅니다.

아주 다양한 브랜드의 보드와 그래픽 어댑터와 사운드 카드... 등등의
하드웨어 공급자가 존재 합니다.

그것들중 상당수는 극악의 특성과 불안정성을 보이는 것들도 있었습니다.
(상당수는 현재 시점에서 이미 도태되었으므로.. 현재의 상황은 예전보다는
 훨씬 나은 상황..)

따라서... 아범컴의 경우는... 매킨토시 보다 훨씬 고사양의 PC도 가능하지만..
훨씬 저사양의 PC도 가능합니다.

(제경우는...윈도우 95를 돌릴때의 사양은..
 펜티엄 MMX / 메모리 32M (EDO) / 마이크로닉스 M54Hi Sync+ 메인보드/MGA 밀리니엄 3D
 /사운드블라스터/ 아답택 AHA 2940UW SCSI /바라쿠다 SCSI HDD /야마하 외장형 CDRW
 / 유에스로보틱스 쿠리어 외장형 모뎀 / ISDN -한국통신 128K / 케이블 모뎀 (시기별로
 인터넷 환경에  변화가 있었기에...) /리얼텍 랜카드 / 시소닉 300W 파워/ EIZO 17인치
 트리니트론 모니터 등등의 구성 이었습니다.  )

윈도우 95는 도스와의 호환성 유지 때문에.. NT보다는 불안정한 것은 피할수 없지만..
OSR2 이후로 안정화 되면서 퍼런화면을 그렇게 자주 볼일은 거의 없었던 것으로 기억 합니다.

  와....이제 살다보니 윈95가 맥 OS보다 더 진보적이구 안정된 시스템이었다라는 글까지 보게되는군요....

제생각엔 케먹 유저들이 아범이나 윈도우즈에 대한 터무니없는 편견이 있는게 아니라 댓글다신 님이 정말 지독히도 어이없는 개인적인 생각을 가지고 있군요.

맥쓴지 17년이 넘었지만 맥빠니 애플빠니 하는 소리 지겨워서 한번도 이런 논쟁에는 근처에 얼씬도 안했지만 님의 댓글들 보니 정말 기도 안차서 실실 웃다가 몇마디 남기렵니다.

혹시 그때 당시 맥OS 7부터 사용해 보신 경험이 있으신가요?
그냥 잠깐 끄적거리는 수준이 아니라 정말 실무에 적용해서  lc, 쿼드라, 파워맥 이런 맥들 사용해 보시구 윈95랑 비교하시는 건가요??
아니면 걍 어줍잖은 여기저기 줏어들은 지식으로 그런 소리 하시는 건가요...

님이 말씀하시는 제대로 된 아범시스템(그때 당시 그런게 있었는지나 모르겠지만..) 기준이 뭔지는 모르겠으나 삼성, 현대, 대우, 금성이라는 기업제품들...그런것들도 다 싸구려 메인보드에 비짜 램 꼽아 팔았었나봅니다??
도스 호환 프로그램만 안돌리면 안정적이었다라는 허위사실은 도대체 무슨 근거로 말하는 겁니까?

그때 당시 도스관련 프로그램 쓰다가 뻑나고 다운되구 불안정한건 당연하고 그냥 선점형 메모리 관리 덕분에 맨날 뻑난 프로그램 종료해주는게 안정적이고 진보적인 시스템이라는 겁니까?

아니 그럼 윈도에선 메모장이랑 지뢰찾기만 해야됩니까?

맥이 그렇게 맨날 뻑나는 불안정한 시스템이구 하위 시스템과 호환 문제가 있는 윈95보다도 못하는 허접이라면 십년도 지난 쿽같은 것들이 아직도 인쇄시장에 그렇게 돌아가고 있을거 갔습니까?

윈95에서 네트웍 설정이나 주변기기 하다못해 모뎀카드 한장이라도 꼽아 본 경험은 있나요?

그냥 선점형 메모리 관리 되니까 맥OS보다 훨씬 진보적이라는 그런 생각은 도대체 뭘 보고 들으면 가질 수 있는건지 원.......

몇가지 지식으로 어설프게 궤변 늘어놓으면서 모르는 사람들에게 잘못된 인식을 시키는 것도 좋아보이지는 않습니다.

아이폰 덕에 정말 애플제품이 범용이 되어간다는 현실이 좋기도 하지만 이런 어설픈 댓글까지 보게 되니 썩소만 나올 뿐 입니다.

  윈 95와 클래식(이 OS 9를 말한다면)을 비교하시는 분도 다 계시네요...; 게다가 윈 95가 당연히 낫다고까지...;;  OS 9이 나오기도 한참 뒤에 나왔을 뿐 아니라 체감 성능 차이가 상당히 컸는데 뭔 소린지 잘 모르겠군요.

  (글 올리고 나니 위에 다른 분이 이미 긴 답글을 달아 주셨군요^^) 이젠 좀 옛날 일이다 보니 안 써 보신 분들이 많아서 누가 보면 정말 윈 95가 맥 클래식보다 나은 줄 알 수도 있겠네요;; 이런 답글도 달아 보게 될 줄이야... ㅋㅋㅋ (황당)

  답글을 달고 글이 날라가 다시 기억을 더듬어 적어봅니다.

카산드라님, 클래식 OS를 말씀하실때의 버전은 무엇을 말씀하시는것인가요? 혹시 system7, os8과 OS9을 묶어 말씀하시는것인가요 아니면 OS9을 말씀하시는것인가요?

윈95와 맥오에스와 굳이 비교하자면 시스템7또는 오에스8과 비교하셔야 한다고 생각됩니다. 오에스9은 1999년 이후에 나온 운영체제로 비교자체가... 물론 카산드라님께서 윈95이 맥오에스9보다 진보된 운영체제라는 의미시라면... 흠흠.

멀티태스킹에 대한 기술적인 내용에 대해 틀리신점은 없는것 같습니다. 단 멀티태스킹 방식으로 진보적인 운영체제다 아니다가 결정된다는 논조신것 같아 수긍이 안될뿐입니다.

그리고 말씀하신 당시에 맥을 사용하는 이유가 몇몇 킬러어플 때문이라고 말씀셨는데요. 그런 논리라면 당시에 윈95 빠르게 보급되었던 이유가 킬러어플(?)들인 게임과 오피스의 영향 크지 않았나 반문 하고 싶습니다. 안정성이나 진보적인 운영체제는 아니었습니다.
말씀하신 예는 극히 국내에 한한 예이지 해외의 실정을 아셨다면 절대 몇몇 킬러 어플 때문이라고 말씀 못하셨을겁니다. 저만해도 고등학교 때부터 맥으로 교육을 받았고 당시 윈도우즈 오피스로 절대 만들수 없는 차트와 프레젠테이션 문서를 시스템 7과 클라리스 웍스로 제작해 숙제를 내곤 했습니다. 아... 클라리스웍스도 맥의 킬러웨어 였던거군요...

  재미있네요.. 사실 windows 95가 불안했던 요인 중에 16bit 프로그램(win 3.1 이전 프로그램) 또한 큰 역할을 했죠. Windows 95가 선점형이라고 광고 한 것이 거짓인 것이 16bit 호환모드 때문입니다. 그 프로그램을 쓰면 바로 협력형으로 바뀌였습니다. 다들 아시겠지만 16bit로 만든 windows 프로그램은 95 나올당시 대부분 프로그램이었습니다.
98 정도 되어야 32bit 프로그램이 나왔고(당시도 불안했지만) 선점형 멀티테스킹이 가능은 했습니다.
오죽하면 windows 16bit 프로그램이 제일 잘돌아가는 시스템은 윈도우 3.1(도스 위에서 실행)도 95도 아닌 OS/2 였다는 것입니다.
OS/2에서는 윈도우 프로그램이 현재 맥에서 사용하는 vm 개념이였고 프로그램이 불안하면 바로 윈도우 3.1 스레드를 제거 했습니다.
윈도우 95가 불안한건 비단 도스 프로그램 때문이 아닙니다.
시스템 자체도 설계를 잘 못했지만(그놈의 dll, 레지스트리) 하위호환성을 너무 보장한것도 큰 역학을 했지요.
그리고 광고는 선점형이다라고요.  이는 전제 조건이 필요합니다. (단 모든 프로그램이 32bit로 작성 되어 있을 것!)
근데 사실 더 재미있는 것은 32bit 로만 작성한 프로그램이 있어도 블루스크린이 뜬 이상한 오에스 였지요.
아참... 그리고 시스템 7 부터 사용했습니다만... 맥이 불안했던 절대적인 공로자인 쿽 3.3 버전이지요. 정품으로 사용하는 분이 거의 없었으니 크랙해서 썼는데 이 프로그램이 시스템을 아주 불안하게 만들었던 기억이 있습니다.
하지만 제 생각은 그래요.. 어차피 시스템 9 제품은 코어가 너무 낙후된건 사실이고 세상에서 그리오래 버틸 오에스는 아니였다는 것이지요.

  /alli

윈도우 95는 클래식 맥 OS보다는 진보적인 운영 환경이라..
라는 것에 대한 이유는 이미 위에서 언급 하였습니다.

더 안정적이다... 라 주장 하지는 않습니다.

안정적으로만 따진다면...

버그없이 잘 프로그래밍된 프로그램을 사용하는 전제라면..
싱글 테스킹의 도스만한 것이 없습니다.

싱글테스킹을 돌린다면... 선점형이니 비선점형이니 하는 것을
따질 이유도 없을테구요.

프로텍티드 모드의 윈도우 운영환경에서 도스프로그램을 돌리면서 불안정해진다고
하는 것은 본질적으로 윈도우 탓은 아닙니다.
그런식으로 따진다면.. 매킨토시에서 별도의 애드인 카드 없이 애플2나 CPM머신의
프로그램을 아주 네이티브 매킨토시 프로그램을 돌리는것 마냥 안정적이어야 한다..
라고 주장하는 것과 별반 다르지 않기 때문 입니다.

도스프로그램을 돌리다가 다운 되었을때.. 알아서 종료해주는 것이 선점형의
특성은 맞습니다. 비선점형이었다면... 아예 시스템 크래시가 일어날수도
있었을 테구요...

도스 지원이나 도스 프로그램의 안정성 측면에서는 윈도우 보다는 OS/2 워프가
더 안정적이었다는 점은 기억 나네요... 윈도우95가 나오고 어느정도 안정화가
이루어질때 까지의 6개월여 동안은 메인 운영 체계로 OS/2를 사용하였습니다.
엑셀이 잘 돌아가지 않는다는 문제점은 있었지만...

흠... 네트워크 설정은 윈도우 3.1에서도 해본적은 있네요...
그당시는 한국통신의 코넷을 사용하였습니다. (트럼펫 윈속/터미널창/모자잌 또는 넷스케이프)

씨스템적으로 본다면... 클래식 맥 OS 7.0은 윈도우 3.1과 특성을 공유한다는
점은 님께서 예전의 PC경험이 있다면 확인 가능할것 같네요..(에컨데 윤곽선 트루타입 글꼴
채용 에서의 상호 협력)

쉘이나 제반 인터페이스적으로 본다면...
클래식 맥 OS는 OS9.2에서 조차도멀티테스킹을 위한 인터페이스면에서는...
윈도우95보다도 열악한 상황입니다. 윈도우는 그래도 작업표시줄이라도
존재 하였지요...

물론 OSX에서는 상황이 달라지게 됩니다. 저도 열렬한 OSX사용자 입니다. 

  /trexx

그당시의 인텔 CPU의 모드는 대략 3가지로 나눌수도
있습니다.

16비트 리얼모드 / 16비트 프로텍티드 모드 / 32비트 프로텍티드 모드

사람들이 자주 착각 하는 것이 16비트이면 모드 비슷한줄 아는 것인데...
16비트 프로텍티드 모드도 선점형 멀티테스킹이 가능 합니다.

이것을 이용한 UNIX버전도 존재 합니다. 예컨데 Xenix

윈도우 95는 정상작동시에는 32비트 프로텍트모드와 16비트 프로텍티드 모드를
사용 합니다.

(이것의 이유는....16비트의 경우가 더 빠르게 동작할수 있는 CPU의 특성때문이며
 이름하여 thunking 이라 하는 것으로 알고 있습니다.)

호환모드는 16비트 프로텍티드 모드나 32비트 프로텍티드 모드의 코드로
작성된 디바이스 드라이브가 없으며 16비트 리얼모드 도스 드라이브만 있는
구형하드웨어 상황에서 별수 없이 돌리는 모드 입니다.
(아예 안돌아 가는 것 보다는 나은 상황이므로....)




 

  흠.. 국내 기업을 폄하해서는 안되지만...
그당시 국내 대기업 PC의 일부는... 윈도우95용 드라이브
없이 도스용 드라이브를 깔아서 공급하는 경우도 없지는
않았습니다.    솔직히... 황당했지요...

  카산드라님,
맥오에스 9에서도 작업표시줄과 유사한것이 있었습니다. 지금 스폿라이트 시계가 위치한 자리에 풀다운 메뉴로 작동하고 있는 어플을 풀다운 메뉴로 보여주고 어플간 스위치 할수도 있었습니다.

  /카산드라

클래식 맥 OS는 OS9.2에서 조차도멀티테스킹을 위한 인터페이스면에서는...
윈도우95보다도 열악한 상황입니다. 윈도우는 그래도 작업표시줄이라도
존재 하였지요...

<- 라는 이 말씀을 보니 클래식과 그 이전 맥 오에스를 제대로 써 보신 적이 없음을 알겠습니다.
써 보신 분이라면 저 기초적인 걸 모르실 리가 없고
실제 쓰는 데에 있어서 멀티 태스킹에 전혀 문제 없었음을 모르실 리도 없지요.

  본문과 관계 없는 답글 관련 답글이 길어지는 데에 보태고 있어서 원글 작성자님께 죄송하군요.

  멀리 95까지 갈 것도 없죠... 윈도우Me 기억 하십니까?
Me와 안정성을 논해 주세요..ㅎ
농담이 아니라 부팅후 15분 간격으로 블루스크린 뜨고 한달에 한번은 포맷을 해 주어야 하는 악마가 만든 os였죠

  개발자의 한사람으로, 윈도우 충분히 좋은 OS입니다.
맥과 윈도우가 추구하는 방향만 다를뿐.

윈도우 소스 뜯어보면 다들 이런 덧글 못달껄요.

  대부분 윈도우를 사용해 보셨을텐데...
윈도우의 작업 표시줄의 특성을 제대로 파악하시지 않으시려
하시는 분도 보이는것 같네요..

윈도우 작업 표시줄은 문서 단위로  곧바로 접근 가능 합니다.
(최소화된창이던지 최대화된 창이던지 여부에 관계없이)

그러나 클래식 OS 우상단 시계 표시 오른쪽에 존재하는 것은
딸랑 로딩된 프로그램 항목만 표시 됩니다.

어느쪽이 보다 멀티테스킹에 최적화된 인터페이스라 할수 있을까요?

OSX도 상황은 다르지 않았습니다.
원래는 DOCK에서... 로딩된 프로그램은 딸랑 백색의 작은 그림자가
표시되는 정도였습니다.

그러다가 버전 업 되면서...
최소화된 문서창은 Dock에 따로 표시 되며.... 최소화되지 않은 창은...
엑스포제 같은 것으로 한눈에 보이게 표시 되는 것으로 발전 하였습니다. 

  Thinking//
여기도 논란이 많군요
<a href=http://www.kldp.org target=_blank>http://www.kldp.org</a> 가셔서 주제중에 사악한 애플이란 주제로 리플이 달린 글이 있는데, 한번 읽어 보시기 바랍니다. 그리고 거기서 리플도 부탁드립니다.

  카산드라 님//
무슨 말씀인지는 알지만 사실 16bit 프로그램이 프로텍트이건 아니건 선점형으로 될 수 없는 프로그램입니다. 이는 윈도우즈 3.1 이전 프로그램이 대부분 프로텍트 모드라는 개념이 미흡했기 때문입니다.
DR DOS 같은 프로그램이 16bit 에서 멀티테스킹을 시도했었고요.
제가 말씀드리고 싶은 요지는 실제로 윈도우즈 95가 선점형 멀티태스크를 주장할 만큼 안정적인 시스템이었냐는 것이지요.
제가 95는 시리얼 넘버를 3개 정도는 머리속에 외울 수 밖에 었었는데요.
정말 거짓말 안보태고 100번 이상 다시 깔았습니다. 물론 그때는 젊어서 조금만 문제 생겨도 바로 까는 버릇이 있었기도 하지만요..
블루스크린의 악명이 괜히 나온 말은 아닙니다.
당시 블루스크린 뜨면 의례.. "재부팅 해야겠네.."하며 푸념하듯 시스템 전원을 눌렀으니까요.
뭐 그렇다고 맥에서는 다운이 없었다고는 말 못합니다. 그놈의 한글 입력기가 너무 어처구니 없게 만들어 놔서 시스템을 불안하게 한 적이 많으니까요.
중언부언 말씀드렸지만...
윈도우 95가 선점형이다라는 말은 실제하지 않은 광고일 뿐이다 라는 것이지요. 그것도 의도적으로 맥의 협력형 멀티태스킹에 대한 비하적인 은유로 선점형 멀티태스킹이라는 말을 썼지만 그만큼 시스템이 안정화 되었어야 했지만 그건 광고에 불가했다는 말씀입니다.
사실 오늘 회사에서 XP가 저절로 재부팅만 안되었어도 이렇게 댓글 안달았을 겁니다. 이런 그지같은..XP ㅜ.ㅜ

  카산드라 //

댓글로 무슨 말씀을 하고 싶은지는 모르겠지만 선점형 비선점형 설명이나 하고 윈95 모드나 따지구 하면서 어설프게 논점에서 벗어나려고 하시나 봅니다?

열렬한 OS X 사용자라는 마지막 줄로 메꾸기엔 잘못된 지식을 남들보다 많이 아는 것 같이 똑똑한 척 하는 것이 잘못된 것이다 라는 문제점을 벗어 날 수는 없습니다.


프로그래밍 운운... 시스템 제반사항이 어쩌구 저쩌구 길게 늘어 써봤자 궤변은 궤변일뿐......

리얼 모드이던 프로텍티드 인지 뭔지 그런 모드이던 간에 그 모드는 윈도가 윈도가 아니구 그럼 머 리눅스랍니까??

윈95 나왔을때 프로그램 대부분이 도스 호환프로그램이었던 건 기억하세요?

그렇게 고가에서 저가까지 최고의 호환성을 자랑하는 윈도 쓰면서 윈3.1에서 네트웍 설정까지 열심히 잡아보셨던 분이 어떻게 맥 OS는 별로 사용을 안해보셨나 봅니다...

마치 윈도에서 프로그램 돌리다가 불안정 한 건 원래 당연하다는 듯이 자연스럽게 쓰면서 맥OS는 메모리 관리도 안되는 허접이다 라는 논리......

정말 맷돌 손잡이가 안드로메다로 날라가는 소리입니다.....

한가지 더.. 맥은 비선점형에 메모리 관리가 안되서 시스템 크래쉬가 어쩌구 저쩌구.....윈95는 멀티테스킹이 잘되서 프로그램 종료만 해주면 된다는 뉘앙스....
이런 말들 직접 적어놓구 윈95가 맥오에스 보다 더 안정적이라고 주장 하지는 않는다구요?
그럼 무슨 말을 하고 싶은 겁니까?

말씀하시는 대로 요약해보자면 윈95가 진보적인OS라는 근거는 메모리의 선점형 관리가 이루어 지며 작업줄과 같은 개념의 세부적인 작업으로 멀티 테스킹이 이루어 지기 때문이다....라는 이유들입니까??

한시간에 몇번씩 프로그램 종료하구 블루 스크린이 떠서 작업하던거 왕창 날라가도 그냥 저런거 되면 더 나은 오에스란 말이죠??

정말 진보적이고 더 나은 OS라는게 과연 사용자 입장에서 봤을 때 무엇입니까?
쉘스크립트 열심히 쳐대면서 모르는 남들이 봤을때 뭐하구있나 싶게 만들면서 우쭐 거리게 만들어 주는 OS가 진보된 OS입니까??

님께서는 그의미를 어떻게 가지고 있는지 정말 궁굼하네요.

  음.. 카산드라님께서 아셔야 할 사항이 있습니다.
맥과 윈도우의 멀티태스킹 방식의 차이인데요.
맥은 프로그램 단위로 작업현황을 보여주고 윈도우즈는 스레드 단위로 작업환경을 보여줍니다.
가령 윈도우즈 에서 한글 파일을 2개 띄어 놓으면 작업표시자가 2개의 프로그램처럼 스레드를 보여줍니다.
맥에서 키노트를 2개 띄어 놓으면 작업표시자가 프로그램은 하나로 보이고 스레드는 익스포제를 통해서 확인이 가능합니다.
처음에는 저도 윈도우에 너무 익숙한 나머지 윈도우 방식이 편했습니다. 하지만 쓰면 쓸수록 윈도우 방식은 일관성이 매우 떨어지는 것을 알게됩니다.
그들이 만든 대표적인 프로그램인  MS office 에서 2개의 문서를 실행하면 작업 표시자는 3개의 스레드를 띄웁니다. 하나는 프로그램 2개는 문서로 말이지요.
즉 프로그램과 스레드에 대한 개념이 모호하니 프로그램과 문서에 대한 구분이 어렵게되고 결국 두개의 프로그램을 못 띄우니 멀티 디스플레이에서 두개의 문서를 띄우지 못하는 기괴한 현상까지 발생합니다.
이는 익스포제로 스레드를 제어하는 맥에서는 있을 수 없는 방식이지요. 즉 프로그램가 스레드를 종속시키는 방법이 아닌 OS에서 스레드를 종속시키니 멀티 디스플레이에서 스레드로 된 문서를 마음대로 움직일 수 있는 것입니다.
사실 MS Office가 그런 방식을 택할 수 밖에 었었던 것도 맥 OS에서 office 프로그램을 처음으로 만들었고 개념을 가져왔는데 윈도우의 개념과 충돌하니 현재까지 계속 유지되고 있는 것입니다.
윈도우즈 작업관리자가 편한것 처럼 보이지만 사실 일관성하고는 전혀 거리가 있는 작업 관리 방식입니다.

  /trexx

흠... 제의견을 올린다면 윈도우 95는 16비트 프로텍티드 모드와
32비트 프로텍티드 모드의 혼재..  그리고 도스와의 하위호환성의
문제 때문에... 씨스템 리소스의 제한이 많았으며... 프로그램 종료시 이것이
제대로 반환 되지 않는 문제점은 있었다고 기억 합니다.
그리렇다고 선점형이 아닌 것은 아니었지요...

따라서.. 상당시간 사용후에는 재부팅을 해서 리소스를 회복해야 하는
문제점이 있었다고 기억 합니다. 

그리고 초기(윈도우95 OSR2이전)에는 FAT32도 아니고 VFAT라는 ...
요상한 화일 씨스템 (사실상 도스의 FAT와 동일 하지만 편법으로 긴이름
지원) 때문에 도스 프로그램을 돌리면 씨스템이 불안정해지거나 날아가는
문제점이 있었습니다. 

  /alli

적어도 인텔 계열 프로세스에서 프로텍티드 모드와
리얼모드에 대하여 기본 개념을 인식 하지 않으면서 논의를
하는 것은 무의미 합니다. 

흠.. 그리고 이상하게 맥 싸이트만 오면... 윈도우=블루스크린을
자주 언급 하는데...  솔직히 전혀 납득 되지 않네요...

전혀 없지는 않았겠지만.. 자주 볼수 있는 상황도 아니었습니다.
윈도우 95~98 시절에 하던 작업은.. 오피스 프로그램 ..., 인터넷
포토샵 (그당시는 디카를 가지고 있지 않았으므로 남의 사진을 이용
-또는 간혹 스캐너를 이용한 리터칭 정도) ,업무용 데이타베이스 (SQL)
,게임..  미디프로그램  , 통계프로그램.. 페이지메이커 등등...

단.. 도스 프로그램은 거의 전혀 사용하지 않았습니다.

  카산드라 님// 네 제가 말씀드리고 싶었던 것이 그말씀입니다. 제일 처음 댓글에서 말씀드렸듯이 하위 호환성을 따랐기 때문에 선점형이라는 말이 광고에 지나지 않다는 것입니다.
맥을 의식해서 맥은 협력형이어서 불안전한 시스템이다라고 광고 하는 것이었는데 실제 95를 사용하니 블루스크린 천국이 될 수 밖에 없었던 것이지요.
'Unix 와 같은 선점형' 당시 윈도우에서 말하는 논조 였습니다. 하지만 실제 유닉스는 커녕 맥의 협력형에도 못미치는 혹은 비슷한 멀티태스크 환경이었다는 것이지요.
즉 선점형이라고 말하려면 OS와 스레드(혹은 프로그램)의 독립화가 되어 스레드가 불안전하게 종료되면 OS는 영향이 없어야 합니다.
근데 95는 어땠나요? 프로그램이 죽으면 바로 OS에 영향을 미쳤고 그결과 내보낸 화면이 블루스크린입니다. 그러니 제가 선점형은 광고에 지나지 않았다고 표현한겁니다.
선점형 멀티태스크의 유일한 장점은 OS의 지배력입니다. 즉, OS가 프로그램을 통제를 재대로 하여 아무리 무겁고 불량한 소프트웨어라도 통치할 수 있다는 것입니다. 기술적인 구현이 어쩐다는 그리 중요한 것이 아닙니다.

오랜만에 들어보내요.^^ VFAT 정말 그지 같았죠... DOS에서는 억지로 8자로 보이는 기괴한 파일명...
OS/2에서 FAT로 긴 파일명을 만들면 OS/2에서는 보이고 도스에서는 안보이는 파일을 생성했습니다. 오히려 시스템의 영향을 안미치는 방식이었지요. 물론 DOS에서 그 파일을 수정하려면 노턴에디터로 수정해야하는 번거로움이 있었지만요.ㅎㅎ

  음.. 글세요.. 제가 블루스크린을 자주 접한 이유는 아마 16bit 윈도우 프로그램을 많이 가지고 있어서도 그랬을 거라는 생각이 들긴합니다.
근데 한글 3.1b 쓸때도 블루스크린 많이 보이지 않았나요?

  맥사이트 안와도 블루스크린은 얘기많이하는데
카산드라님 다른 사이트도 돌아다녀보고 그러세요..

  /trexx

보다 엄밀한 검증을 위하여 저의 환경을 소개 한다면...
제가 가진 MSOFFICE는 OFFICE 2007 입니다.
운영 환경중 윈도우 환경은 윈도우 XP와 윈도우7 입니다.

2개의 워드 문서를 띄운 경우 작업표시줄은 3개의 쓰레드가 아닌 2개의 문서를
보여 줍니다.

MS제품이 아닌 것을 돌려 본다면... 예컨데 두개의 꿀뷰3창으로 각각 다른 만화를
띄웠을때 작업 표시줄은 3개의 쓰레드가 아닌 2개의 꿀뷰 다큐멘트창을 보여 줍니다.

데스크탑에 존재하는 다큐멘트의 갯수대로 작업 표시줄에 보여 줍니다.
(최대크기 / 중간 크기 / 최소화 여부에 관계 없이 대등하게 갯수대로 보여 주므로...
 아주 빠른 접근이 가능 합니다. 게다가 상방 툴바가 아닌 각각의 다큐멘트창에
 메뉴가 존재하는 방식이므로...메뉴에 대한 접근도 빠릅니다.)

이러한 인터페이스는 윈도우95와 사실상 동일 합니다.


이러한 방식에서 한가지 단점은 작업 표시줄 단위에서는 드랙앤 드랍이 잘 되지 않는다는
점입니다.



이에 반해서... OSX는
일반적으로는 프로그램 단위로 보여 주다가...익스포제 같은 것을 거쳐야...
열려진 다큐멘트 창에 바로 접근 할수 있습니다.  (클래식 OS에서는 이것도 되지 않았음)

그리고 메뉴는 상방 툴바에 존재 하므로... 다큐멘트 창이 위치에 따라서는 마우스
이동 거리가 큰 편입니다.

또한 최소화된 문서창은 DOCK에 따로 표시 됩니다. (제목이나 내용은 표시 되지 않으므로..
실용성은 떨어지는 편)

DOCK방식이므로 드랙앤드롭에 유리..


문서단위의 일관성으로 본다면.. 저의 의견으로는 윈도우쪽이 보다 일관성을
가진것 같습니다.

  <a href=http://www.youtube.com/watch?v=IW7Rqwwth84 target=_blank>http://www.youtube.com/watch?v=IW7Rqwwth84 </a>
카산드라님을 위한 유튜브 동영상

  16비트 코드인지 아진지는 모르지만...
다이렉트X 이전의 게임 그래픽 가속 방식이어썬 WING 로
돌아가던 게임이 하나 있는데... civilization2라는...

winG 를 다운 받아서 윈도우 system 폴더에 넣고 돌려보니...
윈도우7에서도 잘 작동 하네요...  ^^

흠... winG는 윈도우 3.1 시절의 방식인것 같은데...

  제가 경험이 많지 않아서인지는 모르겠지만 카산드라님이 이야기 하신 프로그램들은 거의 NT에서 돌렸던걸로 기억되네요..95에서 블루스크린이 하루라도 안보인날은 축복받은 날이거나 작업을 안했거나 둘중 하나였던듯...

  카산드라님,
말씀하신 작업표시줄이라던가 표현 방식등은 멀티태스킹의 문제를 떠나 UI의 관점에 대해서 말씀하시는듯합니다.
그렇지만 맥오에스의 UI는 이미 오래전부터 인정을 받아온 부분입니다. 이것에 대해 다시 논의를 한다면 그만큼 자신이 있을때 하여야 겠죠.

그리고 말씀하신 작업표시줄 말씀하신대로 워드창 한두개 돌리면 직관적으로 보이실수도 있겠지요. 그러나 10개 이상의 문서를 열었다고 하면 어떻게 되나요? 작업표시줄이 말그대로 어느 창이 어느 것인지 구분이 안갈정도로 말이죠. 물론 모니터 해상도가 아주 넓은것을 사용하시면 어느 정도 해결되지요. 그렇다면 작업표시줄 존재의 이유가 무엇인지 궁금해집니다. 어느 분들은 그러시겠죠, 뭐하러 그렇게 많은 창을 띄우면서 작업하나? 컴퓨터 힘들게.... 그렇지만 띄워 놓은 창 줄여가며 작업하는 멀티태스킹의 의미가 무엇일까요?

이런 문제 때문에 인터넷 브라우져들에서 탭이 등장한거고 아도비 어플들에게도 적용되기 시작한것이라 생각합니다.

자 다시 윈도우즈 95시대로 돌아가겠습니다. 카산드라님께서 말씀하신 멋있는 작업표시줄이 있습니다. 그런데 당시 모니터의 해상도는 800x600정도가 대중적일 때입니다. 그렇다면 작업표시줄에 식별가능하게 띄울수 있는 창들의 숫자는 2-3개 정도이고 이것이 윈95 UI의 한계요 그리고 윈95의 멀티태스킹의 한계를 반증합니다. 마소는  2개이상의 프로그램을 유저들이 한번에 사용할것이라는 생각을 당시에는 안한듯합니다. 그리고 실제로 2개 이상의 어플을 돌리면 불안해서 사용못할정도이기도 했습니다.

반대로 맥오에스는 어땠는가? 제기억으로는 3개 이상의 프로그램을 문제없이 왔다갔다하며 사용했습니다. 당시에도 여러 컴퓨터 매거진에 맥오에스의 멀티태스킹 능력이 윈도우즈95의 그것보다 낳다고 표현하였었습니다.

솔직히 카산드라님에게서 처음듣는 표현이었습니다.

  /thinking

제가 보기에는 정확히 반대로 이야기 하시는것 같습니다.

  카산드라 님// 음.. 댓글을 안달려고 했는데요^^
파워포인트와 엑셀 파일 두개 열어 보시죠.. 프로그램 1 개, 도큐멘트 2개 열립니다.
워드는 두개 열리는 것을 보니 더 일관성이 없는 시스템이군요.
그리고 멀티 디스플레이를 엑셀에서는 프로그램을 하나 더 띄우는 편법없이는 불가능 합니다. 파워포인트는 그마저도 안되는 것이고요..

  파워포인트와 엑셀 파일 각 2개요..^^
제가 댓글을 달면 확인 시켜 버리는 것이니 서로에게 이득이 될것이 없을 것같아 몇시간 고민했습니다만.. 워드만 달랑 비교해서 말씀하시니 그냥 댓글을 달았습니다.
그러고 보니 오피스 프로그램을 비롯한 윈도우 UI 환경을 얘기까지 하니 너무 멀리 오긴 했습니다...

  카산드라//
위키백과에 윈도 95가 선점형이라고 나옵니다.
<a href=http://ko.wikipedia.org/wiki/윈도_95 target=_blank>http://ko.wikipedia.org/wiki/윈도_95 </a>

  "보다 엄밀한 검증을 위하여 저의 환경을 소개 한다면...
제가 가진 MSOFFICE는 OFFICE 2007 입니다.
운영 환경중 윈도우 환경은 윈도우 XP와 윈도우7 입니다. "

오피스에 대한 검증을 하려면 워드뿐만 아니라 파워포인트 등 다른 프로그램을
 했다면 제가 굳이 댓글을 달 필요가 없었는데 좀 씁쓸합니다.

접근에 방식에 현재까지 가장 빠른 전환은 솔직히 말해서 alt-tab 이 아닙니다.
mac OS X을 써보셔서 알겠지만 익스포제 기능이야 말로 가장 직관적인 스레드 전환 방법이지요.
숨겨진 스레드 또한 스노우 레퍼드 때부터 익스포제에서 아래 부분에 따로 나타났습니다.
근데 MS는 윈도우 비스타부터 괜시리 어설프게 익스포제를 따라하는데 이게 구현이 만만치가 않지요.
그리고 첨언하자면 윈도우 프로그램 스레드 별 접근 방식은 매우 낡은 방식입니다.
프로그램과 스레드의 개념이 전혀 없는 전환 방식이지요.
맥의 방식에 익숙해 지면 프로그램과 스레드의 구별이 매우 자연스러워 집니다. 커멘드-Q(프로그램 종료), 커멘드-W(스레드(윈도우) 종료) 개념이라고 보시면 되지요.
어느 것이 적정할까요?
요즘 브라우저를 생각해 보면 답이 보입니다. 탭기능 말이지요.
하나의 탭이 스레드(윈도우에서는 ctrl-f4로 종료)라고 생각하면 말이지요. 잘 생각해 보세요. 오피스에서도 비슷하지 않나요? ctrl-f4로 개별 창을 닫을 수 있고 마지막 윈도우를 닫으면 프로그램이 종료됩니다. 완전히 스레드와 프로그램의 개념이 없습니다. ctrl-f4와 alt-f4의 개념이 혼재되어 있지요.
맥은 마지막 윈도우를 커맨드-w로 닫는다고 해서 프로그램이 닫히지 않습니다. 프로그램과 스레드가 구별되어 있기 때문이지요.
이는 요즘 브라우저에서 쓰이는 탭을 연상한다면 쉽게 이해 될 수 있습니다.
윈도우는 마지막 탭을 닫으면 프로그램 종료되지요.
어느게 일관된 방식일까요?
전 맥의 태스크 방식이 훨씬 고급스럽다는 생각입니다.

  /gogi

클래식 맥 OS가 검증 된것은 사실 입니다.
바로 싱글 테스킹일때 입니다.

싱글 테스킹관점에서 본다면 이만한 GUI는 없다고 보아도 과언이 아닙니다.

그러나 역으로 멀티테스킹의 관점에서는 부적절한 인터페이스 입니다.

두가지 근거가 있습니다.

1. 클래식 맥 OS의 경우 매킨토시 초창기나 후기의 OS9.2나 기본
  인터페이스는 일관성을 유지 합니다. 

  그런데 시시템 6.0 이전의 매킨토시의 GUI는 싱글 테스킹 방식 입니다.
  도스의 램상주 프로그램과 유사한 init를 돌리는 것은 멀티테스킹의 범주에
  든다고 보기도 어렵고... 

  그러면 어찌 되나요?  싱글 테스킹에 최적화된 인터페이스가 멀티테스킹에도
  잘 어울린다?  라는 것이 되는데 이것은 말이 된다고 보기는 어렵습니다.

2.두번째로는.... 만일 클래식 맥 OS의 인터페이스가 적절하였다면...
 OSX에서 인터페이스의 대변동은 없어여 했습니다.  그런데.. 실상은
 그렇지 않지요..


그리고..

탭의 방식도 나름 매력적입니다. 저도 그것을 애용합니다. (구글크롬에서)

그러나 과거를 거슬러 올라간다면... 윈도우 9X나 클래식 맥 OS가 존재하던
1990년대 후반기에... 응용프로그램에서 탭을 지원하는 것은 많지 않았습니다.

그당시에도 이미 17인치 모니터가 대중화된 시기 였으므로... 작업표시줄에
작업 다큐멘트 10개쯤 올려 놓는 것은 별문제가 아니었습니다. 그리고 그래도
역부족이면 작업 표시줄을 위로 당겨서 더 두껍게 하여 더많은 다큐멘트를
표시할수 있는 수단도 있었습니다.   

그이후의 버전의 윈도우에서는 어느갯수 이상의 다큐멘트가 열려 있으면
그것을 그룹화 하여 표시 해줍니다. 따라서 갯수의 문제도 해결 되었습니다.

클래식 맥 OS 에서 가려진 작업 다큐멘트에 바로 접근 하는 수단은
해당 유형의 다큐멘트가 한개만 열려 있는 경우 이외에는 없었습니다.

  /Thinking

비선점형 멀티테스킹 -윈도우 3.1 클래식 맥 OS
선점형 멀티테스킹 -윈도우 95 /98/ XP/ 비스타 /7  매킨토시 OSX

확인해 보세요..  ^^

  /trexx

흠... 저도 매킨토시 OSX사용자이므로 OSX의 엑스포제 기능은
아주 매력적이고 우아하다고 생각 합니다.

그러나 윈도우에서는 엑스포제 기능 자체가 필요도 없습니다.
윈도우 7에서 보다 예쁜 외모로 변모된것은 사실이지만...
이것은 어느 운영 체제나 마찬가지 이고.
(구형 버전 보다 보기에 좋아야 하므로..)

기능적으로 본다면 윈도우 XP나 윈도우 7이나 별반 다를게 없습니다.

예를 들면 엑스포제 기능중 바탕하면을 보는 기능이 있습니다.

그러나 윈도우는 멕스포제가 등장하기 한참 예전부터 바탕화면을 보는
단축 버턴이 존재 합니다.


엑스포제 기능중 열려진 다큐멘트 윈도우를 모두 표시하는 기능이
있을것입니다.  그러나 윈도우는 작업 표시줄에 다큐먼트 항목이
모두 표시 되므로... 따로 그러한 기능이 필요하지는 않습니다.
(각각의 다큐멘트를 개벼 표시하던지 그룹화 시켜 표시하던지
 그것은 사용자 취향대로 설정 가능)

결국 엑스포제 기능은.. 작업표시줄 방식이 아닌 DOCK방식을
채용한 매킨토시 OSX의 특징 때문에 필요한것 입니다.


윈도우의 경우 그것이 다큐멘트창인지 응용프로그램 창인지 구별할
필요는 전혀 없습니다.  다큐멘트창에 메뉴가 존재하는 방식이기 때문 입니다.

매킨토시는 상황이 다르지요...

다큐멘트 윈도우와 분리 되어서 상단 모서리에 존재하는 상단 툴바
때문입니다...

구별해서 선택해야 하는 상황이 오히려 성가신것 아닐까요?

  제가 너무 오래되서 기억이 조금 가물가물하고 있습니다. ^^
지금 댓글 읽으면서 기억이 새록새록 돗아나고 있는 중입니다!
일단 비선점형에 대한 글은 지웠습니다.

잘못된 내용이었습니다.

  gogi//
제가 너무 두리뭉실하게 글을 썼나보군요. 미안합니다.
정확히 표현한다면 이번에 발표된 CS5 전까지 카본환경에서 작동하였으며 카본 환경이란 OS X 에서 가지고 있는 System 9 호환 레이어를 의미합니다. 카본 환경에서 작동하는 제품을 어도비에서 만들 때 OS X 의 커널만 쓰고 나머지는 몽땅 어도비에서 만들어서 사용한 것으로 알고 있습니다. 그래서 윈도용이나 맥용이나 차이가 없다고 표현할 수 있었던 것입니다. 이런 방식은 OS X이 가지고 있는 환경을 사용하지 않기 때문에 프로그램 사이즈가 커지는 것을 막을 수는 없습니다. 그러니까 로딩시간이나 메모리를 많이 사용하게 되는 현상은 어쩔 수 없이 발생한다고 봐야겠습니다.

카본에서 코코아로 이주 못한 것이 인텔 맥 지원 문제라고 하셨는데 제가 볼 때는 윈도와 맥을 동시에 지원하기 위해 운영체제의 최소한 외의 부분을 어도비에서 직접 만들어 사용했기 때문이라고 봅니다. 당시 정책이 그랬기 때문이지요.

  /trexx

그리고...

파워포인트 다큐멘트 2개 엑셀 다큐멘트 2개를 각각 열어 보았습니다.

작업 표시줄에는 역시 파워포인트 다큐멘트 2개 엑셀 다큐멘트 2개가
표시 됩니다. 응용프로그램당 프로그램 1개 다큐멘트 2개라는 님의
 의견과는 다른 양상 이네요.

  카산드라 님// 은근슬적 원래 하신 말씀을 빼시는 군요^^
제가 첫째 말씀 드린 것은 윈도우의 스레드 방식에 대한 문제점이었고 MS 조차도 그 방식에 대한 개념이 모호 하다는 것입니다. 갑자기 여기서 왜 메뉴가 나옵니까? 그냥 본인도 프로그램과 스레드가 이원화 되어있는지 몰랐다고 인정하면 안되나요?

또한 제가 언제 작업표시줄 얘기를 꺼냈나요? 제가 익스포제 개념을 말씀 드린 것은 스레드 접근에 대한 애플의 UI가 매우 직관적이게 되어있다는 것입니다.

이런식의 자기 방어적인 말은 서로에게 아무런 도움이 되질 않습니다.
전 제가 잘못한 정보를 가지고 있으면 인정합니다. 근데 님께서는 제가 언급한 스레드와 프로그램 방식에 대한 근거를 말씀드렸는데
처음에는 '워드는 안그렇다' 그렇게 말씀하시다 제가 '파워포인트와 엑셀을 실행해봐라'했더니 갑자기 제가 언급하지 않은 작업표시줄과 메뉴 얘기로 말을 돌리시는 군요.
제가 말씀드린 것은 님을 공격하기위해서가 아닙니다. 제가 언제 님의 의견을 반박하면서 얘기 했습니까?
윈도우 환경은 스레드에 대한 개념이 없다는 것을 알려드린 것이지요.
한번 제가 쓴 글을 다시 읽어 보시기 바랍니다.
윈도우는 스레드 개념이 없어서 UI가 일관되지 않다는 것이 요지입니다. 이는 매우 중요한 사용자 환경을 마련 하고 단축키, 프로그램 전환에 많은 영향주는 것입니다.
솔직히 제가 언급 안한 새로운 주제로 제 의견을 흐리게 만드니 기분이 좋진 않군요.
그냥 스레드 개념이 윈도우에는 없다고 하시면 될것을...

  Thinking//
선점형과 비선점형은 프로세스가 하드웨어를 액세스하기 위해 OS를 거치냐와는 상관이 없습니다.
OS가 멀티 프로세스를 스케줄링하는 방식의 차이를 나타내는 말이고요...
실제로 멀티태스킹이라고 해봐야 OS의 스케줄러가 아주 빠르게 여러 프로세스들을 우선순위에 따라 컨텍스트 스위칭을 해 주는 것인데요.
가끔씩 프로세스가 먹통이 되는 상황인 race condition에 빠질 때 선점형은 OS가 강제로 프로세스를 컨트롤 할 수 있는 반면
비선점형은 전체 시스템이 다운됩니다.
이 부분은 확실히 해야겠네요... ^^ 선점형이 더 좋은 건 맞아요.

카산드라//
솔직히 선점형이라 함은 분명 더 진보된 "개념" 이었지만... trexx님 말씀대로 "구현"이 형편없었습니다.
NT 커널을 제대로 장착한 2000/XP 이전에는 선점형의 이점을 온전히 누리지 못하는 너덜너덜한 아키텍쳐임에 분명했죠.
선점형 멀티태스킹의 최대 장점은 프로세스가 뻗어도 OS 레벨에서는 안정성이 보장된다는 건데
지나친 하위 호환성 문제와 드라이버 문제로 커널 자체가 불안정해서 선점형 멀티태스킹에서 얻는 장점이 무색해졌다는 것이 문제입니다.
뭐... 그래도 그것도 아닌 것보단 나았겠지만요
어쨌든 윈도우에 비해 비교적 커널이 안정적인 편이었던 맥과 OS의 스케줄링 방식 하나만 단편적으로 비교해봐야 별 의미가 없습니다.
그런 비교는 그냥 이론이고 스펙비교에 불과합니다.

  정말 XP에서 실행시켜 보시기 바랍니다. 제가 거짓말 한것으로 몰아부치시 마시고요..

  <a href=http://www.kitech.re.kr/upload/2010/04/15/02/adf2c33c342fe223f8d2a74d2dbb11a7b83a2d27.jpg target=_blank>http://www.kitech.re.kr/upload/2010/04/15/02/adf2c33c342fe223f8d2a74d2dbb11a7b83a2d27.jpg </a>
여기서 한번 확인해 보시기 바랍니다.
아이콘이 프로그램과 스레드의 아이콘이 다릅니다.
파워포인트, 엑셀, 워드 도큐멘트 2개 열었습니다.
파워포인트와 엑셀은 3개의 아이콘이 떠있습니다.
제발 확인 좀 하세요.

  /trexx


이무슨 동문서답이시지요?  ^^

윈도우의 멀티테스킹 사용자 인터페이스의 직관성을 논하는 글인데...
그러면 윈도우의 작업 표시줄을 논하지 다른 것을 논하는 것이
말이 되나요?

엄밀히 하기 위하여 님의 처음 글을 올립니다.

맥과 윈도우의 멀티태스킹 방식의 차이인데요.
맥은 프로그램 단위로 작업현황을 보여주고 윈도우즈는 스레드 단위로
작업환경을 보여줍니다. 가령 윈도우즈 에서 한글 파일을 2개 띄어 놓으면
작업표시자가 2개의 프로그램처럼 스레드를 보여줍니다.
맥에서 키노트를 2개 띄어 놓으면 작업표시자가 프로그램은 하나로 보이고
스레드는 익스포제를 통해서 확인이 가능합니다.
처음에는 저도 윈도우에 너무 익숙한 나머지 윈도우 방식이 편했습니다.
하지만 쓰면 쓸수록 윈도우 방식은 일관성이 매우 떨어지는 것을 알게됩니다.
그들이 만든 대표적인 프로그램인 MS office 에서 2개의 문서를 실행하면
작업 표시자는 3개의 스레드를 띄웁니다. 하나는 프로그램 2개는 문서로 말이지요.
즉 프로그램과 스레드에 대한 개념이 모호하니 프로그램과 문서에 대한 구분이
어렵게되고 결국 두개의 프로그램을 못 띄우니 멀티 디스플레이에서 두개의 문서를
띄우지 못하는 기괴한 현상까지 발생합니다. 이는 익스포제로 스레드를 제어하는
맥에서는 있을 수 없는 방식이지요. 즉 프로그램가 스레드를 종속시키는 방법이 아닌
OS에서 스레드를 종속시키니 멀티 디스플레이에서 스레드로 된 문서를 마음대로
움직일 수 있는 것입니다. 사실 MS Office가 그런 방식을 택할 수 밖에 었었던 것도 맥
OS에서 office 프로그램을 처음으로 만들었고 개념을 가져왔는데 윈도우의 개념과 충돌하니
현재까지 계속 유지되고 있는 것입니다.
윈도우즈 작업관리자가 편한것 처럼 보이지만 사실 일관성하고는 전혀 거리가 있는
작업 관리 방식입니다.

라고 이야기 하셨습니다.

윈도우는 다큐멘트창에 메뉴가 일체화되어 붙어 있는 경우가 대부분입니다.
매킨토시 같이 따로 떨어진 상방 툴바가 존재할리 없으므로..


따라서 MS office 2개 문서를 띄우면 작업 표시중에도 2개의 문서(여기서는 쓰레드)가
표시됩니다.  3개의 쓰레드를 띄운다는 님의 의견과는 전혀 다른 양상 이지요...

쉽게 확인 가능 할텐데요?  필요하면 스크린 샷을 올려 드릴까요? ^^

  카산드라님// 전 이미 올렸습니다. 한번 링크 확인해 보시지요.
Alt-tab 눌렀을 때 화면 캡쳐가 안되서 아이폰으로 사진찍어서 올렸습니다.
작업표시줄과 작업 변경(alt-tab) 서로 완전히 다르게 일관성이 없지 않나요?
그러니 더 일관성이 없다는 것입니다.
맥은 어떤가요? cmd-tab 을 눌렀을때 프로그램 단위로 보입니다.
윈도우 alt-tab 은 프로그램과 스레드가 모두 보입니다. 어느게 일관성 있는 것입니까?

  전 처음부터 일관되게 말씀드렸듯이 작업전환시 alt-tab에 대한 말씀이었습니다.
그래서 ctrl-f4와 alt-f4의 개념을 맥에서 가져오긴 했지만 제대로 실현 시키지 못했다는 말씀을 드리는 것입니다.
계속하다간 너무 낭비적인 글이 될것 같네요..
이젠 퇴근해야 겠습니다.

  /trexx
흠... 그러면 애써 핏대 높여 주장한것이 저는 작업 표시줄,,
님은 작업 표시자.. 가 되나요?  ^^

  카산드라 님// 그렇네요.. 서로 오해가 있었네요..^^
진짜 퇴근입니다^^

  카산드라님 탭에 대한 이야기를 오해하신것 같습니다.
저는 탭기능이 맥에서 구현이 되고 있었다고 말한것이 아니라
윈도우즈의 작업표시줄에 포화상태로 되는 윈도우즈 UI단점을 탭기능등으로 커버가 가능했다는 뜻이었습니다. 탭기능은 이후에 맥의 사파리와 아도비에게 사용된것이죠.

그리고 지금 논의가 되고 있는것은 윈도우즈95와 맥오에스9입니다. 시대 자체가 틀린 오에스인데도 굳이 비교하시겠다니 저도 비교하지요.
윈도우즈 95가 나왔을 당시가 17인치 모니터가 대중화된 시기였다니 금시초문의 이야기 입니다.혹시 윈도우즈98과 헷갈리시는것이 아니신지요. 어느 시대와 어느 버젼의 윈도우즈 이야기를 하시는것인가요?

그리고 윈도우즈 95가지고 다큐먼트 10개쯤 올려서 정말 작업하셨다는 말씀이신가요? 설마요… 아주 안정적인 시스템을 구축하셔서 사용하셨었나 봅니다.

또한가지 맥오에스 9 (클래식 오에스는 맥오에스 10에 포함된 버전이기 잘못된 표현인것 같습니다)의 인터페이스가 10으로 버전 업되면서 인터페이스의 대변동이 되었다고 말씀하셨는데 무엇이 그렇게 대변동이 되었지요? 윈도우즈 95에서 비스타 그리고 지금의 윈도우즈7의 인터페이스 변화야 말로 대변화라고 느껴지는데 말이죠. 그렇다면 윈도우즈 95의 멀티태스킹을 위한 인터페이스도 적절하지 않은것이라는 말씀이신지요?

그리고 저는 싱글 테스킹에 최적화된 인터페이스가 멀티테스킹에도 잘어울린다라고 적지 않았습니다.
그렇지만 오에스9의 훌륭한 UI가 있었기에 지금의 UI가 발전할수 있었던것이라 말하고 싶습니다.
어느 오에스든지 부족한면이 있고 그렇기에 그것을 보완해 나가는것이겠죠. 제 포인트는 오에스 9의 UI가 윈95보다 멀티태스킹을 위해 적합하지 않은 UI라는것에 인정안된다입니다.

또한 작업표시줄에 올릴수있는 공간이 부족해지면 표시줄을 위로 당겨 두껍게 하여 더 올리면 된다고 하셨는데… 그게 윈도우즈95부터 되었나요? (이건 정말 뭘라서 여쭙는겁니다) 되었다한들 가뜩이나 작은 모니터에서 작업표시줄에 어플들의 작업공간을 내주면서까지 굳이 도큐먼트 이렇게 이만큼 있어요~ 보이게 하는것이 말씀하신 멀티테스킹에 최적화된 인터페이스라고 하기에는 어폐가 있는것 같습니다. 그리고 작업표시줄에 표현되는 도큐먼트를 그룹화 하여 표시 해준다고 하셨는데 그게 정말 해결인것인가요? 그것이 정말 처음에 말씀하신 작업표시줄의 이점을 지켜주는것인가요?

왠지 윈도우즈95가 맥오에스9보다 진보된 오에스=진보된 멀티태스킹 왜냐하면 멀티태스킹에 적합한 UI 니까… 이렇게 여러 주장을 확대해가시는데 정말 진보된 오에스가 무엇을 말하시는것이지 부터 의심이 갑니다.

카산드라님 긴 댓글 읽어주셔서 감사하구요. 마지막으로 질문드립니다.
카산드라님께서는 윈도우즈 95의 진보적인 멀티테스킹이 안정적으로 제대로 구현되었다고 생각하시는것인지요? 그렇다면 전세계적으로 유행했던 공포의 블루스크린 패러디들은 다 어디서 나온것인지요?

  읽으면 읽을수록 완전히 다른세상에서의 OS얘기인줄 알았습니다~
아주 먼 다른 은하계의 한 외계행성에 있는 MS가 만든 윈도95?

  /gogi


흠... 윈도우 95가 비교적 안정화된 버전인 윈도우 95 OSR2 시기는
대략 17인치 CRT가 광범위하게 퍼진 시기 였습니다.

(싱글 테스킹이라면... 매킨토시 SE같은 작은 화면도 그럭저럭
 돌아는 가겠지만...코딱지만한 화면에서.. GUI 멀티테스킹을
 즐기는것은 눈이 혹사 되는 일일것 같네요...-아범의 저가형
 14인치 칼라 CRT는극악의 성능을 자랑 하였으므로 GUI에 적합하지도
 않았습니다.)

그때는 바야흐로 인터넷이 대중화 되는 시기 였으므로...
인터넷을 하면 다큐멘트를 10개 올리는 것도 흔한 일이겠지요..
그러저럭 안정적으로 돌아갔습니다. 파란화면을 본적은
거의 없었네요...

매킨토시 운영 환경이 OSX로 넘어가면서...
인터페이스의 대변동이 일어났습니다.

우선 확대/축소/닫기 버턴이 한곳에 모여 있게 되었습니다.
위치는 윈도우와 정반대 이지만.. 기본 행태는 클래식 맥 OS보다는
윈도우나 OS/2를 닮았습니다.

그리고 프로그램 런칭에 아주 자주 사용되는 DOCK 그리고 DOCK의
한계를 보완해주는 엑스포제 기능 같은 것은 클래식 OS에서는 없던
것입니다.

유일하게 클래식 OS의 전통이 계승 된것은 상방 툴바정도..

클래식 OS의 경우 OS9.X조차도 기본 인터페이스는 동일 합니다.
OSX에서도 이것은 확인 되지요... Sheepsaver같은 프로그램으로
클래식 OS를 구동 할수 있기 때문 입니다.

클래식 OS가 싱글 테스팅적 GUI에서 아주 좋은 인터페이스임을
부정 하지도 않으시고 그것을 인정 하시면서... 윈도우95보다
멀티테스킹에 보다 어울리는 인터페이스다.. 라고 주장 하신다면..

클래식 OS의 멀티테스킹적인 인터페이스는 윈도우7에 버금간다..
라고 주장 하시는 것과 별반 다르지 않을것 같습니다.

왜냐하면... 현재의 윈도우7의 외부 인터페이스도 기본 골격은 윈도우95와
별반 다르지 않기 때문 입니다.

이른바 블루 스크린은.... 씨스템 전반에 대한 어느정도의 이해가
있다면 대부분 피해갈수 있는 일에 속합니다.

예컨데.. 이미 언급한바와 같이 리얼모드 드라이브를 띠우고
윈도우를 호환성 모드로 억지로 구동 시키는 일은 윈도우 드라이브가
있는 하드웨어로 교체하면 피해갈수 있었습니다.
(어느정도 검증된 브랜드의 하드웨어를 사용하는 전제에서..)

그리고 윈도우 3.1용 프로그램의 사용을 피하고 윈도우 95용
프로그램을 사용하면 역시 상당부분 감소 하였습니다.
(윈도우 95는 도스프로그램을 도스박스에서 돌리수도
 있었지만... 기존 16비트 코드의 윈도우 3.1용 프로그램도
 윈도우 내부에서 돌릴수 있었습니다. 돌아는 가지만...
 안정적일수는 없었지요.. 윈도우 3.1과 윈도우 95는 이름은
 비슷할지 모르지만...아예 다른 운영 환경이었으므로...)

초창기에 흔히 발생하던 또다른 문제는...
도스용 씨스템 유틸리티를 돌리는 일이었습니다.
이경우 당연히 문제점이 발생 합니다.

  왜 싱글테스킹 UI로서 좋은 인터페이스가 멀티테스킹에서도 좋으면 안되는 이유라도 있는지요?

그리고 저는 오에스9때의 UI가 윈도우즈7의 UI에 버금간다고 한적이 없습니다. 왜냐 하면 저는 윈도우즈의 UI가 멀티태스킹에 좋다고 생각을 안하기 때문입니다. 위 답글에 보셔서 아시겠지만 저는 작업표시줄의 팬이 아닙니다.

그리고 말씀하신 맥오에스의 버튼위치 자리 변화등을 대변동이라고 말씀하시는것인가요? 그리고 이것이 멀티테스킹을 위한 UI하고 무슨상관일까요?

맥오에스 전통이 계승된것은 상반 메뉴바 정도라고 하시는데 이 상반 메뉴바가 애플 UI의 핵심이요 애플 UI의 철학인것을 너무 쉽게 보시는게 아닌지 생각됩니다.

블루스크린. 시스템 전반에 대한 어느 정도의 이해가 있다면 대부분 피해갈수 있는 일이라고 말씀하셨는데요. 진보된 오에스인데 시스템 전반에 대한 어느 정도의 이해가 있어야만 피해갈수 있는것이라면... 그것을 진보된 오에스라고 말할수 없다고 생각됩니다.
카산드라님 같은 이해도를 가지고 있는 유저들이 과연 몇이나 될지... 진보된 오에스를 쓰기 위해서는 그에 맞는 지식이 필요한것일지도.

  정확한 내용을 모르는 입장에서 단지 토론자들의  attitude만을 놓고 볼 때,
카산드라님의 말씀이 훨씬 신빙성있게 들리네요.
다른 분들은 대체로 제 수준에서 봐도 걍 감상적인 느낌이라...

  /gogi

맥오에스 버튼의 위치변화는 멀티테스킹에서 어느정도 이유가 있습니다.

싱글 테스킹이라면 프로그램을 여러개 돌리는 상황이 아니며...
하나의 프로그램만 돌리는 상황과 유사 합니다.

이경우.... 창을 닫는 버턴이 가장 많이 사용될테고 그것에 집중하여도
별문제는 없습니다.  클래식 매킨토시의 창닫기 버튼을 상기하면 됩니다.

그러나 멀티테스킹이라면 동시에 여러개의 프로그램이 구동 되는 경우가
되며 이런 경우 여러개의 다큐멘트 창이 동시에 열려 있게 됨을
의미하는 경우가 많습니다.

이경우는 창의 확대/축소버턴이나 최소화버턴의  사용이 증가하는 경우가
많을 것입니다.  따라서 세개의 버턴이 한곳에 몰려 있는 편이 사용에
편리하게 됩니다.


씨스템 전반에 대하여 알아야 유리하다...  라는 것은 아범의 숙명입니다.
요즈음이야 별문제 없지만... 예전의 상황은 더욱 그러하였습니다.

아범의 경우 운영체계는 M$에서 공급 하지만...하드웨어는 무수히 많은 다양한
공급자가 존재하며... 특히 조립 사용자의 경우는 더욱 복잡 다단한 하드웨어의
조합이 가능 합니다. 

게다가 씨스템을 획기적으로 바꾸는 상황....  도스에서 윈도우95로 넘어가는
상황은 클래식 맥 OS에서 OSX로 넘어가는 상황보다 더 급변 상황입니다.

이러한 골치아픔을 잘 요리하여야 비교적 안정적인 시스템 환경을
누릴수 있는 점이 아범의 치명적인 단점 입니다.
(그래봤자... 리눅스 사용자가 씨스템 환경을 최적화 시키는 것보다야 쉽겠지만..)

제가 요즈음 매킨토시 OSX 환경에 폭 빠지게된 이유 이기도 합니다.
{그럴 시간에 다른 생산적인 일에 몰두하는 편이 인생에 도움될테니...}

  굉장히 소모적인 글이 되는 군요..
지금 오셔서 3.1 프로그램을 쓰는 것이 문제가 된다라고 하시면 기운이 빠집니다. 카산드라 님께서 처음에는 선점형 얘기하시다 제가 3.1 하위호완성 때문에 실질적인 선점형이 아니다라고 했었고요.

윈도우즈에서 축소/확대/최소화 버튼은 모양 그 자체로 넥스트 스텝에서 가져온 것입니다.
솔직히 넥스트스텝을 처음 봤을 때 96년도로 윈도우 95 쓰고 있었던 때입니다. 

사실 윈도우즈 95 쓰면서 놀랐던 것은 이는 완전히 잡탕밥이기 때문입니다. 시작 작업표시줄의 아이디어는 넥스트 스텝의 큐브 독(이는 후에 맥오에스 X에서 독으로 되지요) OS/2 워크 플레이스 런처 등에서 오물조물 가져왔다고 할까요?
제가 끝까지 물고늘어지는 건 단 하나 입니다.

윈도우는 아직도 스레드를 이해하지 못하고 있다. 아니 개념을 못 잡고 있다고 할까요?
아까 언급했듯이 작업 표시에 대한 일관성이 부제하는 점입니다. 지금까지 말이지요. 프로그램과 스레드를 나누워서 생각하는게 뭐가 중요하나? 라고 말할지 모르겠지만 이는 사실 맥 오에스 및 Unix에서 가장 중요한 인터페이스 요소가 됩니다.
음 가령 키노츠와 파워포인트라는 프로그램을 쓴다고 생각해 봅시다.
3개의 키노츠 독을 열어놓고 상호 참조하면서 실행했을때 맥에서는 스레드 단위의 도큐멘트를 OS 차원에서 제어할 수 있습니다. 하지만 윈도우즈 오피스는 파워포인트 3개의 파일을 상호 참조하는 것이 불가능 합니다. 일종의 편법으로 오피스 2003과 2007을 두개 깔아 멀티 디스플레이 환경에서 사용하지요. 비단 그뿐 아닙니다.
도큐멘트 외의 스레드 인스팩터, 폰트 등을 다중으로 열어 놓고 도큐멘트 선택하며 적용할 수 있다는 점입니다. 아마 포토샵쓰면서 느끼셨을 겁니다.
윈도우 환경에서 인스팩터는 스레드로 인식하지 않고 프로그램 안에서 툴바 역할밖에 못합니다.
즉, 프로그램 전체 창을 멀티 화면에 크게 해놓고 도큐멘트 스레드를 적당히 조절한다음 쓸 수 있는 것이 기본 컨셉입니다.
어느 것이 현명한 방법일까요?
작업 표시자에서 보이는 것 처럼 윈도우즈 프로그램은 프로그램을 계속 띄우는 방식이여서 메모리 누수를 해결해야 했고 그 결과 지금 굉장히 문제가 되어온 dll(공유파일)이 난립하게 되었습니다. (물론 dll 이 그것 때문만은 아니지만요..)
이는 다 하위호완성의 결과일 것입니다.
사실 가장 치명적인 것이 생각지도 못한 드라이브 레터 이라는 사실을 간과하시더군요.
드라이브 레터야 말로 정말 없어져야할 짜증나는 유물입니다.
아직도 C:\\ 라는 개념이 살아있는 건 전적으로 윈도우즈 책임이니까요.
이것이 다 도스라는 토양위에 자라다 보니 윈도우즈가 괴물이 되어가는 것입니다.

윈도우즈는 도스에 뿌리를 둔 잡탕 입니다. 그래서 하부적인 개념이 매우 약하지요. 키보드에 쓸데없는 키인 윈도우 키도 왜 있나 싶습니다.
맥에서는 커맨드가 실질적인 작업 키가 되지만 윈도우즈에서 그 역할이 ctrl 키가 있거든요. (복사, 붙여넣기)

여러 오에스를 써본 입장에서 윈도우즈 95.. 글세요. 보면 볼수록 개념이 아주 부실한 괴물일 따름이었고 그 명맥을 현재까지 유지하고 있다는 것입니다.

dll, 엑티브 X, 레지스트리, 너무 환장스러운 네트워크 설정 및 제어 환경 등등 말이지요..
제가 맥을 사용하는 것은 일정 수준이 되면 사용자 편의성을 위해 하위 호환성을 포기하기 때문입니다.

  정태녕 님 // 지지를 하실려면 팩트로 말씀하시면 좋겠습니다. 그냥 느낌으로 감정적이다 신빙성 있다는 말씀이 감정적으로 들립니다.

  아참 그리고 카산드라 님께서 부정적으로 보는 맥의 메뉴 역시 스레드로 존재하는 것입니다.
이는 멀티 디스플레이 환경에서 마우스와 시선을 프리머리 윈도우에 가도록 불편하게 만드는 것도 인정 합니다만 스레드로 남아 있기에 현재 작업하고 있는 환경을 직관적으로 알 수 있다는 장점이 있습니다. 물론 제가 원하는 환경은 활성 윈도우 있는 디스플레이위에 메뉴가 떠있으면 좋겠지만요..
이 메뉴 방식은 아직 까지 인디케이터 역할로 가장 좋은 방법이 아닐까 싶습니다. 아이폰, 아이패드, 아이팟 등을 봤을때 아니 윈도우즈를 제외한 디스플레이 디바이스에서 상위에 인디케이터는 필수 요소 이거든요..
밑의 시작버튼은 인디캐이터 역할로서는 좋다는 생각이 안들어서요..

  카산드라// 오피스 별로 많이 안 써보셨군요. ^^
그 빌어먹을 프로그램 자체 스레드 때문에 알트탭하다 삑사리내서 짜증내며 일해온 게 벌써 몇 년 째인지 모르겠습니다.
별로 안 써보신 듯하니 예를 들어 드리죠.

파일 A를 엽니다. 파일 B를 엽니다. 알트탭으로 파일 A와 B를 오갈 수 있습니다.
파일 A가 활성화된 상태에서 다른 프로그램을 활성화시킵니다.
알트탭을 한 번 누르고 알트를 떼지 않고 있으면 작업 전환창이 유지됩니다. 탭 한 번 더 누르면 '상식적으로' 파일 B로 가야 합니다.
근데 프로그램 스레드 덕분에 파일 A가 유지되는 일이 발생합니다.

아아 아름다워라.

그리고 실제로 회사에서 듀얼모니터로 작업을 자주 하는데, 파워포인트 파일 두 개 양쪽 모니터에 각각 열어놓고 비교하면서 작업 좀 해봤으면 좋겠습니다.
노트북+세로 모니터를 쓰고 있으니 프로그램창 길게 잡아 늘여서 잘 줄맞춰 쓰라는 솔루션은 정중히 사양합니다. -_-

그리고 지금 이 길고 긴 논란의 발단은 카산드라님의 '윈95가 클래식OS보다 진보된 운영체제이다'라는 발언 때문이라는 점을 모두들 상기해 주시면 좋겠네요.
기술적으로는 선점형 멀티태스킹을 지원하기 때문에 윈95가 진보된 구조를 가졌다고 말할 수 있을지 모르고 카산드라님은 블루스크린으로 별로 고생을 안 해보셔서 쌓인 게 없으셔서 그럴지도 모르겠지만, 둘 다 실무에 써 보신 분들 경험담으로 보아서는 대다수 사용자에게 훨씬 큰 불편을 야기하는 OS가 기술적으로 앞서 있다 해서 '진보된' OS라고 보기는 힘들지 않나 싶습니다.

토론 중간에 더 안정적이라곤 안했고 진보된 OS라고만 했다고 하셨는데 안정성도 OS의 중요한 부분이고 윈 2000 전까지 수시 포맷/재설치로 씨름한 저는 윈98까지의 윈도우를 '진보됐다'고는 도저히 인정할 수가 없네요.
OS/2도 비싼 돈 주고 구입해서 몇 달 쓰다가 프로그램 호환 문제로 사용 중단했는데 OS/2는 시장에서 버림을 받았을지라도 '진보된 OS였다' 라고 말한다면 인정할 용의가 있습니다.

  카산드라// 위의 알트탭을 통한 창 이동은 윈7에서도 동일합니다.
알트탭 하나로 프로그램간 이동과 문서간 이동을 모두 처리하는데 태스크바엔 말씀하신 대로 바가 두 개 뜰 뿐이지만 알트탭 해 보면 실제 떠 있는 작업 핸들은 세 개입니다.

게다가 같은 제품군인 오피스 내에서도 어떤 놈은 알트탭 누르면 열린 문서를 모두 닫고 (엑셀) 어떤 놈은 활성화 문서만 닫습니다. (파워포인트)
OS차원의 일관성이라곤 찾아보기 힘든 구조죠. ㅎㅎㅎ

  본 논쟁을 읽다보니 로그인을 안할 수가 없네요. 저는 시스템 6~7, OS8~9, 도스, 윈3.1, 윈95 등등 다 접해본 1인입니다.
윈도우95가 어째서 맥의 OS 보다 더 진보된 운영체제인지 모르겠네요.
맥의 운영체제를 사실상 가져다 배낀 운영체제인 윈도우가 쬐끔은 나아 보일 수 있었겠지만(베끼다 보면 원판보다는 좀더 좋아보이게 만들어야 하겠죠) 이미 1984년 GUI 인터페이스에 마우스를 사용하는 운영체제를 만들어낸 애플과 1994년까지 도스위에서 돌아가는 껍데기 GUI를 가지고 있었던 마소의 윈도우즈와는 비교자체가 힘들다고 봅니다.
윈도우95가 나오면서 비로소 맥의 시스템 7.5와 비교할 만한 운영체제를 만들어낸 마소가 이미 나와있던 맥시스템의 풀다운메뉴 개념을 비켜가기 위해 유닉스쉘등에서 일부 사용되던 개념을 슬쩍 가져와 흉내낸 윈도우의 인터페이스와 멀티테스킹 개념이 마소의 위대한 발명품인 것처럼 들리는 군요.
윈도우95가 나오고 오랜기간 애플,썬 등등 다른 회사들과 표절공방 및 소송을 진행한건 무슨 이유일까요.
맥의 시스템7~8과 윈도우95~98과의 비교는 극단적으로 롤스로이스 팬텀와 중국 로위자동차의 짝퉁과 비교하는 것과 다르지 않다고 봅니다.
개념적으로야 이것저것 가져다 배낀 윈도우95가 좋아 보일 수 있을 진 몰라도 GUI 운영체제의 기본은 사용자의 편리성과 직관성을 위해 만들어 진 것입니다.(trexx님이 잘 지적해 주셨더구요.)
프로그램 1개를 배우면 나머지 프로그램의 50%정도를 이해할 수 있도록 고안된 맥의 풀다운 메뉴 개념과 프로그램별 특성에 맞게 짜맞춰 놓기 편한구조로 만들어진 쉘방식의 윈도우는 사용자를 대하는 태도부터 완전히 틀린 것이라 생각됩니다.
프로그래밍하는 분에 입장에서가 아닌 사용자의 입장에서 GUI의 본질을 이해해 주시면 좋겠습니다. 그래야 멀티태스킹이니 안정성이니 등의 얘기를 할 수 있을 것 같네요.

  trexx님, 그만 하세요.
카산드라님은 이 얘기하다 저 얘기하는 통에 진 빠집니다.
쉘 얘기가 또 나오니 SGI 인디고2 쓰던 생각나네요.

  classiccha 님 전 쉘 얘기 꺼낸적 없습니다.
제가 한 말은 딱 두가지 입니다.
1. 윈도우즈 3.1 프로그램이 돌아가는 윈도우즈 95는 진정한 선점형 멀티테스킹이 아니다.
2. 윈도우즈는 스레드 개념이 빈약하기 때문에 사용자 편의성에 많은 제약이 따른다.
이 두가지 입니다.
1번째 의견은 카산드라님께서도 언급한 부분이고
2번째 부분은 윈도우즈 캡처 화면을 통해 프로그램과 스레드에 대하여 말씀드린 것 뿐입니다.
<a href=http://www.kitech.re.kr/upload/2010/04/15/02/6e634f49d6e33263399f1dab28a975c811c71f69.jpg target=_blank>http://www.kitech.re.kr/upload/2010/04/15/02/6e634f49d6e33263399f1dab28a975c811c71f69.jpg </a>
전 딱 두가지만 말씀 드렸습니다.
자꾸 확대 재생산 되니 저도 이쯤에서 댓글은 그만 하도록 하겠습니다.

  trexx님, 제 얘기는 그만 카산드라님과 대화하시라는 의미였습니다.
저역시 일전에 그분과 얘기해본봐 소모적이라는 생각이었기 때문에요.
쉘 얘기는 전체 글중에 나와서 생각나 그런거랍니다. ^^
오해없으셨으면 합니다.

  classiccha 님 // 네 그런 뜻이군요^^ 감사합니다.

  /trexx

흠...  윈도우 95와 클래식 맥 OS의 인터페이스 논의가
이제는 윈도우 95와 OSX의 인터페이스 논쟁으로 변질 된것
같네요...^^

(흠.. 아무리.. 그당시에 획기적인 운영 환경이라 하더라도
 2010년 현재의 매킨토시 OSX와 비교 대상은 아니라 생각
 하며 한편으로는 비교 대상이 된것은 윈도우95 인터페이스의
 영광일수도 있겠네요... )

(그렇다고 하여서 클래식 OS가 멀티테스킹에 부적합한 인터페이스다
 라는 논의가 슬쩍 숨겨지게 되는 상황은 원하지 않습니다.)

어차피 윈도우95나 윈도우7이나 기본 인터페이스는 동일하므로...
논의를 편하게 하기 위하여 제가 현재 윈도우 운영체계중
메인으로 사용하는 윈도우7을 가지고서 논의를 진행 합니다.

우선 용어의 통일을 기하고자 합니다.
요즈음은 하나의 태스크도 멀티쓰레딩으로 작동하는 경우가 많으므로...
각각의 다큐멘트 태스크를 하나의 쓰레드로 이야기 하는 것은
엄밀히 말하면 사실이 아니며..혼란을 줄수 있으므로 태스크로
표기 하겠습니다.

윈도우의 alt-tab 과 매킨토시OSX의 커맨드-tab 키는 서로
비슷한 기능을 가지고 있습니다.

차이점은... 윈도우는 다큐멘트 단위의 태스크 스위칭이
가능하며 매킨토시는 프로그램 단위의 스위칭이 가능합니다.
(이것은 매킨토시 환경의 단점에 속합니다.)

몇몇 오피스 다큐멘트의 경우 프로그램과 다큐멘트를 동시에
표시하는 경우는 이미 지적해 주신 대로 입니다.

그러나 이경우도 아이콘 형태는 다소 다릅니다.
프로그램의 경우는 약간 큰 아이콘이 우하방에 표시 되며
다큐멘트의 경우는 약간 작으면서 문서표시가 된 아이콘이 우하방에
표시 됩니다.
 
따라서 운영체계가 각각의 다큐먼크 태스크와 프로그램을 혼돈한다라는
주장은 사실이 아닙니다.

그리고 오피스 다큐멘트가 아닌 다른 종류의 다큐멘트에서는 그러한
현상이 없는 경우도 있었습니다.

한편...
윈도우의 경우 이러한 방법을 사용할 이유도 없습니다.

작업표시줄에서 바로 접근이 가능하기 때문 입니다.
(이경우는 철저하게 다큐멘트 윈도우 중심 입니다.
 오피스 다큐멘트의 경우에도 프로그램과 다큐멘트가 따로 표시되는
 일도 없습니다.)


반면 매킨토시 OSX는 상황이 다릅니다.

윈도우의 작업 표시줄에 해당하는 것이 없기 때문 입니다.

결국 커맨트+탭으로 작동중인 응용프로그램 목록을 선택하고...
해당 응용 프로그램에 들어가서 그안에서 다큐멘트를 선택하는 방식을
따르게 됩니다.

그렇지 않다면...엑스포제 기능을 이용하면 됩니다.
이경우는 프로그램 단위가 아니라 다큐멘트 단위의 접근이 가능 합니다.
마치 윈도우의작업표시줄에서 접근 하는 것과 유사한 상황이 되는데...
몇가지 문제점이 있습니다.

데스트크에서 바로 접근 하는 것이 아니라 엑스포제를 경우하여 접근
한다는점... 이것은 시간이 걸리고 번거로운 작업이 됩니다.

또한...해당 다큐멘트의 축소본만 보여지게 되므로....그것의 형태로
다큐멘트의 특성을 유추해야 하는데... 그림문서가 아닌 텍스트문서라면..
식별에 곤란함이 따르게 됩니다.
(제가 최신버전의 OSX를 사용하는 것은 아니므로.. 최신버전에서는
 어떻게 바뀌었는지 확인 요망..)

윈도우의 작업 표시줄은 해당 다큐멘트의 제목이 표시 되므로...
곧 바로 식별 가능 합니다.

포토샵을 예로 들어 주셨는데...

OSX에서 포토샵은 윈도우와는 다소 다른 방식으로 보여지게 됩니다.
윈도우에서는 포토샵 창안에 다큐멘트와 툴바와 주변부 팔레트창이
존재하게 됩니다. 

맥에서는 상방툴바 따로..  주변부 팔레트창 따로 다큐멘트창 따로
존재하는 특성을 가지게 됩니다.

그런데... 이것도 문제는 있습니다.

일단 포토샵 프로그램을 구동 시키고 다큐멘트 창을 열지 않은 상태로
둔 상태에서  바탕화면을 클릭하게 되면...  상방툴바는 파인더 툴바로
대체되고 주변부 팔레트 윈도우도 순식간에 사라지게 됩니다.

그리고 다큐멘트 창을 열어둔 상태에서 바탕화면을 클릭하면
다큐멘트창만 남고 주변부 팔레트창은 사라지게 되며 상방툴바는 파인더 툴바로
바뀌게 됩니다.

이것을 본다면.. 매킨토시 운영 환경에서...다큐멘트창과 주변부 팔레트창을
다루는 방식에서 일관성이 결여된것을 볼수 있습니다.
(바탕화면 크릭시 다큐멘트 창은 ㅡ대로 남아 있지만..주변부 팔레트창은 사라짐)

그리고 편안함 보다는 불편함과 당혹감이 느껴지는것 같습니다.
솔직히 처음에는 매우 황당했으며.. 적응된 현재에도 불편함은 사라지지
않습니다.

파워포인터를 듀얼모니터에 사용하는 문제점에 대하여 언급 하셨는데..
솔직히 저는 듀얼 모니터를 사용하지 않기에 정확한 답변을 줄수는
없습니다.

부득이 다른 분의 해결책을 링크해 올립니다.

<a href=http://www.lastzone.com/55 target=_blank>http://www.lastzone.com/55 </a>

확인해 보시면 아시겠지만. 윈도우가 스레드를 제대로 이해하지 못한다는
님의 견해는 사실이 아님을 알수 있습니다.
일종의 프로그램 정책과 보안상의 문제에 속합니다.


DLL에 대한 님의견해도 사실과는 다소 다른것 같습니다.
DLL은 호환성의 문제와는 사실 관계가 없으며... 이것이 존재하는 원래의 이유는
프로그램의 코드의 낭비를 막고 여러 여러태스크나 어플리케이션에서 자원을 공유하는
목적이었다는 것이 일반적인 견해 입니다.  물론 이러한 방식이 가지는
장단점은 존재 합니다.

한편.. 윈도우95나 XP의 경우 작업 표시줄에서 다큐멘트를 다루는데...
주목할만한 기능도 있었습니다.

각각 다른 종류의 다큐멘트 윈도우.. 예컨데..워드문서 인터넷창 그림문서 을
여러게 선택하여 화면에 정렬(겹쳐쌓기 다북판 배열 수직 분할 수평분할) 할수도
있다는 점 입니다.  이것은 매킨토시 환경에서는 기대 할수 없는 특징이었습니다.

디스크 이름 C:\\ 가 무슨 문제가 될까요?
어차피 다른 별칭(?)을 붙일수 있습니다.  디스크를 접근하는데.. 긴이름이
어떤 잇점이 있을까요?  매킨토시의 터미널창의 상황을 상기해 보세요...
(매킨토시도 하드디스크 단위의 구별은 있습니다. 볼륨항목 아래에..)

윈도우95의 경우 도스 호환성 문제에서 자유롭지는 못하지만...
본질적으로 윈도우 95나 98 그리고 그이후의 NT커널의 윈도우 XP/비스타/7dms
OS/2에서 파생 된 것입니다. 따라서 도스토양 운운은 사실이 아닌 주장 같습니다.

레지스터리 방식은.. 그것이 가지는 문제점과 장점을 동시에 가지고 있습니다.

단점은 익히 아시다시피 프로그램을 빈번하게 많이 설치하는 경우 레이스터리가
꼬일수도 있다는점.. 장점음.. 하드웨어에 대한 로우레벨의 접근과 최적화가
가능하는 점...(이것을 이용한 다양한 트윅과 최적화가 존재)

액티브액스의 문제는 마이크로스프트의 과욕이 부른 결과이지.. 윈도우 운영체제의
본질과 무관합니다. 
 

  /trexx

사실이 아닌 아주 획기적인 이론을 전개하시는것 같습니다.


흠... 윈도우 95는 선점형 멀티테스킹이 맞습니다.
단순한 광고카피에 불과하다는 견해는 아무런 기술적 뒷바침이
없는 자의적 주장에 불과합니다.

호환성 모드로 빠지지 않는한... 리얼모드는 존재하지
않습니다.

리얼모드의 프로그램 조차도...
프로텍티드 모드의 가상 86모드로 구동하며...
프로텍티드모드의 가상 도스 드라이브로 구동하는 방식입니다.
(이것은 마이크로소프트가 원해서 그렇게 된것도 아니고
 인텔 CPU의 특징에 기인 합니다.)

호환성 유지 때문에... 시스템 리소스의 제약이 존재 한것은
사실이지만...

그리고 호환성이라 하더라도 도스나 윈도우 3.1과 100% 완벽한
호환성을 보이지 못하는 한계는 있지만... 전혀 다른 운영 환경과
100% 호환성을 가지는 운영체제는 없다고 보아도 과언이 아닙니다.
(이러한 문제점은 윈도우95용이 아닌 버전의 프로그램을 사용하지
 않으면 해소 되는 문제이기도 합니다.)

초창기 선점형 운영 환경의 몇몇 버그는 존재 하였으며...
그것이 구동 되던 환경이 도스의 화일 시스템이라는 점...이
몇몇 불안정성의 원인이기는 합니다.

아예 새로운 화일 시스템을 도입하였으며... 한참후인 2000년대에
출시 되었으며....다양한 하드웨어가 아닌 애플사에서 공급하는 하드웨어만
사용하며  기존의 클래식 환경과는 완전히 다른 유닉스의 운영 환경을 이용하는
OSX에서 조차도 시스템 크래시는 일어납니다.

익히 아시다시피 다국어 언어(한글은 빠진)로 표시되는 어두운 화면...
그리고 크래시 단계는 아니지만... 무지개 사탕모양의 아이콘이 계속
돌아가면서 시스템이 사실상 먹통 되어서 리셋을 해야 하는 경우가
발생 합니다.  그렇다고 하여서 OSX가 선점형 멀티테스킹 환경이 아니라
주장하는 사람은 없을것 같습니다.

응용 프로그램이나 운체계의 버그가 존재할수 있으며...
간혹 하드웨어 자체가 문제 될수도 있기 때문 입니다.

일부는 강제 종료가 가능하지만... 일부는 그것이 역부족일때가
매킨토시 OSX환경에서도 발생 합니다.

  그리고... 넥스트 스텝의 운영 환경의 창닫기 단추 (X모양)가
문제가 되는 것이 아니라....

3개의 단추가 모여 있는 상황을 이야기 하였습니다.

이것은 클래식 OS의 특성이라기 보다는 OS/2나 윈도우의 특징이며..
멀티테스킹 O/S의 편이성 측면에서 본다면... 오른쪽과 왼쪽 모서리에
분산된 단추 배열 보다는 편의성 측면에서 낫다라는 것을 이야기 한것입니다.

OSX도 이러한 특징을 가지고 있습니다. 반면 클래식 OS는 이러한
특징을 가지고 있지 않습니다. (싱글 테스킹의 관점에서는 분산 된것이
나을수도 있습니다. 창크기의 변화를 줄 일도 별로 없을테고 최소화 시킬일도
별f로 없습니다. 모여 있는 것 보다 따로 있는 편이 실수로 단추를 잘못눌러서
갑자기 프로그램이 종료되는 불상사도 막을수 있기 때문입니다.)

매킨토시 환경의 상당 툴바는 적어도 멀티테스킹적 관점에서는 불합리한
유산일것 같습니다. 다큐멘트와 따로 떨어져 존재하는 툴바... 인디케이터의
용도라면 별문제 없지만 실상은 그렇지 않음을 모르시지는 않으실것 같네요.

  /배투

실상을 본다면
매킨토시 시스템 7.X와 대응 되는 윈도우는 윈도우 3.X(윈도우 3.0 제외)입니다.

공통점이 많았지요..

둘다 트루타입 폰트를 채용 하였으며...
둘다 비선점형(협력형) 멀티테스킹을 채용 하였습니다.
그리고 윈도우 3.1에서 새로 채용된 새로운 자료교한 방식인 OLE와
유사한 기능을 시스템 7.0부터 애플도 사용하게 되었습니다.

윈도우 95가 나올때 애플은 시스템 7.5를 들고나왔지만...
이것은 매킨토시의 시장 점유율이 곤두박질하게 되는 이유중 하나가 됩니다.

  /pighair

윈도우를 제대로 안쓰보신것 같습니다.

알트-탭으로 특정 문서 두개를 오가는 것은 쉽습니다.

아무리 다양한 종류의 문서창을 여러개 열어놓아도 문제될것 없습니다.

님의 방식을 따라서 하는 것이 님에게 도움이 될것 같아서..
고대로 실행 해 봅니다.

파일 A를 엽니다. 파일 B를 엽니다. 알트탭으로 파일 A와 B를 오갈 수 있습니다.
파일 A가 활성화된 상태에서 다른 프로그램C와 D를 활성 활성화시킵니다.

이러한 상황에서 알트탭을 누르면 뜨는 목록이
A-C-D-B 라 가정 합니다. (어떤 순서라도 상관은 없습니다.)

이경우 화일 A와 B 오가는 것은 쉽습니다.

알트-탭으로 화일 A를 선택 합니다.

그다음은 알트를 누른채로 탭을 어러번 눌러서 B가 선택되게 합니다.

그이후에는 알트-탭을 누를때마다 A와 B를 오가게 됩니다.

이것은 윈도우7은 말할것도 없고 윈도우95에서도 가능한 방법입니다.

파워포인트 문제는 이미 위의 저의 리플에 올렸습니다.
확인해 보세요... 

  카산드라님,
윈도우즈 95와 오에스 9.x을 이야기 하는중에 왜 오에스 10으로 가시는지 이해가 안되는군요. 논점을 또 다른곳으로 분산시키어 또다른 논의를 하고 싶으신것인가요?

다시 돌아오죠.
말씀하신 윈95의 진보적인 멀티태스킹은 안정적이지 않았습니다. 백보 양보해서 말씀하신데로 하드웨어와 자신이 사용하는 소프트웨어에 대한 지식이 있어서 그나마 블루 스크린을 덜볼수 있다하더라도 일반 유저에게는 역시나 윈95는 진보적이지도 않고 불안전한 한마디로 말만 대단했던 오에스인것입니다.

마지막으로 맥의 상단 툴바라면 무엇을 말씀하시는것인지요? (설마 이것 가지고 논의를 또 확장하시려는것은 아니기를 바랍니다.)

  카산드라// 제가 졸필이라 설명을 제대로 못 했군요.
다시 설명드리겠습니다.

말씀하신 대로, 가 프로그램의 문서 A, B와 나 프로그램의 문서 C, D가 열려 있어서 알탭 순서가 A B D C로 돼 있고 현재 활성창이 A라고 가정하죠
그럼 알탭누르면 B로 갑니다.
다시 알탭누르면 A로 갑니다.
알트 누른채 탭 두 번 누르면 D로 가고 창순서는 D A B C가 됩니다.
여기서 다시 알트탭 누르면 A로 가고 창 순서는 A D B C가 됩니다.
여기까진 정상.

마우스로 B창 활성화시킵니다. 순서는 B A D C가 됩니다.
다시 알탭 누르면 A로 갑니다. A B D C가 됩니다.
여기서 또 마우스로 D로 갑니다. 창순서는 D A B C가 됩니다.
여기서 문제가 발생합니다.
여기서 알트 누른채 탭을 두 번 누르면 B로 가야 정상입니다.
근데 B로 안 갑니다. 왜냐하면 알트 누른채 처음 탭을 눌렀을 때 문서 A로 가지 않고 가 프로그램의 프로그램 스레드로 커서가 가기 때문이죠.
두 번 눌렀을 때 B로 갈 것을 기대했지만 A로 가는 상황이고, B로 가려면 알트 누른 채 탭을 세 번 눌러야 한다는 걸 말한 겁니다.

윈도우 7까지 동일한 현상이고 주로 프로그램은 마소 오피스에서 발생합니다.
같은 짓을 익스플로러에 적용하면 안 그럽니다.

같은 마소에서 만든 프로그램들이지만 일관성 따위는 개나 줘 버렸죠.

이 정도 설명으로도 이해를 못 하시겠다면 동영상 찍어서 올려 드리겠습니다.

  카산드라// 위 댓글은 저에게 쓰신 답글에 대해서만 쓴 내용이고 앞 내용을 읽어보니 뭐 훌륭하네요.
1. 전 맥 OSX 레오파드부터 썼습니다만 혹시 타이거 이전 버전을 쓰시나요? 레오파드 이후로는 엑스포제 실행 시 마우스 대면 문서명이 나타납니다.
스크린샷: <a href=http://grab.by/3M2X target=_blank>http://grab.by/3M2X </a>

2. Command-Tab이 프로그램만 전환만 돼서 단점이라고 하셨는데, 전 윈도우 3.1부터 XP까지 근 20년 넘게 윈도우를 썼지만 2년 쓴 MacOSX 방식이 훨씬 덜 헷갈리고 편합니다. Command-` 로 문서간 전환 가능한 건 알고 계신거죠?

3. 오피스는 그렇게 놀고 오피스가 아닌 프로그램 안 그렇게 놀고... OS가 응용 프로그램 관리를 일관성 없이 하고 있다는 점을 인지하고 있으시군요.
OS자체는 안 헷갈릴지 몰라도 명확한 기준이 없으니 프로그램마다 다르고, 그럼 사용자는 프로그램에 따라 OS가 어떻게 작동하는지를 학습해야 하는 상황이 발생합니다.
이런 환경을 제공하는 OS를 진보적인 OS라고 보기는 정말 힘드네요.

  마우스 대면 나오는건 레퍼드고 제가 올린 스크린샷은 스노 레퍼드입니다.

  근데 써 놓고 보니 OS가 멍청하다기 보다는 오피스가 멍청한 것 같기도 하군요.

  /gogi

흠,.. 클래식 OS와 윈도우95의 비교 상황에서...
OSX의 특성을 대입하면서 논지를 펼치시는 분이 게시기에
그런것이지 제가 의도한것은 아닙니다.

윈도우 95의 멀티테스킹은... 클래식 맥 OS보다는 안정적입니다.
적어도.. 어느정도의 안정화가 되어 초기 버그가 픽스 되고...
화일 시스템도 요상한 VFAT가 아닌 FAT32로 변한
윈도우 95 OSR의 상황에서...
(노파심에서 부언하지만... 윈도우95용 프로그램만 돌리고...
 컴퓨터 하드웨어 드라이브도 윈도우95를 제대로 지원하는
 전제에서 입니다.)


클래식 OS에서의 해당 프로그램의 다운은 시스템 크래시가
동반 되는 경우가 대부분이지만.. 윈도우95는 그렇지는 않았습니다.
강제종료로 문제된 프로그램만 중지 시키면 되었습니다.

  /pighair

흠... 그런가요?
그런데 윈도우에서 그런일을 하면 그것은 일종의 삽질일수도
있습니다.

작업표시줄에서 손쉽게 선택 가능한데 왜 그런일을 해야 할까요?

윈도우에서 테스크 스위쳐의 일상적인 용도는 두개의 작업을 오갈때 편의성
때문으로 알고 있습니다.

(어차피 윈도우의 경우 알트탭만 한번 누르고 손을 떼는 경우 순환하는 방식은
두개의 다큐멘트를 왔다 갔다 하는 정도 입니다.

님과 같이 알트 누르고 탭을 여러번 눌러서 작업을 왔다갔다 해야할
하등의 이유가 없습니다. ^^ 따라서 삽질이라 표현 한것 입니다.

순환해야 하는 두개의 작업을 선택하는 경우에나 알트 누르고 탭을 여러번 누르는
것이 필요할뿐입니다...^^)


작업 표시줄이 없는 매킨토시 환경에서는...
엑스포제 띄우기-->마우스로 작업할 윈도우 선택-선택된 다큐멘트 활성화...
하는 것 보다는 커맨드-탭이 유리할수도 있습니다.

그러나 윈도우에서는 아무런 작업 없이 작업 표시줄에 바로 보이는 해당 다큐먼트탭을
클릭하면 됩니다. 왜 힘들게 알트-탭 누르고 탭을 여러번 눌러서 해당 작업을 활성화
하는 식으로 손을 혹사해야 할까요?
(작업표시줄에서는 오피스 조차도 다큐멘트 따로 프로그램 따로..로 표시 되지 않으며...
다큐멘트만 표시 됩니다.)



프로그램의 일관성... 은 프로그램의 탓은 사실 입니다.

예컨데... 웹브라우저중 매킨토시 환경에서 많이 사용되는 것은...
사파리와 파이어폭스 그리고 구글크롬 등을 열거 할수 있습니다.

창을 최대화 하는 경우...
매킨토시는 데스크탑을 모두 덮지는 않는 상태로 최대화 하는 방식을
따르는 경우가 많을 것입니다.

그런데 사파리나 크롬은 그러한 전통을 따릅니다.
그러나 파이어폭스는 배신을 때리지요...창 최대화 버턴을 누르면...
윈도우에서와 같이 데스크탑을 모두 덮습니다.

이경우 매킨토시 OSX사용자로써..저는 OSX가 일관성을 상실했다라고
여기지는 않습니다. 파이어폭스 탓이라 여기는 입장입니다.


흠.. 그런데..제가 무슨 회사의 업무용으로 오피스프로그램을 많이
사용하는 경우가 아니라서...

기능은 약간 떨어지지만 가볍고 다루기 쉬운 iWorks 패키지를
더 자주 사용하고 있습니다. ^^

  카산드라님,
이제 어느 정도 저는 답을 찾은것 같습니다.
카산드라님 말씀에 의하면, 윈도우95용 프로그램만 돌리고...  컴퓨터 하드웨어 드라이브도 윈도우95를 제대로 지원하는 전제에서 안정적인다. 그런 뜻이군요.

그에 대한 저의 대답은, 저는 아마도 윈도우 95용 프로그램을 돌리지 않았고 하드웨어도 윈95를 제대로 지원하지 않는것만 사용해서 불안전 한거였구나 입니다.

똑같은 맥락으로 맥오에스에서 크랙안된 프로그램을 사용안하고 (대표적으로 쿽익스프레스) 한글폰트등을 사용안한 미국어 버전 맥오에스7,8들 정말 안정적이었습니다.  이건 맥오에스 9까지 갈 필요도 없습니다. 윈95와 비교 불가 였을 정도이니까요. 폭탄을 맞은 기억이 손에 꼽을 정도였습니다. 그런데 카산드라님 말씀들어보니 제가 윈95를 사용할줄 모르고 사용해서 그랬던것인가 봅니다.

  카산드라// 컴퓨터 사용 시간이 하루에 몇 시간이나 되는지 모르시겠지만, 타 사용자의 사용 패턴을 '삽질'이라 부르는 만용은 삼가 주시기 바랍니다.

작업의 성격에 따라 다를 수 있지만, 키보드만으로 작업할 때 작업 효율이 월등히 높은 일이 많이 있습니다.
저는 대체로 단축키를 거의 외워서 마우스를 안 쓰는 편이며, 마우스를 사용하는 것보다 작업 속도가 상당히 빠릅니다.
열나게 타자 치다가 손을 떼어서 마우스를 움직여서 작업 표시줄을 클릭하고 다시 돌아오라고요?

회사의 업무용으로 오피스 프로그램을 많이 사용하지도 않으면서 업무 고충에서 오는 상황을 설명했더니 삽질일 수가 있다니 어처구니가 없네요.
안그래도 토론 글 보면서 철저히 자기 중심적으로만 대답하는 걸 보고 어느 정도 감은 잡았지만 그런 태도로 토론하시는 건 좀 아니지 싶습니다.
본인이 알트탭을 자주 이용하지 않고 마우스로 한가하게 태스크바 눌러서 전환한다고 남들도 다 그럴 거라고 간주하여 저를 별로 쓸 이유도 없는 기능을 예로 들어서 따져대는 사람으로 취급하셨네요.

말씀대로라면 알트탭은 당최 왜 들어갔을까요?

  /gogi

멀티테스킹에서 윈도우 95는 클래식 맥 OS보다 안정정이다...
라는 것에서 멀티테스킹을 생략하지는 않으시리라 믿습니다.

싱글 테스킹이라면.... 선점형이던지 비선점형이던지 자체로 어느쪽
안정적이다... 라는 것은 성립하지도 않습니다.

싱글 테스킹 측면이라면... OSX나 윈도우7보다 예전의 MS도스가
더 안정적일수도 있습니다.

프로그램이 버그가 있을수도 있습니다.
이경우 해당 테스크는 다운될수도 있습니다.
(OS 때문이 아니라 프로그램 버그 때문에)

이경우 비선점형은 씨스템 전체가 다운 되는 경우가..
선점형일때 보다는 높습니다.

  /pighair

흠.. 제가 님의 글을 잘못 독해 하였나요?

두개의 프로그램이나 여러개의 프로그램을 토글링 하면서 오가는
상황을 님이 이야기 하신것으로 알았습니다.
(알트+여러번의 탭이 아닌 알트+한번의 탭 으로 왔다 갔다 하는 상황)

키보드만 사용해야 하는 상황이라면... 당연히 alt-tab은 유용할수
있습니다. 그런데.. 이경우는 작업 관리자에서 오피스 프로그램항목과
문서 항목을 동시에 표시하여도 별문제는 없을것 같습니다.

이를테면 랜덤 억세스도 아니고 알트 누른채로 여러번 탭을 눌러서
순차적 접근 방식을 따르기 때문 입니다.

게다가.. 님은 이경우도 마우스 사용을 이야기 하였습니다.

그것에 해당 되는 님의 글의 일부를 근거자료로 제시 합니다.

(전략)
말씀하신 대로, 가 프로그램의 문서 A, B와 나 프로그램의 문서 C, D가 열려 있어서 알탭 순서가 A B D C로 돼 있고 현재 활성창이 A라고 가정하죠
그럼 알탭누르면 B로 갑니다.
다시 알탭누르면 A로 갑니다.
알트 누른채 탭 두 번 누르면 D로 가고 창순서는 D A B C가 됩니다.
여기서 다시 알트탭 누르면 A로 가고 창 순서는 A D B C가 됩니다.
여기까진 정상.

마우스로 B창 활성화시킵니다. 순서는 B A D C가 됩니다.
다시 알탭 누르면 A로 갑니다. A B D C가 됩니다.
여기서 또 마우스로 D로 갑니다. 창순서는 D A B C가 됩니다.
여기서 문제가 발생합니다.
여기서 알트 누른채 탭을 두 번 누르면 B로 가야 정상입니다.
근데 B로 안 갑니다. 왜냐하면 알트 누른채 처음 탭을 눌렀을 때 문서 A로 가지 않고 가 프로그램의 프로그램 스레드로 커서가 가기 때문이죠.
두 번 눌렀을 때 B로 갈 것을 기대했지만 A로 가는 상황이고, B로 가려면 알트 누른 채 탭을 세 번 눌러야 한다는 걸 말한 겁니다.
(후략)

마우스 사용이 동반 되는 전제라면... 당연히 alt-tab 을 이용하는 방식은
속된말로 삽질이 됩니다. 그경우는 작업표시줄을 이용하는 것이 훨씬
낫습니다. (어떤 단계를 거치지 않고 바로..랜덤 억세스가 가능합니다.)

흠... 속어를 사용한것은 특정인을 빗대에서 말하는 것은 아닙니다.
그러한 상황 자체를 이야기 하는 것이니... 그것 때문에...기분이 언짢아
하시지는 않으시기를 부탁 드립니다.

  기가 막혀서 말두 안나옵니다. 역사 왜곡의 현장이군요.
카산드라님 classic Mac OS 써보긴 하셨습니까?

  카산드라// 마우스를 설명의 예시에 넣은 것이 큰 잘못이군요.
걍 그만두죠. 알트탭에 뜨는 목록상에 프로그램과 문서가 동시에 표시되면서 생기는 문제점을 죽어라 설명했는데 별 문제가 안 된다고 인식을 하시니 걍 제가 포기하죠.
마우스로 태스크바 찍으면 될 걸 알탭으로 전환해놓고 삑사리난다고 투덜대는 제가 삽질했습니다.

  카산드라//
윈도우 95가 선점형이였던것은 맞습니다.
하지만, 왜 윈도우 95가 선점형이 되어야 했을까요. 그리고나서 윈도우 me이후에 왜 NT커널로 완전히 이주해야 했을까요.

클래식 맥 오에스는 협력형 입니다. 하지만, 벌써 메이져 업데이트가 7번이나 된 시스템의 활용성은 윈도우3.1과는 비교가 되지 않았습니다.

윈도우 3.1의 킬러 어플이 무엇인가요. 무엇때문에 윈도우 3.1을 써야했죠?
덕분에 윈도우 95가 개발되어 출시 되어도 윈도우 98이 출시되기 전까지는 대부분의 어플이 도스 기반이였습니다. MFC 프로그래머가 손에 꼽을 정도였는데, 하드웨어 디바이스 드라이버를 제대로 이해하는 회사 자체도 드물었지요.
(실제 한글 워드95나 엑셀 95판의 출시 일이 96년 이네요.. 거의 97년이 되어서야 이런 저런 쓸만한 95용 프로그램들이 출시 되기 시작 합니다..)

사실, 도스 기반의 프로그램을 윈도우에서 돌리기 위해서는 선점형이 아니면 불가능 합니다.  협력형으로 협력 할 수도 없지요.. 어차피 프로그래머들도 협력따위는 상관하지 않았고요..
멀티태스킹 할만한 프로그램도 별로 없던 시절 입니다. 지금처럼 음악들으면서 플래쉬 돌리는 상황이 아니니까요.

저는 80년에 애플II 부터 사용했고, 맥 LCIII기종을 구입할려다가 시간이 흘러 파워맥 7100, 6100, 8500의 유저가 되었습니다만(이 당시 시스템이  os7이죠.. ) 멀티태스킹의 효과보다 이전 PC에 비해 다루는 데이터의 양이 엄청나게 많은것에 ( 그것도 아주 자연스럽게 다루는것에 ) 너무 많은 충격을 받았습니다.
실례로 이전 맥 시스템에서 외장하드는 거의 필수 였지요. PC에서는 CD-ROM드라이브조차 귀하던 시절 입니다. ( 옥소리 사운드 카드에... CD레코더가 수백만원대 였던 시절이니..)
거의 대부분 데이터가 디스켓으로 가지고 다니던 시절에 수십메가의 스켄 데이터를 처리 한다는것이...

게다가 좀 비싼 시스템을 쓰고 계셨군요.. 램 32메가.. 파워맥 7100 구입 당시 16메가 메모리 가격이 20만원선이라 16M SIMM 메모리 모듈을 만들어서 사용했었거든요..  그래서 그 당시로는 엄청난 40M의 메모리를 사용하고 있었습니다..  그게 1994년 입니다.. 윈도우 95는 1995년에 발매 되었겠죠?

파워맥 이전의 68K맥으로도 포토샵에 쿽 쓰는 분들이 멀티태스킹이 뭔지 모르고 썼을까요....

당시 상황을 기억 하신다면.. 윈도우 95가 시스템 7에 비해 멀티태스킹에 강하다..라는 말씀이 좀 그렇죠..

하긴 윈도우 95도 좋은 시스템 입니다. 말씀하신대로 멀티 만 안하고 드라이버 쓸만 하면요.. 전 지금도 윈95 시스템을 쓰고 있거든요.. 저의 오실로스코프가 영문 윈도우 95 기반이랍니다.. 뭐.. 램디스크로 시스템을 복사해서 단일 프로그램만 돌리니.. 뻗을 일이 없지요.. ㅎㅎ

  /pighair

흠.. 키보드 만으로 다큐멘트간의 전환에서 윈도우의 방식이
불편하다고 하셨는데...    맥의 방식이 더 불편한것 같습니다.

별도의 매크로 유틸리티의 손을 빌리지 않고 시스템에서 지원되는
기능만 사용한다는  전제하에서 맥의 상황과 윈도우의 상황을 정리해
보았습니다.  만일 저의 소견에 오류가 있다면 따끔한 가르침을
부탁드립니다.

매킨토시 시스템에서 테스크 스위쳐 역할을 하는
커맨드+탭 의 경우 다큐멘트가 나열 되는 것이 아니라
프로그램의 나열 입니다.

따라서 프로그램에 다중문서가 열려 있으며... 또다른 프로그램에서도
다중문서가 열려져 있는 경우 사용상 불편함이 나오게 됩니다.

어떤것이냐 하면

테스크스위쳐만으로는..개별 다큐멘트 레벨의 직접접근은 불가능 하다는 점 입니다.

`+탭을 이용하면 다큐멘트간 전환이 가능하다고 하지만..
이것도 동일한 프로그램 안에서일때만 입니다.

(단한개의 프로그램만 사용 되고 있으며 해당 프로그램에 여러개의
 문서창이 열려 있는 상황/또는 커맨드 탭으로 특정 프로그램으로 전환된
 이후의 상황)


결국... 매킨토시의 방식에서는 커멘드+탭으로 프로그램을 이동하고 나서
다시 `+탭으로 문서를 이동하는 방식을 따르거나 마우스에 의존해야 하는
문제점이 있습니다.

그러나 윈도우의 테스크 스위쳐 역할을 하는 알트+탭은 사정이 다릅니다.

하나의 프로그램에 여러개의 문서가 열려 있는 경우...
오피스 같은 특정 프로그램에서는 프로그램 따로 문서 따로 표시되는
점은 있지만.. (이것도 그냥 나열 되는 것이 아니라 문서와 프로그램의
아이콘 표시 형태가 다르게 나옵니다.)

여러개의 프로그램이 사용 되고 있으며 각각의 프로그램에 다중 문서창이
뜨 있는 경우 윈도우의 테스크 스위쳐에서는 개별 문서에 직접적 접근이
가능 합니다.

알트를 누른 상태로  해당 문서에 도달할때 까지 탭을 여러번 누르기만 하면
됩니다.  (이때 므로그램의 아이콘과 문서 아이콘은 형태가 다르므로 구별
가능하여.. 해당 문서의 제목도 표시 되므로 별 문제점은 없습니다.)

그리고 여러개의 프로그램이 사용 되며 각각의 프로그램에 다중 문서가
열려 있는 상황에서... 특정 프로그램의 개별 문서 A와 다른 프로그램의
문서 K를 왔다 갔다 하면서 상호 대조하여 사용하는 것도 손쉽게 가능 합니다.
(예를 들면 워드 문서 A B C D가 열려 있고 기타 잡다리한 프로그램의
 문서 E F G H I 가 열려 있고 엑셀 문서 J K L 이 열려있는 상황을
 가정 합니다.)

 일단 알트+탭을 누르고 원하는 프로그램에 도달하때 까지 탭을 여러번 누릅니다.
 원하는 문서가 선택 되면 손을 땝니다...

 다시 알트+탭을 누르고 알트는 그대로 누른 상테에서 탭을 여러번 눌러서
 원하는 문서 K가 선택 되면 손을 땝니다.

 이제는 그냥 알트+탭을 한번 누르기만 하면 문서 A로..
 다시 알트+탭을 한번 누르기만 하면 문서 K로 가게 됩니다.
 다시 알트+탭을 한번 누르기만 하면 문서 A로... 순환반복하게
 됩니다.
 

  /석수일

윈도우 3.1도 협력형(비선점형) 멀티테스킹 방식입니다.
이경우도 도스의 멀티테스킹은 가능 하였습니다.

인텔 CPU의 특징이라 할수 있는 프로텍티드 모드상의 가상 86모드 때문에...
80386 이상의 시스템의 386 Enhanced  모드에서는...

따라서 도스 프로그램 때문에 선점형을 택한다는 의견은 사실이 아닌것으로
판단 됩니다.

윈도우 3.1의 킬러어플을 든다면 MS오피스 정도가 생각 나네요...
그리고... 넷스케이프나 모자잌..  맥에서 포팅된 프랙탈디자인 페인터...
그리고 무수히 많은 프로그램들...

(윈도우 3.1이나 윈도우 3.11 후기에는 대부분의 도스용 킬러 어플들의
 윈도우로의 이주가 완료된 상황입니다.)

윈도우 95가 출시된 초창기에는...
윈도우 95용 프로그램은 거의 없었습니다.  윈도우 3.1용 프로그램을
윈도우 95에서 구동 시키는 수준이었습니다.

(오피스 프로그램도  마찬가지 상황이었습니다. 
 따라서 초기 운영체계 특유의 버그와 윈도우 3.1용 프로그램을 억지로
 돌리는 것에 대한 문제.. 도스 화일 스시템과 사실상 동일한 VFAT의 문제
 등의 상승 작용 때문에 1995년 당시 상황에서는 거의 쓸것이 못되는 수준
 이었습니다. (이때의 경험으로 윈도우95에 대하여 이상한 선입견을 가지신
 분들이... 많은것 같습니다.)

 따라서 일부 다용자들은 다시 윈도우 3.1로 되돌아가는 경우도 발생 하였으며..
 또다른 일부 (저도 포함됨)는 OS/2 로  이주하였습니다.

 적어도 윈도우 3.1용 프로그램을 구동 시키는데는... OS/2 만한 것은
 없었습니다. 그러나 오피스 사용이 사실상 불가능한 문제점이 있었습니다.)
 
그러나 1997년쯤이면 상황은 전혀 달라지게 됩니다.
(윈도우 95OSR2가 공급되던 시기)

 이정도 시기에는.. 이미 사실상 16비트 화일 시시템이라 할수 있는 VFAT을
 대체하는 FAT32 화일 시스템이 등장하게 됩니다.
 (이것도 현시점의  NTFS보다는 부족한 점이 많지만... 도스 프로그램을
 구동해야 하는 호환성 문제는 없었기에...)

 또한 상당수의 신형 컴퓨터 부품은 윈도우 95용 드라이브를 제대로 지원하게
 됩니다.

 그리고 이미 대부분의 킬러어플들은 윈도우 95용 프로그램으로의 이주가
 완전히 완료된 상황입니다.

윈도우 95시절에도 멀티테스킹... 예컨데.. 음악을 들으면서 인터넷하면서
FTP 유틸리티를 이용하여 동시에 프로그램을 다운로드 받는 일은 자주
있었습니다.


흠.. 저의 컴퓨터 시작은 대략 1983년도에 애플2+ 복제컴을 사용하던 때로
부터 시작합니다.
윈도우는 윈도우 1.X 2.X도 돌려는 보았지만.. 그나마 빈번하게 사용했던 것은
윈도우 3.0이고 실용적으로 사용할수 있는 수준이 된것은 윈도우 3.1 부터 입니다.

그것에 대한 저의 글은...

<a href=http://kmug.co.kr/board/zboard.php?id=talkclub&page=1&sn1=&divpage=6&sn=on&ss=on&sc=off&keyword=%C4%AB%BB%EA%B5%E5%B6%F3&select_arrange=headnum&desc=asc&no=28045 target=_blank>http://kmug.co.kr/board/zboard.php?id=talkclub&page=1&sn1=&divpage=6&sn=on&ss=on&sc=off&keyword=%C4%AB%BB%EA%B5%E5%B6%F3&select_arrange=headnum&desc=asc&no=28045 </a>

<a href=http://kmug.co.kr/board/zboard.php?id=talkclub&page=1&sn1=&divpage=6&sn=on&ss=on&sc=off&keyword=%C4%AB%BB%EA%B5%E5%B6%F3&select_arrange=headnum&desc=asc&no=28046 target=_blank>http://kmug.co.kr/board/zboard.php?id=talkclub&page=1&sn1=&divpage=6&sn=on&ss=on&sc=off&keyword=%C4%AB%BB%EA%B5%E5%B6%F3&select_arrange=headnum&desc=asc&no=28046 </a>

<a href=http://kmug.co.kr/board/zboard.php?id=talkclub&page=1&sn1=&divpage=6&sn=on&ss=on&sc=off&keyword=%C4%AB%BB%EA%B5%E5%B6%F3&select_arrange=headnum&desc=asc&no=28050 target=_blank>http://kmug.co.kr/board/zboard.php?id=talkclub&page=1&sn1=&divpage=6&sn=on&ss=on&sc=off&keyword=%C4%AB%BB%EA%B5%E5%B6%F3&select_arrange=headnum&desc=asc&no=28050 </a>


현재는 매킨토시 OSX 와 윈도우7을 메인 운영체계로 사용하고 있으며...
윈도우 XP는 VMware Fusion에서 돌아가는 가상 머신의 운영체계로
사용하고 잇습니다.



클래식 맥OS에서 쿽이나 포토샵을 사용하는 것은 멀티테스킹의 범주와는
무관합니다. 

본질적으로 그것은 GUI씨스템의 단일 테스킹에 속합니다.

동시에 다른 작업을 병행하면... 협력형 멀티테스킹이 될테고..
그렇지 않다면... 단일테스킹이 되겠지요...

  윈도우 95용 드라이브(32비트 프로텍티드 모드용 드라이브) 지원 여부
이외에 윈도우95의 초기의 하드웨어상의 또다른 문제점은 플럭앤 플레이
문제 였습니다.

이것을 제대로 지원하지 못하는 하드웨어도 다수 있었습니다.

물론 현상황에서 본다면 말도 안되는 소리겠지만... 그당시에는 그랬습니다.

따라서 그것을 제대로 지원하는 업체의 하드웨어를 선택하는 남다른
안목이 필요했던 시기 이기도 합니다.
(P&P가 표기 되어 있는 상태의 메이저 브랜드의 경우는 대부분 별문제
없었습니다.)

아예 P&P가 지원 되지 않으면 점퍼로 세팅하면 될테지만...
문제가 되는 것은 어정쩡한 지원입니다. 특정 보드에서는 되고
다른 보드에서는 안되고... 또는 달느 슬롯의 특정 하드웨어 상황에서는
제대로 되지 않아서 충돌이 일어나는 상황...

오죽하면 우스개 소리로 플럭애플레이가 아니라 플럭앤 프레이(pray) 라는
소리가 있었을까요..

아예 운영체계와 하드웨어를 동시에 공급하는 매킨토시 시스템 사용자들은
이러한 예전 상황을 잘 납득하지 못하는 경우를 자주 봅니다.

초기 윈도우 95 시절에... 제 경우는.... 외장형 모뎀과 외장형 CDR
SCSI 하드디스크를 이용한 이유중 일부이기도 합니다.

  카산드라님 애플II얘긴 필요없구요. 일단 classic Mac OS써보셨냐구요. 일단 이거부터 대답해주셔야지요.

  /자끄루시에..

요즈음도 간혹 사용중입니다. 
seepdaver로 구동 중이지요....

인터페이스의 요모조모를 살펴 보는데는 전혀 지장이 없는것 같은데요?

  아뇨 예전에 classic Mac OS가 현역일때 써보신적 없지요? 자꾸 미꾸라지처럼 요리조리 그런식으로 빠져나가지 마시고 정확하게 말씀하셔야지요. 써보신적 없지요? classic Mac OS로 작업해 보신적 없지요?

  흠... 클래식 매킨토시 직접 소유해 보지는 않았지만..
사용은 해본적 있습니다.

(OS/2 3.0과 윈도우 95 출시후... 어차피 피시를 새로 장만해야 하는
상황이므로..  맥이냐 아범이냐를 한참 고민 햇었지요....  마침 미술을
공부하는 知人이 맥을 가지고  있어서 그분의 동의를 얻어서 한동한
돌려본적 있습니다.

 프로그램은 윈도우와 별반 다르지 않았습니다.

 워드 엑셀 ..  그리고 프렉탈디자인페인터...  등등...다만 인터넷 브라우저는
 깔려 있지 않았습니다.)

고민의 이유는,, 제가 선택한 사양의 아범 피시나 맥시스템이나 가격차이가
별로 크지 않았다는 점 입니다.  (물론 시스템 사양자체는 조립아범이 맥보다
낫겠지만..)

싱글 테스킹에서는 꽤 안정적이었다는 점은 기억 하며...
멀티테스킹시 하나의 어플리케이션이 다운되면 강제 종료는 힘들고
시스템이 얼어 붙는 경우가 있었다는 점도 기억 합니다.

그리고 제가 사용하였던 워드나 엑셀 프렉탈디자인페인터는
전부다 윈도3.1 용이었는데.. 프로그램을 사용하는 느낌이나 프로그램
자체의 내부 인터페이스는 맥이나 윈도우 3.1이나 거의 똑같았다는 점도
아범 선택의 이유였습니다. (원래 맥에서 출발한 프로그램이므로... 약간
차이나 날줄로 기대 하였는데...)

  그런식으로 말하자면 저도 안써본게 없습니다. 아는 사람거 잠깐 써본걸 가지고 뭘 써보셨다고 그러세요. 혹시 새드맥이나 폭탄은 보신적 있습니까?
그당시 종로 YMCA 건물에 있던 엘렉스센터에만 가도 매킨토시 구경하러 온사람들 많았어요. 종로엘렉스 전시용 맥에는 맥을 모르는 사람들이 만든 새로운폴더랑 가상본들이 널려있기는 했지요. 그리고 지금까지 카산드라님이 말씀하신거만 봐도 classic Mac을 제대로 써본적이 없다는거 바로 알겠습니다. 여태까지 "구경한 것"을 가지고 대하소설을 쓰시는군요.
지금 나가봐야해서 이따 다시 얘기하지요.

  흠... 비선점형에서 하나의 테스크가 전부 다운되어도 시스템 크래쉬는
피할수 있습니다. ^^ 어플리케이션 자체가 아주 지능적이라서 자신이
다운 될때에는 스스로 시스템 다운을 막아주는 코드가 들어 있다면...

또는 같은 비선점형이라도 애플이 만드면 다르다...?

과연 이게 말이 된다고 생각 하시는지요?


현재도 클래식 맥 오에스는 사용하고 있습니다.

sheepsaver 에서 구동 되는 매킨토시 시스템 7.5나 8.5나 9.0은
예전의 클래식 맥에서는 다른 인터페이스로 돌아간다고 주장하시는것인지요?

  에뮬료 써본걸 써봤다고 말하면 더이상 토론할 필요가 없습니다.
이거야 원 우기는것도 정도가 있지 당시에 그걸로 밥먹고 산 사람들이 죄다 바보가 되어버리는군요.

  카산드라//
프로텍티트모드, 가상모드를 논하시는것을 보니.. 도스 시절 프로그래밍에서 많이 고생하셨나 봅니다.. ㅎㅎ
(저는 하드웨어 디자인이 업이기 때문에..  님의 고충을 조금은 이해 하지요..)
뭐, 간단히 68K 에서는 몇개의 모드가 있을까요? 혹시 아시나요?
아마 아시는 분이 거의 없을 겁니다. 이유는요.. 간단합니다. 알 필요가 없으니까요.
윈도우 95에서 선점형을 택한건 어쩔수 없어서 입니다. (간단히 말해서 말이죠..)
윈도우 3.1은 도스 호환 프로그램을 더 중점에 두었습니다. 당연하겠죠. 하지만, 이건 거의 실패였습니다. 대부분 사람들이 'm'보다 못한 프로그램을 왜 써야 하냐고 그랬죠.. 시스템 크래쉬는 ....
이런 이유에서 윈도우 95는 도스 프로그램의 운영을 위해 선점형을 쓸 수 밖에 없는겁니다.
( 선점형으로 OS시스템이 주도권을 잡지 못하면 운영이 불가능할 정도였으므로 - 이에반해 MacOS는 더 선진화된 기술을 보여주었죠.. 아마 폐쇄성의 시작이라고 할까요.. 규정을 만들어두고 거기에 맞지 않으면 아예 만들 수 없었죠. 심지어 단축키 까지 그 당시 부터 규정에 두고 있었습니다. 소문에는 규정에 맞는지 애플에서 내부적으로 조사하는 팀이 있다고 할 정도였지요.)

하지만, 윈도우 95는 선점형이 되었다 하더라도, 대부분의 프로그램들이 직접 하드웨어를 제어하고자 했기 때문에 (뭐.. 당연히 알려진 정보가 적으니.. DOS 경험대로 할 수 밖에요) 불안정성이 어쩔 수 없었던 겁니다.
이것은 윈도우 98이나 me에서 NT 아키텍춰로 넘어올때보다 더한 충격이 되었죠. 단도직입적으로 디바이스 드라이버에 대한 이해를 하고 있는 프로그래머가 거의 없었을 정도니까요.
-뭐, 이건 마이크로소프트의 탓 이기도 합니다. 애플이 30여권의 InsideMacintosh책을 내어 놓는 동안 국내에서는 마이크로소프트에서 발행한 원서 조차 없었으니까요. (전 InsideMac을 원서로 전권 소유 하고 있습니다. ㅎㅎ 이책을 한권씩 전권을 구입한 후 맥을 구입했으니까요. 유명한 책이 첫권인 Human Interface GuideLine입니다. 한국어로도 번역되어 출간되었죠. 지금 쓰고 있는 윈도우가 어떤 이론을 바탕으로 만들어 져 있는지 -소프트웨어 기술적인 측면이 아니라 인간공학적인 측면에서- 잘 나타내고 있는 명작 입니다..)

이에 비해 윈도우 95보다 더 일찍 멀티태스킹을 지원하던 맥은 파워맥 6100부터 모뎀 기능을 할 수 있는 GeoPort라는 악세서리를 내 놓습니다. 이게 상당이 특이한데, 일반적으로 PC 에서 쓰는 모뎀은 모뎀기능을 하는 칩에서 단순히 모뎀데이터만 출력하는 반면, 이Geoport는 일종의 사운드카드로 전화선의 신호를 A/D변환해서 보내면 파워PC 칩과 운영체계가 이를 분석해서 모뎀을 에뮬레이션 하게 됩니다. 따라서 소프트웨어 업그레이드 만으로도 속도를 높일 수 있었죠.
뭐, 지금에서 보면 아무것도 아니지만, 이런 FFT분석을 실시간으로 할 수 있을만큼 OS구조가 안정적이였다는 의미 입니다. 뭐, 이걸로 인터넷까지 했었으니까요.. (이런게 멀티태스킹이 아니면 뭡니까? 그것도 실시간 작업인데..)

뭐.. 아직까지 OLDmac에서 포토샵 띄워서 쓰는게 단일 테스크라 말하신다면........

-전 현재 맥프로 (2008 옥타/14G)를 사용하고 있으며.. 업무상 어쩔수 없이 부트캠프도 씁니다.
하드웨어 개발자니까요. 물른 i7 /windows7 머신도 함께 씁니다. (돈 좀 많은(??) 학교 연구원 이거든요.. ㅎㅎ)

  카산드라//
윈도우 3.1의 비선점 멀티와 OS 7 이후의 비선점 멀티가 비슷할 것이라고 생각하신다면 정말 잘못 판단하신 겁니다..
비선점형이라 하더라도 스케줄링은 합니다. 당연히 OS차원에서 지원되지요.
클래식 MacOS가 그렇게 허접하게 만들어진게 아니랍니다.. (뭐.. 에뮬정도에서 그걸 느끼기에는 불가능 하지요..)
단지.. 뾰족한것이 없던 마이크로소프트에서 그나마 3.1보다는 안정적이라고 줄기차게 광고한게 그겁니다만..
뭐.. 아이폰과 비교해서 CPU가 빠르다 라고 주장하던 핸드폰이 오히려 불쌍해 지는것 처럼 보인다 일까요..

  카산드라//
한마디만 더..
아이폰 OS는 선점형 인가요? 아님 비선점형 인가요?
윈도우 CE는 선점형 인가요? 아님 비선점형 인가요?
사실, 이게 무엇이건 상관없습니다. 알 필요도 없고요.
왜냐하면 벌써 사람들이 결과를 알기 때문이죠. 어느것의 똥침을 더 많이 찔러야 하는지..
하지만, 연말쯤 되면 7폰이 나오면 마이크로 소프트는 이렇게 말할겁니다.. 우리는 ABCDEFG해서 아이폰 보다 더 좋아....
하지만.. 벌써 사람들은 알고 있을겁니다.. 어느쪽이 더 빨리 치질에 걸릴지..

  /석수일

어째 논지의 일관성이 없으시고 횡설수설 하시는 것 같네요..
게다가 자신의 생각을 가지고서 근거 없는 소설을 쓰시는분
같기도 합니다.


프로텍티드모드에 가상 86모드가 포함된것은 인텔 CPU특유의 하위호환성
유지 정책 때문 입니다. 저는 프로그래머가 아니므로 도스 프로그래밍
때문에 고생할 이유가 없을것 같네요.. 어떻게 그렇게 마음대로 추측하시고
소설을 쓰시는지요? 이것은 인격적 모독이 될수도 있습니다.
(터보C를 가지고 논적은 있지만....)

도스 프로그램을 염두에 두었다면... 도스를 사용하면 됩니다.
구태여 윈도95를 사용할 이유가 사실상 없지요.

도스 자체가 멀티테스킹이 별반 필요한 환경도 아니었습니다.

도스 자체의 멀티태스킹을 염두에 두었다면...
데스크뷰 386이나 컨커런트도스 같은 것을 사용하는 것이 보다 적절한
선택입니다.

윈도우3.1 은 도스 환경에서의 탈피를 모색한 운영 환경입니다.
또한...OS/2 (OS/2 3.0 이전의 버전)의 부분 복제품이라 할수도 있습니다.

(윈도우 3.X가 등장 하기 이전에 마이크로소프트는 IBM과 공동으로
OS/2 운영 체제를 공동개발 하였으며... 윈도우 3.X의 쉘은 OS/2의
프리젠테이션메니저를 사실상 차용한 것이었습니다.

그리고 윈도우 NT 자체는 여러종류의 CPU에 대한 포팅을
염두에둔 OS/2 포터블 버전 입니다. IBM과 결별후 이름만 윈도우 NT라
바꾸었다고 보아도 과언이 아닙니다.)

윈도우95가 아무리 출중하다 하더라도.. 윈도우 95가 나오기 훨씬
이전에 나왔으며 전용 드라이브 자체가 존재하지 않은 사실상 단종된
하드웨어에 대하여 하드웨어 제작자가 책임질수 있다고 여기시나 봅니다.
(타임머신이라도 타고 시간여행 거슬러 올라갈수 있다면 말이
될수도 있겠지만..)

윈도우3.1에서도.. 포토샵은 띄울수 있었습니다.
포토샵만 띄운다면 당연히 단일 태스크에 가까운 상황이고...
동시에 인터넷 창을 띄우고 웹써핑을 한다면 비선점형 멀티태스킹이 되겠지요

클래식 맥 OS는 비선점형 멀티태스킹을 하며..
따라서 어플리케이션이 다운 되는 경우 시스템 크래시가 일어날수
있는 빈도는 선점형 보다는 높습니다.

이에 반해서.. 제가 현제 사용하고 있는
OSX는 사정이 다릅니다.
선점형 멀티태스킹을 하므로 어플리케이션이 다운 되더라도 다운된
어플리케이션을 강제 종료할수 있습니다. (DOCK에서)

윈도우 95에서도 하나의 태스크가 다운 되면 강제 종료는 가능 하였습니다.

님의 논리 대로라면... 그러면 OSX가 선점형을 채용한것이...
예전 클래식 OS를 원할하게 돌리기 위해서.. 또는 도스 프로그램을
돌리기 위해서라 주장 하실수있으신지요? ^^
..

윈도우 3.1의 비선점형 멀티태스킹도 나름대로의 스케줄링을 하고 있습니다.
선점형 보다는 당연히 떨어지는 수준이며... 해당 프로그램들의 협력이
없다면... 문제가 되는 수준이므로.. 이것을 완곡하게 협력형 멀티태스킹
이라 하는 것이지요.

클래식 OS가 허접하다고 이야기 한적은 없습니다.
다만 클래식OS는 비선점형    윈도우 95는 선점형 멀티태스킹이며..
인터페이스적으로..
클래식 OS 보다는 윈도우 95가 멀티태스킹면에서 진보된 방식이다..
라는 것을 이야기 한것 뿐입니다.

컴퓨터 OS 이야기를 하는데... 왠.. 폰이야기를 하시는지는
이해가 되지 않네요...

흠.,,,
아무리 생각해도...

윈도우 95가 선점형 멀티태스킹을 택한것은 도스 때문이다..라는
주장은 코메디 같네요...

1995년도 즈음이면 도스는 아범 플래폼에서도 사라지는 추세였습니다.
윈도우 3.1의 대성공의 영향 때문에... 대한민국 국내가 아닌
글로블한 레벨에서 본다면 도스용 킬러 어플의 대부분은 이미
윈도우 환경으로 포팅이 완료된 상태 였습니다.

아무리 마이크로소프트가 멍청하다고 하더라도...
철지나서 단종 추세에 있는 환경의 지원 때문에.,. 운영 환경을
완전히 뜯어 고친다라고 하기는 어려울것 같네요.. ^^

  아직도 현역으로 사용되는 visual studio 6.0 은 1998년에 나왔습니다.
한/글 3.0은 1995년 3월 Watcom C 로 작성되었습니다.
2002년까지 전국의 모든 PC 방은 윈도98 SE 를 사용했습니다.
......
윈도 95의 가장 큰 문제점은 16비트와 32비트를 같이 지원하면서 윈도 95용 드라이버가 없거나 불안정해서 생기는 문제들이었습니다.
이 문제들는 1997년 경에야 겨우 해결되었습니다.

제대로된 개발도구도 없던 시기에 제대로된 어플이 있을 수가 없었지요.

  카산드라// 말 섞기 싫어서 이 컬럼은 안 보고 있었는데 간만에 왔더니 또 실소를 금치 못하게 하시는군요.
다시 한 번 여쭤보죠, 하루에 컴퓨터 몇 시간 쓰십니까?
이론상으로야 알트탭 몇 번 해서 문서 찾아서 찾아가는 방식이 직관적이겠죠
근데말입니다, 실제 사용할 때는 윈도처럼 일관성없이 문서끼리 다 뒤섞여 있는게 더 헷갈립니다.
말씀하신 대로 프로그램 두 군데에서 문서를 여러 개 열어 놓고 작업하면서 왔다갔다 하다보면 윈도는 프로그램끼리 묶여있지 않고 문서단위로 알트탭 목록에 표시됩니다.
XLS1-PPT1-XLS2-XLS3-PPT2-XLS4-PPT3 이런 식으로요.
윈도 역시 문서 이동 단축키를 제공합니다. Ctrl-Tab이죠.
근데 이것도 OS차원에서 콘트롤 하진 않는 듯합니다. Ctrl-Tab으로 이동이 되는 녀석이 있고 안 되는 녀석이 있습니다.

작업이 복잡할 수록 일관성 있는 인터페이스가 편합니다.
최적화 버튼이 파이어폭스에서는 전체화면인 것을 예로 들어서 프로그램 잘못이라고 하셨는데, 예시를 잘못 드셨습니다.
최적화는 말 그대로 최적화입니다. 프로그램이 판단하기에 최적이라고 생각하는 형태로 창을 확대하는 거죠.
애플 프로그램이라고 전부 최대화 안 되는 것도 아닙니다. 말씀하시는 걸 보니 MacOSX 쓰고 계시다곤 하는데 별로 깊이 있게 써본 적은 없으신 걸로 보이네요.
사파리나 파인더는 컨텐츠를 최대한 표시하는 정도까지만 확대되는 것이 최적화 작동 방식이고, 아이무비나 아이포토 등은 꽉 채우는 것이 최적화 작동 방식입니다.
파이어폭스는 단축키라든가 기타 모든 작동 방식을 윈도 사용자가 쉽게 적응하도록 하는 것이 제작 방침이라 전체화면을 최적화로 구현한 것으로 판단됩니다. (F5눌러도 Cmd-R 눌러도 리프레시가 되고, F11 누르면 익스플로러처럼 전체화면까지 지원합니다. 탭 이동도 익스플로러 단축키와 동일하죠.)
따라서 파이어폭스 최적화 버튼이 화면을 꽉 채우는 것은 OS차원의 일관성이 없는 예로 적절하지 않습니다. 왜냐하면 최적화버튼은 OS가 책임지는 영역이 아니기 때문입니다.
알트탭 눌렀을 때 뜨는 아이콘 목록은 OS가 책임지는 영역입니다.
여기에 어떤 프로그램은 문서가 아닌 프로그램 자체 인스턴스가 목록에 뜨고 어떤 프로그램은 안 뜨는 것은 OS차원에서 일관성을 보장하지 않는 겁니다.
물론 코드 상에서야 지정된 방식으로 작동하도록 돼 있고 프로그램(MS Office)이 잘못 짠 것일 수도 있습니다만, 그런 게 허용되는 것 자체가 윈도가 문서와 프로그램 인스턴스를 명확히 구분하지 않는다는 방증이 되겠죠.
그래서 관리가 느슨하다고 다른 분이 지적하신 것일 테고, 저도 이와 같은 일관성 부재가 새 프로그램을 추가할 때마다 사용 방법을 익혀야 하는 문제를 야기한다고 생각합니다.
저야 컴퓨터를 늘 만지고 있으니 그나마 낫습니다만, 그렇지 않은 주변인이 새로운 프로그램을 접했을 때 적응하는 걸 보면 맥 쪽이 윈도보다 훨씬 빠릅니다. (이건 좀 성급한 일반화일 수 있습니다만)

카산드라님은 선점형 비선점형 따져 가면서 말씀하시는 걸 보면 굉장히 컴퓨터 전반에 대해 해박할 것 같은데 몇몇 댓글들로 봐서는 그냥 읽은 지식을 바탕으로 실무에 대한 감 없이 이론만 읊고 계신 것 같기도 하군요.
이론도 중요하겠습니다만 실무에서 수년간 경험한 것을 바탕으로 펴는 주장에 이론만으로 응대하면 별로 대화 상대로부터 인정받기 쉽지 않으실 겁니다.

  /pighair

데스크탑이 문서 윈도우가 여러개 열려 있습니다.

매킨토시는 문서에 바로 접근이 불가능한 일관성을 가지고 있습니다.

(아시다 시피 커맨드+탭으로 해당 프로그램 선택 그리고 `+탭으로 해당
 문서를 찿아감)

윈도우는 데스크탑에 열려 있는 문서에 바로 접근 가능 합니다.
(키보드만 쓰고자 한다면.. 알트+탭 만으로..
 마우스를 쓴다면 바로 작업표시줄에서 해당 문서(제목이 대략 표시되므로
 손쉽게 선택 가능)


매킨토시의 환경은 분명 일관성을 가지고 있습니다.
그러나 여러번의 키바꿈과 부가적 키동작이 필요합니다.

게다가 데스크탑에 존재하는 문서 개체에 대하여 데스크탑 레벨에서
직접 접근이 사실상 불가능 합니다. (해당 프로그램에 우선 들어가야 하므로)

(재수가 좋아서 해당 다큐멘트가 가려져 있지 않다면 마우스로 해당 다큐멘트
 윈도우를 클릭 하면 되겠지만... 가려져 있다면 직접 접근은 불가능 하며..
 키보드만으로 바로 접근은 하나의 프로그램에 하나의문서만 열려있는
 특별한 경우 이외에는 불가능)

윈도우 환경도 일관성을 가지고 있습니다.
작업 표시줄 레벨에서는 ...

그리고 키보드만으로 컨트롤 하는 경우에는...  문서개체와 프로그램을 따로
표시하는 경우도 있지만... 작업관리자가 그것을 명확히 구별하지 못하는 것도
아닙니다. 구체적인 증거는 문서와 프로그램의 아이콘 모양이 다르다는 점 입니다.

그리고 윈도우의 경우 데스크탑에 존재하는 문서 개체에 대하여 데스크탑 레벨에서
직접 접근 가능 합니다. (작업 표시줄에서나 작업관리자에서 모두...)

과연 객체지향성을 따진다면 어느쪽이 직관적일까요? 아무리 보아도 윈도우 환경이
더 객체지향성을 가진것으로 느껴 집니다.

사파리나 파이어폭스나 둘다 인터넷 웹을 보여주는 도구 라는 점에서 같은 목적의
소프트웨어 입니다.  따라서 화면 최대화을 하였을때 다른 모습을 보여주는 것은
일관성 상실임에 분명 합니다. 물론 운영체계 탓이 아니라 프로그램 탓입니다.


키보드만으로 문서이동이 매킨토시에서는 편할지 모르지만..
윈도우에서는 마우스이동이던지 키보드 이동이던지 둘다 편합니다.

작업표시줄 이동도 매킨토시에서 엑스포제를 거쳐서 행하는 선택 보다는
훨씬 빠르고 편한 동작이 가능 합니다.

그리고 알트탭 이동도... 매킨토시 보다는 간편합니다.
(매킨토시는 커맨드+탭 후에 손가락을 `로 이동하여 `+탭을 눌러야 하므로)

만일 추가적 손가락 놀림이 편안하다 여긴다면... 그것은 해당 방식에
적응된것에 불과 하다고 생각합니다. -비슷한 경우 한/영 전환에서
한/영 버턴을 한번 누르는 것과 시프트+스페이스로 전환하는 것의
차이와 유사 합니다.. 분명 한/영 버턴이 편하지만.. 오랫동안 시스트+스페이스에
적응 되었다면 그것을 편하다고 여기는 것과 유사한 이치 입니다.

구태여 그룹화의 일관성을 초보자에게 묻는다면...

매킨토시의 작업 관리자-->(커맨드+탭 여러번)-->해당프로그램 선택
-->(`+탭 여러번) 해당 다큐멘트 선택의 방식이 초보자에게 쉬울까요?

또는

(매킨토시의 엑스포제 (대개는 F9키)
--> 다큐멘트 윈도우의 축소본 나열 (그룹화되어 있지 않음)
--->해당 다큐멘트의 선택

아니면....

작업 표시줄 설정에서 그룹화로 설정(윈도우7디폴트)
작업 표시줄의 해당 프로그램 선택-->해당다큐멘트 선택의
방식이 쉬울까요?

(제경우는 윈도우 초보자는 아니라서 개별 보기를 선호 합니다.)


저는 그냥 읽은 지식을 나열 하는 것이 아닙니다. 왜 그런 판단을 하시는지
모르겠군요...    다양한 운영 체계를 직접 사용해본 경험에서 우러나오는
글이 대부분 입니다.  (따라서 대부분의 반론이나 질의에 모두 대답 하는
편입니다.-이게 이론서따위만  보아서 가능하다고 여기시는 것일까요?)

  /카산드라

또 로그인하게 만드시는군요.
무엇이 더 직관적인 인터페이스이며 뭐가 원류이고
뭐가 배낀건지에 관한 얘기를 드렸는데
갑자기 OLE얘기가 나오고 시장점유율 얘기가 나오고..

1995년에 "매킨토시유저인터페이스 가이드"란 책(제목이 맞나?)을
본 적이 있습니다. 국내에서 성안당이라는 출판사에서 번역본이
나오기도 했죠.
그책을 보면 왜 다이얼로그 박스에서 승인버튼이 오른쪽에
취소버튼이 왼쪽에 있어야 하는지 설명 같은것이 나옵니다.
맥오에스는 심리적으로 안정감과 사람의 습관까지 연구하여 만든
인터페이스 입니다. 윈도우의 가져다 베낀 인터페이스하고는
질적으로 틀린 겁니다.
맥 상단의 메뉴바는 어떤 운영체계도 따라하지 못한 매우
유니크한 겁니다. 그 밖에 요소들 중에도 독창적인 것이 꽤 있죠.
애플개발자들은 인터페이스를 만들면서, 어플리케이션을 만들면서
사용자의 습관까지 고민했습니다.
가장 쓰기 좋은 법칙을 만들고 그것을 검증하면서
지금의 스노우레오파드까지 오게 된 거죠.
 
남이 만든것중에 좋은건 돈을 쓰든 법을 쓰든 무조건 가져다
쓰는 마이크로소프트하고는 근본적으로 철학이 틀립니다.

쓰레드가 어쩌니, 테스크가 어쩌니 하는 건 개발자들 얘기고,
뭐가 좋고 나쁘고 얘기는 개인적 취향이므로 어쩔 수 없겠지만
맥을 선택하고 쓰는 사람들은 왜 맥이 좋은지,
맥의 운영체계가 왜 좋은지 느낌으로 알 수 있습니다.

맥도 불편한 점이 한두가지가 아니죠,
98~00년까지 맥의 시장점유율이 곤두박질쳤을때
그 불편함은 최고조에 달했습니다.
(애플이 MS로부터 투자도 받았었죠 그때..)
하지만 애플은 그것을 극복하고 더 나은 제품을
만들고자 노력해서 현재에 이르럿죠.
아이폰OS라는 새로운 개념도 등장했고요.

마이크로소프트도 좋은 어플을 많이 만들었죠,
특히 아웃룩,오피스 등 사무통합부문은 독보적입니다.
사실인지는 모르겠으나 애플의 경리회계파트에서는
PC(특히 엑셀을 중심으로 오피스시리즈)를 쓴다고 하구요,
마이크로소프트 디자인/홍보파트에서는 맥을 쓴다고 하더군요.
 
어느 하나가 모든걸 아우를 정도로 완벽한 건 없습니다.
다만 쓰는 사람이 누구인지에 따라서 선택되어 지는 거죠.
윈도우의 유저가 많으니 윈도우가 우수하다고 할 수도
있겠지만 그걸 모두 마이크로소프트가 만든건 아니죠.
돈의 힘이고 논리입니다.

적어도 애플은 그런 양아치짓을 서슴없이 하는
회사는 아닙니다.
그래서 전 애플이 좋고, 맥이 좋고,
OS7~X를 좋아하고, 그들의 철학을 좋아하고,
그들의 독창성을 좋아합니다.

거기에 맞추어 생활하다보니 윈도우가 불편하군요...ㅎ!

  /배투

운영체계 토론에서 감성은 배제하는 것이 좋습니다.
그것은 객관이 아니고 주관에 불과하기 때문 입니다.

PC용 GUI에서 애플의 매킨토시는 시장을 선도 했던 업체라는점은
사실 입니다.

그러나 마우스나 GUI의 개발자는 애플의 매킨토시가 아닙니다.
마찬가지로 휴대형 MP3나 스마트폰을 맨처음 개발한것은
애플사가 아닙니다.

다만 그것을 개량한 업체는 맞습니다.
(이점은 M$의 윈도우 운영 환경도 마찬가지 입니다.)

또한 심리적인 편안함을 준다는 것도 부정하지 않습니다.
(제가 맥 OSX사용자인 이유도 바로 이것과 무관하지 않습니다.)



애플의 상방 툴바 구조는 적어도 싱글 테스킹환경에서나...
단순 테스크스위쳐 환경에서는 우수한 인터페이스라 할수도 있습니다.

그러나 멀티테스킹 환경에서는 사정이 약간 다릅니다.

여러개의 어프리케이션을 실행시... 사용되는 다큐멘트의 종류가 바뀌면 상방툴바의
메뉴도 바뀌게 됩니다.

포토샵 같이 외부 팔레트 윈도우가 존재하는 프로그램에서 바탕화면을
클릭하면... 다큐멘트만 남고 메뉴와 팔레트윈도우와 상방 툴바는 사라집니다.

(만일 포토샵만 실행하고 다큐멘트를 열어 놓지 않은 경우에 빈화면을
 클릭하면... 더욱 납득 되지 않는 상황을 경험할수 있습니다.
 데스크탑에서 포토샵이 통채로 사라지는 것을 볼 수  있습니다.)

여러개의 다큐멘트윈도우는 동시에 돌릴때... 상방 툴바의 존재는
마우스 이동의 거리가 증가 되는 문제점이 있습니다.

만일 사용자가 해당 어플리케이션 가리기 메뉴를 선택하면...
이경우 해당 어플리케이션의 다큐멘트는 엑스포제 (일반적으로 F9)
기능을 사용하더라도 보여지지 않는 문제점이 있습니다.

역으로 만일 사용자가 해당 어플리케이션에서 기타가리기 메뉴를
선탹하는 경우 다른 실행중 프로그램의 다큐멘트는  엑스포제 (일반적으로 F9)
기능을 사용하더라도 보여지지 않는 문제점이 있습니다.


이러한 제반 문제점은... 적어도 멀티테스킹 운영 환경이라면... 없는 편이 낫습니다.
(적어도 멀티테스킹 운영 환경이라면 데스크탑은 멀티테스킹이 행해지는 장소이지.. 
 특정 프로그램의 배경(투명한배경)이 아니기 때문입니니다.)


그리고  데스크탑에 존재하는 여러가지 프로그램의 다큐멘트 윈도우가 혼재
되어 있을때... 데스크탑에서 이것을 사용자의 의도대로 정렬하는 기능이
없습니다.

예를 들면 데스크탑에 워드문서와 스프레스쉬트문서 웹 문서가 열려 있을때..
이것을 바둑판 형태나 겹쳐쌓기 형태나 수직나누기나 수평 나누기로
정렬 하는 기능이 없습니다.

(적어도 윈도우 95나 윈도우 XP에서는 이것이 가능 하였습니다.
 작업 표시중에서...정렬하고자 하는 다큐멘트를 선택 (컨트롤+마우스왼쪽키)
 한후 마우스 오른쪽키로 정렬시키고자 하는 방식을 지정 하면 되었습니다.

 윈도우7에서는 새로 도입된 기능과의 중복 때문에 없어진 메뉴이지만...)

(매킨토시는 이것이 될리 없습니다.
 왜나하면 데크탑에 열려 있는 다큐멘트를 데크탑 레벨에서 바로
 접근할수 있는 것이 아니라 해아 프로그램에 일단 들어가서 정렬해야 하기
 때문입니다.)

M$가 시장을 석권한데는... 돈의 논리.. 힘의 논리 이전에...
아범 플래폼의 시장의 석권이 선행 됩니다. (마소는 아범의 운영체계 공급자)

그런데... 아범 PC가 나오기 훨씬 이전의 8비트 시절에 애플2와 애플2 복제품은
시장을 석권 하였습니다.

그리고 아범컴이 나온지 얼마 되지 않은 후에 나온 매킨토시는 아범을 압도하는
성능과 인테페이스를 가진 기종이었습니다.

그러나 사양대비 가격이 지나치게 비싼편이었습니다.

그리고 폐쇄적인 플래폼이었습니다.

따라서 아범이 세상을 석권한것 입니다.

한편 이번 게시물의 본론으로 되로아 간다면...
어도비에서....  매킨토시 OSX에 최적화된 프로그램을 이제서야 출시 하는
이유는....

어도비가 윈도우 시장을 우선시하여 농땡이를 피웠다는 점도 있겠지만...

매킨토시 시스템의 문제도 전혀 없지는 않을것 같습니다.

이른바 유니버설 바이너리 코드가 아닌 인탤 전용의 코드로 작성된
스노우레오파드가 출시된지는 그렇게 시간이 흐르지도 않았습니다.

마치.... 윈도우 3.1에서 윈도우 95로 넘어가던 시기인 1995년에
32비트 윈도우 코드로 작성된 전용 프로그램은 별로 없었던 것과
일면 유사한 상황 같기도 합니다..

(마소가 사전에 준비 하지 않은것도 아닙니다.. 윈도우 3.1시절에도
이른바 win32s 라는 것이 존재 하였습니다.)