수고랄거야 있나요. 사실 제가 가장 좋아하는 브로우저가 Netscape입니다. 얼마전까지 Netscape 4.0을 깔아두고 가끔 사용했었습니다.

그런데 이 브로우저가 이제 화려하게 귀환하려고 하는데 딴지가 걸린 것 같아 마읍잡고 파헤친 것입니다.

링크는 얼마든지 가져가셔도 됩니다. 기사의 본문 역시 1. 출처를 밝히고, 2. 수정없이, 3. 누구나 글을 읽을 수 있는 게시판에 퍼가는 것이라면 큰 상과없습니다.

과거 QAOS.com에서 썼던 라이센스 규칙인데 의외로 지키지 않는 사람들이 많더군요.

천재로 봐주시니 감사합니다. 그러나 천재는 사물을 꿰뚦어 보는 능력, 직관력(Insight)이 있어야 하는데,,, 제게는 그런 능력이 없습니다. 따라서 천재라기 보다는 한분야에 계속 종사하다보니 생긴 통찰력(Hindsight)때문으로 보시면됩니다.

예... 저 역시 처음 JWC님의 글을 보고 테스트한 후 무척 실망했습니다. 그토록 기다렸는데...

그렇지만 역시 중요한 원인은 다른 곳에 있더군요.

AppPath에 Nescape.exe만 추가한 상태에선 xml항목이 설정 되지 않는걸로 알고 있습니다. 윗글에서는 Netscape.exe 키만 조회하는 것처럼 쓰여져 있지만 Netscape.exe 키의 내용까지 모두 조회합니다. 따라서 App Paths에 Netscape.exe만 추가하면 당연히 xml 키를 생성하지 않습니다(NS가 설치되지 않았는데 오동작할 이유가 없죠). 그러나 Netscape을 수동 설치한 후 추가하면 xml 항목이 설정됩니다.

아울러 NS가 설치한 모든 파일, 레지스트리까지 모두 다 조사해 봤습니다. 그러나 의심스러운 점은 발견할 수 없었습니다. 만약 의심스러운 점이 발견됐다면 App Paths에서 Netscape.exe를 지우는 해결 방법은 찾지 못했을 겁니다. 왜냐하면 App Paths는 아주 일반적으로 사용되는 키이기 때문입니다.

또한 Netscape를 실행 하게 되면 xml키가 생성 된다는 걸로 알고 있는데 아닌가요? Netscape을 실행하면 xml 키가 생성되는 것이 아니라 처음 설치할 때 생성됩니다. 그리고 윗글에도 있듯이 App Paths에서 Netscape.exe 키를 삭제하지 않으면 IE가 계속 .xml 키를 생성합니다. 레지스트리 모니터로 감시한 결과입니다.

NS의 문제인지 IE의 문제인지 의아해서 NS를 설치하지 않은 컴퓨터에서 레지스트리를 모니터링했습니다. 그런데 재미있는 것은 NS를 설치한 적도 없는 컴퓨터에서도 Netscape.exe를 조회하고 있습니다.

위의 제 글에도 있듯이 근본적으로 누구의 문제인지는 아직까지는 불명확합니다. 그러나 왜 XML 파일에 접근할 때 NS가 설치되지 않은 컴퓨터에서도 Netscape.exe의 설치 여부를 검사하는 것일까요?

.xml 키는 NS의 버그입니다. 그러나 문제는 .xml 키가 아니라 왜 Netscape.exe 키를 조회하는가 하는 부분입니다.

"View Content in IE" 와 관련된 기능입니다. 문제 해결을 제시한 분의 의견입니다. 공식적인 의견은 아니고요.

저 역시 제 글을 포스팅하고나서 인터넷에서 동일한 글을 보았습니다.

만약 "View Content in IE"와 관련된 NS의 버그라면 제 팁을 적용해도 동일한 문제가 발생해야 합니다. 그러나 제글대로 하면 View Content in IE도 잘 쓸 수 있습니다.

즉, NS와 IE 모두 정상적으로 동작한다는 뜻입니다.

↓

who r u? Extraterrestrial?

Microsoft가 의도적으로 삽입한 것인지 다른 의도가 있는 것인지는 저도 모릅니다 이 부분은 안읽으셨나요?

그리고 NS의 자체의 결함이라면 왜 NS를 설치한적도 없는 컴퓨터에서도 XML 파일에 접근할 때 App Paths\Netscape.exe를 조회하는 것일까요? 그리고 왜 NS를 설치한 컴퓨터에서는 App Paths\Netscape.exe 키를 삭제하면 정상적으로 동작하는 것일까요?

NS의 자체의 결함이라면 그 근거를 제시해주시기 바랍니다.

http://www.mozilla.or.kr/ 을 방문해 보시기 바랍니다.

감사랄 것까지 있나요.

예... 안녕하세요. 고양이중사님.

그렇죠. 어떤 의도로 Netscape.exe를 검사하는 것인지는 모르겠지만 두 가지, 검사하는 것과 키를 삭제하면 정상적으로 보인다는 것이 결합하면 의혹이 생길 수 밖에 없더군요.

즐거운 블로깅이 되시기 바랍니다.

예. 십년된 관행이라면 논리적으로 가장 적절한 설명입니다. 사실 이 문제가 촉발된 이유는 IEBlog가 문제를 해결하는 방법으로 Netscape의 삭제를 권고했기때문에 발생한 문제입니다.

아울러 JWC님의 답변은 IE측 개발자측의 답변이므로 이 부분은 NS 개발자에게 다시 확인해보는 것이 순서일 것 같습니다.

도아님도 오랜시간동안 테스트한다고 수고 많으신 것 같습니다. 저 보다는 CN는 더 고군분투하시더군요. 의외의 장소에서 논쟁이 벌어져서요.

즐거운 주말되세요. CN님도 즐거운 주말되시고요, 다음주 보다 새로운 주제로 만나뵙으면 합니다.

예... "IE 개발자의 말이 사실이라면"이라는 전제를 붙일 수 밖에 없지만 사실이라면 가장 합리적인 설명입니다.

그렇다면 제가 가졌던 의문들이 모두 풀리니까요.

어쨋든 도아님 덕분에 그래도 많은걸 알게 된것 같습니다. 저 역시 JWC님 덕에 App Paths 참조가 오래된 관행이라는 것을 알 수 있었습니다. 이런 사실 하나라도 알게되었으므로 글을 쓴 보람을 느낍니다.

예... IE 개발자의 말이 사실이라면...

IE 개발자의 주장처럼 App Paths를 조회해서 NS의 플러그인을 등록하는 것이 관행이라면 NS의 잘못일 가능성이 큽니다. 아울러 App Paths 조회가 관행이라면 NS의 IE 죽이기라는 주장 역시 설득력이 없는 것은 아닙니다.

다만 이 모든 주장은 IE 개발자가 언급한 것이라 NS측에 문의해서 확인할 필요는 있는 것 같습니다.

도아님도 왼손잡이? 좌측 통행을 많이 하죠(^^;)