윈도우 CE(Windows Embedded CE) 5.0 혹은 윈도우 모바일(Windows Mobile) 5.0에서 무선랜(WiFi)을 사용하는 어플을 개발할 경우 디버깅하기가 어려운 경우가 많다. 보통 액티브싱크(ActiveSync)와 무선랜 연결을 동시에 유지할 수 없기 때문이다. 그럴 경우 액티브 싱크 없이 무선랜 연결만으로 Visual Studio 2005에서 디버깅 가능하도록 해주는 방법이 있어서 소개한다.
관련 내용은 작년에 뉴스그룹에서 확인한 것으로 관련된 문제로 고민하는 분에게는 아주 값진 정보가 될 것으로 생각된다.

작년 8월 30일자로 ink라는 아이디를 사용하는 사람이 포스팅한 글이다.

VS 2005를 사용해서 디버깅할 경우에만 아래 사항이 해당된다.
문제: 액티브 싱크 연결이 없을 경우 연결에 필요한 바이너리를 디바이스로 복사하지 않으므로 디버깅하는데 문제가 발생한다.



1 단계: 아래 파일들을 디바이스로 복사한다.

Clientshutdown.exe
ConmanClient2.exe
CMaccept.exe
eDbgTL.dll
TcpConnectionA.dll

위의 파일들은 다음 위치에 있다.
 "C: \Program Files\Common Files\Microsoft Shared\CoreCon\1.0\Target
\wce400\<CPU>"
디바이스에는 다음 폴더를 만들어서 복사할 것을 권장한다.
"\windows\VS2005_Debug"

2 단계: Visual Studio 2005에서 IP 설정을 한다.

Tools >> Options >> Device Tools >> Devices 메뉴에서
Windows CE 5.0 device를 선택하고 "properties"를 선택한다.

"Windows CE 5.0 device properties" 다이얼로그에서 "Configure"를 선택한다.

"Configure TCP/IP Transport" 다이얼로그에서 "Use Specific IP Address"를 선택한 후
디바이스의 IP 주소를 입력한 후 OK를 선택한다.


3 단계: 디바이스의 conmanclient2.exe을 실행한다.


4 단계: cMaccept.exe을 실행해 연결을 활성화 한다.

디바이스의 cMaccept.exe을 실행한다.

cMaccept.exe를 실행 후 3분 이내에 연결을 시도하라(디버깅을 시작하라).
(제일 처음 연결은 3분 이내로 해야하고 그 이후에 동일한 VS2005 인스턴스를 사용해deployment/debugging을 할 경우는 3분 제약이 없다.)

새로 VS2005를 띄운 후 연결을 하려면 4단계를 다시 수행해야 한다.
(만약 CE 디바이스의 security가 disabled되어 있다면 이단계를 건너띌 수 있다.
"HKLM\CoreConOverrideSecurity = 1"로 세팅하여야 하지만
그럴 경우 악의적인 공격에 노출될 수 있다.)

유용한 정보를 제공해준 ink님께 감사드리며 아래는 복사해 온 원문이다.

---------------------------------------------------------------------
From: "ink" <i...@notmyemail.com>
Date: Aug 30, 8:41 pm
Subject: WiFi disabled when PDA is connected to PC?
To: microsoft.public.pocketpc
.developer,
microsoft.public.dotnet.framework.compactframework


Hi dave
Debugging on CE5.0 device without Activesync
This information ONLY applies to the Visual Studio 2005.

Without the help of ActiveSync, VS 2005 does not automatically copy
the
connectivity binaries down to the device and hence debugging becomes
problematic.

In order to use debugger on Windows CE 5.0 devices without active
sync, you
need to:

Step 1:
Manually copy the following files down to the device.

Clientshutdown.exe

ConmanClient2.exe

CMaccept.exe

eDbgTL.dll

TcpConnectionA.dll

Files are located in the "C: \Program Files\Common Files\Microsoft
Shared\CoreCon\1.0\Target\wce400\<CPU>" (I used arm4i), to a folder on
the
device, I sugest createing a new folder in "\windows\VS2005_Debug".

Step 2:
Set the correct IP address in Visual Studio 2005.

Open VS 2005

Tools >> Options >> Device Tools >> Devices

Choose Windows CE 5.0 device, click on "properties".

On the "Windows CE 5.0 device properties" dialog, click on
"Configure".

On the "Configure TCP/IP" Transport dialog, choose "Use Specific IP
Address"
and type in the IP address of your Windows CE 5.0 device.

Click OK.

Step 3:
Manually launch the conmanclient2.exe

Browse to the conmanclient2.exe on the device and run it. You may also
use
the command prompt if you have one.

Step 4:
Enable the connection by running cMaccept.exe

Browse to the cMaccept.exe on the device and run it. You may also use
the
command prompt if you have one.

Connect to the device (i.e. start debugging you application) within 3
minutes after you run cMaccept.exe. (The 3 minutes window is for the
first
connection. As long as you establish the first connection within 3
minutes,
the following deployment/debugging sessions using the same VS instance
is
not limited by this 3 minutes window)

You need to perform Step 4 again when you try to connect from another
instance of VS2005. (You can skip this step if the security is already
disabled on the CE device by setting "HKLM\CoreConOverrideSecurity =
1". But
disabling security may expose your device to malicious attack)

Hope this helps.

ink
---------------------------------
Update: 위와 관련 내용이 있는 링크를 찾아서 추가합니다.
- Visual Studio For Devices : Using Visual Studio 2005 to debug against Windows CE 5.0 devices without using ActiveSync

- Microsoft Active sync 4.5: Wireless connecton problem
신고


실제로 최근에 발견한 어플 버그로 새롭게 알게된 사실이다.
이건 Win32 API를 사용하는 Windows XP나 Windows CE 및 Windows Mobile에 모두 공통적으로 해당되는 내용이다.
전에 API문서에서 본 것도 같지만 실제 기억속에서 잊혀져서 모르는 것과 다름없는 사실이었다.

SetTimer() API를 사용할 때 주기적으로 WM_TIMER 메시지를 받도록 할 수도 있지만 callback함수로 호출되도록 할 수가 있다.

이것과 관련해서 유의해야할 점이 있다. MSDN의 SetTimer() 문서에 다음과 같은 이야기가 있다.

An application can process WM_TIMER messages by including a WM_TIMER case statement in the window procedure or by specifying a TimerProc callback function when creating the timer. When you specify a TimerProc callback function, the default window procedure calls the callback function when it processes WM_TIMER. Therefore, you need to dispatch messages in the calling thread, even when you use TimerProc instead of processing WM_TIMER.

즉 요약을 하면 TimerProc() 이라는 콜백(callback) 함수를 등록하더라도 윈도우 메시지를 처리하는 window procedure가 있어야 한다는 이야기다. 윈도우를 전혀 생성하지 않는 어플은 콜백방식을 사용하더라도 전혀 SetTimer()함수를 사용할 수가 없다는 이야기이다. 사용하려면 windows procedure를 만들어서 window message를 처리해 주어야 한다.

아래는 아주 오래전 MSDN magazine에서 관련 내용을 설명한 기사의 링크이다.
http://www.microsoft.com/msj/0397/hood/hood0397.aspx


이 기사에 따르면 WM_TIMER 메시지는 항상 발생하고 타이머 콜밸 함수를 등록했을 경우 DispatchMessage() 함수가 호출되었을 때 windows procedure로 WM_TIMER 메시지를 보내는 대신에 콜백함수를 호출하게 된다.

그렇다면 만약 TimerProc() 콜백에서 리턴을 하지 않을 경우 어떤 일이 벌어질까?
결국 WM_TIMER를 처리하는 코드를 계속 수행중인 상태가 되어버리고 그 이후의 윈도우 메시지 처리가 중단된 상태가 되어버린다.
이렇게 되면 TimerProc()이 리턴될 때까지 어플이 락업된 상태가 되어버리니 꽤 심각할 수 있다.
물론 모든 콜백 함수를 사용할 때 주의해야할 점이다.

즉 내용을 정리하면 TimerProc()은 windows procedure와 직접적인 관련이 있어서 처리할 때 그 사실을 염두해 두고 잘 처리를 해야한다.
신고


Windows Embedded CE 혹은 Windows Mobile에서 사용하는 파일시스템에 대한 간단하지만 많은 경우 잘 모르는 내용 하나를 소개하고자 한다.
그것은 특별히 계층적인 구조를 가진 file system이 아니라는 사실이다.
사실 cab이나 exe로 설치되는 어플을 만드는 경우 그리 중요한 사실이 아닐 수 있다
하지만 ROM에 탑재되는 어플을 만들경우 이 간단한 사실은 매우 중요하다.

Windows CE계열 운영체제는 모든 파일이 디렉토리의 계층구조가 없이 저장이된다.
즉 ROM에 들어간 파일의 경우 부팅후에 모두 \Windows 디렉토리에서 볼수가 있다.
다른 디렉토리 및 그 디렉토리에 들어간 파일은 처음 부팅하면서 flash혹은 RAM에 만들어지거나 \Windows에서 카피를 해서 파일을 만든다.

중요한 사실은 만약 ROM에 탑재되는 어플을 만들경우 모두 \Windows에서 실행되고 필요한 파일도 \Windows 디렉토리에서 참조할 수 있도록 해야한다. 만약 다른 디렉토리에서 실행되게 만들경우 일단 동일한 파일이 롬에 들어가고(\Windows 아래에) 또한 별도 디렉토리를 메모리에 생성하고 동일한 파일을 그 위치로 복사해서 만들 수 밖에 없다.
이 경우 불필요하게 중복된 파일이 생기면서 flash이든 RAM이든 메모리 낭비가 일어난다.
주로 OEM혹은 OEM에게 소프트웨어를 납품하는 회사들에 해당하는 이야기이다.
아주 단순하지만 메모리의 효율적 사용을 위해서는 알아야할 중요한 사실이다.

신고



 RSS Feed

방명록

Recent Posts

  1. Xcode4 프로젝트에 프레임..
  2. 특허침해에 휘말리는 iOS..
  3. 최근에 변경된 애플 앱스토..
  4. 아이폰 사용팁 20가지
  5. 나의 관심사 재정리하기

Recent Comments

  1. 영회님 좀 더 자세히 설명해주.. coderiff 2010
  2. 완전 멋진데.. 한가지 아쉬운.. 영회 2010
  3. 그렇군요. 지금까지 Gmail의.. 하인도 2010
  4. 저도 예전에 이것때문에 한동.. coderiff 2010
  5. 어이쿠~ 이런 비밀이 있었네요.. 로드맵 2010

Recent Trackbacks

  1. イベント m lサイズ でスタイ.. イベント m lサイズ でスタイ.. 2014
  2. refurbished laptops refurbished laptops 2014
  3. Personal Security Personal Security 2014
  4. 갤럭시 시리즈의 두번째 버전.. 2011
  5. 하인도의 생각 neohind's me2DAY 2010

Calendar

«   2017/11   »
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30    

Bookmarks

  1. The Old New Thing
  2. Windows Mobile Team Blog
  3. Windows CE Base Team Blog
  4. MobileDeveloper wiki
  5. 류한석의 피플웨어
  6. 애자일 이야기

Site Stats

TOTAL 2,634,593 HIT
TODAY 10 HIT
YESTERDAY 70 HIT

티스토리 툴바