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
Not everything can be ported to CE and considering they publish in the MS documentation which methods are supported and which are not, as much as I love to blame MS, someone should have recognized before any code was written that a CE port was in the future. Of course I can't fault your project, if I had a nickel for every web app I have worked on that said in the spec MUST WORK ON FF that only works on IE I would be rich.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway -
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
Joe Woodbury wrote:
(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.)
I'm sorry, but the lounge is now closed due to an unforeseen bout of fundamentalism.
Deja View - the feeling that you've seen this post before.
-
Not everything can be ported to CE and considering they publish in the MS documentation which methods are supported and which are not, as much as I love to blame MS, someone should have recognized before any code was written that a CE port was in the future. Of course I can't fault your project, if I had a nickel for every web app I have worked on that said in the spec MUST WORK ON FF that only works on IE I would be rich.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest HemingwayIn this case, Microsoft deserves the blame. Waiting for multiple handles is extremely common in multi-threading programming. Likewise, passing event handles to external native programs is a common way to a multitude of tasks. Threading is critical to programming and one of the things the compact framework shouldn't have scrimped on. (The .NET 3.5 documentation finally makes clear what is or isn't support--previous documentation left this very vague. Besides, in this case a CE port was specifically not in the future and even if it was, there's only one way to do it without rewriting almost everything below the public interface from scratch.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
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
I don't know much about .NET, but in Win32 you would use the DuplicateHandle[^] function to convert a pseudo handle into a handle proper. Perhaps a similar trick will work for you.
Steve
-
In this case, Microsoft deserves the blame. Waiting for multiple handles is extremely common in multi-threading programming. Likewise, passing event handles to external native programs is a common way to a multitude of tasks. Threading is critical to programming and one of the things the compact framework shouldn't have scrimped on. (The .NET 3.5 documentation finally makes clear what is or isn't support--previous documentation left this very vague. Besides, in this case a CE port was specifically not in the future and even if it was, there's only one way to do it without rewriting almost everything below the public interface from scratch.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
I had the same greif when i first started on compact framework, so I just wrote a wrapper around WaitForMultpleObjects in coredll.dll
-
In this case, Microsoft deserves the blame. Waiting for multiple handles is extremely common in multi-threading programming. Likewise, passing event handles to external native programs is a common way to a multitude of tasks. Threading is critical to programming and one of the things the compact framework shouldn't have scrimped on. (The .NET 3.5 documentation finally makes clear what is or isn't support--previous documentation left this very vague. Besides, in this case a CE port was specifically not in the future and even if it was, there's only one way to do it without rewriting almost everything below the public interface from scratch.)
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
"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.
-
"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.
Give me a break. The CF support[s] threading. Period. Moreover, it runs on various forms of CE which fully supports multi-threading. On top of all that, ARM processors account for 70% of processors that run CE/CF.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
modified on Tuesday, January 29, 2008 10:43:23 PM
-
Give me a break. The CF support[s] threading. Period. Moreover, it runs on various forms of CE which fully supports multi-threading. On top of all that, ARM processors account for 70% of processors that run CE/CF.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
modified on Tuesday, January 29, 2008 10:43:23 PM
"Give me a break. The CF supporting threading. Period." What? "Moreover, it runs on various forms of CE which fully supports multi-threading." CE supports whatever the HAL supports which, again, is dependent on hardware.
-
"Give me a break. The CF supporting threading. Period." What? "Moreover, it runs on various forms of CE which fully supports multi-threading." CE supports whatever the HAL supports which, again, is dependent on hardware.
"Give me a break. The CF support[s] threading. Period." Typo. The Compact Framework [CF] supports threading. It supports event handles. It even supports waiting on one event handle. This support isn't optional. Moreover the HAL doesn't dictate whether multi-threading is supported or not. Any CPU can be multi-threaded (may be awkward on some, but it can still be done.) The gaps in the CF threading model can only be explained by laziness and stupidity. Take your pick.
Anyone who thinks he has a better idea of what's good for people than people do is a swine. - P.J. O'Rourke
-
Not everything can be ported to CE and considering they publish in the MS documentation which methods are supported and which are not, as much as I love to blame MS, someone should have recognized before any code was written that a CE port was in the future. Of course I can't fault your project, if I had a nickel for every web app I have worked on that said in the spec MUST WORK ON FF that only works on IE I would be rich.
Need a C# Consultant? I'm available.
Happiness in intelligent people is the rarest thing I know. -- Ernest HemingwayWait 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|
-
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