저같은 경우는
실제 실행 Code보다 Data 특히 Image등이
전체 크기의 대부분(2/3 이상)을 차지하는 경우가 많아
Runitime시 이 File들을 불러 오도록 처리하도록 한답니다.
물론 최초 배포시 모든 File을
그 다음 부터 실행 File만 배포 하지요.
님도 Image을 많이 사용하다면 이 방법을 사용해 보세요.
현 프로그램에 몇 줄(Image 읽어 붙이는 코드)만 추가하면 되니까
개인적으로 추천해 드리고 싶군요.
프로그램 배포를 고려한 프레임웤을 짜는일은 프로젝트 초기에 결정되어져야 하는 일입니다. 나중에 이것을 바꾸기란 무척 힘들다고 할수 있습니다.
물론 규모가 작고 프로그램간 연계가 적다면 적은 노력으로도 가능하지만 반대의 경우 새로운 프로젝트를 발생시켜야만 가능할 정도로 공수가 많이 들어 갑니다.
일단 몇가지 예를 들면
1.델파이 초창기에 유행했던 실행파일 레벨의 체계가 있습니다.(SDI스타일 이였죠) . 메뉴역시 EXE형태의 실행파일이었고 단위 프로그램 역시 EXE로 되어 윈도우프로그램이라고 하기에는 좀 어설펐습니다..이때는 프로그램간 연동을 프로그램을 처음 실행할때는 런 파라미터 (dir에 /r 처럼)를 사용하였고 이미 기동중인 프로그램과 연동할땐 DDE또는 OLE를 연동해 처리 했습니다..
2.그뒤에 사용되던것이 님이 얘기하신 통짜로 묶어서 배포 관리하는 방식이었습니다.(MDI스타일 이였죠) 님이 얘기하신대로 프로그램 변경시 전체를 다운 해야 하는 문제가 있었습니다.. 20M가 넘는 실행파일이 변경 될때마다 몇백개 클라이언트가 다운 받는다는건 네트웍의 마비가 우려되는 상황입니다..
3.요즘 유행하는 것은 MDI형태의 메인 프로그램과 별도로 만들어진 DLL을 동적으로 LoadLibrary하여 사용하는 방법입니다..실제 공통bpl들을 별도 배포하고 버전관리를 통해 변경된 프로그램(DLL)만 다운 받아 사용하면 200~300K정도의 파일을 다운 받게 됩니다.
4.마지막으로 BPL형태로 프로그램을 분리하는 방식인데 불행히도 제가 직접 해보지 않은 것이라 뭐라 평가 하기 어렵군요..
제가 보기에는 이미 MDI코딩이 되어 있는 프로그램 인것 같은데 세번째 방법으로 전환하심이 좋을것 같습니다..물론 코딩은 사뭇 다름니다..얼마나 공수가 들어갈지 미리 예측하시는 것도 중요하구요..왜냐하면 ALL or Nothing이기 때문입니다.. ^^;
실제 실행 Code보다 Data 특히 Image등이
전체 크기의 대부분(2/3 이상)을 차지하는 경우가 많아
Runitime시 이 File들을 불러 오도록 처리하도록 한답니다.
물론 최초 배포시 모든 File을
그 다음 부터 실행 File만 배포 하지요.
님도 Image을 많이 사용하다면 이 방법을 사용해 보세요.
현 프로그램에 몇 줄(Image 읽어 붙이는 코드)만 추가하면 되니까
개인적으로 추천해 드리고 싶군요.
즐푸하세요 ^^;