Media Log

결론부터 이야기 하면 널 체크는 할 필요가 없다.

if (p)
{
free(p);
p = NULL;
}

또는
if (p)
{
delete p;
p = 0;
}

이렇게 메모리를 해제하기 전에 널 포인터인지 체크하는 코드를 수도 없이 많이 보았다.
아마도 이미 해제한 메모리를 또 해제 하다가 프로그램이 죽지 않게 하기 위해서 일 것이다.

그런데 free나 delete에는 널 포인터를 집어 넣어도 아무런 문제가 없이 작동한다. -아무 짓도 하지 않는다.
생각보다 많은 사람들이 잘 모르고 있는 부분이다.

위 코드는 다음처럼만 써주어도 된다.

free(p);
p = NULL;

해제 후에 0을 넣어주는 것도 많은 경우에는 필요가 없지만(지역 변수의 포인터를 해제하는 경우) 이후에 언제라도 다시 해제를 시도할 가능성이 있을 때는 써주는 것이 의미가 있다.

cppcheck 같은 정적분석 도구를 사용할 시에는 맨 위의 널 포인터를 체크하는 코드를 보면 성능이 떨어진다면서 저런 짓을 할 필요 없다고 경고해주기도 한다.

저작자 표시 비영리 동일 조건 변경 허락
신고
  1. Favicon of http://eslife.tistory.com BlogIcon esstory at 2011.05.30 12:58 신고 [edit/del]

    이게 너무 오랫동안 습관이 ㅎㅎ
    처음에 null 로 초기화 안한 변수를 delete 해서 많이들 죽여 봐서.. 저렇게 하는 게 당연하다고 생각했는데 결국 '괜한 짓' 이군요 ㅎ

    Reply
  2. Favicon of http://sunyzero.tistory.com BlogIcon stevenkim at 2011.07.21 00:42 신고 [edit/del]

    정말 사람의 습관이라는 것이 무서운게, 학생때 널체크로 배웠더니...

    나중에 초급시절을 벗어나 free(NULL)이 문제가 없는 것을 알았어도, 어느 순간 보면 기계적으로 널체크 코딩을 하고 있더군요.

    Reply
  3. gcd at 2012.02.22 06:43 신고 [edit/del]

    여담이지만, 여기에 대고
    if (p != NULL) ...
    이라고까지 써놓은 걸 보면 정말 몸이 움찔(?)하더군요.

    Reply
  4. Favicon of http://blog.daum.net/knightofelf BlogIcon shint at 2013.10.26 21:34 신고 [edit/del]

    이것은 중요합니다... ㅠㅠ...
    if(p != NULL)
    {
    free(p);
    p = NULL;
    }

    Reply

submit

리눅스 3.0 시대

2011.05.25 23:16 | Softwares
나는 RSS 피드 500여개 정도를 등록해서 구독하는데, 그 중에 내가 특히 좋아하는 피드 2개는 네이버캐스트 IT 분야h-online의 피드이다.

네이버캐스트에는 IT분야 말고도 여러 주제에서 주옥같이 잘 쓰여진 글들이 많이 올라오는데, 아쉽게도 RSS 피드를 제공해주지 않는다. 이전 회사에서 같이 일했던 동료 하나가 피드를 만들어서 제공하고 있는데 나는 그 피드를 이용해서 꼬박 꼬박 잘 구독하고 있다. 여기에 가면 볼 수 있다.

h-online은 오픈 소스 프로젝트의 동향에 관해서 좋은 정보들을 많이 제공해 주는데, 별 볼일 없는 프로젝트들 맑고 굵직 굵직한 메이저 프로젝트들만을 다뤄줘서 좋다. 오픈 소스를 좋아하는 사람이라면 이 뉴스 피드를 구독함으로써 많은 새로운 프로젝트들을 알게되고 소식들을 접할 수 있게 될 것이다.

얼마전에 Gnome 3.0도 나오고 리눅스가 이제 좀 쓸만해지려나 하고 요즘 기분이 좋았었는데, 어제는 h-online에서 리눅스 3.0이 나올지도 모른다는 소식을 듣고 마음 속으로 비명을 질렀다. 그것도 바로 내일 모레!
오래전부터 쭉 3.0을 설계해 왔던 것은 아니고 그냥 다음 버전부터 2.8.0이나 3.0으로 이름을 붙이자는 이야기가 오가고 있는 것이기 때문에 조금 실망스럽기는 하지만 어쨌거나 설레이는 일이고, 리누스 토발즈의 말을 읽어 보면 정말 3.0으로 진행될 확률이 꽤 높은 것 같다.

예전에 리눅스 2.8이 나오면 어느 정도 윈도만큼 쓸만해지지 않을까 하고 생각을 한 적이 있었는데 내가 참 순진했다.
곧 3.0이 나올텐데도 이렇게 꼬졌다니!
Linux is only free if your time has no value.
누군가 이런 말을 했는데, 리눅스에서 삽질하고 뭔가가 잘 안 돌아갈 때마다 내가 이 빌어먹을 것을 왜 쓰고있지? 하고는 저 말에 고개를 끄덕끄덕 거리게 된다.
그럼에도 불구하고 나는 계속 리눅스를 쓴다. 리눅스에서는 그렇게 시간 낭비 하는 것도 즐거우니깐.
저작자 표시 비영리 동일 조건 변경 허락
신고

'Softwares' 카테고리의 다른 글

2011년 최고의 오픈소스들  (0) 2011.09.10
구글 플러스의 무제한 사진 업로드 정책  (0) 2011.07.14
리눅스 3.0 시대  (0) 2011.05.25
ACE 6.0 static build  (2) 2011.03.06
프로세스 모니터 사용법  (6) 2011.01.14
2010년 분야별 최고의 오픈소스들  (5) 2011.01.09

submit
오프라인 비즈니스 혁명 - 8점
정지훈 지음/21세기북스(북이십일)
회사를 그만두고 두 달 가까이 코딩을 안하고 강시처럼 살았더니 프로그래밍 책을 다시 집어드는게 조금 무서워졌다.
그래서 요즘엔 이런 읽기 쉬운 편한 책들을 많이 읽고 있다.

이 책은 얼마전에 거의 모든 IT의 역사라는 책을 썼던 정지훈님의 신간이다. 나는 '거의 모든 IT의 역사'를 아주 재밌게 읽어서 바로 알라딘에서 작가의 신간 알리미 신청을 해두었었다.
저자는 하이터치 하이컨셉이라는 블로그를 운영하고 있으며 책 내용이 블로그에 그대로 올라오며 그 외 다른 좋은 내용들도 가끔씩 올라오므로 꼭 구독해서 보기를 권한다.

거의 모든 IT의 역사가 지금까지의 일들을 정리한 책인 반면에 이 책은 앞으로 어떤 방향으로 세상이 변해갈지 하는 내용을 담고 있다.

처음 책을 몇 장 넘겼을 때는 2008년도에 징하게 읽었던 웹 2.0 경제학 이야기들이 또 나오는 건가 했는데, 읽을 수록 새롭고 몰랐던 내용들을 많이 배워서 좋았다.

3D 프린터나, DIY 무인 비행기, 오픈소스 자동차 프로젝트 같은 것들은 참 신선했다.
이런 것들을 보면 프로그래밍을 하는 것보다 서비스를 기획하는게 어쩌면 재밌지 않을까 하는 생각도 든다.

장사해서 돈을 벌어 먹고 있는 사람들은 이 책을 한 번 읽어보기를 추천한다.
저작자 표시 비영리 동일 조건 변경 허락
신고

submit
이전에 윈도우 드라이버를 공부하면서 정리해놨던 내용들이다.
여기에 있는 내용들은 전부 이 책에서 배운 내용들이다.
아마 지금까지 나온 윈도우 드라이버 책 중에 가장 좋은 책일 것이며, 앞으로도 이런 책은 안나올 것 같다.

만일 드라이버를 처음 접해서 아래 내용이 전혀 이해가 안되더라도 그냥 외워서 따라할 수 있도록 정리해놨다. 경험이 쌓여가면서 하나씩 이해가 될 것이다.

  • IRP를 완료시킬 때는 STATUS_PENDING 이라는 상태 코드를 써서는 안된다.
    물론 디스패치 루틴에서 STATUS_PENDING을 리턴할 수는 있지만, IoStatus.Status에 STATUS_PENDING을 할당한 뒤 I/O를 완료시키면 안된다는 뜻이다.
  • IoCompleteRequest를 호출 하기 전에는 IRP에 대해 지정한 취소 루틴을 제거해야 한다.
    Driver Verifier는 이런 경우를 적절히 찾아내서 버그체크를 띄워준다. 단, Irp가 큐잉된다면(StartPacket을 한다던지 Cancel-Safe Queue에 들어간다던지) 디큐될 때에 자동으로 취소 루틴이 제거된다.
  • Irp를 종료할 때, IoStatus.Status와 리턴 값은 일관성이 있어야 한다.
    즉 IoStatus.Status는 성공코드를 넣고 실패코드로 리턴하는 경우가 있으면 안된다.
    Driver Verifier가 이 오류 또한 적절히 발견해줄 것이다.
  • 디스패치 루틴에서 STATUS_PENDING을 리턴하기 전에는 Irp를 Pending으로 Marking해준다. 반대로 Irp를 Peding으로 마킹해 주지 않으면 STATUS_PENDING으로 리턴하면 안된다.
    둘은 항상 짝이 맞춰져서 다녀야 한다.
  • StartPacket을 호출하고 나면 더이상 IRP를 건드리지 않는다. 함수가 리턴되자마자 Irp는 이미 완료되었을 수 있다.
  • STATUS_MORE_PROCESSING_REQUIRED를 리턴하지 않는 모든 완료루틴에 대해서 다음의 코드를 넣는다.
    if(Irp->PendingReturned)
    {
        IoMarkIrpPending(Irp);
    }

    완료루틴을 설정하지 않았을 경우에는 시스템이 Irp를 완료시켜가면서 상위 스택으로 Pending 비트를 복사해주지만,
    완료 루틴이 설정되어 있으면 시스템이 이 작업을 해주지 않기 때문에 해당 완료 루틴에서 직접 PendingReturned 값을 체크하여 Irp를 Pending으로 마크해주어야 하기 때문이다. -어떤 경우라도 시스템은 PendingReturned 변수만큼은 항상 잘 셋팅해준다.
    만약 잘 이해되지 않는다면 그냥 외우기만 해도 좋다. 이는 언제나 참이다. 단, 완료 루틴에서만이다. 다른 루틴(디스패치 루틴이라던지)과 착각하면 안된다.
  • Lower Driver로 Irp를 건네주는 과정에서 완료루틴을 설정한다면 반드시 IoCopyCurrentIrpStackLocationToNext를 호출해야 한다.(IoSkipCurrentIrpStackLocation은 안된다.)
  • Next Driver에 Irp를 전달한 이후에는 더 이상 Irp는 자신의 소유가 아니며 건드리지 말아야 한다. 그 Irp는 다른 드라이버나 쓰레드에서 free되거나 완료되었을 수 있다. 하지만 만일 드라이버가 스택 아래로 Irp를 건네준 이후에 그 Irp에 접근하고 싶다면 반드시 완료 루틴을 설정해야만 한다.
    Io 매니저가 해당 완료루틴을 호출해 줄 때 완료루틴 내에서 잠시 다시 Irp는 내 드라이버의 소유가 되고, Irp에 액세스 할 수 있다.
    만약 Next Driver가 Irp를 완료 시킨 후에, 내 드라이버의 디스패치 루틴이 그 Irp에 접근해야만 한다면 완료루틴은 반드시 STATUS_MORE_PROCESSING_REQUIRED를 리턴해야만 한다. 이는 Irp의 소유를 디스패치 루틴에게로 건네준다. IO 매니저는 Irp의 처리를 중지하고 디스패치 루틴에게 궁극적으로 해당 Irp의 Completion을 맡긴다.
    디스패치 루틴은 이후에 IoCompleteRequest를 호출해서 Irp를 완료시킬 수도 있고 처리를 더 하기 위해 Pending으로 마킹할 수 있다.
  • 드라이버는 다음과 같은 경우 반드시 STATUS_PENDING을 리턴해야만 한다.
    • Irp가 완료되기 전에 디스패치 루틴이 리턴하는 경우
    • 해당 Irp가 다른 쓰레드에서 완료되는 경우
  • Arbitrary 쓰레드에서는 비동기적 Irp만을 생성할 수 있다. NonArbitrary 쓰레드에서는 동기 Irp도 생성할 수 있다.
  • IRQL이 Dispatch Level 이상인 경우에는 쓰레드를 대기 시켜서는 안된다. 즉, KeWaitFor- 같은 함수 들을 사용할 수 없다는 이야기이다.
    단, 쓰레드를 재우지 않고 단순히 오브젝트가 시그널 되었는지 Peek 해보는 것은 상관없다. 대기 함수들에 타임아웃값을 0으로 넘겨주면 Peek만 시도할 수 있는데, 유저모드에서는 WaitFor함수 패밀리에 dwMilliseconds를 0으로 건네주면 된다.
    커널 모드(KeWaitFor 함수 패밀리)에서는 유저모드처럼 그냥 0을 넣어버려서는 안된다. KeWaitFor 함수에 NULL 포인터를 전달하게 되면 Peek하겠다는 것이 아니라 무제한 기다리겠다는 의미이다. 반드시 LARGE_INTEGER 값을 0으로 셋팅해서 함수에 넘겨주어야만 한다.
    쓰레드를 재우면 안되는 이유는, IRQL이 Dispatch Level 이상이 되면 다시 재스케줄링 될 수 없기 때문이다.
    이는 비단 WaitFor 함수 패밀리뿐 아니라, 쓰레드를 대기 상태로 만드는 모든 함수를 사용 할 수 없다는 의미임을 알아야 한다.
  • IRQL이 디스패치 레벨 이상이 된 경우에는 특정 데이터를 참조하기 위해 페이지 폴트를 일으켜서는 안된다.
    페이지 폴트는 소프트웨어 예외 중 하나인데 사실 이는 디스패치 레벨 상태에서는 페이지 폴트 뿐만이 아니라 모든 경우의 Exception이 발생해서는 안된다는 의미이다. 이는 위에서 설명한 대기 함수를 사용할 수 없는 이유와 같다.
  • #pragma alloc_text(PAGE, Function Name)
    위와 같은 디렉티브를 선언했다면 그 함수의 시작부에 PAGED_CODE 매크로를 사용한다.
    이는 반드시 한 쌍으로 있어야 한다.(둘다 있거나 둘 다 없어야 한다.)
    Pagable에 대한 의미는 따로 설명하지 않는다.
    PAGED_CODE에 대한 더 자세한 내용은 여기에 써두었다.
  • 커널 스택은 x86에서 12K만큼 할당된다. amd64에서는 24K이다.
    단지 자신의 드라이버에서만 커널 스택을 사용할 것이라 착각해서는 안된다. 자신의 드라이버의 상위에 다른 필터 드라이버들이 있을 경우, 해당 필터드라이버가 사용하고 남은 커널 스택만큼을 받아서 사용하게 된다.
    따라서 평소엔 잘 돌아가던 드라이버가 백신같은 필터 드라이버가 설치된 환경에서는 블루스크린이 발생하기도 한다.
    이것은 모든 드라이버에서 최대한 스택을 아껴써야 함을 의미한다.
    유저모드에서 하듯이 다음 줄처럼 코딩 해서는 안되며
    WCHAR sz[MAX_PATH]; // 지역변수 하나가 커널 스택의 약 5%를 써버렸다.

    이는 좀 귀찮더라도 아래와 같은 방법으로 수정되어야 한다.
    PWCHAR sz = ExAllocatePoolWithTag(PagedPool, sizeof(WCHAR) * MAX_PATH, POOL_TAG);
    if(sz == NULL)
    {
        // Process the error.
    }
     
    __try
    {
        // Do something
    }
    __finally
    {
        if(sz)
        {
            ExFreePoolWithTag(sz, POOL_TAG);
        }
    }

  • 커널 스택은 pagedpool에 할당됨을 알고 있어야 한다. -함수가 대기 상태로 되면 시스템에 의해서 언제라도 Page out 될 수 있다.
    Event 객체는 NonPagedPool에 할당되어야 하는데, 스택에 할당했을 경우에는 KeWaitFor 함수의 WaitMode인자로 KernelMode를 전달함으로써 이 스택 메모리가 Page out 되지 않도록 할 수 있다.
  • DriverEntry가 아닌 곳에서 디바이스를 생성한다면, 초기화가 끝난 이후에 DO_DEVICE_INITIALIZING 플래그를 지워줘야 한다. -이는 AddDevice 루틴도 예외가 아니다.
    deviceObject->Flags &= ~DO_DEVICE_INITIALIZING;
    이것을 지워주지 않는다면, CreateFile같은 Api로 장치를 열 수 없다.
    만약 DriverEntry에서 만드는 경우에는 리턴되자마자 IoManager가 알아서 플래그를 지워주므로 생략해도 상관없다.
  • 캔슬 큐에 집어 넣고 pend 상태로 처리한 Irp는 나중에 완료하기 직전에 꼭 Cancel Queue에서 제거해주어야 한다.
    이 때 Cancel Queue에서 빼면서 리턴값을 꼭 검사해서 실제로 Queue에 존재했었고 제거된 경우에만 이 Irp를 완료시켜야 한다.

    // pIrpContext는 Insert할 때 넣어주었던 그 변수를 사용해야 한다.
    PIRP pPendedIrp = IoCsqRemoveIrp(&g_pDevExt->cancelIo.CancelSafeQueue, pIrpContext);
    if(pPendedIrp)
    {
        DriverLog(SHOW, "pIrp = 0x%08X\n", pIrp);
        pIrp->IoStatus.Status = status;
        pIrp->IoStatus.Information = information;
        IoCompleteRequest(pIrp, IO_NO_INCREMENT);
    }
    이렇게 해야 여러 요청이 동시에 들어왔을 때의 미묘한 동기화 문제를 피할 수 있다.(그렇지 않으면 같은 Irp를 2번 이상 완료시킬 수 있다)

저작자 표시 비영리 동일 조건 변경 허락
신고
  1. 아저씨 at 2011.05.25 00:14 신고 [edit/del]

    좋은 글 감사합니다.

    Reply
  2. 오곡 at 2013.07.09 18:09 신고 [edit/del]

    WDM 의 핵심들 잘배우고 갑니다~!

    Reply

submit
폰노이만 VS 아인슈타인 - 8점
김원기 지음/숨비소리
어느 블로그를 구경하다가 이런 책도 있었구나 하는 것을 알게 되었다. 도서관에도 없는데다가 절판된 책이라서 YES24에서 중고책으로 3천원에 사서 봤다.

제목만 봐도 참 재밌지 않겠는가? 내가 유별난건지는 모르겠지만 천재들 이야기는 항상 재밌다. 특히 컴퓨터와 관련된 천재 이야기는 더 재밌다.
그래서 아인슈타인 이야기 보다는 폰 노이만 이야기를 할 때가 더 재밌었다.

이 책에서 프린스턴 고등연구소라는 곳을 처음 알았다. 죽을 때 까지 이 곳에서 돈을 받으며 하고 싶은 연구를 마음껏 할 수 있다. 아인슈타인과 폰노이만은 이 연구소의 첫 멤버 였다. 어떠한 압박도 없었기 때문에 꿈의 연구소라고 불리우지만 그만한 명성이 쌓아놨어야 이 곳에서 종신 교수를 할 수 있다.

돈 3천원으로 아주 재밌게 잘 읽었다. 하지만 특별히 배울 점이라던가 할만한 것은 없다.
폰 노이만은 몇 년전에 읽었던 책의 일부를 프린스턴 연구소에 가서도 한 글자도 틀리지 않고 기억해내서 동료들은 깜짝 놀라게 하곤 했다. 어릴 때부터 열자리가 넘어가는 수의 곱셈을 암산으로 해낼 수 있었다. 이딴 이야기들을 들어봤자 우리가 뭐 흉내나 낼수 있겠는가.
저작자 표시 비영리 동일 조건 변경 허락
신고

submit
내몸 사용설명서 - 10점
마이클 로이젠.메멧 오즈 지음, 유태우 옮김/김영사
이전에 다니던 회사에서 건강을 끔찍히도 생각하던 한 사람이 있었다.
그 분은 내 팀장이기도 했었는데, 내가 지금까지 만난 사람 중에서 가장 똑똑한 사람이었고 자기관리를 잘하는 사람이었다.
어느 정도로 철저하게 관리를 했냐면, 밖에서 파는 대부분의 음식들을 먹지 않았다. 그래서 항상 도시락을 싸서 다녔고, 어쩌다 단체 회식 같은 것을 하면 굶기 일쑤였다.

이 책은 그가 내게 읽어보라고 언젠가 권해준 책이다.
나는 이 책과 마이클 로이젠의 다른 2권의 책들까지 모두 다 진지하게 읽었고, 이제는 나도 건강에 대해 진지하게 생각을 하면서 살기 시작했다.

다른 2권의 책의 제목은 내몸 젊게 만들기내몸 아름답게 만들기이며 얼마전에 이 블로그에 포스팅을 했었다.
위 두 책들보다 이 책이 훨씬 유명하고 많이 팔렸으며, 또한 중요한 내용들을 담고 있다.
심장, 혈관, 뇌, 뼈와 관절 그리고 근육. 폐와 소화기관, 우리 몸의 면역체계 등 정말 중요한 것들을 많이 배울 수 있다.

이 책을 읽는 것은 명문 의과대학을 다니는 것과 같다.

이 책의 표지에 써있는 말인데, 명문 의과대학은 물론 뻥이지만, 잘 읽어두면 살아가면서 자신에게든 남들에게든 큰 도움이 될 수 있을 것이니 이 글을 읽는 사람들도 꼭 읽어봤으면 좋겠다.
저작자 표시 비영리 동일 조건 변경 허락
신고

submit
Gmail 업무 기술 - 8점
카바사와 시온 지음, 김욱 옮김/한빛미디어

2000년 3월 한메일 주소를 갖게된 이후로 2008년 말까지 우직하게도 한메일만을 고집해왔었다. 2008년도 언젠가부터 메일을 보낼 때 G메일을 가끔씩 쓰기 시작했는데, 그 후 한메일로 오는 메일들을 자동으로 G메일로 퍼갈 수 있다는 것을 알게 된 후로 기존에 받았던 메일을 모두 G메일로 옮겨버리고 완전히 이사를 했다.
처음 G메일을 사용하면서 불편했던 점 한가지는 수신확인 기능이 없다는 것이었는데, 회사 생활을 하다보니 수신확인이라는 기능이 연애초기에 애인과 편지 주고 받는 것을 빼면 그다지 필요하지 않다는 것을 알게되었다.

쓰면 쓸수록 G메일에 빠져들어서 나는 이제 G메일과 다른 구글 서비스들의 광팬이 되어버렸다.
내가 G메일에서 특히 좋아하는 기능들은 다음과 같다.
  • 아카이브
  • 구글 톡 대화기록을 G메일로 저장
  • 메일과 그 회신메일들이 그룹으로 묶여서 보여지는 기능
  • 라벨과 필터를 쉽게 적용.
  • 똑똑한 스팸필터 기능.
이 책에서 새로운 기능들을 배울 수 있을 것 같아서 읽어보긴 했는데 책은 재밌게 읽긴했다만 많은 것을 얻지는 못했다.
  • gmail-backup.com 에서 gmail을 백업할 수 있다는 것.
  • Inbox 위에 나오는 광고를 환경설정에서 없앨 수 있다는 것.
  • 제목 끝에 EOM을 붙이면 G메일이 그걸 인식하고 본문이 없다고 메세지 박스를 띄우지 않는다는 것.
  • 별태그를 여러 색깔로 만들어서 사용할 수 있다는 것.
이 책에서 배울 가장 중요한 점은 메일을 삭제할 필요가 없다는 점이다. 하드디스크나 메일함의 용량이 모자라서 그나마 덜 중요한 데이터를 삭제 해본적이 있는가? 그랬다면 아마 이전에 지웠던 데이터 때문에 나중에 후회해본 적도 있을 것이다.
이제는 용량이 부족해서 어쩔수 없이 데이터를 지워야 하는 시대는 지났다. 사랑하는 사람에게 받았던 연애편지는 물론 대부분의 사람들이 소중하게 다룰테지만, 인터넷쇼핑몰에서 구매확정을 해달라고 보내오는 귀찮은 메일조차도 지우는 것보다는 잘 분리해서 보관하고 있는 편이 더 낫다. 이것은 꼭 메일에만 적용되는 것이 아니라 다른 모든 디지털 데이터와 잘 살아가는 현명한 처사이다.
G메일에서는 아카이브 기능과 필터, 라벨 기능을 통해서 이를 쉽게 적용할 수 있는데 책에 잘 설명되어져 있다.

다음 메일주소를 만들어서 쓰다가 네이버가 뜨니깐 네이버 메일 주소들을 만들어서 또 다른 사람들에게 주소를 가르쳐주고. 그래서 양쪽을 다 들어가면서 메일 확인을 하는 사람들은 꼭 G메일을 안쓰더라도 이 책을 읽어볼 필요가 있다. 한 곳에서 메일을 관리할 수 있는 방법을 배울 수 있을 것이다.

내가 G메일에서 가장 싫어하는 기능이 방금 생각이 났다.
첨부파일을 보낼 때 exe 파일은 보낼 수 없는 점. 압축을 해서 보내도 실행파일인 것을 알아채고 허용을 안해주는데, 그래서 나는 다른 서비스에 파일을 올리고 링크를 복사해서 주거나 파일의 확장자를 바꿔서 보내면서 상대방에게 양해를 구한다. 첫번째 방법은 다른 서비스에 의존하게 되는 것이 영 맘에 들지 않는다. G메일로 첨부하면 보낸 파일 또한 G메일에 저장되는 것이 더 깔끔한데 말이다. 두 번째 방법은 정말 한심한 방법인데, 저 방법을 쓰고 앉아있는 내가 너무 한심해서 G메일에게 더 화가 나곤 한다. 상대방이 다시 첨부파일의 이름을 변경해야하기 때문에 친한 친구에게나 사용하는 것이 좋을 것이다.
저작자 표시 비영리 동일 조건 변경 허락
신고
  1. 11 at 2011.05.18 19:19 신고 [edit/del]

    exe는 압축해서 첨부 가능해요

    Reply
    • Favicon of http://www.benjaminlog.com BlogIcon 김재호 at 2011.05.19 09:57 신고 [edit/del]

      zip 포맷으로 압축하면 첨부가 안됩니다. 7z나 alz, rar로 압축하면 가능하긴 해요. 그런데 이렇게 보내면 상대방 컴퓨터에 압축 풀수있는 프로그램이 없을 때 더 불편하게 만드는 꼴이죠.

  2. Favicon of http://joogunking.tistory.com BlogIcon joogunking at 2011.07.22 19:02 신고 [edit/del]

    강력한 스팸 필터 기능만으로도 쓸 이유능 충분하죠.
    저는 웹브라우저 오페라의 이메일 클라이언트 기능을 지메일에 연결해 사용하고 있습니다. 지메일 관련 유용한 링크 하나 추천합니다.
    http://kr.geek2live.org/tag/Gmail%20Tips

    Reply

submit