소프트웨어가 중복 실행 되지 않게 하기 위해서 사용하는방법. 몇가지 방법이 있다.

온라인 게임 클라이언트들이 대부분 이 방법들을 사용하고 있다. 따라서 멀티로더와 같은 것을 만들때 대부분 별도의 디버거를 어플리케이션에 붙여서 관련 함수들을 찾아서 사용한다. ;;

아무튼, single instance를 위한 작업이라면 그냥 아에 알려진 방법을 전부 다 섞어서 사용해도 될 것 같다. -_-..
그러면 멀티로더를 만드는 사람이 '한가지'를 발견해서 수정해도 작동 되지 않음을 알고 포기 할 수도 있고 (가능성 낮은가-_-).. 최소한 작업시간을 10초라도 더 증가 시킬 수 있으니 ...

사실 대부분의 방법들은 그 목적을 위해서 만들어 졌다기 보다는 다른 용도로 만들어진 것들이지만 그것들을 활용해서 이러한 효과를 볼 수 있는 것이다. 예를 들어 뮤텍스나 세마포어, data_seg 같은 것들은 쓰레드간의 데이터 공유를 위해서 존재 하는 것들인데 이것들을 활용 하는거다. 만세!

뭐 암튼, 뮤텍스와 data_seq의 예제를 대충 남겨둔다. FindWindow야 워낙 알려진 것이니까 스킵.

아.. 그리고 요즘은 별도의 보안 프로그램(HackShield, GameGuard)을 이용하기도 한다.

Mutex

#ifdef _SINGLE_INSTANCE
  Char  sMutexName[ MAX_PATH ];
  ::_stprintf( sMutexName, _T( "[ApplicationName].SingleInstance" ) );
  this->hSingleInstanceMutex = ::UNICreateMutex( NULL, YES, sMutexName );
  if( ::GetLastError() == ERROR_ALREADY_EXISTS )
  {
   if( ::WaitForSingleObject( this->hSingleInstanceMutex, 5000 ) == WAIT_TIMEOUT )
   {
    ::exit( 0 );
   }
  }
#endif


#pragma data_seg()

#define _INSTANCE_NAME  "[Applicatipn].SingleInstance"
#pragma data_seg(_INSTANCE_NAME)
DWORD   _InstanceCount=0;
#pragma data_seg()
#pragma comment(linker, "/section:" _INSTANCE_NAME ",rws")


_InstanceCount++;
if ( _InstanceCount > 1 )
{
   ::exit( 0 );
}


아 사실 자세히 전부 다 쓰려고 했는데..
귀찮다...

말랑양이 원해서 한시간에 걸쳐서 만들어 본 것

티스토리와 태터툴스에서 RECENT COMMENT에서 자기 이름으로 달린 COMMENT는 보이지 않게 하는 사이드 바 스킨.

태터툴스는 코드를 고치면 쉽게 되지만 티스토리는 코드 수정이 안되므로 스킨을 수정해서 자바 스크립트를 이용해서 핸들링.

다만, 단점은 출력 갯수가 5개 일 경우는 자기가 5개 달면 자기가 단 5개가 출력 되니까 아무것도 나오지 않게 된다. 그래서 최대 출력 갯수 (티스토리는 30개)를 출력 하게 해 놓고 스킨에서 5개만 출력 하게 강제 수정.

그러면 자기가 최소한 25개의 리플을 최근에 달지 않는한은 5개는 남의 것이 나온다는..;;

자세한건 사용하는 말랑양이 자세히 써주겠지..;

스킨 코드 보기

NSIS(Nullsoft Scriptable Install System)는 어느새인가 국내 배포 프로그램에서 나름 차지 비율을 높여만 갔다. 아직 해외에서 발매되는 주요 상용 소프트웨어는 Install shield를 쓰고 있지만 전 세계의 수 많은 공개 프로그램들은 NSIS를 사용하고 있다.

우리도 꽤 오래전에 Install Shield를 이용해서 배포를 하다가 Install Factory로 바꿨었고 지금은 NSIS를 사용을 하고 있는데 최근에 배포 패키지의 용량이 2GB를 넘어버렸다.

nsis script를 이용해서 컴파일을 하는데 다음과 같은 에러가 나왔다.

Internal compiler error #12345: error mmapping file () is out of range.

Note: you may have one or two (large) stale temporary file(s)
left in your temporary directory (Generally this only happens on Windows 9x)."

뭐 대략 이런 메세지.

처음에는 파일 시스템의 문제인줄 알았다. 그리고 생각하니 NTFS를 쓰는데.. 단일 파일이 2GB를 넘는다 해도 문제가 없을텐데?라는 생각이 들고 하나씩 뜯어 나가니.. 아쉽게도 NSIS는 대용량 배포, 즉 2GB 이상을 공식적으로 지원 하지 않는다.

패키지 파일이 2GB 이상일 경우는 그다지 많지 않다. 결국 NSIS의 패키징 방식을 조금 바꾸어서 분할 배포를 해야 한다. 하지만 아쉽게도 NSIS는 공식적으로 분할 패키지 파일을 지원하지 않는다. 따라서 별도의 편법을 이용해서 배포 패키지를 만드는 수 밖에 없다. ㅠ_ㅠ.

어떤 방법이 있을까 곰곰히 생각해보고, nsis forum에서도 검색을 해보고, google도 좀 해보고..

결국 방법은 2가지로 압축 되었다.

첫번째 방법은 CAB으로 배포 데이터를 분할 압축하고 NSIS는 CAB 데이터를 풀어주고 프로그램 등록 및 레지스트리 등 각종 배포후 작업을 진행 하는 것.

관련한 정보는 http://nsis.sourceforge.net/CABSetup_plug-in 에서 관련 플러그인 자료를 구할 수 있다.

두번째 방법은 7zip (7z) 방식을 이용하는 것이다.

처음에는 더 친숙한 CAB 방식을 선택 했지만 이 녀석과 NSIS를 묶는 것 자체가 더 짜증났다. 한참을 준비하다가 훨씬 더 간단하게 만들 수 있는 7zip 방식으로 급 선회. 이 녀석은 lzma 방식으로 매우 높은 압축 효율율을 자랑한다. ZIP 보다 높은 압축률을 자랑한다. NSIS도 lzma 방식을 사용한다.

http://www.7-zip.org/ 에서 SDK와 인스톨 버젼을 배포 한다. 이 인스톨 버젼에 shell용 압축 해제 프로그램이 포함 되어 있다. 이것을 이용해서 NSIS SCRIPT의 외부 명령 실행 명령을 이용해서 설치 도중에 함께 배포한 데이터 파일을 배포 하는 것이다.

GUI 프로그램까지 함께 배포 하고 있으므로 정말 손 쉽게 일반 압축 프로그램을 사용하는 것 처럼 설치 하고자 하는 풀 인스톨 파일을 분할 압축 또는 단일 압축을 하고 NSIS 스크립트에서는 7zip sdk를 이용해서 만든 별도의 프로그램 또는 함께 배포 해주는 압축 해제 프로그램을 포함해서 단순히 압축을 해주는 것이다.

매우 쉬워서 기존의 스크립트를 새 스크립트로 변경 하는데 10분도 걸리지 않으며 NSIS의 고통스러운 점인 단순히 스크립트의 내용 수정으로 인해서 엄청난 압축 시간을 요하는 매번의 컴파일을 거치지 않아도 된다는 것이다.

자세한 스크립트 설명은.. 나중에 사무실에서 시간이 나면 올려야겠다 ;;

어쨋든, 이리 저리 하여 NSIS 2GB의 저주에서 벗어났다. 만세에~

관련한 7Z PLUGIN 에 대한 설명은 이곳을 눌러주세요.

게임 서버와 클라이언트에서 어떤 리스트(명단)을 주고 받을때 자료 구조를 만들어서 쓰기 보다는 주로 STL을 쓴다. 그중에서 많이 쓰이는 것들이 list와 vector인데, 이번에도 역시 서버에서 리스트를 받으면서 vector를 사용하였다.

뭐 워낙 클라이언트에서도 많이 쓰이고 있고, 해당 기능을 구현 하는 곳에서도 많이 쓰였기 때문에 별 생각 없이 코드를 작성, QA 도중에 이상한 문제가 발생 하기 시작했다.

구현된 기능중에 벡터 컨테이너에 저장된 구조체 배열 중에서 특정 값을 가진 아이템들을 전부 삭제 하는 기능이 있었다. 예를 들어서 유저 목록이라고 한다면 A라는 class id를 가진 모든 유저를 삭제 하는것과 같은 기능이다.

처음에 구현된 코드는 다음과 같았다.

iterator iterCur;  
iterator iterEnd;

iterCur = this->MemberList.begin();
iterEnd = this->MemberList.end();

for ( ; iterCur != iterEnd ; iterCur++ )
{
 if (iterCur->type == ipPacket->type) {
  this->MemberList.erase(iterCur);
 }
}

그런데 이 코드를 통해서는 정상적으로 기능이 구현 되지 않았다. 테스트 된 환경중에 2개의 데이터를 벡터에 넣어두고 둘다 지워질 수 밖에 없는 경우의 값을 대입시켰을때 조건이 명확함에도 한개만 삭제 되어졌다. VS의 디버거를 통해 알아본 결과 루프가 1회만 돌고 있기 때문이었다.

1회만 도는 원인이 반복자의 무효화 관계가 있을 거라고 생각하고는 erase 이후에 반복자를 다시 대입시켜 주는 코드로 변경해보았다.

iterator iterCur;  
iterator iterEnd;

iterCur = this->MemberList.begin();
iterEnd = this->MemberList.end();

for ( ; iterCur != iterEnd ; iterCur++ )
{
 if (iterCur->type == ipPacket->type) {
  this->MemberList.erase(iterCur);
  iterCur = this->MemberList.begin();
  iterEnd = this->MemberList.end();
 }
}

허나 이 역시 매한가지. 그리고는 곰곰히 생각해보았다. 그냥 벡터의 .size()를 통해서 루프를 돌릴까.. 하는 고민을 했으니 배열로 접근 할 경우 삭제가 불가능하기에 접고 저렇게 작동하는 원인을 찾기 위해 노력해 보았다. 그리고는 다음과 같은 결론을 내렸다.

일단 처음의 두 코드의 루프가 전부 돌지 않았던 것은 for 문 자체의 증감식문 때문이었다. 만약 처음의 첫 코드를 이용 할 경우 반복자의 무효화가 발생 할 경우 stl 내부에서 참조 오류를 내며 crash 되어버린다.

그것은 이미 무효화 되어 버린 반복자에 for의 증감식문이 영향을 줘서 그렇다. (처음 두 코드에서 for에 있는 iterCur++ 문) 따라서 루프 속에서 iterCur or iterEnd or iterEnd의 무효화가 일어날 경우를 대비해서 다시 대입 시켜 주어야 한다.

즉, 반복문 안에서 두가지 경우가 일어 날 수 있게 되는 것이다. 현재 반복문의 증감식으로 부여 받은 이터레이터가 유효한 경우는 지워지지 않은 경우이므로 증감식문을 이용하여 증감 시키고, 무효화가 일어나는 경우, 즉 삭제가 될 경우는 별도의 값으로 해당 이터레이터를 대입 시켜 주어 증감식문의 영향을 받지 않게 해야 한다.

하지만 만약 벡터가 삭제가 된 이터레이터 외에 앞 뒤 아이템의 위치 역시 변경 될 경우는 난감할 지도 모르겠다. (이런 경우가 있나?)

어쨋든 대략 이런 구조로 작성 하면 되겠다.

   iterBegin = this->MemberList.begin();
   iterEnd = this->MemberList.end();

   for ( iterCur = iterBegin; iterCur != this->MemberList.end(); iterCur = iterNext ) {

    iterNext = iterCur;
    if (iterCur->type == ipPacket->type) {
     MemberList.erase(iterCur);

     반복문의 증감식을 이용 할 수 없으므로 별도의 값을 대입. 벡터 전체의 재정렬(전체 무효화)가 생기지 않는다면 루프의 증감식문의 영향을 받지 않은 정상 반복자를 별도로 저장 하고 해당 값을 대입해도 된다. 아래와 같이 begin을 대입하면 삭제가 이루어 질때마다 전체를 처음부터 다시 돌것이므로 성능 저하가 온다.

     iterNext= this->MemberList.begin();
    } else {
   
     반복문의 증감식 대용
     ++iterNext;
    }

어쨋든, for의 증감식문을 전혀 생각 안하고 버릇대로 손이 갔다가 고생좀 했다 ;;

---------------------------------

아래 리플을 보고 알았습니다. -_-. visual assist 쓰면서 몰랐다니. ㅡㅡ;
추가 vector의 erase의 반환값이 있었나 봅니다 -_-. 반환값이 current iterator인가 봅니다~

iterCur = this->MemberList.erase(iterCur);

으로 삭제 된 후의 이터레이터를 받아 올수 있는거 같군요.

게임 케릭터 미리 보기 작업을 하느라 처음으로 ASP.NET C#을 이용해서 그래픽 파일을 브라우저로 전송하는 코드를 작성할 일이 생겼다.

ASP.NET을 처음 만져봐서 각종 정보를 찾아 보니 든든한 클래스가 많이 존재했다. Bitmap, ImageConvert, Color 등..

따라서 게임 그래픽 데이터 파일을 로드하여 Bitmap 에 넣고 각종 변환 작업 (색 변경, 조합, 이미지 머지 등) 수행 후에 BMP로 저장 또는 Response.OutputStream으로 바로 이진 전송을 해도 오류가 나는게 아닌가.

오류도 당황스럽게 GDI+ 일반 오류. (A generic error occurred in GDI+) 가 발생 하는게 아닌가..

뭐가 문제란 말이냐!! GIF나 JPG로는 잘 저장이 되는데! 심지어 파일로도 저장이 잘 되는데 BMP나 PNG, TIFF 등 이미지 손실이 없을 것만 같은 것들은 모조리 저장이 안된다니!?

한참을 고민하다가 해결 방법을 찾았다. 바로 목표 스트림으로 출력하는게 아니고 별도의 메모리 스트림을 거쳐서 찍으니까 모든게 해결. ... 쳇;

뭔가 별도의 포멧으로 저장 할때는 스트림에서 읽었다 썼다를 반복이라도 하는건가!?

------------------------------
  Bitmap Image;

  Image = new Bitmap (320,240);

  Image에 대한 그래픽 처리 blah blah..

  Response.Clear();
  Response.ContentType="image/bmp";
  Image.Save( Response.OutputStream, ImageFormat.Bmp);
  Image.Dispose();

- 출력 오류 GDI+ 일반 오류 발생.

------------------------------

  Bitmap Image;
  MemoryStream memStream = new MemoryStream();

  Image = new Bitmap (320,240);

  Image에 대한 그래픽 처리 blah blah..

  Response.Clear();
  Response.ContentType="image/bmp";
  Image.Save( memStream, ImageFormat.Bmp);
  memStream.WriteTo( Response.OutputStream );
  Image.Dispose();

- 성공

구글(Google)의 R&D 센터가 한국에 생긴다. 조금이라도 IT나 인터넷, 프로그래밍.. 이런 이야기에 관심이 있는 사람이라면 이런 저런 이야기가 많이 듣거나 봤을 것이다. 구글의 사무실 분위기 사원 복지 정책 등을 보고 있자면 소프트웨어 엔지니어의 천국이라는 생각이 들 정도이다.

많은 사람들의 구글의 채용 정책에 관심이 많고.. 또 많은 언론에서 구글의 독특한 채용 방법을 기사에 올리고 있다. 그러던 중에 우연히 매일 경제에 포스트 된 기사를 볼 수 있었다. 구글의 입사 시험 문제 중에 하나 였는데 사무실 옆 자리에 있는 형이 관심을 갖고 있는걸 보고 나도 한번 보게 되었다.

해당 기사 보러 가기 (이곳을 누르면 해당 기사로 갈 수 있습니다.)

" 양수 n에 대해서 1과 n 사이에 1이 나오는 횟수를 나타내는 함수를 f(n)이라고 한다. 예를 들어 f(13)=6이다. f(n)=n이 되는 첫번째 양수는 1이다. 두번째 양수는 무엇인가. "

풀어서 이야기 하면 양수 N 까지의 숫자를 나열 했을때 1 이 들어간 수를 헤아리는데 양수 N까지의 1의 갯수가 양수 N과 동일한 두번째 값을 찾는 문제이다.

단순하게 N까의 루프에서 1의 숫자를 헤아리게 만든다면 P4 3G 라도 엄청난 시간이 걸린다. -_-

한번쯤 관심이 있다면 풀어 보자~

<< 풀어본 답 열기 >>

많은 프로그래머들이 겪고 있는 신비로움일까. 아니면 무지에서 나오는 결과일까.

내가 속한 팀에서는 대부분 사내 테스트이 경우에는 디버그 버젼의 클라이언트를 이용해서 사용한다. 더 많은 클라이언트, 케릭터 정보, 많은 로그들을 얻을 수 있다는 장점이 릴리즈 버젼의 클라이언트 보다 더 크게 작용하기 때문이다.

그런데 여기서 가끔 문제가 생긴다. 릴리즈 버젼의 바이너리와 달리 디버그 버젼은 탱크와도 같아서 정말 튼튼하다. 프로그래머의 가벼운 실수 쯤은 가뿐히 넘어가 버린다.

많은 프로그래머가 실수하는 배열의 인덱스 오류로 인한 오버 플로우 정도는 디버그 컴파일시에 생기는 패딩 효과에 의해서 무마 되어 버린다.

그런데 오늘 정말 거지 같은 일이 있었다.

Windows API를 사용하는데 같은 클래스의 같은 메소드에서 Windows API의 결과가 릴리즈와 디버그가 달랐다. 한시간 넘게 고민하고 고쳐보고 구글질을 해봤지만 결국 원인 규명에는 실패. 참 난감하다.

이렇게 한참을 한 가지 문제를 해결 못해서 끙끙 거리다 보면, 어떤 책의 구절을 찾기 위해서 책장에서 책을 하나 하나 꺼내서 뒤지다가 없으면 책을 내동댕이 쳐서 엉망이 되어버린 방 처럼 머리속이 엉망이 된다.

그럴때는 지우개라도 사용해서 머리를 깨끗하게 비우고 다시 시작하고 싶다.

그리고, 많은 경우가 잠시 바람을 쐬고 처음 부터 차근 차근 하면 해결 되기도 한다. -_-

하지만. 오늘은 실패했다. ㄴㅁ..