기본 콘텐츠로 건너뛰기

윈도 프로그램 개발 전에 염두할 것....

출처 어쩌다가...코더 (i happened to be the coder) | 주인님
원문 http://blog.naver.com/j2doll/30003391482

...일단 아래 글을 읽기 전에, 아래의 글은 본인이 훗날 다시금 이 글을 읽고
...실수(?)를 번복하지 않기를 바라는 심정으로 필자에게 하는 것입니다.
...그러므로 매우 주관적이고 글체가 싸늘하더라도 이해해 주시기 바랍니다.
...그동안 윈도 개발을 해오고, 다른 사람들이 해온 것을 최근까지 본 결과(?)에 입각한
...느낀점(?)을 적어 본다. 그리고 앞으로 적는 내용은 피부로 느끼는 최소한의 필수 사항이라고
...생각된다.
...첫째, 모든 다른 프로그램들이 그렇겠지만 버그 피드백 시스템이 코딩이라는 작업이
...최초에 들어 가기 전에 필요하다. 그 기능으로는 크래쉬 레포트의 작성은 필수이겠고
...그외 닥터왓슨같은 리포트 제공 기능까지 있으면 금상첨화일것같다.
...레포트의 내용으로는 메모리 덤프와 소스 코드에서의 크래쉬 위치, 그리고 그때의
...메모리, 레지스터 값등의 기록과 함께 테스터의 특정한 환경에 대한 기록(CPU,OS)
...필수일것이다. 그리고 현재 프로세스와 각 모듈에 대한 정보는 필수일것이다.
...이런 기능은 물론 소스가 존재하는 라이브러리를 사용하면 좋지만,
...상용 툴킷을 사용해도 괜찮을 것같다.
...둘째로 다른 윈도 버젼과 씨피유에 대한 지원 테스트 여부가 필수일것 같다.
...32비트윈도와 64비트윈도윈 구십오부터 엑스피, 서버 제품군까지의 지원 여부와
...인텔, 에엠디 씨피유 등등에 대한 테스트도 피해가기 어렬울 이슈일것이다.
...셋째로는 윈도 업데이트별 지원 여부 확인일 것이다. 인터넷 보급이 당연시된 작금에는
...업데이트 적용은 누구에게나 해당되지만 전혀 업데이트를 하지 않는 사용자도 있기
...마련이고, 그럴때를 위한 테스트, 지원 여부 등을 확인해야 한다.
...넷째로는 유니코드에 대한 적용으로 전체 코드가 유니코드와 멀티 바이트 스트링에 대한
...상호 호환이 가능하면 좋을 것이다.
...다섯째로는 리소스의 외국어 지원여부이며 영어와 한국어는 필수로 지원되어야 하고,
...제이외국어 지원의 추가는 더 중요하다.
...여섯째로는 특정 프로그램과의 충돌 등의 여부 테스트이다.
...사용 빈도가 높거나 특정 집단이 사용하는 프로그램들과의 충돌 여부는 필수다.
...(x,x,x트온,x,아래x한글 등)
...귀하가 개발하는 프로그램이 매우(?) 유명하지 않다면 위의 프로그램들과의 충돌 체크
...여부는 피할 수 없을지도 모른다.
...그리고 끝으로 라이브러리의 바이너리 플러그인 방식의 교체까지 지원된다면 더
...유연한 지원을 할 수 잇을 것이다.
...내용이 주저리주절하지만...간단한 결론을 내자면
...동료 개발자뿐 아니라 초고급 개발자(?), 외부 개발 지원 인원 등등과 함께
...(me) 또한 언제든지 실수를 할 수 있는 가능성이 존재하며,
...개발 제품 전체를 교체할 수 있더라도 테스터들에게 무리없이 지원이 가능해야 한다는
...점이다. (이글을 보고 윈도를 만들란 말이냐?!라는 강한 의문점도 느끼신다면,
...컴퓨터는 영세 업체에게는 관대하고 대기업에게는 큰 부하를 주는 세무기관은 아니라는 점을
...명심해야 할 것이다...)
언젠가 이글을 쓴 훗날에 필자가 프로젝트를 시작하기 전에 이글을 최소한 세번이상 읽고
작업중에 일주일에 일회이상 읽기를 반드시 저에게 바랍니다.
(이보게 코더, 매번 그러는 거지만 이제는 잘 좀 해보세!!)

댓글

이 블로그의 인기 게시물

80040154 오류로 인해 CLSID가 {xxxx-...}인 구성 요소의 COM 클래스 팩터리를 검색하지 못했습니다.

원문보기 .NET 으로 만든 응용프로그램에서 com 객체를 호출한 경우 Windows7 64bit 에서 제목과 같은 에러가 발생했다. Win32 COM 과 .NET 프로그램간의 호환성 때문에 생긴 문제였다. 원인은 .NET 실행시 JIT 컴파일러에 의해 최적화된 기계어로 변환되기 때문.. Win32 COM은 컴파일시.. Win32 COM에 맞춰 빌드 속성에서 하위버전으로 맞춰 컴파일을 다시하는 방법도 있지만 메인 프로젝트가 .NET이라면 참조되는 모든 프로젝트를 다 바꿔야할 노릇.. 또 다른 방법은 COM+를 이용하여 독립적으로 만드는 것이다. 분리시키는 방법은 아래 주소해서 확인할 수 있다. http://support.microsoft.com/kb/281335 나의 경우는 Win32 COM DLL을 64비트 .NET 프로그램에서 참조하니 COM 객체를 제대로 호출하지 못하였습니다. 그래서 .NET 프로그램의 Target Machine을 x86으로 설정하니 제대로 COM 객체를 호출하였습니다.

[Pyinstaller] 실행 파일 관리자 권한 획득하기

고객사에서 일부 사용자에게서 프로그램 오류가 발생한다며 아래와 같이 에러 캡처를 보내왔습니다. 프로그램에서 로그를 남기기 위해 로그 파일을 생성하는데 권한의 문제로 로그 파일을 생성하지 못해 프로그램 오류가 발생한 것 같습니다. 처음에는 Python 코드에서 관리자 권한을 요청하는 코드를 넣으려고 했는데, 실제로 Stackoverflow를 찾아보면 이런 내용이 나옵니다. 프로그램이 관리자 권한으로 실행되지 않았다면 관리자 권한으로 다시 프로그램을 실행시키는 코드입니다. import os import sys import win32com.shell.shell as shell ASADMIN = 'asadmin' if sys.argv[-1] != ASADMIN: script = os.path.abspath(sys.argv[0]) params = ' '.join([script] + sys.argv[1:] + [ASADMIN]) shell.ShellExecuteEx(lpVerb='runas', lpFile=sys.executable, lpParameters=params) sys.exit(0) 하지만 개인적으로 이런 방식은 마음에 들지 않았고 조금 더 찾아보니 Pyinstaller로 exe 파일을 만들 때 옵션을 설정하여 관리자 권한을 요청하도록 할 수 있다고 합니다. --uac-admin을 옵션에 추가하면 프로그램 실행 시 관리자 권한을 요청할 수 있습니다. pyinstaller.exe --uac-admin sample.py 하지만 안타깝게도 이 방식은 원하는 대로 동작하지 않았습니다. 마지막으로 manifest 파일을 이용하여 시도해보았습니다. spec 파일을 이용하여 pyinstaller로 빌드하면 <실행 파일 이름>.manifest 라는 파일이 생성됩니다. 파일에서 아랫부분을 찾아볼 수 있습니다. <security> <re

초간단 프로그램 락 걸기

프로그램에 락을 걸 일이 생겨났다. 하드웨어 락을 걸면 쉬울텐데 그 정도는 아니고 프로그램의 실행 날짜를 제한 해 달라고 한다. 그래서 파일(license.lic)을 가지고 락을 걸리고 결정을 했다. 요구 사항은 아래와 같다. 1. license.lic 파일이 없으면 프로그램을 실행 할수 없게 한다. 2. 지정한 날짜를 넘어서는 프로그램을 실행 할수 없게 한다. 3. 사용자가 시스템 날짜를 되돌렸을때 인식하여 프로그램을 실행 할수 없게 한다. 음.... 1.번 문제는 사용자가 프로그램을 실행하기 위해서 license.lic 파일을 받아야만 한다. license.lic 파일에는 최근 실행 날짜/종료날짜 이런식으로 적도록 한다.(물론 내용은 암호화 한다.) 최근 실행날짜는 프로그램이 실행때마다 업데이트 하도록 하고 시스템 날짜와 비교하여 시스템 날짜가 최근 실행 날짜보다 이전의 날짜면 시스템 날짜를 되돌렸다고 인식하도록 한다.(3.번 문제 해결) 시스템 날짜와 종료 날짜를 비교하여 시스템 날짜가 종료 날짜를 넘으면 프로그램을 실행 할수 없도록 한다.(2.번 문제 해결)