얼마전에 윈도우폰7의 개발문서가 유출되서 일부가 인터넷에 올라왔다.(http://wmpoweruser.com/?p=13486) 물론 진위여부에 대한 논란이 있을 수 있지만 개인적으로는 내용으로 봤을 때는 진짜가 맞다고 확신한다.
얼마 안되는 분량이지만  중요한 내용들이 일부 있어서 앞으로 출시될 윈도우폰7의 모습이 어떨지 약간 예상해 볼 수 있다. 물론 곧 있을 MIX 컨퍼런스를 통해서 공식적으로 세부적인 내용이 공개가 되서 좀 더 자세한 내용을 알 수 있을 것이다.
(참고로 이 글은 개발자를 대상으로 쓴 글이기에 일반인이 이해하기 어려운 내용이 있을 수도 있다.)

impTrack
1. 윈도우폰7 개발환경
Windows Phone Application Platform이라는 명칭으로 어플 개발환경을 지칭한다. 주 개발방식은 Silverlight, XNA, .NET Compact Framework이고 native code를 사용한 개발은 OEM과 MO(Mobile Operator)에게만 제한적으로 제공될 것이다.

즉, 이번의 OS가 변경이 되면서 바이너리 호환성뿐만 아니라 소스코드의 호환성도 상당부분 포기한 것으로 보인다. 기존의 Win32로 개발한 코드는 윈도우폰7에서 재사용하지 못하게 된다. 물론 OEM혹은 MO와 같이 일하는 업체의 경우는 native code를 접근할 수 있는 방법이 지원이 되겠지만 그렇지 못할 경우 .NET CF혹은 Silverlight를 사용해서 어플을 재개발해야만 할 것이다. 사용할 수 있는 native code도 용도에 맞게 제한을 할 것이고 또한 합의한대로 사용을 하는지 MS에서 심사과정을 거치게 된다.


2. 폐쇄적인 어플 다운로드 및 실행 환경
소프트웨어가 제한된 Sandbox에서 수행되고 현재 애플이 아이폰에서 하는 것과 유사하게 MS에서도  소프트웨어 등록 절차를 통해서 소프트웨어 실치를 완벽히 통제 할 것으로 보인단. 또한, OEM에서 만든 어플도 외부에서 다운로드해서 설치하는 어플과 동일한 환경에서 수행이 될 것이며 심지어 OEM어플도 MS Marketplace 심사과정을 거쳐야만 디바이스에 탑재가 가능해 진다.
즉, 이것이 의미하는 것은 기존 윈도우 모바일의 자유로운 어플 실행환경을 버리고 아이폰과 유사하게 MS가 소프트웨어를 완벽히 통제하는 시스템으로의 변경을 뜻한다.

일단 native개발환경을 기본적으로 제공하지 않는 것은 좀 더 통제하기 쉬운 .NET runtime으로 실행환경을 제한해서 통제를 용이하게 하려는 의도가 보인다.
또한 기존 윈도우 모바일에서는 잘 못 만들어진 어플 하나로 전체 시스템이 불안해질 수 있는 가능성이 항상 열려 있었지만 이제는 소프트웨어 등록절차를 통해서 그런한 소프트웨어가 소비자 단말에 설치가 되는 것을 막는 것이 가능해진다.

예전에 본 MS 통계자료에 의하면 MS로 제출되는 오류보고 내용 중 상당부분이 MS나 OEM어플이 아닌 3rd party 어플이었다. 그동안 윈도우 모바일의 불안정한 문제들에 대해서 소비자들의 불만이 많았고 이러한 것을 좀 더 효과적으로 통제할 수 있는 방법이 어플의 권한을 제한하고 등록과정을 통해서 문제가 있는 어플들을 사용할 수 없도록 미리 걸러내는 것이다. 심지어 OEM어플도 심사를 하겠다고 하니 전혀 예외를 두지 않을 생각으로 보인다.

물론 이런 시스템 안정성을 향상시키는 것외에도 애플이 아이폰의 폐쇄적인 환경을 통해서 영향력을 더 키우고 많은 수입을 올릴 수 있는 채널을 만들어 낸 것처럼 MS도 유사한 플랫폼 통제를 통해서 더 많은 수익을 내려고 하는 의도도 분명히 있을 것이라고 생각된다.

참고로 최근에 공식적으로 확인되지는 않았지만 윈도운폰7은 3가지 기구타입으로 제한한다는 소문이 떠돌고 있다. 이것은 호주에 있는 MS관계자를 통해서 나온 말로 MS는 공식적으로 부인하고 있다. 일단 사실 이라면 하드웨어 사양, 기구, 소프트웨어까지 상당히 많은 부분을 MS에서 통제할 것으로 보이고 어느정도 범위내에서 통일된 사용자 경험을 제공할 수 있을 것으로 생각된다. 물론 OEM들은 그만큼 차별화하기가 어려워지고 부정적으로는 단순히 MS 제품을 찍어내는 공장으로 지위가 하락할 수도 있다.

3. 3 Screens + Cloud
윈도우폰7의 변환들이 단순히 윈도우폰만을 염두해 둔 것이 아니라 Silverlight를 통해서 추구하고 있는 데스크톱 + TV + 모바일의 3개의 화면에서 유사한 사용자 경험을 제공하는 것을 강조하고 있다. 그런 의미에서 기존 윈도우 모바일에서 제공되지 않았던 Silverlight가 이번에 주요 개발환경 중 하나로 등장하게 되었다. 이러한 3 screen전략은 Adobe가 Flash와 AIR를 통해서도 추구하고 있고 Oracle (인수 전 Sun)에서도 Java와 JavaFX를 통해서 추구하고 있다. 과연 각 screen을 어떠한 기술이 장악할 수 있을지 지켜보는 것도 재미있는 관전 포인트 중에 하나일 것으로 생각된다.


4. 다소 부정적인 개발자들의 반응
XDA 개발자 포럼에서의 반응은 그리 좋지는 않다. 데스크탑 윈도우에서도 이미 여러 해 전부터 .NET을 주 개발플랫폼으로 밀려고 했고 많은 사람들이 .NET으로 개발하고 있지만 여전히 많은 개발자들이 native code (Win32, MFC, WTL 등)으로 개발을 하고 있다. 기존에 윈도우 모바일은 Win32 API를 지원했기에 기존에 만들어진 데스크탑 코드를 쉽게 윈도우 모바일로 가져올 수 있었다. 하지만 더이상 native code를 지원하지 않는다면 포팅하기 어렵거나 불가능해지는 어플에 상당히 제약이 생길 수 밖에 없다.

또한 .NET 환경이 아무래도 native환경보다는 약간 느릴 수 밖에 없다. 게임이야 개발환경보다는 OpenGL ES와 같은 하드웨어 가속기 지원여부가 성능에 더 큰 영향을 미치기 때문에 상관없을 수 있다. 하지만 높은 성능을 요구하는 멀티미디어 어플의 경우 과연 native 개발환경없이 개발이 얼마나 수월할지 의문이 든다.

예를 들면, 나는 가끔 Youtube에서 플래시 비디오(*.flv) 파일을 저장해서 내 스마트폰에 설치된 CorePlayer를 통해 스마트폰으로 동영상을 보는 경우가 있다. 멀티미디어 코덱의 경우 대부분 C로 만들어 지고 일부 어셈블리까지 사용하기도 한다. 만약 .NET 개발환경만 제공이 된다면 디바이스에서 디폴트로 제공되는 코덱외의 다른 코덱을 추가하기가 어려워 보인다. 그렇다면 CorePlayer같은 어플에서는 어떻게 코덱을 지원할 것인지 문제가 된다. native 개발환경이 제공되지 않으므로 발생되는 문제는 이외에도 여러 가지가 있을 것이다.

5. 개인적인 평가
이번의 변화로 기존의 보유하고 있던 많은 수의 윈도우 모바일 어플들은 더이상 윈도우 폰7에서 사용할 수 없게 되므로 MS는 완전히 새로운 출발을 해야 하는 입장이다. 더군다나 기존의 개발자들도 계속 윈도우 폰에서 개발을 하려면 역시 기존의 지식의 많은 부분을 버리고 새로 시작을 해야할 가능성이 크다. 특히 native개발자라면 상당히 커다란 변화에 충격을 느끼는 사람들도 있을 것이다. MS의 입장에서도 아마 커다란 도박일지도 모른다 하지만 이건 어쩔 수 없는 선택이라는 생각이 들기도 한다.
어떻게 진행이 될지 두고봐야하겠지만 윈도우폰7이 성공하려면 기존의 개발자와 개발된 어플들을 어떻게든 쉽게 포팅할 수 있는 방법을 제공하고 최소한 기존 .NET CF 어플이라도 최소한의 노력으로 윈도우폰7에서 돌아갈 수 있도록 개발자들을 적극적으로 지원하는 것이 필요하다고 생각된다.
결국 애플 앱스토어에서 볼 수 있듯이 얼마나 빨리 그리고 얼마나 많은 양질의 어플들을 확보할 수 있는지가 윈도우폰7의 성공여부를 결정 할 수 있다.
그나마 MS가 개발자 지원에 있어서는 높은 점수를 줄 수 있어서 뭔가 잘 해내지 않을까라는 기대를 조심스럽게 해본다.
어떻게 보면 기존의 윈도우 모바일에서 별 영향력이 없었던 모바일 개발자들에게는 새로 변화되는 환경이 새로운 기회의 장이 될 수 있지 않을까도 생각이 된다.

* 과연 안드로이드는?
재미있는 사실은 지금 안드로이드의 모습은 예전(혹은 현재?)의 윈도우 모바일의 모습을 많이 닮은 것 같고 이번에 출시될 윈도우폰7은 아이폰의 모습을 많이 닯은 것 같다. 물론 구글과 MS는 사업적인 목표가 달라서 발생하는 부분도 있지만 MS가 아무래도 모바일쪽에서는 훨씬 더 경험이 많기 때문에 이번에 윈도우폰7의 모습이 더 아이폰과 같이 폐쇄적이고 통제된 모델을 닮아가는 사실이 재미있기만 하다. 이미 안드로이드에 대해서도 여러가지 부정적인 목소리들이 나오고 있다. 특히 단말의 종류가 너무나 다양해져서 발생하는 fragmentation에 대해서는 MS는 이번에 나름대로 대안을 내놓은 듯 하지만 과연 안드로이드는 어떻게 될지 궁금하기도 하다.


*photo above taken from: zdnet.com



저작자 표시 변경 금지
신고


드디어 윈도우폰(Windows Phone) 7에 대한 실체가 MWC에서 들어났네요.
여러 곳에서 잘 요약을 하셔서 제가 특별히 다시 정리하지는 않을 생각입니다만
몇 가지 개발자 입장에서 중요한 점들에 대해서 이야기를 해볼까 합니다.


윈도우폰7관련 소식은 MS 서진호 차장님 블로그를 참조하세요.
http://blogs.msdn.com/jinhoseo/default.aspx

또한 영문으로 윈도우폰7에 대해 잘 요약된 글이 있어서 링크를 겁니다.(영문)
http://gizmodo.com/5471805/windows-phone-7-series-everything-is-different-now

한국어로 잘 정리한 자료도 링크 겁니다.
MS제국의 역습, '윈도폰 7 시리즈'

제 의견을 약간만 덪붙이면, 일단 기존에 윈도우모바일을 버리고 완전히 새롭게 디자인된 것으로 보이구요.
제가 알고 있기로는 몇 년 전에 계획하던 윈도우폰7의 모습과도 전혀 다른 형태로 발표가 되었네요. 특히 기대했던 것처럼 Zune 기능이 들어가 있고 거기다 추가로 XBox Live기능도 추가되어 있습니다. 이제 진정으로 아이폰과 승부할 수 있는 디바이스가 탄생할 수 있을 것 같다는 생각이 듭니다.

발표자료 중에 출시를 위해 협력중인 OEM과 사업자에 대한 이야기가 있었습니다.

마이크로프로세서는 퀄컴(Qualcomm)쪽과 협력중에 있다고 했습니다.

윈도우폰7 런치를 위해 협력중인 OEM: Samsung, LG, Garmin, Asus, HTC, HP, DELL, Sony Ericsson, Toshiba

윈도우폰7 런치를 위해 협력중인 사업자: T-Mobile, Telefonica, Sprint, Vodafone, AT&T, Orange, SFR, Verizon, Telstra, Telcom

역시 우리의 삼성과 LG는 협력중인 OEM에 들어가 있지만 국내 사업자인 SKT나 KT는 보이지가 않네요. 그러므로 국내에서는 윈도우폰7을 올해 안에 볼 가능성이 좀 희박하지 않을까 싶은데요. 제 소식통에게 한 번 문의해봐야 겠네요.

또한 기존 윈도우모바일과 차별되는 점이 MS에서 직접 모든 윈도우 폰에서 비슷한 UI가 제공되도록 어느정도의 통제를 할 것 같습니다. 일단은 기존처럼 커스터마이즈 가능한 Today screen이 제공되지 않는 것 같고 커스터마이즈 가능한 부분들이 더 줄어 들 것으로 예상이 됩니다.
또한 하드웨어 사양도 정해진 사양을 만족하는 디바이스만 만들 수 있을 것 같습니다. 그래서 사용자에게 좀 더 통일된 사용자 경험을 전달하는 것이 주요 목표 중에 하나로 보입니다. 그동안 디바이스 별로 너무 중구난방이긴했으니까요.

일단 OS의 세부적인 내용이 좀 더 공개되야 확실하겠지만 기존에 쌓아왔던 개발지식은 많은 부분을 버리고 다시 시작해야할 가능성이 높아 보입니다. 일단 현재 Zune의 SDK가 없지만 XNA 라는 프레임워크를 통해서 게임 개발은 가능합니다. 제 생각으로는 윈도우폰7 개발을 준비하실 분들은 XNA에 대해서 대략적으로라도 한 번 살펴보는 것이 도움이 되지 않을까 생각됩니다. 참고로 XNA는 C#을 사용해서 개발합니다. 저같이 native code가 더 익숙한 개발자에게는 더 배워야할 것이 많을 것 같네요.

어찌되었든 새로 발표된 윈도우폰7을 보면서 그래도 MS가 죽지는 않았구나 라는 생각이 들더군요. 개발자에게는 공부해야할 것이 많아질 수 있겠지만 그만큼 또 새로운 기회가 생기는 것이 아닌가 생각됩니다. 개발자 여러분 공부 열심히 합시다!!! ^^





저작자 표시 변경 금지
신고


요즘 국내에서 화두에 오르는 스마트 폰을 꼽으라면 아이폰과 옴니아2가 있다. (물론 이제 곧 출시를 앞둔 모토로이도 있긴하다.) 그리고 이 두가지를 비교하면서 아이폰에는 찬사가 윈도우 모바일 폰인 옴니아에는 비판이 더 많이 따라다니는 듯 하다. 개인적으로 보기에는 윈도우 모바일과 아이폰을 비교하면 당연히 아이폰이 승리할 수 밖에 없다. 도대체 왜 이런 비교가 무의미할 정도의 차이점을 가져오는 것일까? 뻔한 이야기이지만 잘 모르는 사람들을 위해 나의 생각을 나누려고 한다. 결론부터 간단히 이야기하면 윈도우폰과 아이폰은 태어난 환경과 목적이 전혀 다른 기기들이다. 하지만 현재 같이 경쟁할 수 밖에 없는 상황이다. 그러므로 비교가 안되는 것이 자연스러운 결과일지도 모른다.

1. 윈도우 모바일 이전의 PDA 세상

1996년 Palm이라는 회사에서 PalmPilot이라는 PDA를 출시하면서 PDA라는 시장을 개척했고 여러해 동안 최고의 PDA회사로 PDA의 선구자로 군림하였다. PalmPilot은 현재와 비교하면 상당히 저사양의 하드웨어 돌아갔고 화면도 컬러가 아닌 모노크롬을 사용했으면 입력방식은 스타일러스를 사용하였고 특징적으로 화면 하단부분에 필기인식을 위한 영역이 따로 존재하였다. 나름대로 하드웨어 사양에 비하면 빠르게 돌아가는 OS를 가지고 있었으며 비교적 활발한 개발자 생태계를 통해서 여러 killer app 들을 확보하였다. 어떤 app들은 현재까지도 회자가 되기도 하니 나름대로 그 시대에는 현재 애플 이상으로 성공을 누리고 있었다.

Palm Pilot
사진출처: cnet.com - Photos: 10 years of Palm handhelds


2. MS의 PDA 시장으로 진출

MS에서는 비슷한 시기의 데스크톱에서의 윈도우의 성공을 임베디드 디바이스로 이어가기 위해서 윈도우CE 1.0을 출시하였고 이 때부터 'MS의 손안에 들어가는 PC'에 대한 도전이 시작되었다. 사실 처음 시도들을 그다지 성공적이지는 않았다. 현재 우리가 아는 윈도우폰의 초장기의 모습은 2000년에 출시된 Pocket PC 2000에서 볼 수 있다. 제품의 이름처럼 Pocket PC는 PC에서 나름대로 성공한 윈도우의 환경을 PDA로 끌어와서 Palm이 주도하고 있던 PDA 시장에 도전장을 낸 것이나 다름이 없다. 또한 제품 이름에서처럼 시작버튼 대표되는 윈도우의 GUI와 유사한 부분들이 많았고 현재와는 다르게 PC와 유사해서 새로운 것을 배울 필요가 없다는 것을 내세우며 오히려 그당시에는 장점으로 홍보가 되었다.

Palm에서도 뛰어난 제품을 만들었지만 여러해가 지나도 근본적인 모습에 큰 변화는 없었다. MS의 Pocket PC는 컬러풀한 UI 그리고 MP3 재생등의 멀티미디어 기능을 내세우며 모노크롬의 화려하지도 않은 Palm PDA의 주도권을 점점 뺏어가기 시작했다. 물론 Palm도 거기에 대응하기 위해서 컬러버전의 디바이스도 내놓았고 MP3등을 지원할 수 있는 확장팩도 내놓긴했지만. 모든 것을 기본으로 제공하면서 가격도 비교적 저렴한 Pocket PC를 사용한 디바이스에게 시작을 내줄 수 밖에 없었다. 결국 나중에는 Palm에서 Palm OS를 사용한 PDA생산을 중단하고 윈도우 모바일 운영체제를 도입하면서 Palm의 시대를 끝을 맞이했다고 볼 수 있다. 나름대로 Pocket PC의 공격에 대응을 하려고 했지만 너무나 늦었고 이미 대응할 수 있을 힘을 키웠을 때는 시장의 추세가 회복하기 어려운 시점이었다.

사실 PDA 라는 단말이 개인정보를 관리하는 것이 주 목적으로 출발한 기기이고 그렇기 때문에 비지니스 쪽 사용자들이 많을 수 밖에 없다. Pocket PC는 이러한 환경 가운데서 만들어졌으며 Palm을 이기면서 나름대로 그 시대에서는 큰 승리를 거둘 수 있었다. Pocket PC가 시장의 대세가 되어가면서 우리가 흔희 아는 HP의 iPaq 시리즈가 한 때 엄청난 인기를 끌었었다.

3. 윈도우폰의 변천

아래 그림은 왼쪽 위부터 순서대로 Pocket PC 2000, Pocket PC 2002, Pocket PC 2003 Windows Mobile 5.0, Windows Mobile 6.1, Windows Mobile 6.5의 오늘(Today) 화면들이다. (윈도우 모바일은 폰의 idle screen을 Today라고 칭한다)


출처: Wikipedia - Widows Mobile

화면을 보면 느끼는 것이 Pocket PC 2000 부터 Windows Mobile 6.1까지 화면이 약간더 화려해 지고 중간에 소프트키 개념이 도입이 되긴 했지만 전체적인 구성이 크게 달라지지는 않았다. 또한 MS에서 제공하는 기본 어플들도 보면 오래전 버전과 현재 버전이 그리 크게 바뀌지는 않은 것을 알 수 있다. Palm과 유사하게 스타일러스를 사용한 입력방식을 가정하고 만들어졌고 UI적인 부분은 약간 더 보기 좋게 변하긴 했지만 버전업되면서 변화하는 것들은 GUI보다는 실제적인 OS에서 제공하는 기능들에 초점이 맞추어져 있었다. 하긴 데스크톱을 봐도 Windows95나 Windows7 이나 기본적인 GUI는 유사하게 동작하니 데스크톱 세계와 별반 다를게 없다고도 할 수 있을 것 같다.

윈도우 폰은 그동안 처음 출발이 그랬던 것처럼 비지니스 업계의 사람들에게 좀 더 친화적인 기능을 제공을 했었고 비록 멀티미디어 기능을 지원하긴 했지만 그것이 핵심기능으로 부상하게 된 것은 그리 오래되지 않았다. MS에서도 목표하는 시장이 비지니스 영역이었고 비록 현재 UI가 별로라고 느껴질지 모르겠지만 비지니스 친화적인 기능에서는 아직 윈도우폰이 아이폰 보다는 높은 점수를 받을 수 있다. 윈도우 모바일 6.0 정도 부터는 MS도 비지니스 영역보다는 일반 소비자를 타깃으로 좀 더 일반 사용자 시장에도 OS의 입지를 굳히려고 노력을 하고 있다.

여기서 강조하고 싶은 것은 윈도우폰은 원래 Palm PDA와 경쟁하기 위해서 만든 제품이었고 일반 소비자보다는 비지니스 시장에서 사용되는 것이 목표였다. 또한 Pocket PC 2000년부터쳐도 벌써 10년이 된 모바일에서는 오래된 OS이다.

4. 출발이 다른 아이폰

아이폰의 경우는 이미 모바일 시장이 많이 활성화되었고 하드웨어가 비약적으로 발전하고 새로운 기술들이 도입되는 가운데 태어난 기기이다. 어떻게 보면 후발주자라서 불리할 수도 있지만 아직 확고한 강자가 없는 모바일 시장에서는 윈도우폰처럼 10년의 가까운 과거를 이어가는 것을 걱정할 필요가 없이 최신 기술로 무장한 상태로 시장에 처음 발을 내디딜 수 있었다. 물론 최신 기술만으로 시장에서 성공할 수 없지만 애플 나름대로의 뛰어난 디자인과 몇 년을 앞서가는 선견지명으로 탄생한 하드웨어와 소프트웨어의 조합은 전세계의 IT업계 사람들에게 잊을 수 없는 경험을 선사하였다.

iPhone 3GS
출처: apple.com

아이폰은 그야말로 애플이 늘 그래왔듯이 철저하게 소비자 위주의 시장을 타깃으로 하고 있다. 아이폰에서 폰 기능을 뺀 것이 아이팟 터치라는 MP3와 비디오 위주의 엔터테인먼트 디바이스로 팔리고 있는 것이 윈도우폰과는 대조된다. 예를 들면 윈도우 폰은 이전에 Pocket PC Phone Edition 라고 불리웠고 즉 폰기능이 추가된 PDA개념에서 진화해 왔다.

즉, 우리는 애플이 만든 최신형 엔터테인먼트 디바이스와 10년전에 설계가 되었던 PC를 본딴 PDA를 비교하고 있다고 해도 과언이 아니다.

MS가 비지니스 영역에서 강했고 애플이 소비자 영역에서 강했던 것처럼 동일한 내용을 현재 모바일에서 볼 수가 있다. MS의 데스크톱 윈도우는 비지니스 영역에서 많이 사용되므로 항상 하위 호환성이 중요한 문제였고 그것을 확보하기 위해서 많은 노력이 들어갔다. 사실 윈도우폰이 하위 호환성이 뛰어나게 보장되는 것은 아니지만 그래도 급격한 변화는 윈도우폰에 많은 투자를 한 비지니스영역에 부정적인 결과를 낳을 수 밖에 없다. 반면 애플은 일반 소비자나 디자인 혹은 음악 등 특정 영역에서 많이 사용되었고 이들은 하위 호환성에 대해서 덜 민감한 사람들이다. 그래서 데스크톱 영역에서도 하위 호환성을 과감히 포기하면서 혁신을 이루어 나가기도 하였다.
이제는 이러한 모습이 모바일에서 재현되고 있다.

5. 설계의 차이점

일단 출발부터가 다른 디바이스이고 또한 기반이 되는 기술도 다르기 때문에 차이가 나는 것이 당연하다. 특히 터치가 지원되는 디바이스가 보편화 되고 아이폰이 기존에 사용하지 않았던 정전식 방식을 사용하면서 기본적인 손맛부터가 확인이 달라지게 되었다. 물론 HTC HD2와 같이 윈도우 모바일이면서도 정전식 터치 방식을 지원하는 단말이 최근에 나오긴 하였고 여러가지로 호평을 받고 있다. 하지만 단순히 하드웨어적으로 터치하는 방식외에도 기본적으로 스타일러스를 사용하는 방식때문에 UI구성또한 판이하게 다를 수 밖에 없다. 스타일러스를 사용하는 감압식은 보통 정확한 터치가 중요해서 UI 자체가 높은 정확도를 요구하는 마우스를 사용하는 데스크톱의 UI를 그대로 끌어와도 사용이 가능하지만 정전식은 부정확성 때문에 뭔가 크고 조작하기 쉽게 만들 수 밖에 없다. 그러한 차이점들 때문에 HTC HD2가 정전식 터치 방식을 지원한다고 하더라도 감압식 방식에서 스타일러스 사용을 가정하고 만들어진 UI위에서는 아무래도 조작하기 힘들어 질 수 밖에 없는 문제점들이 있다.

출처: pocketnow.com

또한 윈도우 모바일의 경우 초창기의 Pocket PC Phone Edition의 경우 낮은 해상도이면서 화면은 현재의 디바이스보다 훨씬 큰 LCD를 사용했다. 예를 들면 삼성의 초기 윈도우 모바일 단말인 SCH-i700의 경우 QVGA(240x320)의 해상도이지만 LCD 크기는 무려 3.5 인치를 사용했다. 지금 보면 낮은 해상도에 무지 큰 화면을 가진 디바이스 이지만 그 당시에는 이게 일반적인 모습이었다. 단순히 큰 LCD사이즈로 인해서 지금 무지 작어보이는 윈도우 모바일의 컨트롤들도 그 당시에는 매우 보기 좋도록 커다란 모습이었고 꼭 스타일러스의 정확한 조작이 아니더라도 지금보다 사용하기가 쉬웠다.

현재 많은 OEM들이 만들어 내는 윈도우 폰의 경우 작은 LCD의 높은 해상도를 지원하다보니 때로는 윈도우 UI가 매우 작게 느껴지곧 한다. 물론 이러한 문제들을 보안하기 위해서 고해상도의 경우 상대적으로 높은 DPI를 사용한다.

윈도우폰의 경우 처음설계가 현재와 다른 하드웨어 환경에서 이루어졌고 그렇기 때문에 태생적인 한계를 갖는 경우가 있다. 하지만 아이폰의 경우 하드웨어가 하나로 정해져있고 기본적인 틀은 변하지 않고 있다. 아이폰의 장점이 여러가지가 있지만 이러한 단일 폼팩터(form factor)가 커다란 장점 중의 하나이고 하드웨어가 (거의) 하나로 볼 수 있기 때문에 소프트웨어도 그것에 맞게 적절하게 만들 수 있는 장점이 있다.

5. MS의 딜레마

현재 윈도우폰 시장은 계속 축소되고 있다. 사실 Palm이 새로운 시대를 위해 미리 준비하고 소비자의 새로운 필요에 부합하는 기기를 제 때 내놓지 못한 것처럼 현재 윈도우폰도 유사한 모습을 보여주고 있다. 윈도우 모바일 5.0 이후로는 OS의 핵심적인 커널 부분도 큰 업데이트가 없었으며 비로소 6.5버전에 와서야 약간의 의미가 있는 UI적인 변화들이 들어갔다. 원래 2009년에 계획되었던 윈도우 모바일 7.0 출시는 한참 뒤로 연기가 되었고 다음달 MWC에서 발표가 있을 것이라는 이야기 외에는 별다른 소식이 없다.

MS로서는 딜레마가 될 수 밖에 없는 것이 10년이 된 Pocket PC를 조금씩 땜빵해가면서 여태까지 왔는데 이것을 획기적으로 바꾸자니 기존의 개발된 어플들의 호환성을 어느정도 보장 못하면 기존의 사용자들이 떨어져 나갈 수도 있고 또 가만히 있자니 아이폰이나 안드로이드에 대응할 수 있는 결과물을 만들기가 쉽지 않을 것이다. 어찌되었든 시대적인 상황은 뭔가 획기적인 변화를 요구하고 있고 MS는 현재 도박을 해서 좀 더 많은 고객을 끌어들일 것인지 아니면 안전하게 가면서 현재 줄고 있는 OS시장을 현상이라도 유지를 해야하는지 잘 판단해야 될 것이다. 일단 여러가지 업계의 소문은 뭔가 획기적인 변화를 준비하고 있는 쪽으로 기우는 것 같다.

6. 윈도우폰이 나아갈 방향

윈도우폰은 진퇴양난의 상황이고 이번 윈도우모바일7.0 이 얼마만큼 성공을 하느냐가 앞으로 윈도우폰의 미래를 결정하는 열쇠가 될 것이다. 만약 올해 하반기에 디바이스가 나온다면 내년 말정도면 윈도우폰의 미래가 어느정도 결정되어 있을 것 같다.

앞에서 윈도우폰과 아이폰은 출발이 다른 기기라서 서로 비교하는 것부터가 아이폰의 승리를 가져올 수 밖에 없다고 이야기를 하였다. 그렇다면 다른 대안을 없을까? 전에 MS에서 자체적으로 만든 Zune이라는 MP3 플레이어에다가 전화기능을 추가해서 새로운 기기를 출시할 것이라는 소문이 돌기도 했다. 일명 Pink Project라고 불리기도 했는데 최근에 다시 이러한 소문이 돌고 있다.  사실 아이폰과 비교하려면 Zune에 전화 기능과 어플 다운로드 기능을 추가해서 경쟁하는 것이 더 합리적인 것 처럼 보인다. 둘 다 근본이 엔터테이먼트 디바이스이기 때문이다. Zune이 그렇게 출시될 경우 윈도우폰은 완전히 죽어버릴 가능성이 많다. 또한 OEM과의 관계가 있기 때문에 절대 그렇게 할일은 없다고 생각된다. 물론 최근에 구글도 그러한 입장을 표명하다가 HTC를 통해서 구글폰을 내놓긴했다. 하지만 구글은 안드로이드를 통해서 OEM으로 부터 돈을 받는 것이 아니고 구글서비스가 많이 퍼지게 하는것이 목적이라 가능하지만 MS는 OS를 팔아서 돈을 벌기때문에 구글처럼 OEM관계를 해칠 수 있는 있을 가능한 하지 않을 것이라 생각된다.

Microsoft's Zune Phone in April?
출처: techtree.com


어찌되었든 MS에게는 참으로 힘든 시기일 것이다. 올해 윈도우 모바일 7의 발표로 다시 스마트폰 시장에서 영향력을 넓혀나갈 수 있을지 아니면 점점 시대의 요구사항에 부응하지 못해서 시장에서 살아져 갈 지 잘 지켜봐야할 한해가 될 것이다.

개인적인 생각은 MS가 그렇게 쉽게 죽지 않을 것이라 생각한다. 여기서 다루지는 않았지만 비지니스 영역의 사용자 관점에서 볼 경우 윈도우폰이 그래도 아이폰 보다 아직은 여러가지 장점들을 가지고 있다. 그렇기 때문에 죽더라도 쉽게 죽지는 않을 것이라 생각된다. ^^ 더군다나 2004년부터 쭉 윈도우 모바일 개발을 했었는데 나의 개발 경험의 한 축을 이루는 플랫폼이 사라진다면 여러가지로 많이 아쉬울 것 같다. 어떻게든 살아남아줬으면 하는게 나의 바램이다.




저작자 표시 변경 금지
신고


Windows Template Library(WTL)의 최신 버전을 받아서 AppWizard 설치 스크립트를 실행하고 Visual Studio 2008 에서 윈도우 모바일 용 WTL Mobile Application Wizard를 실행시 제대로 실행이 안되는 문제가 있었습니다.
(현재 2009/5/7 일자 릴리즈 버전(WTL8.1 9127)이 가장 최신입니니다.)

제 사용환경은 아래와 같습니다.

OS: Windows Vista Home Premium
IDE: Visual Studio 2008 Professional
Browser: Internet Explorer 8.0

일단 IE8.0을 사용하는 사람들 가운데 윈도우 모바일용 AppWizard가 제대로 실행이 안된다는 보고가 많이 있었습니다.
저도 전에 이것 저것 시도하다가 안되서 포기했다가 오랜만에 다시 WTL 설치 시도를 했습니다.
일단 공식 배포버전이 아닌 Subversion에서 직접 소스를 가져와 wizard 설치 스크립트를 실행을 해주니 그동안 안되던 AppWizard가 정상적으로 동작을 합니다.

아래 SVN 명령으로 필요한 소스 가져올 수 있습니다.
svn co https://wtl.svn.sourceforge.net/svnroot/wtl/trunk wtl


혹시라도 저처럼 고생하신 분이 계시면 참고하세요.

참, WTL 헤더파일들 include directory에 추가하는 것 있지 마시고 stdafx.h에 "#define _SECURE_ATL 1"도 추가해 줘야 문제 없이 빌드가 됩니다.
저작자 표시 변경 금지
신고


순수히 소프트웨어 개발자 입장에서 윈도우 모바일 폰 개발이 어떻게 이루어지는지 간략히 정리해 보았다.
나도 모든 과정을 자세히 아는 것이 아니라서 대략 이런 과정들을 거치겠구나 정도 수준에서 이해하면 될 것 같다.
그리고 일부 과정은 꼭 윈도우 모바일이 아닌 많은 임베디드 시스템에서 유사하게 거치는 과정으로 볼 수 있다.

1. 제품기획
기획하는 사람이 시장의 흐름과 회사의 전략에 맞게 필요한 하드웨어와 소프트웨어 스펙을 정하고 어떠한 모양의 기구를 사용할 것인지 정한다. 물론 기획하는 사람 혼자서 할 수 없는 일이고 각 분야의 전문가들의 의견을 구해서 기본적인 폰의 컨셉을 정한다.

2. 기구 및 하드웨어 설계
기본 컨셉과 사양이 정해지면 거기에 맞는 기구와 하드웨어 설계에 들어간다.
보통 기구 디자인은 미리 준비가 되어 있는 경우도 많이 있겠지만 하드웨어의 경우 슬라이드 나 바타입 등 기구 특성에 맞게 부품을 구성하고 하드웨어를 설계한다.
보통 하드웨어 하는 사람들의 특성이 가능한 싼 하드웨어를 사용하려고 하지만 얼마나 소프트웨어 개발이 쉬운지가 반드시 고려가 되어야 하는 부분이다. 좀 더 싼 하드웨어를 사용하더라도 소프트웨어 개발비용이 엄청나게 증가할 수도 있기 때문이다.

3. 소프트웨어 개발 시작
초기 하드웨어 설계가 확정되면 테스트 보드를 만들고 실제 소프트웨어를 올리는 작업이 시작된다.
소프트웨어를 올리는 초기 과정을 보드 브링업(bring-up) 이라고 한다.
테스트 보드에서 기본적인 하드웨어 초기화 하고 CPU가 부팅이 되도록 처리하는 과정이다.
실제 이러한 과정을 통해서 부팅 후 OS혹은 커널이 제대로 돌아가고 필요한 드라이버들을 올리고 하드웨어를 테스트할 수 있는 테스트 프로그램을 수행하는 절차를 거친다.
이 과정에서 하드웨어적인 오류들이 발견되고 보통 몇 번의 하드웨어 수정 과정을 거친 후 최종 하드웨어 설계가 확정되게 된다.

사실 업계에서 일을 시작하기 전에는 CPU부팅 및 다양한 하드웨어 초기화를 위해서 하드웨어 및 소프트웨어에 대해 많은 지식과 경험이 필요할 것으로 생각했으나 막상 업계에서 일을 하다가보니 실제 중요한 부분은 이미 주어져 있는 경우가 많이 있다는 사실을 알게되었다.
즉, 요즘의 CPU나 기타 하드웨어 업체는 하드웨어와 하드웨어 매뉴얼만 팔지 않는다. CPU의 경우 해당 CPU를 기반으로 만든 레퍼런스 보드가 있고 그 보드에서 기본적인 동작을 확인할 수 있는 소프트웨어가 올라간 BSP(Board Support Package)를 제공하고 있다. 그래서 그런 BSP를 기반으로 개발을 시작하는 경우가 대부분이다. 물론 실제 단말과 레퍼런스 보드와 하드웨어 구성이 다르게 때문에 BSP에서 제공된 코드를 기반으로 필요한 부분을 수정하거나 새로 만들거나 해야 하지만 달랑 CPU와 CPU매뉴얼만 가지고 시작하는 것보다는 엄청 빠른 속도로 소프트웨어 개발을 하는 것이 가능하다. 그리고 하드웨어 구성이 레퍼런스 보드와 유사하다면 많은 노력없이도 소프트웨어가 기본적으로 동작하도록 만드는 것이 가능하다. 물론 BSP 소스의 완성도는 낮은 편이라서 상용화를 위해서는 이미 돌아가는 코드이더라도 보완하고 버그를 수정하고 해야만 한다.
CPU뿐만 아니라 블루투스나 다른 칩셋 같은 것을 파는 하드웨어 업체들도 직접 드라이버를 개발해서 제공해주는 경우가 많고 이미 이제는 그렇게 하지 않으면 하드웨어를 팔 수 없는 환경이 되어버렸다.

image of reference board
[source : windowsfordevices.com]

4. 윈도우 모바일 개발 과정
윈도우 모바일 5.0 버전부터는 윈도우CE 5.0 커널을 기반으로 만들어 지고 있다. 윈도우 모바일의 경우 윈도우CE의 커널을 거의 그대로 가져와서 약간 다른 쉡(shell)을 입히고 만들어 졌다. 그래서 실제 내부적으로는 윈도우 모바일과 윈도우CE 개발 과정에서 유사한 점이 상당히 많다.
윈도우CE의 경우 플랫폼 빌더(Platform Builder)라는 툴을 사용해서 OS를 만든다. 윈도우 모바일의 경우는 Adaption Kit 혹은 Adaptation Kit Update라는 이름의 툴로 OS 개발을 한다. AK혹은 AKU는 플랫폼 빌더의 커맨드 라인 버전이라고 보면 된다. AKU관련해서는 제조사에서 NDA(Non-Disclosure Agreement) 를 맺기 때문에 공개적인 곳에서 AKU관련 질문이나 이야기를 할 수 없게되어 있다. 하지만 개발 과정이 윈도우 CE와 공통된 점이 많기 때문에 특정 문제에 대해서는 윈도우CE 관련 된 자료를 통해서 문제점들을 해결해 나갈 수 있다.

OEM에서 소프트웨어 개발에 필요한 부분은 크게 부트로더 및 OAL(OEM Adaptation Layer) 개발, 드라이버 개발, In-ROM 소프트웨어 개발 등으로 나눌 수 있다.
OAL은 MS가 만든 OS와 그 밑에 하드웨어 사이를 연결해 주는 포팅레이어로 OEM에서 특정 하드웨어 위에서 MS OS가 돌아갈 수 있도록 해준다.
OS가 정상적으로 부팅이 되면 다양한 하드웨어나 OS와 인터페이싱을 제대로 할 수 있도록 드라이버들을 작성하는 일이 필요하다. 그리고 롬에 탑재될 다양한 소프트웨어 개발이 필요하다.


[source: msdn.microsoft.com - Windows CE Architecture ]

그리고 윈도우모바일 폰에서 가장 중요한 부분 중에 하나는 RIL(Radio Interface Layer)의 개발이다. 사실 RIL관련 부분도 공개적으로 논의할 수 없는 내용이라서 자세히 설명할 수는 없지만 인터넷으로 검색해 보면 약간의 자료를 찾을 수 있다. 보통 윈도우 모바일 같은 스마트폰은 2개의 프로세서(CPU)를 사용한다. PDA는 보통 Application Processor라고 불리는 CPU에서 수행이 되고 실제 통신 기능은 일반폰(Feature phone)에서 사용하는 퀄컴이나 기타 업체의 베이스밴드 칩을 사용한다. 보통 윈도우 모바일이 수행하는 AP와 통신을 담당하는 MP와 프로세서간의 통신이 필요하며 이러한 세부적인 H/W, S/W의 구현은 OEM마다 다르고 개발과정에서 가장 중요한 부분 중에 한 가지라고 볼 수 있다. RIL의 경우는 윈도우 모바일이 돌아가는 AP에서 MP와 통신하기 위한 기능을 제공하는 레이어이고 OEM에서 만들도록 되어 있다. 사실 두개의 CPU간의 통신 기능이 들어가야 하므로 하나의 CPU만을 사용할 때 비해서 통신관련 기능 수행에 약간의 딜레이가 발생하거나 통신과정 중 명령이 제대로 전달이 안되 오류가 발생할 가능성이 생기게 된다. 아마도 이런 이유 때문에 일반폰 대비 스마트폰이 통신 기능이 떨어진다는 사용자들의 이야기가 나오는 것이 아닌가 싶다.

5. 다양한 인증과정
일단 하드웨어 및 소프트웨어가 어느정도 수준에 오르게 되면 H/W 및 S/W를 다양한 인증기관에 시험을 의뢰해야 하고 통과 절차를 거쳐야 단말을 실제 출시할 수 있게된다. 여러 가지 인증 과정 중 가장 중요한 것이 바로 통신사업자 인증과정이다. 이것을 흔희 망연동 테스트라고도 부르며 (줄여서 망연동) 실제 사업자 망(국내는 SKT, KT혹은 LGT)에서 사업자가 단말을 테스트하고 문제점이 없는지 검증하는 과정이다. 물론 단순히 통신 기능뿐만 아니라 사업자에서 정한 다양한 UI스펙에도 부합하는지 확인하고 전반적인 폰의 사용성 또한 체크를 하게 된다. 이러한 과정들은 아무리 빨라도 한 두달 이상 진행하는게 보통이다. 물론 이러한 과정을 진행하기 전에 OEM에서 자체적으로 테스트를 진행하고 어느정도 합격하는데 무리가 없다는 선에서 인증과정에 들어간다. 일부 해외 사업자의 경우 인증과정에서 fail처리가 되면 다시 인증의뢰를 하는데 시간이 오래걸리므로 사전 검증을 통해 오류를 줄이는 것이 매우 중요할 수 있다.

6. 양산과 마케팅
일단 다양한 인증기관과 최종적으로 사업자의 승인이 나게되면 본격적으로 단말의 대량 양산을 시작하게 된다. 그와 동시에 혹은 그 이전에 다양한 마케팅 전략을 통해서 출시될 폰에 대해 홍보를 시작하고 필요한 유통경로를 통해서 최종적으로 소비자에 의해서 구매가 된다.

7. 시장문제 대응
폰이 출시되었다고 개발이 다 끝나는 것이 아니다. 일단 단말이 출시되고 어느정도 시간이 지나기까지 발견이 되지 못했거나 중요한 문제가 아니어서 수정을 미뤘던 버그들에 대한 보고가 들어오게 된다. 간혹 매우 치명적인 버그가 발견되기도 하며 이러한 것들에 대해 수정을 해서 사용자들이 업데이트 받을 수 있도록 새로운 바이너리를 만들어서 배포한다.

이상으로 간략히 윈도우 모바일을 만드는 과정에 관해서 살펴보았다. 간략히 설명하였지만 기획부터 개발 및 테스트, 양산 및 최종 마케팅까지 보통 폰하나를 만들기 위해 수백명의 사람들 개발과정에 참여를 하게되는 결코 쉽지않은 과정이다. 혹시라도 관심있는 분에게 조금이라도 도움이 되었길 바라며 글을 마친다.

[업데이트] 영문 위키에 AKU관련되서 약간의 정보가 있어서 링크겁니다.

그리고 RIL관련 기본 정보도 MSDN에 있네요 T.T
원래 비공개된 내용으로 알았는데 생각해보니 Windows CE 6.0에도 이제 관련 기능이 포함되서 기본적인 내용은 더 이상 비공개할 의미가 없는 것 같네요. 
MSDN: http://msdn.microsoft.com/en-us/library/ms890075.aspx
신고


작년 8월에 미라지(SCH-M480)로 핸드폰을 바꾸면서 4개월간 싱크메일 서비스에 의무 가입이라 사용을 했었다. 개인적으로는 그다지 이점이 없어서 4개월 사용후 해지하고 데이퍼 퍼팩트 정액제로 갈아탔다.
내가 개인적으로 느낀 사용소감 몇가지만 정리해 보았다.

1. 실시간 이메일 체크
일단 실시간으로 이메일을 확인할 만큼 긴급한 일도 없을 뿐더러 별로 그럴 만한 사람이 얼마나 될지도 좀 의문이 든다. 여러가지로 생산성 향상을 위한 글을 읽어보면 이메일을 자주 체크하는 것이 생산성에는 마이너스라고 많이 언급되어 있다. 그리고 긴급한 일이 있으면 전화를 해야지 이메일로만 연락하는 사람은 드물 듯.

2. 회사 메일 확인 불가
일단 회사에서 Exchange Server가 구축이 되어 있지 않으면 syncmail서버로 이메일을 포워딩 해야 한다. 개인 메일이야 포워딩해서 받아도 큰 문제는 없지만 기밀사항이 들어간 회사 메일을 외부 서버로 포워딩 한다는 것은 있을 수가 없다. 우리 회사는 Exchange Server를 사용하지 않기때문에 싱크메일로 회사 메일을 확인하는 것은 불가능한 일이었다. 더욱더 싱크메일이 가치가 사라지는 이유 중 하나이다.

3. 정액제로 이메일 첨부 및 전송 무제한으로 사용 가능
사실 이메일에 첨부파일이 포함되어 오는 것 굳이 핸드폰으로 많이 확인할 필요 없다. 4개월동안 그냥 궁금해서 엑셀 파일 한 번 폰으로 받아서 본 것 밖에 없다.


데이터 퍼팩트 정액제 전환 이유

1. 일단 이메일은 몇시간에 한 번 정도 체크해도 되고 긴급한 일이 있을경우 수동으로 이메일 체크를 사용해도 충분하다.
2. 비슷한 가격으로 이메일 외의 다른 데이터 서비스도 사용이 가능하므로
내가 주로 사용하는 서비스는 버스도착시간 확인이나 미투데이지 모바일 정도 아주 가끔 웹서핑을 하는데 실제 거의 안한다. 물론 정액제로 최소한 수백메가 이상 사용이가능하면 웹서핑은 좀 더 자주 할 수도 있겠지만.

데이터 퍼팩트 정액제로 실제 한달에 사용할 수 있는 전송량이 대략 30~40메가 선이지만 이메일 자주 쓸일 없는 사람들에게는 적당하고 간단한 데이터 서비스도 사용가능하니 개인적으로는 싱크메일보다는 훨씬 나은선택이다.

SKT가 데이터 정액제가 많이 부족한데 좀 더 저렴한 가격으로 좀 안심하고 마음껏 쓸 수 있는 요즘제가 나왔으면 좋겠다.

참고로 아래 링크에 이통사 3사 데이터 요금제 관련해서 아주 잘 정리된 자료가 있으니 참고하시기 바란다.
http://www.mymits.net/zboard/zboard.php?id=lecture&no=2396


신고


DrawText 주의 사항

2008.03.11 00:14
DrawText()는 Win32로 UI 프로그래밍할 때 많이 사용하는 함수 중 하나이다.
역시 초보가 저지르기 쉬운 실수 인데 최근에 실수한 예를 보게 되어서 기억을 되살리는 의미로 여기에 간략히 올려본다.

위 함수를 사용하는 경우 text를 외부에서 받을 때 특히 주의해야한다.
출력 문자열에 '&'가 들어가면 다음 글자 밑에 밑줄이 그어진다.

아래는 MSDN 도움말에 있는 예제이다.
input string:   "A&bc&&d"
normal: "Abc&d"
DT_NOPREFIX: "A&bc&&d"

기본적으로 '&'문자는 특수한 케이스로 처리를 한다.
개인적으로 디폴트로 off가 되어야 맞을 것 같지만 함수 사용시 DT_NOPREFIX를 사용하지 않으면 때로 예상하지 못했던 결과가 나오므로 주의가 필요하다.
사실 '&'문자를 많이 사용하지 않으므로 DT_NOPREFIX을 사용하지 않았다가 뒤늦게 문제를 발견할 가능성이 높다.

참고로 Windows CE/Mobile 이 아닌 Desktop API의 경우 DT_HIDEPREFIX, DT_PREFIXONLY 등의 추가 옵션도 제공한다.

아래는 MSDN 도움말의 링크이다.
http://msdn2.microsoft.com/en-us/library/ms533909(VS.85).aspx



신고


윈도우 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/09   »
          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,633,059 HIT
TODAY 14 HIT
YESTERDAY 13 HIT

티스토리 툴바