I have a win32 GUI (MFC) application which I need to port to a WIN CE environment. I keep encountering undefined identifiers. What is the best way to deal with this- is there some site where i can get a mapping of some kind between win32 supported features and corresponding wince features (even if they are not supported, the information that they are not is valuable)
I think this is what you are looking for:
MFC Reference for Devices
Related
This article (from the Windows engineering team) says:
WOA [Windows On ARM] will not support any type of virtualization or emulation approach,
and will not enable existing x86/64 applications to be ported or run.
Does that mean I won't even be able to recompile an x86/64 application from source for ARM?
If yes, what exactly prevents me from doing that? My understanding is that the Win32 API is present on Windows 8 ARM.
If no, what do they mean by not being able to port x86/64 applications to ARM?
From the Windows article you link to, the second quoted paragraph is the killer. Porting existing apps is definitely NOT supported.
Developers wishing to target WOA do so by writing applications for the WinRT (Windows APIs for building Metro style apps) using the new Visual Studio 11 tools in a variety of languages, including C#/VB/XAML and Jscript/ HTML5. Native code targeting WinRT is also supported using C and C++, which can be targeted across architectures and distributed through the Windows Store. WOA does not support running, emulating, or porting existing x86/64 desktop apps. Code that uses only system or OS services from WinRT can be used within an app and distributed through the Windows Store for both WOA and x86/64. Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.
If we enabled the broad porting of existing code we would fail to deliver on our commitment to longer battery life, predictable performance, and especially a reliable experience over time. The conventions used by today’s Windows apps do not necessarily provide this, whether it is background processes, polling loops, timers, system hooks, startup programs, registry changes, kernel mode code, admin rights, unsigned drivers, add-ins, or a host of other common techniques. By avoiding these constructs, WOA can deliver on a new level of customer satisfaction: your WOA PC will continue to perform well over time as apps are isolated from the system and each other, and you will remain in control of what additional software is running on your behalf, all while letting the capabilities of diverse hardware shine through.
Only a subset of Win32 is supported on Win8 for ARM:
http://msdn.microsoft.com/en-us/library/windows/apps/br205757.aspx
If you try to build an application that uses a Win32 API that's not supported, it won't build because the API won't be in the library. If you try to create your own library to support the APIs, the application still won't be usable because the only way to deploy apps to customers will be through the MS app store, which will no doubt check for API conformance.
From The "Building Windows for the ARM processor architecture" article:
Consumers obtain all software, including device drivers, through the Windows Store and Microsoft Update or Windows Update.
It might be possible to do so on your development machine (but maybe not - I'm really not sure if such a 'hack' will be possible, supported or not), but you certainly won't be able to deploy it in any kind of widespread fashion.
In short, any existing Win32 application will likely need significant work to be ported to Win8 for ARM. It won't be a matter of recompile and fix any errors that pop out to get the application to run on ARM.
They do provide this caveat a little further in your cited article:
Additionally, developers with existing code, whether in C, C++, C#, Visual Basic, or JavaScript, are free to incorporate that code into their apps, so long as it targets the WinRT API set for Windows services.
They've got version of Office and IE available; I'm positive those weren't ground-up reimplementations.
At Microsoft BUILD conference, I saw this figure.
I'm wondering whether the position of Win32 is correct or not. What is the role and position of Win32 API in modern Windows architecture?
My concept of Win32 API is a sort of assembly of all modern Windows architecture. Win32 API (or DDK) bridges "Windows Kernel Services" to the other technologies.
I thought that Internet Explorer/.NET/Silverlight are all build upon Win32 API. Even if a fancy new Metro Apps, I conjecture that Win32 is at the bottom place. However, this figure defies my knowledge.
As you can see, IE/.NET/SL/Metro are sitting horizontally with Win32.
Questions:
Does this figure necessarily mean that Win32 is not the framework of all other modern technologies?
What is "Windows Kernel Services"? How programmers can access them? Isn't it through Win32 API and DDK?
The diagram is wrong.
While there were originally other subsystems (e.g. POSIX) which accessed ntdll.dll (the "Kernel Services" gateway) without going through Win32 (kernel32.dll, user32.dll) these are all now defunct.
All modern application frameworks for Windows are built on Win32. The other subsytems are no longer supported. In some cases (drivers, and boot-time system utilities such as chkdsk) code is written directly against the native API, but these scenarios are very rare.
I'm not very familiar with WinRT, but I think Win32 fits underneath it as well (or it may use a combination of Win32 and direct ntdll.dll services).
According to Sasha Goldshtein,
Next, a C++ Metro application will still load Win32 DLLs such as kernel32 and ntdll. Moreover, the WinRT APIs call into the Win32 DLLs – so they are not a replacement but rather a wrapper, an API flavor, on top of Win32. (Historical note: Windows used to have a feature called “environment subsystems”, which can be roughly described as API flavors. WinRT is not an environment subsystem – it is a library on top of the Win32 environment subsystem.)
The diagram is (presumably) correct, but only for Windows 8. Windows 8 has a significantly different architecture from previous versions.
I believe applications can make requests directly to the kernel, but the interface is mostly undocumented. Device drivers use the kernel directly.
Microsoft recently released tools and documentation for its new Phone 7 platform, which to the dismay of those who have a big C++ codebase (like me) doesn't support native development anymore. Although I've found speculation about this decision being reversed, I doubt it. So I was thinking how viable would be to make this codebase available to Phone 7 by adapting it to compile under C++/CLI. Of course the user interface parts couldn't be ported, but I'm not sure about the rest. Anyone had a similar experience? I'm not talking about code that does heavy low-level stuff - but there's a quite frequent use of templates and smart pointers.
c++/cli can theoretically be used with WPF/Silverlight using the trick of replacing the C# generated from the XAML with a macro definition that can be used inside the main class in a code behind file. I worked out this technique but haven't had the motivation to take it beyond theory - I'm quite happy mixing languages.
As far as using c++/cli in a pure safe mode for your logic code, this may still not be possible but I'd love to hear how someone goes trying it now. Whilst researching it for Silverlight back in 2008 I found this daunting silverlight forum comment:
I just gave Silverlight&C++ it a try by compiling the MSIL from my C++ project into a Silverlight-compatible DLL. The good news: it works, and you can call this code from a Silverlight project. The bad news: The C++ compiler apparently uses MSIL instructions that Silverlight disallows.
So, if you try this, even with the simplest of programs, you'll almost immediately get the exception "Operation could destabilize the runtime." To me, this makes it seem less likely that we'll see Silverlight for C++ soon, as the compiler will need to behave quite a bit differently.
You can generate verifiable managed code in C++/CLI using the /clr:safe option. The problem is that most of your normal c++ code will not compile with that option.
C# is currently the only supported language for WinPhone7.
I fully expect that MS will add support for VB and C++/CLI in the future too, but don't expect to open up the native-code kimono anytime soon.
Native code just has too many issues to overcome, specifically around security, reliability, etc. Managed code is FAR easier to statically verify and FAR easier to control while running.
If you're upset about porting C++ code to C#, just be glad MS didn't force you to have to move to Objective-C ;)
From our own experience, the proces of porting well-written C++ to C# actually takes a lot less effort than one might at first expect. Sure, there's a learning curve, but you have that with any port. We actually got so much benefit from porting our core app and data engines to C# that we re-tooled our entire team to code in C# and port our C# back to C++ where necessary rather than the other way around! So far, we've only ported two modules back to C++ and call our C# code from our native code via interop instead.
Again, remember, WinPhone is a brand new platform using best of breed, highly-productive, next-generation development tools and platforms. It is not your father's WinMo.
If support for C++ is something you find to be crucially important, then make sure MS know - (respectfully and professionally) state your position in the MSDN forums and at developer events near you.
Update1: 2012-12-17:
While native C++ still isn't officially supported for Windows Phone 7, Windows Phone 8 now supports native C++ code so you can more easily port your existing C++ codebase(s) to Windows Phone 8 (as well as Windows 8 and Windows desktop apps).
While there isn't 100% compatibility between the Windows8/Phone8 platforms and API's right now, I expect the two platforms to become increasingly integrated over the next couple of releases.
This is especially true now that one of the key barriers to closer cooperation between Windows and other groups at Microsoft recently left the company ;)
Update2: 4/15/2014:
As per the recent announcements at //BUILD/ 2014, you can now start building "universal" apps in C++ & XAML, C#/VB & XAML or JavaScript & HTML that will run on Windows 8.1, Windows Phone 8.1 and Xbox One! For more details on building Windows Phone 8.1 Universal Apps, read this article.
The whole development idea is built on Silverlight. I think you can add your managed dll written in C++ without any problem to this Silverlight project, but it could not use native code.
I am planning to install the tools on my machine tonight and will try this out.
It is fine if MS decides to leave the path and create something new, that is MS' decision. So let's face the facts. Silverlight is no success yet. MS lost significant share due to Apple, Android and RIM. Application developers simply have to evaluate the business case for their own applications and decide if they trust in a share gain of Windows 7 phone or not. For the company that I run, we decided not to support any more MS Windows phone 7, not because of this or the other technical reason, but just because that we don't believe in the return of our investment for the port.
We start supporting Apple, Symbian, Andoid and MeeGo in the future if we see a market success of this new platform. All support C/C++ and enable us to reuse our proven application cores. So why worry at all. Personal technology preferences should not be gating. If personal preferences worry, then I would kick MS out for their to me ugly looking UI.
Thomas
It is on the horizon finally!
So a survey sent to windows phone developers about their future
development preferences and XNA isn't mentioned once in the Survey (A
survey sent to windows phone developers - did I mention that)
They do however ask:
How would you prefer to use C++ in your mobile apps/games?
Develop apps/games that are C++ from top to bottom (UI, business logic, and platform
APIs)
Use C++ for business logic and then write platform abstraction layer
Use C++ for business logic use 3rd party runtime engines
I don’t want to use C++
Our VB6 application uses a 3rd party control (PowerTCP from Dart) for SSL3 connectivity. However, this doesn't seem to work on Windows 7 - and I have not found any useful information on what I can do to make it work.
Is there a VB6.0 compatible control that will work on Win 7 for SSL3 communication?
Unfortunately, I can only suggest a workaround, not a solution: If you do not find a suitable ActiveX control for your VB6 application, you might consider migrating the communication part of your application to VB.NET.
This has the following advantages:
Calling .net code from VB6 is not hard.
The .net Framework has a built-in SSLStream class, which might already do what you want, so you're not dependent on a third-party component.
Since VB6 IDE support ended in April 2008, you will probably want to migrate your application to VB.NET sooner or later anyway. Therefore, migrating parts of your application now might be a better investment of your time than familiarizing yourself with a new third-party ActiveX control.
It has the following disadvantages:
One more layer in your application: Your VB6 code can call the .net code, but not vice-versa.
You need to familiarize yourself with the .net-COM interop stuff (it's not difficult, but it's something that needs to be done).
Your deployment process becomes more complicated, since you require the .net Framework to be installed on your customer's machines and you need to register your .net library as a COM component (so that your VB6 application can access it).
Dart still support the ActiveX control - why not ask them for help directly and post a question on their support forum?
Apologies in advance if you've already tried this.
In our project, we have a lot of ActiveX controls written in VB6. On big (x86) computers it works very well. These controls are hosted on website. And mobile users also wants to use it.
So is there any possible solution to recompile/cross-compile an .ocx and make .cab file to works under ARM architecture?
Or maybe I can emulate x86 architecture on mobile phones/PDAs?
Mateusz
There is no way to take a control written in VB6 and run it on a device with an ARM processor (via cross-compiling, emulation or otherwise).
Your best route is to rewrite your application in something that targets both x86 and the ARM mobile platform of your choice (one of java/j2me, .net framework/compact framework, flash, C/C++, etc) or just make your application run at the server and expose it via the web