New Powertoy Released


Posted by: Dave Edson


Hello Everyone…


The Microsoft Smart Devices Remote Tools Framework Power Toy 1.0 has been released to the web. Let’s call it RTFx for short.


It’s a framework to make it easier to write remote tools (like Remote Heapwalker, etc). All of the connectivity issues are done for you, and a unified shell is provided. Your code consists of data objects, view objects, and data collectors. RTFx does the rest.


You write the desktop-side components in C#, the device-side components are written in either C++ or C#.


Included with this powertoy is a new version of the Remote System Information, called RTFx SysInfo (attachment is a screen shot). Lots of samples are provided as well.


This blog is where we will support RTFx initially. If traffic grows, we can create a category just for RTFx.


You can download it here:


http://www.microsoft.com/downloads/details.aspx?FamilyID=35e9ef0f-833f-4987-9d1f-157a0a6a76e4&displaylang=en


I am very anxious to hear your feedback on this powertoy.


Cheers!
Dave Edson
RTFx Dev

rtfxsi.PNG

Comments (14)

  1. patbateman says:

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

  2. Oskar Berreteaga says:

    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

  3. windowsmobile says:

    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!

  4. windowsmobile says:

    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!

  5. ken sadahiro says:

    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).

  6. ce_base says:

    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

  7. Roger says:

    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.

  8. Dave Edson says:

    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

  9. ken sadahiro says:

    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

  10. Avi Kcholi says:

    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:CEToolstoolscoreconsrcremtoolscommondevicelibarmV4idebugcecorecon.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 CEToolstoolscoreconsrcremtoolscommondevicelib

  11. Bob Hanson says:

    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

  12. ken sadahiro says:

    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.

  13. bob53050 says:

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

    Thanks for the reply :)

    Bob Hanson