|
|
||||||||
| 경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지 |
|
patch.rar
1.2MB
리모트 디버깅은 협업이나 장비를 콘트롤 할 때만 필요한 게 아니고.
고객이 사용하는 OS가 Windows 10 일수도 있고, Windows 7, Windowns XP, Windows Server 2013, 2016, 2019 등 고객 마다 다양한 OS 환경일 수 있는데... 제 각기 다른 환경에서 프로그램이 어떤 특성을 갖고 실행되는지 확인해야 한다고 할 때,,. 리모트 디버깅 기능을 사용하지 않으면... 각기 다른 OS를 대상으로 디버깅 하기 위해 여러 대의 PC가 필요하고 거기다 또 다른 OS가 설치되어 있는 PC 마다 개발 툴 까지 설치해야 하죠. 그러나 리모트 디버거를 이용하면 개발 툴이 설치되어 있는 PC 하나만 있으면 되고 VMWare나 Hyper-V 를 이용해서 필요한 OS를 설치하면 되고, 일일히 개발 툴 까지 설치할 필요 없이 Guest OS에 리모트 디버거만 설치하면 되므로 효율적인 디버깅이 가능하죠. OS 별로 여러대의 PC를 사용할 필요가 없으니. 엠바 애들은 정말 아마츄어 같이 툴을 엉터리로 만들어 놔요.
로컬 디버거에 IPC 메카니즘으로 Shared memory 기법을 이용하면 간단하고 효율적일 것을 소켓을 이용하질 않나. 리모트 디버깅 시에도 디버깅 심볼 파일을 리모트로 카피해서 사용할 필요 없이 VC++ 처럼 이미 컴파일러가 로컬에서 디버깅 심볼 파일을 생성해 놓았으므로 이걸 그대로 로컬에서 사용하면 됄 것을. 엠바 툴은 리모트로 카피해서 사용하기 때문에 리모트와 로컬 사이에서 디버깅 심볼 정보를 사용하기 위해선 네트웍으로 패킷을 주고 받는 과정이 필요해서 리모트 디버깅이 느려지거 든요. VC++ 리모트 디버거는 심볼파일을 리모트로 카피하지 않고 로컬에서 직접 처리하기 때문에 리모트 디버깅이라도 마치 로컬 디버거를 사용하는 것 처럼 빠르게 사용할 수 있는데 말이죠. 엠바 애들 프로그램 만드는 수준을 보면... 종속성은 델파이 컴파일러로 부터 시작합니다.
VC++ 같은 경우 어지간해선 컴파일러 버전이 달라도 .obj 파일 구조가 호환성을 갖고있지만 델파이로 컴파일된 .dcu 는 버전간 호환성이 없어요. ISO 같은 어떤 국제표준도 없고 자기들 독단적으로 마음대로 바꿔가면서 표맷에 변경을 가해버리기 때문에 툴 버전간에 호환성이 없고, 이로인해 RTL, VCL 런타임 패키지들도 툴 버전에 종속돼 버립니다. 그리고... 디버깅 정보 포맷도 디테일하게 들어가면 버전 마다 차이가 있는데... 댓글에 언급되어 있는대로 디버깅 심볼정보를 로컬쪽에서 파싱하면 리모트쪽 코드가 종속성을 가질 필요가 없으나 엠바는 디버깅 심볼 파일을 리모트 쪽으로 카피해서 파싱을 리모트 쪽에서 처리하기 때문에 리모트 디버거가 개발 툴이 바뀔 때 마다 변경 될 수 밖에 없죠. 처음부터 리모트 디버거 설계를 잘못한 케이스. 그리고 몇 년 째.. 버그를 방치하고 있는 것은... 게으르다. 혁신과는 거리가 멀다. 매너리즘에 빠져있다. 그리고 기술적인 역량도 없다. 대충 그런 이유 아니겠습니까. Rad Studio 10.3.3 Rio 는 시스템에서 삭제한 상태라 확인해 볼 수 없고.. 관련 글 리스트
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Copyright © 1999-2015, borlandforum.com. All right reserved. |
사실 전 거의 리모트디버깅은 할 일이 없습니다. 보랜드 시절부터 이 툴은 저 혼자 쓰다 보니 다른 협업이 거의 없고 또한 장비를 컨트롤 할 때도 노트북컴에 설치해서 쓰다 보니 그렇게 필요하지 않습니다.
다만, 이렇게 까지 해주시는 것이 늘 감사합니다. 그리고 커파일러의 내부의 이야기를 듣는 것 만으로도 즐겁습니다. 거의 컴파일러를 들여다 보지 않고 살고 있고, 하다 안되면 마이크로소프트의 제품을 사용하면 되니까요. 그런데 매번 해결책을 주시니 감사합니다.