Rant time: .NET Compact Framework
-
Got assigned to port my rather thin .NET interface to our low level stuff to CE and the Compact Framework. The code is so simple I figured it would be easy. Not. I'm left wondering what planet the Compact Framework team lives on. The one that's killing me is the lack of WaitHandle.WaitAny() and then to discover that ManualResetEvent.Handle() isn't an actual handle, but a pseudo handle! With no way to get the actual handle. So now I have write a bunch of code that Microsoft didn't write to save space or some such nonsense. (If this has been fixed in .NET 3.5 CF, let me know. I doubt it since once again it appears that nobody at Microsoft actually writes code of any significance for the compact framework. If they did, the framework, and Visual Studio support, wouldn't suck so bad.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
LOL This is such a typical reaction from someone coming from the .NET Framework. Part of the.NET CF team's design philosophy is simple: if there's an easy work around, they won't provide the feature. For the record, WaitHandle.WaitAny() is still unsupported in .NET CF 3.5. If you don't want to have to write the P/Invoke calls yourself, you can always use the Smart Device Framework, which does this for you already. Our implementation of WaitHandle (namely, OpenNETCF.Threading.EventWaitHandle) supports 4 overloads of WaitAny(). I hate to plug our products on here, but there is a free of charge version :)
------------------------- Neil Cowburn, MVP Principal Partner OpenNETCF Consulting, LLC -------------------------
-
Wait till you come to the memory model. It is a stupid 64MB memory model :. Even Mobile 6 is crippled. After you do a lot of extra works, you will may find yourself too little memory to run in a PDA! Simple thing like multiple instances detection is not directly supported. :doh: X|
Actually a 32MB memory model where a lot of the virtual address space is taken by native DLLs due to how they load. Windows Mobile is so big that it overflows the dedicated 32MB slot for execute-in-place DLLs and places a large number of them in the per-process address space, leaving around 12MB for your program if you're lucky. Multiple instance detection: if running on Windows Mobile and using the right version of Compact Framework, it does multiple instance detection for you, but this only works if your application is responsive. Don't block the UI thread for any length of time.
DoEvents: Generating unexpected recursion since 1991
-
Got assigned to port my rather thin .NET interface to our low level stuff to CE and the Compact Framework. The code is so simple I figured it would be easy. Not. I'm left wondering what planet the Compact Framework team lives on. The one that's killing me is the lack of WaitHandle.WaitAny() and then to discover that ManualResetEvent.Handle() isn't an actual handle, but a pseudo handle! With no way to get the actual handle. So now I have write a bunch of code that Microsoft didn't write to save space or some such nonsense. (If this has been fixed in .NET 3.5 CF, let me know. I doubt it since once again it appears that nobody at Microsoft actually writes code of any significance for the compact framework. If they did, the framework, and Visual Studio support, wouldn't suck so bad.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
When Windows CE was developed, the team was trying to reduce the footprint of the API to reduce the size of core system DLLs. They carefully reviewed the Windows API and added only essentials while keeping a decent amount of power. My favourite example: MoveTo and LineTo APIs were omitted, because the Polyline API can be used to draw single lines, and many graphics accelerators support it directly. The vertex drawing is also slightly different between a single Polyline call and multiple LineTo calls. On the other hand PolyPolyline was also omitted as few accelerators supported multiple polylines in a single operation, and it could be replaced by multiple Polyline calls. When the .NET Compact Framework team started, they also cut down the .NET Framework API but generally left in only the least complicated, not the most functional, overloads. CF 1.0 shipped with only the ability to create one-pixel-wide pens and bizarrely, considering the underlying support, only the DrawLine method, not DrawLines. That meant you had to call DrawLine repeatedly to draw a complicated figure, resulting in multiple cross-process calls to GWES.EXE which would otherwise have been a single call, giving lower performance. As you're aware, only having WaitAny, not WaitOne, wouldn't have been a problem: you can call WaitAny with a single handle. Needing WaitAny when you only have WaitOne: a big problem. (WaitAll isn't supported because the underlying WaitForMultipleObjects doesn't support it.) Compact Framework 1.0 didn't support wait timeouts (again, what planet?) If you're trying to use Compact Framework 1.0, don't bother. Switch to version 2.0. CF 1.0 was pretty buggy even in SP3. CF 2.0 SP2 seems to be reasonably good. For a boatload of useful wrappers and tools, including many classes which implement missing APIs, see OpenNETCF Smart Device Framework 2.1[^]. If developing GUI applications, be aware that Visual Studio 2005 Smart Device projects don't Dispose components[^]. I'd appreciate you voting up
-
"In this case, Microsoft deserves the blame. Waiting for multiple handles is extremely common in multi-threading programming." Yes, but the compact framework is designed to support various small and embedded processors which may not contain everything you need to execute threaded programs.
I'm with Joe. CE supports multi-threading fully. Been there, done that. Size of processor matters not; device matters not. In fact, the display GUI is running as a thread, which is why any intensive processing *must* be put into a separate thread so the display does not freeze!
Gary
-
Actually a 32MB memory model where a lot of the virtual address space is taken by native DLLs due to how they load. Windows Mobile is so big that it overflows the dedicated 32MB slot for execute-in-place DLLs and places a large number of them in the per-process address space, leaving around 12MB for your program if you're lucky. Multiple instance detection: if running on Windows Mobile and using the right version of Compact Framework, it does multiple instance detection for you, but this only works if your application is responsive. Don't block the UI thread for any length of time.
DoEvents: Generating unexpected recursion since 1991
-
I'm with Joe. CE supports multi-threading fully. Been there, done that. Size of processor matters not; device matters not. In fact, the display GUI is running as a thread, which is why any intensive processing *must* be put into a separate thread so the display does not freeze!
Gary
Okay, fine. You win. "They" got to implementing the next-to-last function in the threading API and said "screw it".
-
When Windows CE was developed, the team was trying to reduce the footprint of the API to reduce the size of core system DLLs. They carefully reviewed the Windows API and added only essentials while keeping a decent amount of power. My favourite example: MoveTo and LineTo APIs were omitted, because the Polyline API can be used to draw single lines, and many graphics accelerators support it directly. The vertex drawing is also slightly different between a single Polyline call and multiple LineTo calls. On the other hand PolyPolyline was also omitted as few accelerators supported multiple polylines in a single operation, and it could be replaced by multiple Polyline calls. When the .NET Compact Framework team started, they also cut down the .NET Framework API but generally left in only the least complicated, not the most functional, overloads. CF 1.0 shipped with only the ability to create one-pixel-wide pens and bizarrely, considering the underlying support, only the DrawLine method, not DrawLines. That meant you had to call DrawLine repeatedly to draw a complicated figure, resulting in multiple cross-process calls to GWES.EXE which would otherwise have been a single call, giving lower performance. As you're aware, only having WaitAny, not WaitOne, wouldn't have been a problem: you can call WaitAny with a single handle. Needing WaitAny when you only have WaitOne: a big problem. (WaitAll isn't supported because the underlying WaitForMultipleObjects doesn't support it.) Compact Framework 1.0 didn't support wait timeouts (again, what planet?) If you're trying to use Compact Framework 1.0, don't bother. Switch to version 2.0. CF 1.0 was pretty buggy even in SP3. CF 2.0 SP2 seems to be reasonably good. For a boatload of useful wrappers and tools, including many classes which implement missing APIs, see OpenNETCF Smart Device Framework 2.1[^]. If developing GUI applications, be aware that Visual Studio 2005 Smart Device projects don't Dispose components[^]. I'd appreciate you voting up
Mike Dimmick wrote:
When Windows CE was developed, the team was trying to reduce the footprint of the API to reduce the size of core system DLLs.
Maybe that was the publicly stated goal. It was more a black-ops, hide in the corner project. Get stuff working to prove the concept, before full recognition of MS. Competition was Palm in those days. Remember using WinCE as a boot loader for Linux? Yeah, same old Linux. Same tools, same libraries, different CPU. :) [RANT] Not only was a lot of compatibility left out, what's there changes (not always for the good), including the UI, with different versions of CE. Convert from CE 1.3 to Pocket PC - rewrite the application's UI. :confused: We developers put up with and work around the :mad: until they maybe get it right. 8 versions of the OS in 8 years! Five different compilers/IDE's. Just plain asinine. No worry. Just like they did with Vista, they'll get it right eventually. X| [/RANT]
Gary
-
Okay, fine. You win. "They" got to implementing the next-to-last function in the threading API and said "screw it".
-
Got assigned to port my rather thin .NET interface to our low level stuff to CE and the Compact Framework. The code is so simple I figured it would be easy. Not. I'm left wondering what planet the Compact Framework team lives on. The one that's killing me is the lack of WaitHandle.WaitAny() and then to discover that ManualResetEvent.Handle() isn't an actual handle, but a pseudo handle! With no way to get the actual handle. So now I have write a bunch of code that Microsoft didn't write to save space or some such nonsense. (If this has been fixed in .NET 3.5 CF, let me know. I doubt it since once again it appears that nobody at Microsoft actually writes code of any significance for the compact framework. If they did, the framework, and Visual Studio support, wouldn't suck so bad.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
So I'm guessing you didn't bother to let the CF team know (via bug report) of this lack? You'd just rather sit back and complain and not try to make it better? :sigh:
Machaira wrote:
So I'm guessing you didn't bother to let the CF team know (via bug report) of this lack?
Condescending day I suppose, but as a matter of fact I did. But I'm quite sure they already knew about it. I'm equally sure they don't care. (Yes, CF is that bad.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Mike Dimmick wrote:
When Windows CE was developed, the team was trying to reduce the footprint of the API to reduce the size of core system DLLs.
Maybe that was the publicly stated goal. It was more a black-ops, hide in the corner project. Get stuff working to prove the concept, before full recognition of MS. Competition was Palm in those days. Remember using WinCE as a boot loader for Linux? Yeah, same old Linux. Same tools, same libraries, different CPU. :) [RANT] Not only was a lot of compatibility left out, what's there changes (not always for the good), including the UI, with different versions of CE. Convert from CE 1.3 to Pocket PC - rewrite the application's UI. :confused: We developers put up with and work around the :mad: until they maybe get it right. 8 versions of the OS in 8 years! Five different compilers/IDE's. Just plain asinine. No worry. Just like they did with Vista, they'll get it right eventually. X| [/RANT]
Gary
[QUOTE] We developers put up with and work around the until they maybe get it right. 8 versions of the OS in 8 years! Five different compilers/IDE's. Just plain asinine. [/QUOTE] Thanks Microsoft, for continually getting things not quite right with every technology you've ever released. I and my fellow developers appreciate the employment. As long as we know you'll be out there owning the desktop and making a shambles of everything you touch, we'll always be secure in our jobs. Long live the Microsoft way of mucking technologies up :D
patbob