Whidbey Native Code Development for Devices

Posted September 24, 2004

Chat Date: September 8, 2004

Please note: Portions of this transcript have been edited for clarity

Introduction

Moderator: mikefos (Microsoft)
Welcome to today's Chat. Our topic covers Whidbey Native Code Development for Devices. Questions, comments, and suggestions are welcome.

Moderator: mikefos (Microsoft)
Hey folks, we've had a bit of a scheduling mishap this morning. You're welcome to start posting questions regarding Whidbey Native Code Development for Devices

Moderator: mikefos (Microsoft)
We'll introduce our hosts as they come online

Moderator: mikefos (Microsoft)
Thanks folks!

Host: jabraham (Microsoft)
Hi, I'm Jeff Abraham, and I'm a developer on the Visual C++ for Devices team. I work on the IDE, primarily on the project system (compiler tool GUI interfaces, deployment, etc.) and the wizards.

Host: NishanJ (Microsoft)
Howdy, my name's Nishan Jebanasam, I'm a Program Manager in the Visual C++ for Devices team. I'm supposed to be responsible for designing and spec'ing our native development features, including IDE integration and runtimes. In reality I fetch coffee for the developers

Host: pabloosi (Microsoft)
I would like to introduce myself. My name is Pablo Osinaga and I am a Software Design Engineer in Test working on the C++ ATL library for Windows CE that we are delivering in Whidbey

Host: MarioCh (Microsoft)
HI, I'm Mario Chenier, I'm a developer lead in Visual Studio for Devices team. I work on the Native and Connectivity pieces of VS2005

Host: ritchieh (Microsoft)
Hi everybody, I'm Ritchie Hughes and also an SDE/T. I work with Pablo on the libraries test team, specifically on MFC.

Host: Josh_Heitzman (Microsoft)
I'm Josh Heitzman, and I am also developer on the Visual C++ for Devices team. I own ATL and some other random things.

Host: dkochhar (Microsoft)
Hi, I am Dushiant Kochhar. I am Software Design Eng in Test. I am responsible for native IDE features and Cab projects

Host: TaoMa (Microsoft)
This is Tao Ma, and I am a developer on the Visual C++ for Devices team. I own MFC, Resource Editor and AppWizards (co-owner with Jeff Abraham)

Start of Chat

Host: NishanJ (Microsoft)
Q: VS was the tool for CE 1-2, then EVx for 3-4, now it sounds like were heading back to VS. Is VS going to be the tool moving forward?
A: Yes. Whidbey will support Windows Mobile 2003 and onwards, and Windows CE 5.0 and onwards. We're investing in VS moving forward

Host: NishanJ (Microsoft)
Q: So to develop for devices we will have to purchase VS, and the free EVC will no longer be supported?
A: Yes, VS will have to be purchased. eVC will continue to be available for targeting up to Windows Mobile 2003 and Windows CE 5.0, but will not undergo any further feature enhancements

Moderator: mikefos (Microsoft)
Q: Is there any way college students can get the beta without having to join MSDN, I did have MSDN two years ago but not currently.
A: Hey eila, we'll need to follow up with you offline on this one. I'll whisper you my contact info.

Host: jabraham (Microsoft)
Q: Will the device installation support be better than what is currently implemented. The BuildCABs feature, it would be nice to simplify that in the IDE.
A: Yes, we're working on improving the device installation support. The simple "BuildCabs" won't be around in the next release. We're creating device setup projects (similar to what the desktop has) that will allow you to build cabs with custom actions, custom registry keys, etc.

Host: NishanJ (Microsoft)
Q: Will there be a low end "express" type of tool for developing device code?
A: Unfortunately there are no plans at this point to have a native device development "express" sku. We're sensitive to the price jump from free eVC to VS, and will continue to explore ways to get native device development out there as cheaply as possible. Unfortunately, nothing is concrete at this moment with respect to sku pricing

Host: jabraham (Microsoft)
Q: The new device installation project sounds really cool. But will it require .NET on the desktop?
A: The new setup features will require .NET on the desktop because VS 2005 will require .NET on the desktop. As far as I know (I don't directly own the feature) we will not require .NET CF on the device in order to use the cabs.

Host: NishanJ (Microsoft)
Q: Is native device driver development supported in current 2005 b1 ?
A: No. Whidbey will not have kernel debugging. The recommended tool for device driver development will still be Platform Builder

Host: NishanJ (Microsoft)
Q: Will Whidbey support building Windows driver with DDK?
A: Checking with some folk right now. If I have an answer before the chat ends I'll post it up Moso. Otherwise this may be a good question for the (desktop) VC newsgroup

Host: Josh_Heitzman (Microsoft)
Q: What transports will be supported for debugging?
A: Whidbey will support debugging over TCP/IP and KITL, although the latter will only be supported if Platform Builder 5.0 is installed.

Host: NishanJ (Microsoft)
Q: Will developing in VS target all the PocketPC, smartphone, and such devices, such as legacy PocketPC 2000 and soon to be legacy PPC 2002?
A: No. Whidbey will only support Pocket PC 2003 onwards, Smartphone 2003 onwards and Windows CE 5.0 onwards. For earlier versions of PPC/Smartphone, eVC will still be the tool

Host: Amit (Microsoft)
Q: Any weblog about Whidbey dev for devices?
A: https://blogs.msdn.com/vsdteam/ is our team blog and lot us also contribute on individual blogs. For example:

https://blogs.msdn.com/Josh_Heitzman/

https://blogs.msdn.com/JeffAbraham

Host: jabraham (Microsoft)
Q: Will the native debug support be as good as it is for desktop applications (c++)?
A: We won't have all of the features of the desktop native debugger, but we will have most of them. You will be able to attach to process, psuedo-detach (small performance penalty because underlying OS support). The biggest missing feature is interop debugging (between .NET and native code). We aren't supporting data breakpoints or edit and continue. We will be supporting data visualization (e.g. pretty formatting for STL and ATL debugging, and Windows messaging). We won't support causality (stepping from one thread into another across an apartment thread call as in DCOM or COM).

Host: NishanJ (Microsoft)
Q: Will native device development be a full equal to desktop and .NET development in the upcoming VS
A: Our goal is to get as close to the desktop C++ development experience as possible. For the WHidbey release, there will be some gaps (e.g. no Managed C++). The experience will be different to .NET (e.g. no Designers)

Host: Josh_Heitzman (Microsoft)
Q: A little off topic and maybe cant be answered, but is Microsoft going to keep with the PocketPC or let it die. I've heard bad articles saying PDAs are on their way out
A: Microsoft is still fully committed to developing the Pocket PC platform.

Host: NishanJ (Microsoft)
Q: What are the features NOT supported by whidbey when developing on Devices, such as edit &continue? hardware breakpoint (address/data)?
A: Broad question :) What specifically are you interested in? Edit&Continue will not be supported. For Hardware breakpoints, we will support address breakpoints but not data breakpoints

Host: NishanJ (Microsoft)
Q: The Dialog Editor in EVC was not very good. It seemed like the placement was all off. Is this fixed in Whidbey to be a WYSIWYG?
A: Unfortunately, the Whidbey Dialog Editor will not be WYSIWYG. We do filter device controls, and have added CAPEdit and SIP, but for WYSIWYG you'd be better off with the Managed Designers :)

Host: Josh_Heitzman (Microsoft)
Q: Has anybody ever thought about merging WinDbg into Whidbey for Windows driver development?
A: It's possible someone at Microsoft has thought about this, but the folks here don't know, as our focus is on Windows CE development, and that is beyond our scope of knowledge.

Host: NishanJ (Microsoft)
Q: I heard Whidbey will allow multi-platform support in the same project, including desktop and device platforms. Is this true?
A: Great question, Nishan. Yes, Whidbey will allow you to add platforms to a project after creating it. Device wizards will generate device code only though, so if you add Win32 as a platform after creating a project you need to add the desktop code yourself

Host: TaoMa (Microsoft)
Q: Will MFC be continued to be updated for devices? Specifically, will Web Services calls be implemented for devices as it is in c++ 2003 (not managed)?
A: Yes MFC will be there but will be different from eVC MFC. For Web Services I don't think we support this in MFC, but ATL will. And in ATL, it will be Web Services consumption.

Host: jabraham (Microsoft)
Q: In eVC4 , there is no way to bind an SDK (PocketPC 2003, 8402_USA, STANDARDSDK_420) with a configuration. Is it addressed in Whidbey?
A: In Whidbey, we have moved from having projects targeting instruction sets to having projects platforms, which we define as the combination of an SDK and an instruction set. This means that you can have different sets of defines for Pocket PC 2003 (ARMV4) and SmartPhone 2003 (ARMV4). Configurations are strongly tied to SDKs.

Host: NishanJ (Microsoft)
Q: Will we be able to make ActiveSync Providers??
A: There won't be any explicit support for this, but you should be able to do it. I believe there are articles on MSDN on how to create AS providers. I don't have the links on me right now, but if you search for the appropriate keywords you should be able to find them

Host: TaoMa (Microsoft)
Q: how will MFC for devices in Whidbey be different than eVC MFC?
A: We have same set of binary bits (MFC DLL) targeting different platforms (Windows CE, Pocket PC, and Smartphone), we cut down some classes scarcely used (like CArchieve), we pretty much sync up with current desktop MFC code base which is highly security checked. But we still keep the eVC CE specific classes (except CCeSocket) will slight changes

Host: NishanJ (Microsoft)
Q: Will there be any support to "Test" IrDA without having to own two devices??
A: There is no explicit support for this. There may be some clever ways to do this (e.g loop a serial cable back to the device, or map the Emulator COM port to a serial port) but I'm not sure if this will help. If you discover a way, post to the newsgroup

Host: NishanJ (Microsoft)
Also, you may want to check out the Pocket PC PowerToys to see if anything there may help

Host: Josh_Heitzman (Microsoft)
Q: Will there be any new frameworks for developing GUI apps on the PocketPC besides ATL and MFC? And will ATL be enhanced for GUI apps?
A: In the box in Whidbey, there is nothing new, and we have no plans to add addditional GUI development support to ATL; however, WTL 7.1 (Windows Template Library) was ported to CE. WTL is now an open source project, which can be found at https://sourceforge.net/projects/wtl/, and last I talked to the Microsoft author of it, there were plans to further enhance the CE support in WTL and include Whidbey compatible wizards (the wizards in 7.1 were compatible with eVC4.0).

Moderator: mikefos (Microsoft)
We appreciate your questions and look forward to seeing you in the newsgroups or other future chats

Moderator: mikefos (Microsoft)
Thanks to our hosts today as well!

Moderator: mikefos (Microsoft)
You guys are great!

Top of page