TLLOC.dll문제는 64bit 노트북이라는 것..회사에서 개발중인 대부분은 Visual Studio 6.0 기반의 32bit 프로젝트이기 때문에 Visual Studio 6.0을 포기할 수 없었다. 해보지는 않았지만 Visual Studio 2008로 프로젝트를 구성하면 된다고 하지만..그 많은 소스파일들과..설정, 라이브러리 호환(오래전에 포스팅한 버클리DB)..등의 부가적인 문제가 너무 귀찮아 질 듯하여 Visual Studio 6.0을 끝까지 고수하기로 했다.
사전 조사결과, 설치상의 문제점, SDK 설치의 문제점, 디버깅 할때 문제가 발생가능 하다는 점을 알아두고 작업에 들어갔다.
대부분 검색하여 문제를 해결하는 바람에 스크릿샷은 없다.
설치 중간 중간 윈도우 설정을 바꿔가며 진행하여 언제쯤 했는지 못르겠지만 사용자 계정 컨트롤도 항상 알리지 않음으로 설정했다. TakeOwnerShip 관련 레지스트리도 등록했다.
윈도우7 64bit - Visual Studio 6.0을 설치 하는데 발견된 문제점(기억나는것)
1. 설치 자체가 불가
설치 마지막 즈음에 SETUPWIZ.INI 파일 관련해서 에러가 났다. 이땐 SETUPWIN.INI파일을 직접 수정해주어야 하므로 이미지 파일을 사용할 경우 압출을 풀어 SETUPWIN.INI 파일 내용 중
VmPath=ie4\msjavx86.exe
위 부분 라인을 삭제해준다. 그리고 다시 설치를 진행하면, 일단, 설치는 완료된다.
VmPath=ie4\msjavx86.exe
위 부분 라인을 삭제해준다. 그리고 다시 설치를 진행하면, 일단, 설치는 완료된다.
2. February SDK 2003 설치 불가
the image fule ~~~setup64.exe is valid, but is not for a machine type other then the current machine.
February SDK 2003은 Visual Studio 6.0을 지원하는 공식적인 마지막 SDK라고 한다.(표현이 적당한지 모르겠다) 문제는 64bit에서 안깔린다. 절대로
sdk 설치 파일은 setup과 setup64가 있음에도 불구하고 절대 안깔린다. 적어도 필자는 실패했다. 32bit 환경에서 64bit 프로그래밍이 가능하도록 64bit 개발용 sdk를 설치한다는 뜻인지..
수많은 검색 끝에 외국 포럼에서 setup64.exe를 setup.exe로 rename하고..뭐 그런 글이 있었지만...해결책은 아닌 듯 했다.
원문 : http://www.sevenforums.com/software/22923-visual-c-6-platform-sdk-feb-2003-installation.html
어챂 현재로서는 sdk가 32bit용만 필요하므로 뭐든 깔리기만 하면 되지만 설치 프로그램(setup) 자체가 64bit 에서 동작이 안되는 문제인 것이었다.
결국 다시 검색
금쪽 같은 한국어 페이지 : http://www.mediamob.co.kr/ryusw/frmView.aspx?id=188794
결국 Windows Server 2003 SP1 SDK를 설치했다.
Windows Server 2003 SP1 SDK 이미지 파일 다운로드 페이지
http://www.microsoft.com/download/en/details.aspx?id=15656
그리고 기존의 프로젝트를 컴파일 하는데,
uuid.lib(exdisp_i.obj) : fatal error LNK1103: debugging information corrupt; recompile module
조금만 문제가 기술적으로 간다라는 생각이 들면...그냥 포기해버리는 경우가 있으나..난 64bit 노트북에 윈도우7 64bit를 쓰면서 예전 개발 프로젝트를 그대로 진행하겠어! 라는 고집으로 다시 검색을 했다.
첫번째 찾은 해결책은 Project Setting을 변경하는 것이다.
Project - Setting 애서 Link 탭의 Debug Category를 선택하여 Debug Info를 해제하는 것이다. 즉, 디버깅 정보가 포함되어야 하는데 uuid.lib에서 디버깅 정보를 가지고 올수 없다는 메세지 였던 것이다. 결과적으로 Release Mode에서는 문제가 없다는 것.
그래서..Debug info를 체크해제하면..디버깅은 어떻게 하나??
난..그런거 못한다...디버깅 못하면 안댄다....이 방법은 패스....
해결책은 의외로 간단했다. 32bit 시스템에서 설치했던 라이브러리를 복사해오면 되는 것이다.
위와 같은 문제는 Windows Server 2003 SP1 SDK 가 설치된(대부분 C:\Program Files\Microsoft Platform SDK) 안에 Lib폴더에 uuid.lib파일을 혹시나 백업해두고 32bit 시스템에서 설치했던 February 2003 SDK의 uuid.lib를 가져다 놓고 다시 빌드하면 문제없이 빌드 및 사용가능 하다.
필자의 경우 현재까지 uuid.lib, shell32.lib 파일 관련하여 발생하는 문제를 위와 같이 해결했다. 현재까지는 빌드된 프로젝트 결과물의 동작에서 이상한 점을 느끼진 못했다.
그리고 문득 생각이 들었다..어차피 link만 걸리는 거면 해당 라이브러리만 있으면 되는거 아닌가. 처음 문제제기는 February SDK 2003의 설치가 불가능 하다는 것이었다. 결국 내가 필요한건 SDK의 Library 파일과 Header파일이 아닌가. 32bit 시스템에 설치했던 라이브러리를 통째로 복사해오면 되지 않는가하는 것이다. 그리고 Visual Studio 6.0 option->directories에 해당 폴더만 추가하고 최상위로 올리면 되지 않느냐 하는 것이다. 물론 그렇게 하지는 않았다. 가정이므로.... 하지만 통째로 백업은 해두었다.
sdk 설치 파일은 setup과 setup64가 있음에도 불구하고 절대 안깔린다. 적어도 필자는 실패했다. 32bit 환경에서 64bit 프로그래밍이 가능하도록 64bit 개발용 sdk를 설치한다는 뜻인지..
수많은 검색 끝에 외국 포럼에서 setup64.exe를 setup.exe로 rename하고..뭐 그런 글이 있었지만...해결책은 아닌 듯 했다.
원문 : http://www.sevenforums.com/software/22923-visual-c-6-platform-sdk-feb-2003-installation.html
어챂 현재로서는 sdk가 32bit용만 필요하므로 뭐든 깔리기만 하면 되지만 설치 프로그램(setup) 자체가 64bit 에서 동작이 안되는 문제인 것이었다.
결국 다시 검색
금쪽 같은 한국어 페이지 : http://www.mediamob.co.kr/ryusw/frmView.aspx?id=188794
결국 Windows Server 2003 SP1 SDK를 설치했다.
Windows Server 2003 SP1 SDK 이미지 파일 다운로드 페이지
http://www.microsoft.com/download/en/details.aspx?id=15656
그리고 기존의 프로젝트를 컴파일 하는데,
uuid.lib(exdisp_i.obj) : fatal error LNK1103: debugging information corrupt; recompile module
조금만 문제가 기술적으로 간다라는 생각이 들면...그냥 포기해버리는 경우가 있으나..난 64bit 노트북에 윈도우7 64bit를 쓰면서 예전 개발 프로젝트를 그대로 진행하겠어! 라는 고집으로 다시 검색을 했다.
첫번째 찾은 해결책은 Project Setting을 변경하는 것이다.
Project - Setting 애서 Link 탭의 Debug Category를 선택하여 Debug Info를 해제하는 것이다. 즉, 디버깅 정보가 포함되어야 하는데 uuid.lib에서 디버깅 정보를 가지고 올수 없다는 메세지 였던 것이다. 결과적으로 Release Mode에서는 문제가 없다는 것.
그래서..Debug info를 체크해제하면..디버깅은 어떻게 하나??
난..그런거 못한다...디버깅 못하면 안댄다....이 방법은 패스....
해결책은 의외로 간단했다. 32bit 시스템에서 설치했던 라이브러리를 복사해오면 되는 것이다.
위와 같은 문제는 Windows Server 2003 SP1 SDK 가 설치된(대부분 C:\Program Files\Microsoft Platform SDK) 안에 Lib폴더에 uuid.lib파일을 혹시나 백업해두고 32bit 시스템에서 설치했던 February 2003 SDK의 uuid.lib를 가져다 놓고 다시 빌드하면 문제없이 빌드 및 사용가능 하다.
필자의 경우 현재까지 uuid.lib, shell32.lib 파일 관련하여 발생하는 문제를 위와 같이 해결했다. 현재까지는 빌드된 프로젝트 결과물의 동작에서 이상한 점을 느끼진 못했다.
그리고 문득 생각이 들었다..어차피 link만 걸리는 거면 해당 라이브러리만 있으면 되는거 아닌가. 처음 문제제기는 February SDK 2003의 설치가 불가능 하다는 것이었다. 결국 내가 필요한건 SDK의 Library 파일과 Header파일이 아닌가. 32bit 시스템에 설치했던 라이브러리를 통째로 복사해오면 되지 않는가하는 것이다. 그리고 Visual Studio 6.0 option->directories에 해당 폴더만 추가하고 최상위로 올리면 되지 않느냐 하는 것이다. 물론 그렇게 하지는 않았다. 가정이므로.... 하지만 통째로 백업은 해두었다.
3. 디버깅 오류
프로젝트를 빌드하고, 실행(디버깅)을 했다. 그런데...일단 소스자체에 문제가 있어 Access Violation이 발생하여 디버깅이 중지하고, 소스를 수정하여 다시 실행을 했다.(Visual Studio 6.0 의 Build 결과를 보면 여기서 문제점을 찾을 수 있다.) 1 Error 있음에도 무시고 실행(디버깅)을 했다. 실행이 된다. 그런데 소스를 수정하였슴에도 불구하고, Break Point가 꼬이고 동일한 오류가 발생한다. 앞의 괄호에 써둔 내용을 스스로는 유심히 보지않고는 별 걱정을 다 했다. 64bit라 소스에서 void*를 써서 메모리 계산을 잘못했나..라느니..별 걱정을 다했다.
아무튼..결론은 무엇이냐면 : 디버깅을 하다가 소스의 오류로 인해 프로그램이 종료되면 윈도우7에서는 해당 프로세스가 종료되지 않는다는 것이다. 즉, 소스를 수정해서 다시 빌드하면 해당 실행파일에 접근할 수 없다는 Error가 출력되고, 습관 처럼 F5를 누르면 프로그램은 실행된다. 새로운 Binary Code를 덮어 쓰지 못했으니 프로세스와 소스에서 디버깅하는 것이 매칭이 되지 않는 것이다. 정말 초보적인 건데...Build 결과의 1 Error을 유심히 보지않아...삽질을 한거다.
즉, 프로세스를 강제로 죽여야 한다는 말인데....
32bit 프로그램 같은경우 작업 관리자(taskmgr)를 실행해보면, 프로세스이름 *32 와 같은 형식을 표시된다.
또다른 문제 발생..프로세스 끝내기, 프로세스 트리끝내기..아무것도 동작하지 않는다. 왜 않죽나..
cmd 창에서 Taskkill /PID ~~ /F 명령으로 프로세스를 강제 종료 시켜도 프로세스가 죽지를 않는다..
결국 다시 검색
/*
프로세스 죽이는데는 이만한게 없다고 한다.
KillProcess
http://orangelampsoftware.com/products_killprocess.php
KillProccess를 이용해 다행이 오류난 프로세스를 죽일 수 있었다. 뭔가 치명적인 문제가 있는 듯, 죽기도 죽지만 다시 살아나는 것도 목격했다 ㅡ,.ㅡ
아무튼, 그렇게 오동작 하는 프로세스를 강제로 죽이고나면 수정한 소스대로 실행파일을 만들고 디버깅 및 실행이 가능하다.
*/
//=> 확인결과 프로세스는 죽지 않는다. Visual Studio 6.0을 종료해야 정지된 프로세스가 종료된다. 아마도 프로세스 관리 권한에 따른 문제인 듯 하다.
아무튼..결론은 무엇이냐면 : 디버깅을 하다가 소스의 오류로 인해 프로그램이 종료되면 윈도우7에서는 해당 프로세스가 종료되지 않는다는 것이다. 즉, 소스를 수정해서 다시 빌드하면 해당 실행파일에 접근할 수 없다는 Error가 출력되고, 습관 처럼 F5를 누르면 프로그램은 실행된다. 새로운 Binary Code를 덮어 쓰지 못했으니 프로세스와 소스에서 디버깅하는 것이 매칭이 되지 않는 것이다. 정말 초보적인 건데...Build 결과의 1 Error을 유심히 보지않아...삽질을 한거다.
즉, 프로세스를 강제로 죽여야 한다는 말인데....
32bit 프로그램 같은경우 작업 관리자(taskmgr)를 실행해보면, 프로세스이름 *32 와 같은 형식을 표시된다.
또다른 문제 발생..프로세스 끝내기, 프로세스 트리끝내기..아무것도 동작하지 않는다. 왜 않죽나..
cmd 창에서 Taskkill /PID ~~ /F 명령으로 프로세스를 강제 종료 시켜도 프로세스가 죽지를 않는다..
결국 다시 검색
프로세스 죽이는데는 이만한게 없다고 한다.
KillProcess
http://orangelampsoftware.com/products_killprocess.php
KillProccess를 이용해 다행이 오류난 프로세스를 죽일 수 있었다. 뭔가 치명적인 문제가 있는 듯, 죽기도 죽지만 다시 살아나는 것도 목격했다 ㅡ,.ㅡ
아무튼, 그렇게 오동작 하는 프로세스를 강제로 죽이고나면 수정한 소스대로 실행파일을 만들고 디버깅 및 실행이 가능하다.
*/
//=> 확인결과 프로세스는 죽지 않는다. Visual Studio 6.0을 종료해야 정지된 프로세스가 종료된다. 아마도 프로세스 관리 권한에 따른 문제인 듯 하다.
//수정 : 위 프로세스 죽이는 것은 의미 없는 듯...
첨부된 TLLOC.dll 파일을 C:\Program Files (x86)\Microsoft Visual Studio\Common/MSDev98/Bin/ 에 복사하여 덮어쓴다.
(당연히 기존것은 백업해 둘 것)
중간 중간 자질구레한 문제들이 추가로 발생했으나, 간단한 것들은 기억조차 나지않을 만큼 해결에 문제가 없었으며, 중요한 것들만 기록했다.
진행 중인 중요 프로젝트를 우선으로 문제가 없는 것을 확인하고, Visual Studio 2008을 깔고..혹시나 해서 시스템 복원 시점도 지정해 두었다.
물론, com 형태의 프로젝트는 좀 문제가 있다. 빌드는 상관이 없으나, RunTime환경이 문제인 것이다. OS가 64bit이고..뭐 그런 문제..그건 프로젝트 진행하면서 64bit 지원 여부에 대한 추가개발 등이 계획되었으므로, 개발환경에 대한 문제가 아니다.
쓰다보니..1시간 30분동안 글을 썻네..
블로그는 만들어 두고 1년에 한번씩 포스팅을 하는 듯...
도움이 되셧다면 리플하나, 이거 생각보다 제가 제 블로그에 오는데 도움이 되네요 ㅎ
