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.
Hi, Paul,
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".