aapt dump xmltree kakaotalk2.6.2.apk AndroidManifest.xml

프로토콜

네트워크 프로그래밍에서는 소켓의 입출력 프로그래밍과 쓰레드 처리가 중요하지만 프로토콜이라는 통신규약이 처리의 중심을 이룬다. 프로토콜은 네트워크로 연결된 컴퓨터 사이의 공통언어이다.
TCP/IP 도 프로토콜의 하나이다. 그러나 TCP/IP 언어는 OS에서 내부적으로 전부번역해 처리해 주는 반면 데이터를 전송하는 역할만을 수행할 뿐이다. 따라서 네트워크로 연결된 컴퓨터끼리의 자료 교환을 위해서는 프로토콜을 만들어야 한다.
프로토콜은 문자 스트림으로 처리될 수도 있고 바이트 스트림으로 처리될 수도 있다.

1. 문자스트림 방식
하나의 프로토콜은 한 라인의 문자열이 된다. 의미 있는 데이터를문자열로 차례대로 구성하고 마지막으로 라인 구분자(line separator)를 포함시킨다. 이렇게 구성된 BufferedReader의 readLine 메서드에서 프로토콜 단위로 쉽게 처리가 가능하게 해준다.
문자 스트림 방식에서는 구성되어있는 문자열 데이터의 길이가 일정치 않은 경우가 많으므로 문자열 데이터 사이에는 문자열 데이터를 구분할 수 있는 구분문자(delimiter)가 들어가게 된다. 이 방식은 대부분의 자바 네트웤 프로그램에서 사용된다.
                             "201|gamefesta|안녕하세요.|"
앞의 프로토콜은 구분 문자 '|'에 의해서 3개의 문자열로 구분된다. "201"은 프로토콜이 대화를 보내는 코드임을 나타내는 숫자이며, "gamefesta"는 대화를 보내는 사람의 아이디이고 마지막의 "안녕하세요"는 실제 대화 내용이다.
구분문자를 이용하는 방법은 구분 문자에 의해서 구분이 되므로 데이터의 길이가 어떻게 되든 상관이 없다. 단지 구분 문자가 실제 문자열 데이터에 나타나지 않도록 구분 문자를 정의하는 것만 조심하면 된다. 이처럼 프로토콜은 프로토콜이 어떤 기능을 하는 지를 나타내는 코드와 그 코드에 맞는 데이터가 순서대로 구성된다.
자바에서 문자 스트림 클래스와 함께 가장 많이 이용되는 클래스는 StringTokenizer 클래스이다. 이것은 문자열을 토큰단위로 잘라주는 클래스이다. 각 문자열 데이터는 delimiter에 의해서 구분되어지고 분리된 문자열 데이터는 하나의 토큰이 된다. 그리고 이 클래스는 구분 문자에 의해서 구분된 토큰인 문자열 데이터를 순서대로 추출해 낼 수 있다. 

2. 바이트 스트림 방식
바이트 스트림 방식은 전송할 데이터가 큰 크기의 바이트 데이터인 경우에 적합하다. 그리고 프로토콜이 일정한 길이를 갖게 할 때도 유리하다.
예를 들어 float형 변수 같은 숫자를 저장하는 변수는 값에 따라서 문자열로 변환할 때 상당히 가변적으로 길이가 변한다.
물론 문자열로 고정된 길이의 데이터를 구현할 수도 있다. 하지만 문자열보다는 바이트 배열을 이용해서 고정된 길이를 갖게 하는 것이 훨씬 간편하고 유리하다.
                x =10.43,  y=100.422,  z=24.230545
위와 같은 데이터는 바이트 스트림으로 처리하는 것이 유리하다. 이 3개의 float 데이터를 byte 배열로 변환해서 보내면, float가 4바이트이기 때문에 3*4=12 바이트면 충분하며 어떤 경우든지 12바이트만 전송하면 된다. 또한 고정된 길이를 갖기 때문에 특정한 데이터만을 바로 얻어낼 수가 있다.

자바 프로그램과 자바 프로그램간의 통신이라면 객체 직렬화를 이용하는 것이 좋다. 객체를 입출력하는 것이므로 객체 직렬화를 이용하면 스트림 속에서 복잡하게 데이터를 얻을 필요도 없으며 프로토콜 수정시 발생하는 문제점도 줄일 수 있다. 또한 String 같은 객체를 포함한 객체도 직렬화가 가능하며 복잡한 기능을 하는 직렬화 객체도 전송해서 바로 사용할 수 있다는 장점이 있다. 

**  다른 바이트 순서를 가진 시스템과의 통신 **

자바의 기본 데이터형은 Big Endian이다. 이것은 최상위 바이트MSB 가 메모리의 가장 처음에 위치하는 형태이다. 가령 정수 0x01234567이 있다면 이것은 바이트 0x01. 0x23, 0x45, 0x67 순으로 메모리에 위치하게 되고 또한 네트웤 출력에서도 이 순서로 출력이 된다. 어떻게 보면 이것이 당연하다고 생각되겠지만 컴퓨터에서는 최상위 바이트가 마지막으로 위치하는 리틀 엔디안을 많이 이용한다. 
리틀 엔디안에서 0x1234567은 0x67, 0x45, 0x23, 0x01 순으로 메모리에 위치하게 된다. cpu에 따라서 다르기는 하지만 대부분의 C/C++ 은 리틀엔디안 이다. 그러므로 자바 시스템에서 리틀엔디안 시스템과 통신을 할 때에는 바이트 순서를 조심해야 한다.
정수 0x1234567 네트웤을 통해 리틀 엔디안 시스템으로 전송할 때 리틀 엔디안의 시스템에서 이 데이터를 메모리에 차례대로 집어넣고 정수로 바꾸면 실제수는 0x67452301이 된다. 그러므로 처음부터 자바 시스템에서 데이터를 거꾸로 보내거나 리틀 엔디안 시스템에서 이것을 거꾸로 바꾸어서 처리해주어야 한다.
그리고 또 조심해야 할 것은 문자 인코딩 방식이다. 자바에서는 문자에 내부적으로 유니 코드를 사용하므로 완성형 코드를 사용하는 윈도우 프로그램과 통신하기 위해서는 인코딩에 대해서 신경 써야 한다. 물론 문자 스트림에서는 현재 시스템의 문자 인코딩 방식으로 입출력하지만 바이트 배열을 인코딩 방식을 지정해서 입출력하는 것이 더 명확하다.
String s = new String(bytes, "KSC5601" );        //완성형 바이트 배열로 문자열 생성
byte [] bytes = s.getBytes("KSC5601");      //문자열로부터 완성형 바이트 배열 얻기

DataOutputstream의 writeBytes(String s)같은 메서드는 인코당과 관계없이 현재 저장된 상태 그대로 출력하므로 사용해서는 안된다.
여기에서 바이트 배열의 기본 데이터형 변환에 대해서 생각해보자.

byte [] bytes = new byte [4];
in.readBytes(bytes, 0 ,4); // 길이 4의 바이트 배열을 읽는다.
int n = ((int)bytes[0] << 24) | ((int)bytes[1] << 16 |
          ((int)bytes[2] << 8)  | ((int)bytes)[3];

앞의 코드는 겉으로 보기에는 아무런 문제가 없어 보인다. 쉬프트 연산을 제대로 수행하기 위해서 int형으로 캐스팅했고 쉬프토도 제대로 된 것처럼 보인다. 하지만 문제는 캐스팅에서 발생한다. 자바는 C처럼 unsinged형을 지원하지 않고 데이터형은 모두 signed형이다. 그러므로 바이트 값의 범위가 0~255가 아니라 -128~127이다. 
예로 0xff라는 바이트는 (물론 자바에서의 0xff는 정수 0x000000ff이지만 편의상 바이트로 표기되었다고 하자)255가 아니라 -1이다. 이 바이트를 정수로 캐스팅하면 0xffffffff인 -1이 된다. 만약에 최하위 바이트 (byte[3])가 0xff라면 or연산으로 결합되므로 결국에는 다른 바이트에 상관없이 0xffffffff가 계산된다.

자바에서 바이트의 정수 캐스팅을 하기 위해서는 먼저 정수 0xff(0x000000ff)로 and연산 시켜서 바이트를 정수로 만들어야 한다. 즉 앞의 코드는 다음과 같이 바뀌어야 ㅏㄴ다. 
int n = ((bytes[0] & 0xff) << 24) |
         ((bytes[1] & 0xff) << 16) |
         ((bytes[2] & 0xff) << 8)  |
         (bytes [3] & 0xff;)
마찬가지로 int 형을 long형으로 바꿀 때에도 정수를  0xffffffffL인 long형 상수를 and 연산키켜 주면 된다.

long l = (ints[0]&0xffffffff << 32) | (ins[1] & 0xffffffffL)

바이트 배열을 실수 데이터형으로 변환시킬 때에는 바이트 배열을 먼저 int나 long형으로 바꾼 후에 float나 double로 바꿀 수 있다. int혀을 float로 바꿀 때에는 다음과 같이 하면 된다.
float f = Float.intBitsToFloat(i); // 바이트 배열을 정수로 바꾼 i를 float로

long형을 double로 바꿀 때에는 다음과 같이 하면 된다.
double d= Double.longBitsToDouble(1); // 바이트배열을 LONG형으로 바꾼 1을 double로
         


-도서출판 대림, 김찬수/김양준 공저, "자바게임 프로그램밍" 참조

Home » Getting information about images » Example of using the --info linker option

To display the component sizes when linking enter:

armlink --info sizes ...

Here, sizes gives a list of the Code and Data sizes for each input object and library member in the image. Using this option implies --info sizes,totals.

The following example shows the output in tabular format with the totals separated out for easy reading:

Example 2. Image component size information

Code (inc. data)   RO Data   RW Data    ZI Data      Debug3712        1580        19        44      10200       7436   Object Totals0              0        16         0          0          0   (incl. Generated)0              0         3         0          0          0   (incl. Padding)21376        648       805         4        300      10216   Library Totals 0              0         6         0          0          0   (incl. Padding)===============================================================================Code (inc. data)   RO Data    RW Data    ZI Data      Debug25088       2228       824         48      10500      17652   Grand Totals25088       2228       824         48      10500      17652   ELF Image Totals25088       2228       824         48          0          0   ROM Totals===============================================================================Total RO  Size (Code + RO Data)             25912 (  25.30kB)Total RW  Size (RW Data + ZI Data)          10548 (  10.30kB)Total ROM Size (Code + RO Data + RW Data)   25960 (  25.35kB)

In this example:

Code (inc. Data)

Shows how many bytes are occupied by code. In this image, there are 3712 bytes of code. This includes 1580 bytes of inline data (inc. data), for example, literal pools, and short strings.

RO Data

Shows how many bytes are occupied by read-only data. This is in addition to the inline data included in the Code (inc. data) column.

RW Data

Shows how many bytes are occupied by read-write data.

ZI Data

Shows how many bytes are occupied by zero-initialized data.

Debug

Shows how many bytes are occupied by debug data, for example, debug input sections and the symbol and string table.

Object Totals

Shows how many bytes are occupied by objects linked together to generate the image.

(incl. Generated)

armlink might generate image contents, for example, interworking veneers, and input sections such as region tables. If the Object Totals row includes this type of data, it is shown in this row.

In the example, there are 19 bytes of RO data in total, of which 16 bytes is linker-generated RO data.

Library Totals

Shows how many bytes are occupied by library members that have been extracted and added to the image as individual objects.

(incl. Padding)

armlink inserts padding, if required, to force section alignment. If the Object Totals row includes this type of data, it is shown in the associated (incl. Padding) row. Similarly, if the Library Totalsrow includes this type of data, it is shown in its associated row.

In the example, there are 19 bytes of RO data in the object total, of which 3 bytes is linker-generated padding, and 805 bytes of RO data in the library total, with 6 bytes of padding.

Grand Totals

Shows the true size of the image. In the example, there are 10200 bytes of ZI data (in Object Totals) and 300 of ZI data (in Library Totals) giving a total of 10500 bytes.

ELF Image Totals

If you are using RW data compression (the default) to optimize ROM size, the size of the final image changes and this is reflected in the output from --info. Compare the number of bytes under Grand Totals and ELF Image Totals to see the effect of compression.

In the example, RW data compression is not enabled. If data is compressed, the RW value changes.

ROM Totals

Shows the minimum size of ROM required to contain the image. This does not include ZI data and debug information which is not stored in the ROM.

Concepts

• Linker options for getting information about images.

Reference

Linker Reference:

• --info=topic[,topic,...].

이 솔루션 아티클은 Windows Live Messenger를 클린 인스톨 하는 방법에 대해 설명합니다.

 

1. 컴퓨터에서 Windows Live Messenger를 삭제 합니다.

1) 프로그램 목록을 엽니다.

Ÿ   Windows Vista 와Windows 7은 시작을 클릭한 후 검색상자에 프로그램 및 기능을 입력한 후 Enter를 누릅니다.

Ÿ   Windows XP는 시작과 실행을 클릭한 후 Control Appwiz.cpl를 입력합니다. 확인을 누르면 프로그램 추가/제거 창이 나타납니다.

2) Windows Live 필수패키지(Windows Live Essentials) 를 찾아 제거를 클릭합니다.

3) 새 창이 열리면, 제거를 클릭 한 후 계속을 클릭합니다.

4) 목록에서 Windows Live Messenger를 선택하고 계속을 클릭합니다.

5) Windows Live Messenger 제거를 위해 화면의 지침을 따릅니다.

 

2. 컴퓨터에서 임시 파일 및 폴더를 제거합니다.

1) 디스크 정리 관리 창을 엽니다.

Ÿ   Windows XP에서, 시작, 실행을 클릭하여 cleanmgr 을 입력한 후 확인을 클릭합니다.

Ÿ   Windows Vista 및 Windows 7에서, 시작을 클릭하고 검색 상자에 cleanmgr 을 입력한 후 Enter를 누릅니다.

만약 메시지가 나타나면 정리할 드라이브를 선택하십시오. 목록에서 C:를 누른 다음 확인을 누릅니다.

 

참고:

• 하드 디스크가 분할된 경우 CleanMgr 유틸리티에서 드라이브를 선택하라는 메시지를 표시합니다. 

• 디스크 정리 유틸리티에서 비울 수 있는 디스크 공간을 표시합니다. 

• 이 작업에 몇 분이 걸릴 수 있습니다.

 

2) 디스크 정리 탭에서 다음 옵션만 선택되어 있는지 확인합니다.

• 다운로드한 프로그램 파일 

• 임시 인터넷 파일 

• 임시 파일 

• 임시 오프라인 파일 

• 오프라인 파일

 

3) 확인을 두 차례 누릅니다.

 

3. Windows Live Messenger와 관련된 캐시 파일을 삭제합니다.

1) Microsoft Windows Explorer 설정을 변경합니다:

a. 시작, 내 컴퓨터를 클릭합니다.

    Windows Vista 및 Windows 7의 경우, 시작, 컴퓨터를 클릭합니다.

b. 도구 메뉴에서 폴더 옵션을 클릭합니다.

    Windows Vista, Windows 7의 경우, 도구 메뉴가 보이지 않는다면 Alt를 클릭합니다.

c. 보기 탭의 고급 설정 리스트에서 숨김 파일 및 폴더 아래의 숨김 파일 및 폴더 표시를 선택합니다.

d. 알려진 파일 형식의 파일 확장명 숨기기 확인란의 선택을 취소합니다.

e. 폴더 옵션 창을 닫기 위해 확인을 클릭합니다.

 

2) Windows Live Contacts 폴더를 제거합니다:

a.       사용 중인 운영체제에 따라 다음 위치를 찾습니다.

·         Windows XP:

시작에서 내 컴퓨터를 클릭합니다.

다음 위치를 찾습니다.

C:\Documents and Settings\<Windows logon name>\Local Settings\Application Data\Microsoft

 

·         Windows Vista 및Windows 7:

시작에서 내 컴퓨터를 클릭합니다.

다음 위치를 찾습니다.

C:\Users\<Windows logon name>\AppData\Local\Microsoft

 

참고: <Windows Logon name>은 Windows에 로그인 할 때 사용하는 로그온 이름입니다.

b. 해당 위치에서 Windows Live Contacts 폴더를 삭제합니다.

 

4. Windows Live Messenger 관련 레지스트리 키를 제거합니다.

중요: 다음 단계에서는 레지스트리를 수정하는 방법을 설명합니다. 레지스트리를 수정하기 전에 해당 레지스트리를 백업하고 문제 발생 시 이를 복원하는 방법을 이해해야 합니다. 레지스트리를 백업, 복원 및 편집하는 방법에 대한 자세한 내용은 다음 웹 사이트를 참고하십시오.

http://support.microsoft.com/kb/256986

 

1) 명령 프롬프트를 실행합니다.

Ÿ   Windows XP에서, 시작, 실행을 클릭하여 CMD를 입력한 후 확인을 클릭합니다.

Ÿ   Windows Vista 및 Windows 7에서, 시작을 클릭하고 검색 상자에 CMD를 입력한 후 Enter를 누릅니다.

 

2) 아래에 표시된 명령어를 기호(", ‘)를 포함하여 순서대로 정확하게 복사하여 붙여넣기 한 후 Enter를 누릅니다.

 

참고: 간혹 키가 없다는 오류가 나타날 수도 있으며 이러한 경우 다음 명령어를 입력합니다.

 

REG DELETE "HKLM\Software\Microsoft\Windows Live\Messenger' /f

 

REG DELETE HKCU\Software\Microsoft\MSNMessenger /f

 

REG DELETE "HKCU\Software\Microsoft\Windows Live\Communications Clients\Shared" /f

 

REG DELETE HKCU\Software\Microsoft\IdentityCRL /f 

 

 

5. 컴퓨터를 다시 시작합니다.

 

6. Windows Update를 수행합니다.

1) 다음 사이트를 방문합니다.

http://windowsupdate.microsoft.com

2) 컴퓨터를 업데이트 해야 하는지 확인한 다음 필요한 경우 업데이트를 설치합니다.

3) 업데이트를 적용한 후 컴퓨터를 다시 시작합니다.

 

7. Windows Live Messenger를 다시 설치합니다.

1) 다음 사이트를 방문합니다.

http://download.live.com

2) Windows Live Messenger를 다운로드 하여 설치합니다. 

매형한테 새해선물 받은 토끼옷을 착용한 미미~~~ ^^