유니코드에 대비한 프로그램을 작성하는 여섯가지 원칙

출처: http://www.jiniya.net/lecture/techbox/unicode1.html

MBCS는 한 문자를 표현하는데 여러 바이트를 사용하는 것을 말한다. 일반적인 영문자의 경우 모두 한 바이트로 표시되지만, 한글과 같은 경우에는 두 바이트를 사용한다. 또한 두 바이트를 사용하더라도 인코딩 규칙에 따라서 서로 다른 두 바이트가 생성된다. 따라서 인코딩 규칙이 맞지 않는 경우에는 제대로 된 문서를 읽을 수 없는 불편함이 있다. 이러한 불편함을 해결하기 위해서 나온 것이 유니코드다. 유니코드에 대해선 이미 많은 문서에서 소개가 되었기 때문에 별도로 설명하진 않겠다. 혹시 좀 더 자세한 내용이 궁금하다면 http://www.jinsuk.pe.kr/Unicode/Unicode_intro-kr.html를 방문해 보도록 하자.

Windows NT에 기반한 운영체제의 경우 커널 코드가 유니코드를 통해서 작성 되었다. 문자열을 입력 받는 API의 경우 유니코드 버전이 기본적으로 사용된다. 만약 MBCS 버전의 API를 호출한다면 내부적으로 MBCS문자열을 유니코드로 변경한 후에 다시 유니코드 버전의 API를 호출하게 된다. 따라서 MBCS 버전의 프로그램을 작성하는 것은 NT 기반의 운영체제에서는 비효율 적이다. 이러한 점 때문에 최근에는 대부분의 업체에서 NT 기반의 프로그램은 유니코드 버전을 출시하고 있다. 유니코드와 MBCS 빌드에 상관없이 유연하게 컴파일 되는 프로그램을 만들기 위해서 지켜야할 여섯 가지 기본 원칙에 대해서 알아보자.

첫째, 문자열 타입은 T형을 쓴다. T형의 경우 유니코드, MBCS 빌드에 상관없이 적절한 타입으로 변환되기 때문에 빌드가 변경된다고 해서 따로 타입을 수정해 주는 불편함이 없다. char를 사용할 장소에 TCHAR를, char *를 사용해야 한다면 LPTSTR을, const char *을 사용해야 한다면 LPCTSTR을 사용하도록 한다.

둘째, 문자열 리터럴은 항상 TEXT 매크로로 묶어 둔다. 문자열 리터럴은 프로그램 내에서 사용되는 문자열 상수를 의미한다. 그런데 이러한 문자열 상수의 경우 유니코드 빌드에선 앞에 L을 붙여서 wchar_t형이 되어야 한다. 즉, 보통의 경우엔 "%s\n"과 같이 사용하면 되지만, 유니코드 빌드에선 L"%s\n"로 변경해 주어야 한다. 이러한 작업을 일일이 빌드가 바뀔 때 마다 해주는 것은 매우 번거롭고 오류가 많이 나는 일이다. 이러한 작업을 도와주는 것이 TEXT 매크로다. 위에 언급된 문자열 상수의 경우에도 TEXT("%s\n")과 같이 사용하면 MBCS 빌드에선 "%s\n"이, 유니코드 빌드에선 L"%s\n"이 된다. 매크로가 알아서 처리해 준다. 따라서 문자열 리터럴은 항상 TEXT 매크로로 묶어주도록 하자.

셋째, CRT 문자열 함수는 T타입 함수를 사용한다. T형과 마찬가지로 이러한 함수들은 빌드에 따라 적절한 인자를 입력으로 받는다. 예를 들자면 문자열을 복사하는 strcpy에 대응하는 함수로는 _tcscpy가 있다. _tcscpy는 유니코드 빌드에선 인자를 wchar_t로 받고, MBCS빌드에선 인자를 char로 받는다. 따라서 _tcscpy를 사용하고 인자를 T형을 사용한다면 빌드가 변경된다고 해서 직접 수정해야 하는 부분이 없다. 아래 표에는 일반적으로 자주 사용하는 문자열 함수들과 거기에 대한 T타입 함수를 표시해 두었다. 표를 살펴보면 알겠지만 변환 규칙은 무척 간단하다. str로 시작하는 함수는 _tcs로 치환 하면 되고, 그렇지 않은 함수들은 앞에 _t를 붙이면 된다. 물론 그렇지 않은 함수들도 일부 있다. 그러한 함수들은 MSDN을 이용하면 손쉽게 T타입 함수명을 알 수 있다.

넷째, 길이와 크기를 구분한다. 문자열에는 길이와 크기가 있다. MBCS 빌드에서 기본적인 문자 단위로 사용되는 char형의 경우 그 크기가 1바이트 이기 때문에 크기와 길이가 동등한 의미를 가진다. 이러한 이유로 기존의 MBCS 빌드에서 사용하던 많은 코드가 크기와 길이를 정확하게 구분하지 않고 혼용해서 사용하고 있다. 하지만 유니코드 환경으로 넘어오면 크기와 길이는 항상 달라진다. 따라서 함수의 인자가 길이와 크기 중 어떠한 것을 요구하는지 판단해서 정확하게 사용하도록 해야 한다.

다섯째, std::string을 사용하는 경우다. std::string의 경우 ANSI 문자열을 표현하도록 선언된 클래스다. 유니코드 문자열을 표현하는데 사용할 수 있는 타입으로 std::wstring이 있다. 이 둘을 빌드 타입이 변경될 때 마다 바꿔줘야 하는 것은 번거로운 일이다. 이쯤되면 std::tstring이 없는지 궁금해 질 것이다. 하지만 std::tstring은 없다. 없으면 우리가 만들어야 한다. std::string의 경우 std::basic_string<char>로 선언된 것이고, std::wstring의 경우 std::basic_string<wchar_t>로 선언된 것이다. 따라서 우리는 아래와 같이 std::tstring을 정의할 수 있다.

마지막으로 일부 함수나 메시지 인자의 경우 반드시 char나, wchar_t로 취급해야 하는 경우가 있다. 이러한 경우 부득이하게 빌드에 따라서 문자열을 변환해서 사용해야 하며 빌드가 변경되면 반드시 코드를 수정해야 한다. 따라서 처음 작성시에 안전하게 두 가지 빌드로된 버전을 모두 작성해 놓거나 아니면 다른 빌드에서 컴파일 할 경우 에러가 나도록 처리해 두면 편리하다. 아래와 같은 전처리기를 사용하면 쉽게 작성할 수 있다. 유니코드 빌드에선 _UNICODE가 선언된다는 점을 기억해 두자.

만약 현재 프로그램이 MBCS 기반이고 유니코드 부분을 지금은 신경 쓰지 않아도 된다면 #error 전처리기를 사용하면 된다. 이렇게 하면 유니코드로 빌드 할 경우 컴파일 오류가 발생하기 때문에 어떤 부분이 수정되어야 하는지 바로 찾을 수 있기 때문에 편리하다.

오픈소스 크래쉬 리포팅 플랫폼

구글에서 하는 것 같은데 좋은지 잘은 모르겠음.

대략적으로 보이는 양으로 봐서는 방대한 스타일은 아닌듯 보이고...

난 서버쪽을 주로 해서 클라이언트 크래쉬 리포팅 쪽을 많이 다뤄보지 않아서 잘 평가가 안되네..

주요 특징

1. (개별 사용자 용) 크래시가 발생했을 때, 이를 breakpad 에서 사용하는 포맷으로 덤프를 남겨주는 부분: in-process 덤프만 있는 게 아니라, 다른 프로세스에서 dump를 남기는 방식(out-of-process dump)도 지원한다
2. (Build-System 용) 디버그 정보를 읽어서 breakpad 내부 형식으로 바꾸는 부분 : Win32 pdb 나 –g 옵션을 넣고 빌드한 *nix 바이너리에서 심볼 데이터를 뽑아낸다
3. (Crash Collector 용) 1에서 나온 정보를 가지고 2를 이용하여 스택 트레이스를 뽑아내는 부분

참조:  Breakpad 로 CrashReporter 만들기

더 있을수도 있지만 우선은

두가지 방법인데 둘다 원격으로 무엇을 실행하는 용도로는 사용을 했었는데 설치로 사용은 안해봤네 ㅋㅋ


NT 시스템에 대한 모의 해킹 중 다양한 서비스를 원격 인스톨하는 기법을 사용하는 경우가 있습니다.

기본적인 명령어의 사용법이나 개념 이해를 도울 수 있는 자료가 있기에 올려봅니다.

---

- How may I remotely install RA on a single distant PC?
- You can use a free tool called psexec.exe available from www.sysinternals.com to deploy and run Slave on all the machines of your LAN with a single line of text.

For the ones that want to understand how it works, you need the Administrator account of the distant PC, and the PC must be reachable by TCP/IP.
Open a DOS box and type the following commands:

• NET USE \192.168.112.24IPC$ /user:administrator password
• COPY "C:Slave.exe" "\192.168.112.24C$WinNT (you may have to replace WinNT by Windows)
• NETSVC \192.168.112.24 schedule /start   (make sure that the Scheduler Service is started)
• NET TIME \192.168.112.24                        (note the time of the remote PC)
• AT \192.168.112.24 10:00 "C:Slave.exe"    (replace 10:00 by the time of the PC plus one minute)

That's it! RA is running on the remote PC so you can access it with Master! You can also use the following commands:

• REGINI -m \192.168.112.24  ra.reg             (to install some Registry settings on the remote PC)
• SHUTDOWN \192.168.112.24 /R /Y /C /T:0  (to reboot the remote PC)

There is a LOGON SCRIPT in the PDF Manual to remotely install/Update/Remove RA on remote PCs. 

---

출처 : http://www.twd-industries.com/en/faq.htm 

정리해 보자면... 

1. psexec 를 활용하여 명령어 한번에 원격 서비스 설치 가능

예) psexec \* -u domainadministrator -p password -c -d -i "C:myservice.exe"

       - psexec \192.168.124.145 -u domainmike -p secret -c -d -i "C:myservice.exe"

2. psexec 활용 불가 시

net use \192.168.112.24IPC$ password /user:administrator

copy "C:slave.exe" "\192.168.112.24C$WinNT

netsvc \192.168.112.24 schedule /start

net time \192.168.112.24

at \192.168.112.24 10:00 "C:slave.exe"

or

regini -m \192.168.112.24 ra.reg 

shutdown \192.168.112.24 /r /y /c /t:0

이 기법은 원격 VNC 설치에도 즐겨 사용되는 기법입니다.

출처:원격 인스톨 방법

은근 가끔씩 필요한 정보

DiamondCS 에서 제공하는 Autostart Guard, Autostart Viewer 프로그램이 모니터링하는 Windows 자동 실행 위치의 리스트 입니다.

웜, 바이러스 등에 감염되었을 때 한번쯤 살펴봐야 할 곳들이죠.

Autostart Locations are listed in no particular order.

Registry Autostart Locations

1. HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRun
   All values in this key are executed. 
2. HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunOnce
   All values in this key are executed, and then their autostart reference is deleted. 
3. HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunServices
   All values in this key are executed as services. 
4. HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionRunServicesOnce
   All values in this key are executed as services, and then their autostart reference is deleted. 
5. HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun
   All values in this key are executed. 
6. HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRunOnce
   All values in this key are executed, and then their autostart reference is deleted. 
7. HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRunOnceSetup
   Used only by Setup. Displays a progress dialog box as the keys are run one at a time. 
8. HKEY_USERS.DefaultSoftwareMicrosoftWindowsCurrentVersionRun
   Similar to the Run key from HKEY_CURRENT_USER. 
9. HKEY_USERS.DefaultSoftwareMicrosoftWindowsCurrentVersionRunOnce
   Similar to the RunOnce key from HKEY_CURRENT_USER. 
10. HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionWinlogon
    The "Shell" value is monitored. This value is executed after you log in. 
11. HKEY_LOCAL_MACHINESoftwareMicrosoftActive SetupInstalled Components
    All subkeys are monitored, with special attention paid to the "StubPath" value in each subkey. 
12. HKEY_LOCAL_MACHINESystemCurrentControlSetServicesVxD
    All subkeys are monitored, with special attention paid to the "StaticVXD" value in each subkey. 
13. HKEY_CURRENT_USERControl PanelDesktop
    The "SCRNSAVE.EXE" value is monitored. This value is launched when your screen saver activates. 
14. HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession Manager
    The "BootExecute" value is monitored. Files listed here are Native Applications that are executed before Windows starts. 
15. HKEY_CLASSES_ROOTvbsfileshellopencommand
    Executed whenever a .VBS file (Visual Basic Script)  is run. 
16. HKEY_CLASSES_ROOTvbefileshellopencommand
    Executed whenever a .VBE file (Encoded Visual Basic Script) is run. 
17. HKEY_CLASSES_ROOTjsfileshellopencommand
    Executed whenever a .JS file (Javascript) is run. 
18. HKEY_CLASSES_ROOTjsefileshellopencommand
    Executed whenever a .JSE file (Encoded Javascript) is run. 
19. HKEY_CLASSES_ROOTwshfileshellopencommand
    Executed whenever a .WSH file (Windows Scripting Host) is run. 
20. HKEY_CLASSES_ROOTwsffileshellopencommand
    Executed whenever a .WSF file (Windows Scripting File) is run. 
21. HKEY_CLASSES_ROOTexefileshellopencommand
    Executed whenever a .EXE file (Executable) is run. 
22. HKEY_CLASSES_ROOTcomfileshellopencommand
    Executed whenever a .COM file (Command) is run. 
23. HKEY_CLASSES_ROOTatfileshellopencommand
    Executed whenever a .BAT file (Batch Command) is run. 
24. HKEY_CLASSES_ROOTscrfileshellopencommand
    Executed whenever a .SCR file (Screen Saver) is run. 
25. HKEY_CLASSES_ROOTpiffileshellopencommand
    Executed whenever a .PIF file (Portable Interchange Format) is run. 
26. HKEY_LOCAL_MACHINESystemCurrentControlSetServices
    Services marked to startup automatically are executed before user login. 
27. HKEY_LOCAL_MACHINESystemCurrentControlSetServicesWinsock2ParametersProtocol_CatalogCatalog_Entries
    Layered Service Providers, executed before user login. 
28. HKEY_LOCAL_MACHINESystemControlWOWcmdline
    Executed when a 16-bit Windows executable is executed. 
29. HKEY_LOCAL_MACHINESystemControlWOWwowcmdline
    Executed when a 16-bit DOS application is executed. 
30. HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionWinlogonUserinit
    Executed when a user logs in. 
31. HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionShellServiceObjectDelayLoad
    Executed by explorer.exe as soon as it has loaded. 
32. HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionWindows un
    Executed when the user logs in. 
33. HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionWindowsload
    Executed when the user logs in. 
34. HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer un
    Subvalues are executed when Explorer initialises. 
35. HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionPoliciesExplorer un
    Subvalues are executed when Explorer initialises. 

Folder Autostart Locations

1. windirStart MenuProgramsStartup
2. UserStartup
3. All UsersStartup
4. windirsystemiosubsys
5. windirsystemvmm32
6. windirTasks

File Autostart Locations

1. c:explorer.exe 
2. c:autoexec.bat
3. c:config.sys
4. windirwininit.ini
5. windirwinstart.bat
6. windirwin.ini - [windows] "load"
7. windirwin.ini - [windows] "run"
8. windirsystem.ini - [boot] "shell"
9. windirsystem.ini - [boot] "scrnsave.exe"
10. windirdosstart.bat
11. windirsystemautoexec.nt
12. windirsystemconfig.nt출처:Windows 자동 실행 위치 
    
    

보통 Auto Start시키는 설정은 다음과 같습니다. 여기에서 예제 스파이웨어 파일명을 malware.exe로 가정해 보겠습니다.

1) win.ini 파일에서 다음과 같이 설치됩니다

[winodws]

load = malware.exe

run = malware.exe

2) system.ini 파일에서 다음과 같이 추가됩니다.

[boot]

Shell = explorer.exe malware.exe

3) Autoexec.bat 파일에서

%windir%system32% 디렉터리 밑에 malware.exe

4) Registry Shell Open

[HKEY_CLASS_ROOT/exefile/shell/open/command]

[HKEY_LOCAL_MACHINE/Software/Classes/exefile/shell/open/command]

"malware.exe %1 %*" 요런식으로 값이 들어가 있습니다.

5) Alternative Registry Keys

[HKEY_CLASSES_ROOT.exe] @="myexefile"]

[HKEY_LOCAL_MACHINE/Software/Classes/myexefile/shell/open/command@="malware.exe %1 %*"]

winstart.bat

6) Main 레지스트리에 등록되는 경우

[HKEY_LOCAL_MACHINE/SoftwareMicrosoft/Windows/CurrentVersion/RunServices]

[HKEY_LOCAL_MACHINE/SoftwareMicrosoft/Windows/CurrentVersion/RunServicesOnce]

[HKEY_LOCAL_MACHINE/SoftwareMicrosoft/Windows/CurrenVersion/Run]

6) wininit.ini 에 혹시 등록되어 있는 프로그램이 없는지 확인

[그림출처:http://wiki.secondlife.com/wiki/Unicode_In_5_Minutes]

인코딩 타입이란 특정 캐릭터셋으로 만들어진 파일을 보여주는 방식입니다. 전세계 주요 언어문자를 하나의 바이너리 코드로 처리하기 위해서 유니코드(unicode)를 만들었지만 이 코드를 보여주는 인코딩 방식은 다양합니다.
많이 사용하는 인코딩 타입으로는 UTF-8, UTF-16, EUC-KR, ISO8859-1, MS949등이 있는데요, 텍스트 파일이 어떤 인코딩 타입으로 설정되어 있느냐에 따라 똑같은 유니코드 데이터도 제대로 보이기도 안보이기도 합니다. 그럼 이 파일이 어떤 인코딩타입으로 되어 있는지 알아내려면 어떻게 해야 할까요?
BOM이라는게 있습니다. BOM(Byte Order Mask)은 파일이 어떤 인코딩 타입임을 나타냅니다만 어떤 에디터는 이 BOM을 생략하기도 하기때문에 절대적이라고 볼 수는 없습니다.
그럼 자바로 쉽게 인코딩 타입을 확인할 수는 없을까? ICU를 이용하면 가능합니다.
ICU(International Component for Unicode)는 이와 관련된 라이브러리를 제공합니다. C와 Java를 지원하며 제가 확인한 것은 자바용인 ICU4J입니다.
1.Maven의 POM에 관련 설정을 추가합니다.

      <dependency>
          <groupId>com.ibm.icu</groupId>
          <artifactId>icu4j</artifactId>
          <version>4.0.1</version>
          <type>jar</type>
          <scope>compile</scope>
      </dependency>

    public static String readFileToString(File file) throws Exception {
        try {
CharsetDetector detector = new CharsetDetector();           
            detector.setText(FileUtils.readFileToByteArray(file));
            return FileUtils.readFileToString(file, detector.detect().getName());  
        } catch (IOException e) {
            throw new Exception(e);
        }
    }

출처: http://pragmaticstory.com/1548

주요출처: http://blog.naver.com/kkan22/80125996680

*  /Wp64 옵션을 켜고 컴파일하여 발생한 경고 / 오류를 해결한다

    1) 일반적으로 발생하는 경고 / 오류

    - 최신 C++ 표준을 적용해 발생하는 템플릿 사용 또는 기본 인자에 관련된 오류 경고

    - 타입 캐스팅 되면서 발생하는 데이타 손실 경고

    - MFC를 오버라이딩해서 사용할때 함수 파라미터/리턴 타입의 변경된 부분에 대한 오류

    - INVALID_HANDLE_VALUE 대신 OxFFFFFFFF를 사용한 경우

    - 사용하는 외부 라이브러리도 모두 64비트이어야 하는데 32비트 라이브러리를 사용하는 경우

* 여러개의 모듈로 제품이 구성되어 있을경우 기본 라이브러리=>DLL=>실행 파일순으로 전체 프로젝트에 포팅해야 한다.

[테스트]

1. 먼저 테스트할 프로그램이 순수하게 64비트로 구성된 프로그램인지 아니면 WOW64를 사용하는 부분도 있는지를 검토해야 한다.

    이러한 것은 테스트 계획 수립단계에서 결정되어야 하며 이에 따라서 테스트 도구가 64비트용만 있으면 되는지 아니면 32비트와 64비트용이

    모두 필요한지가 결정이되고 테스트 환경구축 및 일정산정에도 도움이 되기때문이다.

2. 일반적으로 32비트와 64비트 프로그램 모두 같은 소스를 기반으로 하기때문에 테스트 단계에서의 버그 수정은 다음의 순서를 따른다

    1) 64비트 환경에서 테스트 하고 버그를 수정한다.

    2) 32비트 환경에서 부작용이 없는지 다시 컴파일한후 테스트한다.

    3) 다시 64비트 환경에서 다시 컴파일한후 테스트 한다.

[포인터 관련]

64비트 윈도우가 채택한 LLP64 데이타 모델의 경우 기존의 데이타 타입은 호환성을 위해 32비트를 유지하고 포인터를 64비트로 변경한

데이타 모델이다 그래서 64비트 응용 프로그램을 개발하기 위해서는 다른 어떤 데이타보다 포인터를 다룰때 주의 해야 한다.

1. 포인터를 int, long, UINT, ULONG, DWORD 로 타입캐스팅 하지 말아야 한다.

비트수준의 작업을 하기 위해 포인터를 타입 캐스팅해야 할때는 반드시 32비트와 64비트 윈도우에서 모두 사용할수 있는 타입인 INT_PTR, UINT_PTR를 사용해야 한다. 64비트 윈도우에서는 포인터의 크기가 64비트 이고 int나 long은 32비트이기 때문에 포인터를 int, long, ULONG, DWORD로 타입 캐스팅을 해서는 안된다.

< 포인터를 잘못 타입캐스팅 한예>

PVOID ImageBase;

ImageBase = (PVOID)((ULONG)ImageBase  |  1);

<포인터를 정상적으로 타입 캐스팅 한예>

ImageBase = (PVOID)((ULONG_PTR)ImageBase | 1);

<HANDLE도 void*로 정의 되어 이기때문에 포인터랑 마찬가지로 취급해야 한다>

2. 부득이하게 포인터의 데이타가 손실되더라도 32비트로 타입캐스팅 해야 할경우에는 PtrToLong()이나 PtrToUlong() 함수를 이용해야 한다.

이 함수들은 Basetsd.h에 정의 되어 있다. 이 함수들을 사용하면 데이타 손실 경고를 발생시키지 않는다.

이 함수들은 조심해서 사용해야 하는이유는 타입 캐스팅된이후에는 데이타가 손실된것이므로 이 값들을 포인터로 다시 사용해서는 안된다.

이함수들은 상위 32비트 값들을 얻어낸다.

3. 값을 얻어오는 OUT 형태의 인자를 사용할때 주의 해야 한다.

다음과 같이 정의된 함수를 예로 생각해보자

void func(OUT PULONG* Pointer);

ULONG ul;

PULONG lp;

func((PULONG *)&ul);

lp = (PULONG)ul;

잘못된 호출이다. &ul 을 PULONG*으로 타입 캐스팅 했기때문에 컴파일러 오류는 발생하지 않지만 함수에서는 &ul에 64비트 포인터 값을 쓰게된다.

이 코드는 32비트 윈도우에서는 정상적으로 동작하겠지만 64비트 윈도우에서는 포인터의 데이타 손실이 발생하게 된다.

대신에 다음과 같이 호출해야 한다.

PULONG lp;

func(&lp);

4. 다형성 인자를 사용할경우 UINT_PTR이나 PVOID를 사용해야 한다.

32 비트 윈도우에서는 어떤 타입의 데이타를 넘길지 결정할수 없을때는 DWORD등을 함수의 인자로 타입캐스팅해서 사용하기도 했었다.

그러나 64비트 윈도우에서는 반드시 UINT_PTR나 PVOID와 같은 64비트 윈도우와 32비트 윈도우에서 모두 사용할수 있는 데이타 형을 사용해야 한다.

5. 플랫폼에따라 LPARAM, WPARAM, LRESULT 타입의 크기는 변한다

이 타입들은 포인터나 다형성 인자로 사용되는 타입이기때문에 64비트 코드로 컴파일할때 64비트 크기로 컴파일된다.

그러므로 64비트 환경에서는 정상적으로 동작하게 하려면 LPARAM, WPARAM, LRESULT들을 32비트의 크기를 가지는 DWORD, ULONG, UINT, INT, int,

long값들과 같이 사용해서는 안된다.

6. 꼭 필요한 경우가 아니라면 명시적인 구조체 패킹을 하지말고 64비트 윈도우에서는 8바이트를 기본으로 패킹되는것이 좋다.

   64비트 윈도우에서는 32비트 윈도우와 달리 데이타 패킹을 기본적으로 8바이트 단위로 한다.

7.비트연산에 대해서는 신경써야 하는데 기존의 32비트 윈도우에서는 -1을 비교할때나 INVALID_HANDLE_VALUE 대신 0xFFFFFFFF를 사용하는

   소스도 있었지만 64비트 윈도우에서는 사용해서는 안되는 값이다. 또한 32비트 소스에서는 1 << 33 과 같이 시프트 연산을 할 경우 정상 동작 하겠지만

   64비트 소스에서는 사용해서는 안되는 값이다.

8. NOT 오퍼레이션을 사용할때 주의 해야 한다.

   UINT_PTR a; ULONG b;

   a = a &~(b-1);

   ==> 올바른 코딩

  a = a & ~((UINT_PTR)b -1);

9.작은 크기의 데이타를 할당할때 주의해야 한다

  struct S{

         DWORD NumberOfPointers;

         PVOID Pointers[100];

}

다음의 코드는 잘못된 코드인데 컴파일러는 8바이트 정렬을 맞추기 위해서 4바이트를 추가적으로 패딩해서 할당하기 때문이다.

malloc(sizeof(DWORD) + 100*sizeof(PVOID));

이코드는 다음과 같이 수정하면 된다.

malloc(offsetof(struct S, Pointers) + 100*sizeof(PVOID));

우선 준비물

FastCGI 설치본   

RubyInstaller

RoR extensions for IIS

흠 실패당 ㅠ.ㅠ

위에 준비물들이 Ruby 는 1.9가 되었는데 나머지는 1.8 시절것들만 있이서 호환이 잘 안된다. ㅍ.ㅍ

시간을 좀 들여서 수정을 하거나 최신본을 찾아야 될듯하다 ㅠ.ㅠ

우선 배보다 배꼽이 큰 상황이라 연기