New Powertoy Released

Interesting Finds: June 30, 2006 AM

Jason Haley — Fri, 30 Jun 2006 18:04:08 GMT

re: New Powertoy Released

patbateman — Mon, 03 Jul 2006 16:44:08 GMT

It looks nice and its a great idea, but why the Hell only C# on Desktop side?

re: New Powertoy Released

Oskar Berreteaga — Mon, 03 Jul 2006 16:59:08 GMT

I've been unable to have a look at it because I don't have Smart Devices for VS 2005 installed. Anyway, I just wanted to know more about the framework features but without installing it, there's no way to view the readme :-(

My specific questions are:
- Does the framework support continuous device info polling or does it have to be done from the client application side?
- Which components must the device's OS include in order to run the framework?
- I guess write operations on data are available as well as read ones, right?

Oskar

re: New Powertoy Released

windowsmobile — Thu, 06 Jul 2006 20:32:09 GMT

Hello folks!
My name is Ken Sadahiro and I'm the program mananger who helped Dave ship this powertoy.
Since Dave is unavailable right now, I'm going to step in and answer the questions posted so fare to the best of my knowlege.

patbateman said:

> It looks nice and its a great idea, but why the Hell only C# on Desktop side?

I think Dave is referring to the fact that all of the sample code for the desktop side are written in C#. We have an intern writing C++ code for the desktop side.

Just curious- What is your preferred langauge?

Oskar Berreteaga said:

> Does the framework support continuous device info polling or does it have to be done from the client application side?

There's a synchronous mode (command issued from desktop, device responds) and an asynchronous mode (command issued from desktop starts an asynchronous pushing of data fromd device). Most samples use synchronous mode (COMMANDHANDLER_SYNC), but the one sample plugin that shows how to use asynchronous mode (COMMANDHANDLER_ASYNC) is the ClipboardSync sample.

> Which components must the device's OS include in order to run the framework?

The Remote Tools Framework (more precisely CoreCon) will send the necessary DLLs (rtfhlp10.dll for core RTFx support), and Microsoft.RemoteToolSdk.DeviceComponents.dll (for managed code support) down to the device so that the RTFx plugin will run. rtfhlp10.dll requires CoreCon, but that also gets setup appropriately on the device by CoreCon itself.
Depending on which APIs you call from your device side components, there may be other requirements.

> I guess write operations on data are available as well as read ones, right?

Do you mean the ability to write any data on the device side? You have access to WinCE API on the device side, so you have a variety of options...

Hope this helps!

re: New Powertoy Released

windowsmobile — Thu, 06 Jul 2006 20:33:19 GMT

re: New Powertoy Released

ken sadahiro — Wed, 12 Jul 2006 00:48:45 GMT

Let me clarify this:

> We have an intern writing C++ code for the desktop side.

You can write in native code (C++) or managed code (C++/managed, C#, or VB). One incentive for writing managed code on the desktop side is that you can extend the view that is provided in the remote tools shell (installed with the framework).

re: New Powertoy Released

ce_base — Wed, 12 Jul 2006 01:47:09 GMT

Comment from Dave Edson.

I would like to explain a bit the different components of RTFx.

Desktop Side
-----------------
* RemoteToolServer.dll - a Native COM component that talks to CoreCon. CoreCon is the transport layer that ships with VS2005. RemoteToolServer.dll brings up the "Select Device" dialog, and opens a communication channel that's accessed by the "Command Transport" object in the .NET code.
* Microsoft.RemoteToolSdk.dll - A .NET Library that talks to RemoteToolServer.dll. This library contains the code to provide a managed communication channel (the CommandTransport), and also the shell view that the plugins use. The entire plug-in architecture, .cetool file format decoding, and doc/view stuff is contained in this .DLL
* RemoteToolsShell.exe - .NET application that creates a top-level form window, and then gets the "guts" from the Microsoft.RemoteToolSdk.dll to display the shell.

Device Side
--------------
* RTFHLP10.DLL - A native DLL that talks to the device-side of CoreCon. A communication channel is established with this DLL, and the "CCommandTransport" is available as an object for native device-side apps to use.
* Microsoft.RemoteToolSdk.DeviceComonponents.dll - A .NETCF 1.0 library that wraps RTFHLP10.DLL with a CommandTransport object that has the same interface as the desktop side. Managed device-side applications consume this library.

So, if you write a plugin that's all managed (such as SimplePluginManaged from the samples), your project output generates two binaries that are packed into the .cetool file. The desktopside binary is a .NET class library that is consumed by the Microsoft.RemoteToolSdk.dll library via a LoadAssembly call. The desktopside binary uses all sorts of objects from the .NET class libary, and the plugin gets all the connectvity for free. The device side binary consumes the Microsoft.RemoteToolSdk.DeviceComponents.Dll library, which then p/invokes the RTFHLP10.DLL.

If you write the desktop side in managed code, the above paragraph is for you. If you want to write your desktop code in native, then you have to do a whole lot more work. Since the plugin's desktop code uses the Microsoft.RemoteToolsSdk namespace, there are lots and lots of dependancies between your desktop code and the library. If you go native, you lose all that. Which means that a native desktop application would need to talk directly to the RemoteToolServer COM object. You still get a command transport-like object, with command packet-like things, and you still get an easy way to bring up the "Select Device" dialog box and make the connection. You still get to easily deploy your bits down to the device, start that app and establish the CoreCon connection. What you DON'T get is a shell to present the information, docs objects, view objects or any data traffic rules. And, you will be writing COM code (fun fun fun). Also, RTFx's native library generates a critical data file automatically for CoreCon that instructs CoreCon how to deploy and execute the device-side binaries. If you write your desktop app in native, you will need to write your own UI, own main window, and you will need to generate your own CoreCon data file. You will need to "install" your binaries for each platform before you can run your desktop app. RTFx's native code does all this for you.

We are working on making a native sample program that will show how this is all done. Keep in mind that there are lots of ways to shoot yourself in the foot. The managed part of the framework takes care of a lot of micro-details that keeps CoreCon stable. It is easy to confuse CoreCon and make for some very pizza-laden long evenings scratching your head.

Hopefully this makes some sense. Go ahead and ask away if you have more questions.

Dave Edson
RTFx Wrangler

re: New Powertoy Released

Roger — Wed, 19 Jul 2006 20:38:44 GMT

Did anyone tried to build the sample plugins? Can't build the DeivceSideARMV4I using VS2005 with Windows Mobile PPC SDK 5.0. The include path and the additonal library are all screw-up.

re: New Powertoy Released

Dave Edson — Wed, 19 Jul 2006 23:05:33 GMT

Roger,

Can you send me the error output from the failed build?

Dave Edson

Here's my bot-confuser email address: davee at microsoft.com

re: New Powertoy Released

ken sadahiro — Thu, 20 Jul 2006 21:57:28 GMT

I am assuming the resolution to Roger's issue is noted here -- http://blogs.msdn.com/ce_base/archive/2006/07/20/672810.aspx

Quick survey for folks who are trying out this power toy:
* What is your programming language of choice in VS2005?
A. C++
B. C#
C. VB
* What target OS/SDK version are you using?
A. Pocket PC/Smartphone 2003 or Second Edition
B. Windows Mobile 5.0 for PocketPC/Smartphone
C. Windows CE 5.0

re: New Powertoy Released

Avi Kcholi — Mon, 31 Jul 2006 13:09:43 GMT

I couldn’t care less if the desktop is C++ or C# however what does bother me are two things.
1. The target device is either ARMV4 or ARMV4I
2. I have both PB 5 and VS 2005 installed on my work machine and I installed the RTFx of June 29, and trying to build it I discover that either I’m stupid or I’m missing something - where do I get for instance cecorecon.lib I definitely don’t have this directory on my computer: C:\CETools\tools\corecon\src\remtools\common\devicelib\armV4i\debug\cecorecon.lib
searching my hard disk I couldn't find it at all.
So what is it that I have to install in order to have CETools\tools\corecon\src\remtools\common\devicelib\

re: New Powertoy Released

Bob Hanson — Thu, 24 Aug 2006 22:10:23 GMT

As I checked the supported systems list, it looks like WinCE 5.0 devices are not supported.

Can you please verify if this is true?

Thanks :)

Bob Hanson

re: New Powertoy Released

ken sadahiro — Sat, 26 Aug 2006 09:16:40 GMT

Windows CE 5.0 is supported, however, only for ARM processors.
Is there a specific processor for which you need support? Please give us your vote.

re: New Powertoy Released

bob53050 — Sat, 26 Aug 2006 16:29:13 GMT

We are using x86 and would really hope to see this supported :)

Thanks for the reply :)

Bob Hanson