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

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

아무튼, 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의 저주에서 벗어났다. 만세에~

게임 서버와 클라이언트에서 어떤 리스트(명단)을 주고 받을때 자료 구조를 만들어서 쓰기 보다는 주로 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();

- 성공

필자가 처음에 WEB을 접했던건 아주 오래전이다. 아직 VT 기반의 통신이 주였고 많은 사람이 VT 기반의 통신을 시작하기 시작할때 였다. 당시에 두산에서 서비스 하던 인터피아라는 유료 계정 서비스를 이용하여 처음으로 UNIX SHELL을 접하게 되었고, 그 이후에 ppp 또는 slip 서비스를 이용해서 처음으로 WEB을 접했을때는 정말 놀라웠다.

단순히 TEXT 기반의 통신에서, 아니 활자 만으로 이루어져 있던 텍스트 북에서 삽화가 함께한 책을 처음 발견 했을때의 놀라움 정도랄까? 이미지와 함께 볼 수 있는 인터넷 문서라니! 하지만 그 이상도 그 이하도 아니었다. 아직 세상은 Client Side에서 작동되는 어플리케이션이 대세였고, 온라인은 텍스트 기반이었으며 당시에 접한 WWW은 나에게는 단지 그림책일 뿐이었다.

언제부터인가? VT 통신이 정점을 찍고 하향 곡선을 그리기 시작했다. 그리고 발전 가능성이 깊다고 기대 되어지던 WEB 세상은 하나 하나 늘어나기 시작하고 VT 망의 10년에 가까운 데이터와 커뮤니티를 가진 업체들은 그 힘을 조금씩 잃어 가기 시작했다. 그때 까지만 하더라도 WEB 은 정적이었고 유저의 시스템에서 돌아가는 어떤 시스템들 보다도 사용자의 편리성은 결여 되어 있었으며 만약을 위한 준비 조차 힘들게 보였다.

벌써 상당히 오래쓴 테터 툴스이지만 몇일 전에 새 글을 포스트 하다가 우연히 이 에디터의 기능이 눈에 들어왔다. 지금까지는 별 생각 없이 사용했지만 그 기능들을 내가 인지 하고 나서는 놀라움에 사로 잡혔다.

아니. 단 6년만에 이렇게 놀라운 발전이 있었나?

그렇다. 웹은 끊임 없이 발전했다. Windows Application이 Windows 95가 나오면서 MSDOS의 TEXT 기반의 시스템에서 GUI 시스템으로 변경 되고 나서의 발전 만큼이나, 유저가 소프트웨어를 직접 설치해서 사용하는 어플리케이션에는 절대 따라 오지 못할 것만 같았던 WEB이 이제는 Server Side에서도 충분한 처리를 하고 다양한 표현 방법을 가질 수 있게 구성된 HTML과 그것을 효과적으로 (물론 사용에는 조금 스트레스를 불러 오지만) 컨트롤 할 수 있게 해주는 Javascript 덕이다. (비록 Windows 에서는 재미를 보지 못한 Java지만 WEB 에서는 그 목적 이상을 달성한 Java에게 갈채를-_-)

큰 편리함이지만 큰 불편함이었던 마우스에 의존 하는 시스템, 즉 단축키 시스템에 의한 직접 호출 기능의 부족과 정적으로만 생각되어지던 이미 출판 되어 버린 문서와 같은 HTML의 동적 변환 ( HTML + JAVASCIPT 결합물인 Dynamic HTML), 어느 시스템에서도 동일한 환경을 보장하는 SSI 시스템까지.

이제 컴퓨터를 한다는 개념 자체가 온라인 상태에서의 어떤 행위를 이야기 할 정도로 그 의미가 변했다. 더 이상 오프라인, 사용자의 시스템에 국한 된 시스템은 더 이상 그 값어치를 지니지 못하고 모든건 옮겨 가고 있다. 아니 이미 거의 대부분이 옮겨져 버렸다. (이것은 10년 전에는 오프라인에서도 컴퓨터를 가지고 할게 많았지만 지금은 단 10분만 오프라인 상태에서도 컴퓨터로 할게 없다는 점에서도 알 수 있다 -_-)

아마도 이제 컴퓨터의 모든 시스템은 온라인 클라이언트화 될 것이고, Windows Application의 설 자리는 점점 잃어 갈 것이다. HTML과 Javascript 그리고 최근에 비약적 성장을 하고 있는 Flash 가 그 자리를 조금씩 대체 해 나갈 것만 같다.

DOS 시절 부터 유저 소프트웨어 프로그래머 였던 나로써는 조금씩 사라져 가는 과거의 향수와 더욱 더 편리하고 강력해지는 새 환경 변화속에서 묘한 기분을 느낄 수 밖에 없다..

구글(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 라도 엄청난 시간이 걸린다. -_-

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

<< 풀어본 답 열기 >>

완료 된지 시간이 조금은 지난 프로젝트. 게임으로 따지면 서비스가 시작된지 조금 된 게임들. 프로그램으로 따지면 최초 개발 이후 고객에 따라서 커스터마이징을 하고 있는 과정 정도에 있는 경우에 해당한다.

어떤 프로젝트든지 완벽한 문서와 모든 코드를 숙지 할 수 있는 교육 과정이 있다면야 문제 없지만, 현실적으로는 그런 일은 드물다. 아니 있을 수 없다고 해야 할런지..

완성된 프로젝트를 이어 받아서 커스터마이징 및 유지 보수, 추가 작업을 하다 보면 가끔은 이런 기능이 있으면 좋을 텐데 하고 관련 자료를 찾아서 적용 준비를 하다보면 평소에는 보이지 않던 파일명과 클래스명이 보이곤 한다. 혹시.. 라는 마음에 찾아 보면 역시나 oTL.. 이미 구현이 되어 있지만, 코드 깊은 곳에 묻혀 있어 알 수 없었다던가 특수한 경우에만 작동하게 되어 있다던지 하는 일이 있다.

나름 난감하다. 그 기간동안 이런게 있다는 사실을 몰랐다니! 아쉬워 해봐야 소용 없다.. 하지만 다른 숨겨진 기능을 찾기에는 유지 보수에도 시간이 부족하다. 결국 프로젝트를 구성하고 있는 모든 구성요소를 모른채 계속 일을 이어 갈 수 밖에 없다.

oTL

이런 일은 가끔 예상치 못한 문제를 낳기도 한다.

예를 들어서 게임에서는 유저의 시야권에 다른 케릭터가 접근하게 되면 해당 사실을 서버에게 알려준다. 그런데 완성되고 나서 몇년이 지난후에 새 개발팀이 해당 프로젝트를 맡아서 진행하다가 이미 시야에 들어온 유저의 데이터의 갱신이 필요한 일이 생겼다.

그래서 작업 방법을 고민하다가 시야에 유저가 들어왔을때 해당 사실을 통보해주는 모듈을 사용하여, 같은 UserID를 가진 User Object가 다시 전송되면 업데이트 되는 방식으로 구현. 서비스를 한동안 진행하던 중에 우연히 코드중에 유저의 정보만을 업데이트 시켜주는 현재는 자주 사용되지 않는 패킷 모듈이 있었음을 발견 한다.

그런데 문제는 서버에서는 유저 데이터를 업데이트 시켜줄때 사용하는 정보와 유저가 시야에 들어왔을때 사용 되는 데이터가 동일할 것으로 예상. 공통적으로 유저 정보를 보내는 모듈을 사용하고 있었다.

어느 한쪽이 패킷 규약이 변경되면 다른 한쪽 역시 같은 모듈을 사용하므로 같이 변경 되는 그러한 방식.
그런데 서버 개발자도, 클라이언트 개발자도 이것을 모르고 있었다는거.. 결국 패킷은 데이터가 밀리는 현상이 발생. 특정 유저의 경우에는 예상치 못한 값에 의한 클라이언트 크래쉬가 일어나게 되었다. ;

난감..

한참동안을 원인을 못찾다가 이런걸 발견 하게 되면 정말 가슴이 아프다. 왜 조금 더 꼼꼼하게 살펴 보지 못했을까.. 하는 아쉬움은 이미 늦어 버렸으니까..

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

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

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

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

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

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

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

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

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

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