현재 쓰는 PC를 조립할때 부터 Windows7로 OS를 넘어오면서 64bit를 쓰기 시작했다..
메모리를 8기가 달고 나서부터는 제대로 쓰기 위해서는 64bit를 쓸 수 밖에 없었다.
그러면서 역시나 몇 가지 프로그램들이 OS와의 호환성 때문에 사용 불가능해졌고
(특히나 스캐너와 프린터... 스캐너야 산지 이제 10년째 되니까 그렇다고 하지만 프린터는 캐논 LBP3200이라 산지 그리 오래 되지도 않는구만..)
대신 DirectX11과 같이 이전 OS에서 더이상 지원하지 않는 프로그램들을 사용할 수도 있게 되었다.
그런데 아직까지는 대부분의 프로그램들이 32bit이고 64bit로 넘어가는 과도기이므로 현재로서는 두 가지 프로그램을 같이 사용할 수 밖에 없는데 여기서 의외로 좀 헷갈리는 부분들이 있다.
예전에 16bit 에서 32bit로 올라갈때는 지금 생각해 보면 의외로 호환성이 그리 좋지도 않았고 또 비교적 빠르게 전환이 되어서 그렇게 큰 차이점이 있던거 같지는 않은데 현재는 아직까지 대세는 32bit인데다가 일반 사용자들이 그냥 쓰기에는 둘 다 별 차이가 없어 보여서 별 생각없이 쓰다가 나중에 삽질했던 경험들이 좀 있다.
관련 내용들을 한 번 정리해 보려고 한다.
1. IE9 64bit용
현재 64bit로의 전환이 이루어지고 있는 중이기 때문에 제작사가 부지런하거나 여유가 있을 경우는 32bit/64bit용 프로그램을 별도로 만들기도 한다.
MS야 당연히 Windows OS를 만드는 회사이다 보니 IE 같은 경우도 두 가지 버전이 설치가 된다.
그런데 처음에 이상하게 생각했던 부분은 두 가지의 IE 중 32bit IE가 기본 IE로 설정이 되어있는 것이다.
나는 64bit OS를 쓰는 김에 되도록이면 전환을 먼저 하려고 두 가지 버전을 제공하는 프로그램은 64bit용을 먼저 사용하려고 했었다.(물론 OS가 64bit니까 그게 효율이 낫지 않을까 하는 생각도 들었고..)
그런데 여기 맹점이 하나 있었다.
프로그램이 64bit니까 IE에 붙어서 도는 프로세스들도 모두 64bit여야 하는 것이다.
즉, IE용 ActiveX들, 쓰기는 싫지만 예를들어 금융거래를 위한 플러그인 들도 유명한 것이 아니면 64bit용은 제공을 하지 않는 상황인 것이다.
특히나 지금은 아니지만 초기에는 Flash조차도 베타버전으로 패치가 상당히 자주 나왔었다.
(아래 글들이 대개 주제는 다르지만 근본 원인은 이것과 동일한 내용임)
처음에 왜 64bit OS에 32bit 프로그램을 default 로 설정했나 잠시 의아해 했었지만 이걸 한 번 당하고 나니까 그렇구나 싶으면서도 64bit로의 전환이 쉽지 않겠다는 생각이 들기 시작했다.
그래서 그런지 모르겠지만 요즘 ActiveX를 쓰는 사이트가 아니면 주로 Firefox와 Chrome을 사용하는데 이 두 프로그램은 아예 64bit용을 제공 자체를 하지 않는다.
(물론 이건 내부적으로 64bit 작업을 하지 않아서일 가능성이 더 크지만..)
2. Virtual Dub/비디오 인코딩
동영상 인코딩을 할 때 Virtual Dub을 사용하여 주로 작업한다.
편집작업 같은 건 보통 잘 안하고 오디오 뽑거나 용량/크기 조절하거나 등등의 작업에 많이 사용한다.
그런데 새 버전을 받으러 가봤더니 웬일로 64bit 버전도 같이 제공을 하는 것이다.
그런데 제공을 하면서 별로 권장은 하지 않고 있었다. 코덱 문제로 되도록이면 32bit 버전을 쓰라고..
무슨 얘긴가 싶었는데 각각의 프로그램으로 영상을 로드한 다음 재인코딩을 위해 코덱설정 페이지를 가보고서 이유를 알 수 있었다.
<32bit virtual dub. 한페이지가 넘어가는 코덱 목록이 나온다>
<64bit Virtual Dub. 반페이지도 못 채운다>
어차피 Virtual Dub이 자체적으로 인코딩을 하는 프로그램이 아니라 환경을 잡아주고 코덱을 이용해서 인코딩을 수행하기 때문에 프로그램이 64bit라봤자 대부분의 코덱이 32bit인 상황에서 인코딩할 코덱 자체가 거의 없다.
Windows에 기본적으로 깔려있는 거의 15~20년 묵은 사용할 일이 전혀~ 없는 코덱들만이 보인다.(하나 빼고..)
주로 사용하는 Xvid나 요즘 들어 많이 사용하는 H.264 계열 등은 설치가 되지 않았다.
따로 64bit 버전 코덱이 있는지는 모르겠으나 내가 사용하는 코덱인 K-Lite Codec에서 배포하는 64bit 용도 따로 설치를 했건만 역시 리스트에는 보이지 않는다. 디코딩 전용 코덱만 있는 것인가..
여튼 혼자 앞서 나간다고 되는 건 아닌 것 같다.
3. Total Commander
사용한지 15년이 다 되어가고 정품구매해서 사용하고 있는, 없으면 PC 사용 효율이 절반 이하로 급락하는 필수 프로그램인 Total Commander도 비슷한 문제가 있다.
Total Commander는 아직도 16bit 버전부터 지원하고 있는데(이제 16bit 는 6.x까지만 지원하는 걸로 알고 있다. 지금 현재 최신버전은 7.56a) 64bit 버전은 8.0부터 지원을 목표로 아직 베타 테스트중이다.
Total Commander에서 파일이나 폴더를 누르면 일반적으로 탐색기 등에서 눌렀을 때 나오는 Context 메뉴에 Total Commander에서 지원하는 추가 메뉴들이 같이 나타난다.
그런데 Windows7에서는 아래 그림과 같이 X64라는 항목과 함께 그 메뉴 위로 갔을 때 세부 메뉴로서 윈도우 자체의 Context 메뉴가 나타난다.
처음에는 Windows7이라서 그런가보다 하고 그냥 넘겼는데.
쓰다가 보니까 귀찮기도 하지만 X64로 커서를 옮기면 만일 PC가 좀 버벅이던 상황이거나 하면 오른쪽 메뉴가 나타나는데 시간이 좀 걸린다. 하드를 읽는 소리도 들리고.
그래서 위의 일들을 좀 겪은 다음에 보니 아무래도 32bit 에서 저런 context 메뉴를 읽는데 제약이 있어서 64bit용으로 구성된 저것만 읽어주는 프로그램이 따로 있어서 그걸 통해서 context를 읽은 뒤 소켓통신이던, IPC던 통해서 전송받아 표시하는, 그러한 좀 비효율적인 방식으로 도는 것이 아닌가 하는 생각이 들었다.
그래서 Total Commander 설치 폴더를 보니 역시나 그런 프로그램들이 존재했다.
TCMDX32.EXE : Total Commander 32bit->64bit helper tool
TCMDX64.EXE : Total Commander 32bit->64bit helper tool
위 프로그램은 32bit용이지만 아래 프로그램은 64bit 용이다.
아마 저런 프로그램을 실행해서 읽어오는 듯 하다.
그래서 아직 베타버전이긴 하지만 64bit용 Total Commander 8을 깔아서 봤더니 원래 나오던 형식대로 아래와 같이 표시가 된다.
물론 버벅이지도 않고 바로 나온다.
그래서 잠깐 정식 버전 나오면 64bit로 갈아타야지 싶다가...
역시 받을 때 경고가 나왔듯이 64bit로 실행하면 지금까지 쓰던 그 많던 플러그인들이 상당수가 사용불가가 되는 상황이라..
Total Commander를 플러그인 없이 쓰는건 Firefox를 Plugin 없이 쓰는 것의 절반 정도로 불편하기 때문에..
아무래도 Plugin들의 옮겨가는 상황을 보고 판단해야 할 듯 하다..
4. Java
이건 직업상 Java를 이용해서 개발일을 하다 보니 생긴 문제인데..
물론 Java 자체는 OS도 상관없는데 32bit/64bit야 문제가 될 이유가 없다.
예전에도 주로 Unix들에서는 자바가 32bit/64bit용이 모두 설치가 된 경우가 많아서(물론 요즘 Unix OS는 다들 64bit이다) 어느걸로 실행하도록 잡냐고 물어올 경우 나는 대개 64bit로 하라고 해왔다. OS가 64bit니 그게 가장 성능향상에 도움이 될 듯 하여..
그런데 개발환경으로 사용하는 Eclipse의 경우는 32/64bit가 별도로 배포된다.
이것까지는 이미 알고 있었는데 일반적으로 순수 Java는 상관이 없지만 Eclipse 는 UI 사용을 위해 OS Independent한 Swing을 사용하지 않고 성능향상등의 목표를 위해 OS Dependent한 SWT를 사용하기 때문에 OS별로도 배포본이 따로 있었고 물론 32/64bit용도 별도로 존재한다.
그래서 아무 생각없이 64bit용을 받아서 실행해 봤는데 화면도 안뜨고 오류발생..
또 곰곰히 생각을 해봤는데 아차 싶은게.. Java도 32/64bit용이 따로 있기 때문에 64bit로 깔아야 했던 것..
참고로 이런저런 상황에 대응하기 위해 Java 는 1.2버전부터 최근의 7까지 모두 깔아놓는데 다 설치본으로 깔면 꼬일까봐 최신버전만 인스톨을 하고 나머지는 기존에 설치해 놓은 JDK 폴더 전체를 복사해서 쓰고 있는데..
(JAVA_HOME이나 Path만 신경쓰면 복사해 써도 별 문제 없음. 특히나 Eclipse에서는 알아서 맞춰주므로 더 편함)
예전에 깔아놨던 32bit용을 copy해서 사용해서 생긴 문제였다.
순수 Java 를 실행했으면 역시나 또 문제가 없는 것이었지만 SWT 사용을 위해 64bit dll이 존재했기 때문에 JNI에서 문제가 발생했던 듯...
Java 인스톨을 64bit용으로 하니 이제 문제가 해결되었다.
위의 네 가지는 내가 실제로 겪었던 문제이고 일부는 다른 사람들도 겪을 만한 일들이긴 한데.. 아마도 64bit로의 완전한 전환이 이루어 질 때까지는 당분간 발생할 문제일 듯 하다.
이러한 문제들 때문에 되도록이면 64bit 프로그램을 사용한다는 원칙을 가지고 있으면서도 일부 32bit 프로그램을 설치할 수 밖에 없는 경우들이 생겼다.
(Oracle 접속을 위한 Client 설치시에도 32bit를 깔아야 했다. oci.dll 을 쓰는 DB 툴들이 다들 32bit기 때문에..-.-;;)
예전 16bit->32bit의 경우에는 16bit에서의 제약이 너무 컸기 때문에 프로그램 개발자들의 입장에서도 되도록이면 32bit로 만드려고 했기에 비교적 쉽게 넘어갈 수 있었지만 32->64bit의 경우는 대부분의 일반 프로그램에서 32bit를 사용해도 메모리 부족 등의 문제가 생길만한 프로그램은 일부 멀티미디어 프로그램을 제외하고는 거의 없고 64bit로 넘어온다고 큰 이득도 없는 편이라(개별 프로그램에서는) 아마 시간이 꽤나 걸리지 않을까 싶다.
일부 CPU에서는 벌써 128bit를 쓰는 것도 있는걸로 아는데(PC는 아니지만 PS3의 Cell.. Register만 128bit 인지도...) 어느 정도까지 올라갈지 모르겠지만 당분간은 64bit까지만 가면 잘 바뀌지 않길 바란다.
메모리를 8기가 달고 나서부터는 제대로 쓰기 위해서는 64bit를 쓸 수 밖에 없었다.
그러면서 역시나 몇 가지 프로그램들이 OS와의 호환성 때문에 사용 불가능해졌고
(특히나 스캐너와 프린터... 스캐너야 산지 이제 10년째 되니까 그렇다고 하지만 프린터는 캐논 LBP3200이라 산지 그리 오래 되지도 않는구만..)
대신 DirectX11과 같이 이전 OS에서 더이상 지원하지 않는 프로그램들을 사용할 수도 있게 되었다.
그런데 아직까지는 대부분의 프로그램들이 32bit이고 64bit로 넘어가는 과도기이므로 현재로서는 두 가지 프로그램을 같이 사용할 수 밖에 없는데 여기서 의외로 좀 헷갈리는 부분들이 있다.
예전에 16bit 에서 32bit로 올라갈때는 지금 생각해 보면 의외로 호환성이 그리 좋지도 않았고 또 비교적 빠르게 전환이 되어서 그렇게 큰 차이점이 있던거 같지는 않은데 현재는 아직까지 대세는 32bit인데다가 일반 사용자들이 그냥 쓰기에는 둘 다 별 차이가 없어 보여서 별 생각없이 쓰다가 나중에 삽질했던 경험들이 좀 있다.
관련 내용들을 한 번 정리해 보려고 한다.
1. IE9 64bit용
현재 64bit로의 전환이 이루어지고 있는 중이기 때문에 제작사가 부지런하거나 여유가 있을 경우는 32bit/64bit용 프로그램을 별도로 만들기도 한다.
MS야 당연히 Windows OS를 만드는 회사이다 보니 IE 같은 경우도 두 가지 버전이 설치가 된다.
그런데 처음에 이상하게 생각했던 부분은 두 가지의 IE 중 32bit IE가 기본 IE로 설정이 되어있는 것이다.
나는 64bit OS를 쓰는 김에 되도록이면 전환을 먼저 하려고 두 가지 버전을 제공하는 프로그램은 64bit용을 먼저 사용하려고 했었다.(물론 OS가 64bit니까 그게 효율이 낫지 않을까 하는 생각도 들었고..)
그런데 여기 맹점이 하나 있었다.
프로그램이 64bit니까 IE에 붙어서 도는 프로세스들도 모두 64bit여야 하는 것이다.
즉, IE용 ActiveX들, 쓰기는 싫지만 예를들어 금융거래를 위한 플러그인 들도 유명한 것이 아니면 64bit용은 제공을 하지 않는 상황인 것이다.
특히나 지금은 아니지만 초기에는 Flash조차도 베타버전으로 패치가 상당히 자주 나왔었다.
(아래 글들이 대개 주제는 다르지만 근본 원인은 이것과 동일한 내용임)
처음에 왜 64bit OS에 32bit 프로그램을 default 로 설정했나 잠시 의아해 했었지만 이걸 한 번 당하고 나니까 그렇구나 싶으면서도 64bit로의 전환이 쉽지 않겠다는 생각이 들기 시작했다.
그래서 그런지 모르겠지만 요즘 ActiveX를 쓰는 사이트가 아니면 주로 Firefox와 Chrome을 사용하는데 이 두 프로그램은 아예 64bit용을 제공 자체를 하지 않는다.
(물론 이건 내부적으로 64bit 작업을 하지 않아서일 가능성이 더 크지만..)
2. Virtual Dub/비디오 인코딩
동영상 인코딩을 할 때 Virtual Dub을 사용하여 주로 작업한다.
편집작업 같은 건 보통 잘 안하고 오디오 뽑거나 용량/크기 조절하거나 등등의 작업에 많이 사용한다.
그런데 새 버전을 받으러 가봤더니 웬일로 64bit 버전도 같이 제공을 하는 것이다.
그런데 제공을 하면서 별로 권장은 하지 않고 있었다. 코덱 문제로 되도록이면 32bit 버전을 쓰라고..
무슨 얘긴가 싶었는데 각각의 프로그램으로 영상을 로드한 다음 재인코딩을 위해 코덱설정 페이지를 가보고서 이유를 알 수 있었다.
어차피 Virtual Dub이 자체적으로 인코딩을 하는 프로그램이 아니라 환경을 잡아주고 코덱을 이용해서 인코딩을 수행하기 때문에 프로그램이 64bit라봤자 대부분의 코덱이 32bit인 상황에서 인코딩할 코덱 자체가 거의 없다.
Windows에 기본적으로 깔려있는 거의 15~20년 묵은 사용할 일이 전혀~ 없는 코덱들만이 보인다.(하나 빼고..)
주로 사용하는 Xvid나 요즘 들어 많이 사용하는 H.264 계열 등은 설치가 되지 않았다.
따로 64bit 버전 코덱이 있는지는 모르겠으나 내가 사용하는 코덱인 K-Lite Codec에서 배포하는 64bit 용도 따로 설치를 했건만 역시 리스트에는 보이지 않는다. 디코딩 전용 코덱만 있는 것인가..
여튼 혼자 앞서 나간다고 되는 건 아닌 것 같다.
3. Total Commander
사용한지 15년이 다 되어가고 정품구매해서 사용하고 있는, 없으면 PC 사용 효율이 절반 이하로 급락하는 필수 프로그램인 Total Commander도 비슷한 문제가 있다.
Total Commander는 아직도 16bit 버전부터 지원하고 있는데(이제 16bit 는 6.x까지만 지원하는 걸로 알고 있다. 지금 현재 최신버전은 7.56a) 64bit 버전은 8.0부터 지원을 목표로 아직 베타 테스트중이다.
Total Commander에서 파일이나 폴더를 누르면 일반적으로 탐색기 등에서 눌렀을 때 나오는 Context 메뉴에 Total Commander에서 지원하는 추가 메뉴들이 같이 나타난다.
그런데 Windows7에서는 아래 그림과 같이 X64라는 항목과 함께 그 메뉴 위로 갔을 때 세부 메뉴로서 윈도우 자체의 Context 메뉴가 나타난다.
쓰다가 보니까 귀찮기도 하지만 X64로 커서를 옮기면 만일 PC가 좀 버벅이던 상황이거나 하면 오른쪽 메뉴가 나타나는데 시간이 좀 걸린다. 하드를 읽는 소리도 들리고.
그래서 위의 일들을 좀 겪은 다음에 보니 아무래도 32bit 에서 저런 context 메뉴를 읽는데 제약이 있어서 64bit용으로 구성된 저것만 읽어주는 프로그램이 따로 있어서 그걸 통해서 context를 읽은 뒤 소켓통신이던, IPC던 통해서 전송받아 표시하는, 그러한 좀 비효율적인 방식으로 도는 것이 아닌가 하는 생각이 들었다.
그래서 Total Commander 설치 폴더를 보니 역시나 그런 프로그램들이 존재했다.
TCMDX32.EXE : Total Commander 32bit->64bit helper tool
TCMDX64.EXE : Total Commander 32bit->64bit helper tool
위 프로그램은 32bit용이지만 아래 프로그램은 64bit 용이다.
아마 저런 프로그램을 실행해서 읽어오는 듯 하다.
그래서 아직 베타버전이긴 하지만 64bit용 Total Commander 8을 깔아서 봤더니 원래 나오던 형식대로 아래와 같이 표시가 된다.
그래서 잠깐 정식 버전 나오면 64bit로 갈아타야지 싶다가...
역시 받을 때 경고가 나왔듯이 64bit로 실행하면 지금까지 쓰던 그 많던 플러그인들이 상당수가 사용불가가 되는 상황이라..
Total Commander를 플러그인 없이 쓰는건 Firefox를 Plugin 없이 쓰는 것의 절반 정도로 불편하기 때문에..
아무래도 Plugin들의 옮겨가는 상황을 보고 판단해야 할 듯 하다..
4. Java
이건 직업상 Java를 이용해서 개발일을 하다 보니 생긴 문제인데..
물론 Java 자체는 OS도 상관없는데 32bit/64bit야 문제가 될 이유가 없다.
예전에도 주로 Unix들에서는 자바가 32bit/64bit용이 모두 설치가 된 경우가 많아서(물론 요즘 Unix OS는 다들 64bit이다) 어느걸로 실행하도록 잡냐고 물어올 경우 나는 대개 64bit로 하라고 해왔다. OS가 64bit니 그게 가장 성능향상에 도움이 될 듯 하여..
그런데 개발환경으로 사용하는 Eclipse의 경우는 32/64bit가 별도로 배포된다.
이것까지는 이미 알고 있었는데 일반적으로 순수 Java는 상관이 없지만 Eclipse 는 UI 사용을 위해 OS Independent한 Swing을 사용하지 않고 성능향상등의 목표를 위해 OS Dependent한 SWT를 사용하기 때문에 OS별로도 배포본이 따로 있었고 물론 32/64bit용도 별도로 존재한다.
그래서 아무 생각없이 64bit용을 받아서 실행해 봤는데 화면도 안뜨고 오류발생..
또 곰곰히 생각을 해봤는데 아차 싶은게.. Java도 32/64bit용이 따로 있기 때문에 64bit로 깔아야 했던 것..
참고로 이런저런 상황에 대응하기 위해 Java 는 1.2버전부터 최근의 7까지 모두 깔아놓는데 다 설치본으로 깔면 꼬일까봐 최신버전만 인스톨을 하고 나머지는 기존에 설치해 놓은 JDK 폴더 전체를 복사해서 쓰고 있는데..
(JAVA_HOME이나 Path만 신경쓰면 복사해 써도 별 문제 없음. 특히나 Eclipse에서는 알아서 맞춰주므로 더 편함)
예전에 깔아놨던 32bit용을 copy해서 사용해서 생긴 문제였다.
순수 Java 를 실행했으면 역시나 또 문제가 없는 것이었지만 SWT 사용을 위해 64bit dll이 존재했기 때문에 JNI에서 문제가 발생했던 듯...
Java 인스톨을 64bit용으로 하니 이제 문제가 해결되었다.
위의 네 가지는 내가 실제로 겪었던 문제이고 일부는 다른 사람들도 겪을 만한 일들이긴 한데.. 아마도 64bit로의 완전한 전환이 이루어 질 때까지는 당분간 발생할 문제일 듯 하다.
이러한 문제들 때문에 되도록이면 64bit 프로그램을 사용한다는 원칙을 가지고 있으면서도 일부 32bit 프로그램을 설치할 수 밖에 없는 경우들이 생겼다.
(Oracle 접속을 위한 Client 설치시에도 32bit를 깔아야 했다. oci.dll 을 쓰는 DB 툴들이 다들 32bit기 때문에..-.-;;)
예전 16bit->32bit의 경우에는 16bit에서의 제약이 너무 컸기 때문에 프로그램 개발자들의 입장에서도 되도록이면 32bit로 만드려고 했기에 비교적 쉽게 넘어갈 수 있었지만 32->64bit의 경우는 대부분의 일반 프로그램에서 32bit를 사용해도 메모리 부족 등의 문제가 생길만한 프로그램은 일부 멀티미디어 프로그램을 제외하고는 거의 없고 64bit로 넘어온다고 큰 이득도 없는 편이라(개별 프로그램에서는) 아마 시간이 꽤나 걸리지 않을까 싶다.
일부 CPU에서는 벌써 128bit를 쓰는 것도 있는걸로 아는데(PC는 아니지만 PS3의 Cell.. Register만 128bit 인지도...) 어느 정도까지 올라갈지 모르겠지만 당분간은 64bit까지만 가면 잘 바뀌지 않길 바란다.
최근 덧글