Prev: C# Threading - Exiting background threads without aborts
Next: XML Serializer in CF (slow)
From: Paul G. Tobey [eMVP] paultobey _at_ earthlink _dot_ on 5 Jan 2010 13:01
I'd like to know if anyone has done this, particularly if they are running
..NET CF programs side-by-side with such an extension to get WCF servers to
work. I don't think that .NET CF was intentionally crippled, but certainly
Microsoft intentionally did not include the server pieces, so that the size
of the framework would be minimized. Because of their general focus on
Windows Mobile, where the IP of a device is likely not to be fixed for more
than a few minutes, until you move to the next cell, they concentrated on
things like email transport, etc. Many devices, particularly those based on
generic CE, however, has stable IP addresses and would make great servers, if
the framework supported it (or could be configured with extra components that
supported it). I hope that we'll see this in the near future, but don't have
any inside information that it is coming...

Paul T.


"MarkusSchaber" wrote:

> Hi, Paolo,
>
> On 5 Jan., 08:11, paolo patierno
> <paolopatie...(a)discussions.microsoft.com> wrote:
> > Is there another way to hosting a web service on compact framework ?
>
> Of course, you can implement all the server side yourself, or it
> _might_ work to grab the code from Mono/XSP or another alternative
> server implementation.
>
> But the compact framework is not only downscaled, but intentionally
> crippled to make it useless for most serious usages, I can only
> strongly advise try to switch to other alternatives if possible -
> although I know that this is impossible in some cases.
> .
>
From: MarkusSchaber on 7 Jan 2010 05:17
Hi, Paul,

On 5 Jan., 19:01, Paul G. Tobey [eMVP] <paultobey _at_ earthlink _dot_
net> wrote:
> I don't think that .NET CF was intentionally crippled, but certainly
> Microsoft intentionally did not include the server pieces, so that the size
> of the framework would be minimized.

Well, when leaving out pieces to downsize the framework, one usually
builds a real subset of functionality to deliver. One can see this e.
G. in Java, or when looking at the embedded OSes which provide a posix
subset (eCos, QNX).

But as MS did it, it is rather difficult to use the same pieces of
source code on different compact framework targets (CE / Mobile /
PocketPC) and on the desktop without having several different projects
referencing the same source files, simply due to the fact that the
assemblies are differently signed. No "create once, run everywhere",
so e. G. a simple dll modeling some business data structures or some
mathematical algorithms (and no dependency on system functionality)
cannot be easily shared.

And is it really reducing the size when some basic functionality will
be reprogrammed by every application instead of delivered by the
framework? So e. G. instead of reducing the available timer services
to one, we have a crippled DateTime.Now which only goes to second
resolution, and an Environment.TickCount, and have to sync them
manually when we neet timestamps for measuring data which tickles in
faster then once a second. See, measuring and timing is nothing
uncommon in embedded applications.

> Many devices, particularly those based on
> generic CE, however, has stable IP addresses and would make great servers, if
> the framework supported it (or could be configured with extra components that
> supported it).  I hope that we'll see this in the near future, but don't have
> any inside information that it is coming...

My personal guess here (from seeing the design decisions) is that MS
politically wants to sell XP Embedded or the windows server edtitions
in those markets, and not CE.

But that's only my rant from outside, stumbling over CE and CF, and
looking back and glorifying my former experiences with eCos and Linux
programming. I don't see "Developers, Developers, Developers..." here,
but "Business Models" and "Restrictions Management".
From: "Paul G. Tobey [eMVP]" paul tobey _AT_ earthlink _DOT_ on 7 Jan 2010 21:12
They're balancing that against there not being enough memory in the average
device to run *any* .NET CF program. They've chosen, generally, pretty
well. The .NET CF team are not off in some ivory tower, either. They're
listening, I'm sure. It's silly to saw that being a server in Web service
conversation is a basic function. It is, in fact, a <1% function. When you
need it, it's annoying not to have it, but that doesn't mean that every
application needs it.

Point #2 (DateTime.Now), I think is because your target device (hardware),
doesn't return anything in the ms field, not because of some
short-sightedness on the part of the .NET CF team. It would be easy to
verify this on a PC running Windows CE that is set up to return something
for ms. There certainly are situations where you need timing measurement
and, if your hardware provides them, you're free to write a managed code
wrapper to allow your program to do that. The .NET CF, however, can't
somehow manufacture a microsecond timer out of nothingness.

I don't doubt that there are 'tensions' between the CE guys and the XPe
guys, but I think that, if the CE guys can make a business case for doing X,
they're going to do it. I'll ask them when I have a chance in a few weeks,
because I want it too.

Profit is what makes things work. If you have no chance to make money
selling your OS, it seems to me that you aren't highly incentivized to
provide good stuff. You can certainly do lots of good stuff using Linux and
there are many situations where it's 'better' than CE, but I've been through
the plusses and minuses of this in great detail as a device OEM and MS kills
Linux for any device that you're going to have people write code for. If
you're building a box that doesn't have to be programmed by your customer,
Linux will make you much happier.

Paul T.

"MarkusSchaber" <msr(a)soloplan.de> wrote in message
news:cc5bd661-28fe-49c1-8c72-c8d1e309a68e(a)r24g2000yqd.googlegroups.com...
Hi, Paul,

On 5 Jan., 19:01, Paul G. Tobey [eMVP] <paultobey _at_ earthlink _dot_
net> wrote:
> I don't think that .NET CF was intentionally crippled, but certainly
> Microsoft intentionally did not include the server pieces, so that the
> size
> of the framework would be minimized.

Well, when leaving out pieces to downsize the framework, one usually
builds a real subset of functionality to deliver. One can see this e.
G. in Java, or when looking at the embedded OSes which provide a posix
subset (eCos, QNX).

But as MS did it, it is rather difficult to use the same pieces of
source code on different compact framework targets (CE / Mobile /
PocketPC) and on the desktop without having several different projects
referencing the same source files, simply due to the fact that the
assemblies are differently signed. No "create once, run everywhere",
so e. G. a simple dll modeling some business data structures or some
mathematical algorithms (and no dependency on system functionality)
cannot be easily shared.

And is it really reducing the size when some basic functionality will
be reprogrammed by every application instead of delivered by the
framework? So e. G. instead of reducing the available timer services
to one, we have a crippled DateTime.Now which only goes to second
resolution, and an Environment.TickCount, and have to sync them
manually when we neet timestamps for measuring data which tickles in
faster then once a second. See, measuring and timing is nothing
uncommon in embedded applications.

> Many devices, particularly those based on
> generic CE, however, has stable IP addresses and would make great servers,
> if
> the framework supported it (or could be configured with extra components
> that
> supported it). I hope that we'll see this in the near future, but don't
> have
> any inside information that it is coming...

My personal guess here (from seeing the design decisions) is that MS
politically wants to sell XP Embedded or the windows server edtitions
in those markets, and not CE.

But that's only my rant from outside, stumbling over CE and CF, and
looking back and glorifying my former experiences with eCos and Linux
programming. I don't see "Developers, Developers, Developers..." here,
but "Business Models" and "Restrictions Management".


From: MarkusSchaber on 8 Jan 2010 08:06
Hi, Paul,

On 8 Jan., 03:12, "Paul G. Tobey [eMVP]" <paul tobey _AT_ earthlink
_DOT_ net> wrote:
> It's silly to saw that being a server in Web service
> conversation is a basic function.  It is, in fact, a <1% function.  When you
> need it, it's annoying not to have it, but that doesn't mean that every
> application needs it.

That's what modularity is for. Have a separate webservice.server.dll
or similar which contains the server side parts of the code, and then
it can be deployed optionally. Just like you can stick together the
modules in XP Embedded, Linux or eCos.

> Point #2 (DateTime.Now), I think is because your target device (hardware),
> doesn't return anything in the ms field, not because of some
> short-sightedness on the part of the .NET CF team.

And where does Environment.TickCount (which is present on cf) get its
milliseconds from?

So it is my task to create code to link those 2 clocks together, so I
can have at least some sub-second timestamps (I don't need
milliseconds, 1/10th of a second is enough). But this is not easy to
do from within userspace software, it is easier with hardware
awareness (which the OS has via its drivers).

> It would be easy to
> verify this on a PC running Windows CE that is set up to return something
> for ms.

Then this is against the documentation which says "In Windows CE, time
is specific only to the second. You can get a more precise time span
measurement, for example, in milliseconds, by using the TickCount
property.".

> Profit is what makes things work.  If you have no chance to make money
> selling your OS, it seems to me that you aren't highly incentivized to
> provide good stuff.  You can certainly do lots of good stuff using Linux and
> there are many situations where it's 'better' than CE, but I've been through
> the plusses and minuses of this in great detail as a device OEM and MS kills
> Linux for any device that you're going to have people write code for.  If
> you're building a box that doesn't have to be programmed by your customer,
> Linux will make you much happier.

You say "MS kills Linux" - I believe this instantly for XP Embedded &
co. They are rather nice and competitive systems, at least from my
experience. And I'm looking forward to the successor. It is easy to
deploy lean or "downsized" desktop software there. But CE does not
live up to what it could be.

And XP Embedded has higher licensing costs compared to CE AFAICS, so
there's the business case for crippling CE for certain usages.

Thanks for your paience,
markus
From: "Paul G. Tobey [eMVP]" paul tobey _AT_ earthlink _DOT_ on 11 Jan 2010 21:56
>That's what modularity is for. Have a separate webservice.server.dll
>or similar which contains the server side parts of the code, and then
>it can be deployed optionally. Just like you can stick together the
>modules in XP Embedded, Linux or eCos.

This is what I'm hoping for!

>And where does Environment.TickCount (which is present on cf) get its
>milliseconds from?

The timer is an interrupt that ticks periodically and is counted and
returned when GetTickCount is called. Not at all connected to the real-time
clock (if any). You actually don't even have to have a RTC for Windows CE
at all.

>So it is my task to create code to link those 2 clocks together, so I
>can have at least some sub-second timestamps (I don't need
>milliseconds, 1/10th of a second is enough). But this is not easy to
>do from within userspace software, it is easier with hardware
>awareness (which the OS has via its drivers).

Essentially impossible, I'd say. If you need this, choosing hardware that
can do it (via the RTC itself), is the 'right' way to do it. Most RTCs take
a long time to read, so getting an accurate measurement is very unlikely.
Is this RTC synced somehow to a coordinated time standard? If not, it's not
going to be accurate to 0.1 seconds anyway. Clocks drift that much in short
order.

>Then this is against the documentation which says "In Windows CE, time
>is specific only to the second. You can get a more precise time span
>measurement, for example, in milliseconds, by using the TickCount
>property.".

I'll check it when I can or, if you're building a device, adjust your
OEMGetRealTime() implementation to return *something non-zero* for the ms.
That should tell you if it's the framework or not. It seems highly unlikely
to be a restriction in the framework, because I can't figure out what the
reason for adding a silly restriction like that would be, but the only way
to prove it is to see a non-zero value.

>You say "MS kills Linux" - I believe this instantly for XP Embedded &
>co. They are rather nice and competitive systems, at least from my
>experience. And I'm looking forward to the successor. It is easy to
>deploy lean or "downsized" desktop software there. But CE does not
>live up to what it could be.

Has in the half dozen or so devices I've designed. Didn't have to bloat the
cost with hundreds of MB of RAM, hundreds of GB of hard disk, fancy display
adapters, high-cost processors, etc. It's perfect for small, inexpensive
devices.

>And XP Embedded has higher licensing costs compared to CE AFAICS, so
>there's the business case for crippling CE for certain usages.

Just because you're paranoid, it doesn't mean they're not out to get you...

CE targets small devices. Cripling is to make it fit, not, because it's too
competitive, or at least I've never seen that in talking to the teams at MS.

Paul T.


First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: C# Threading - Exiting background threads without aborts
Next: XML Serializer in CF (slow)