I can build (and do, in fact), a Windows CE device with no display, no
window manager, no shell (obviously), etc., etc. It's only *some* Windows
CE devices that are 'like' Pocket PC or SmartPhone, not all of them.
Paul T.
> Hello,
>
[quoted text clipped - 13 lines]
>
> Markus
> somebody told me recently that for most programs there isn't that much
> difference. Why make one at all? Only for confusion.
Isn't much difference between what? CE and PPC? That can be sort of true
or patently untrue. Since CE is modular I can make it very similar or not
at all similar.
> On the PC you also have a modular OS.
No you don't (excluding XPe, which is out of the scope of this
conversation). You can install applications and drivers at run time, but
that is not a modular OS. You cannot remove supported features and APIs from
the kernel. kernel32.dll, user32.dll, etc. all have a fixed set of
functions and you're guaranteed that. You cannot say the same for
coredll.dll.
> You can decide wether to install
> that server tools, webserver etc. or not. It's as simple as that.
That statement shows you don't understand how the OS is actually built.
> Why
> not let the manufacturer of the PDA decide what to offer his customers
> (he's doing that already anyway) and make no difference except which
> modules he included. A programm should be able to figure out whether the
> needed modules are present or not.
An application cannot figure out what will be available on the device at
compile time and at run time it may be too late (it may be linked to
something that isn't available). It's not simply a matter of a DLL being
present or not, it's also a matter of is a specific function actually in a
specific DLL. Would you want to write an app where you have to call
LoadLibrary and GetProcAddress for every function (even for the Win32
functions)? That's just not a realistic scenario. That's the point of the
SDK.
> The only problem might be devices with no visible/audible output systems
> (e.g. no display).
I can give you a lot more scenarios than that.
-Chris
Markus Humm - 03 Apr 2006 19:33 GMT
[snip]
>> On the PC you also have a modular OS.
>
[quoted text clipped - 4 lines]
> functions and you're guaranteed that. You cannot say the same for
> coredll.dll.
Hm, I didn't say much about the kernel. I meant auxilary things (like
the GUI or like DirectX, Multimedia functions etc.)
>> You can decide wether to install
>> that server tools, webserver etc. or not. It's as simple as that.
>
> That statement shows you don't understand how the OS is actually built.
Then it has too much functions in the kernel which don't really belong
there (my opinion).
>> Why
>> not let the manufacturer of the PDA decide what to offer his customers
[quoted text clipped - 10 lines]
> functions)? That's just not a realistic scenario. That's the point of the
> SDK.
Okay if using thins in a static way you're right, but why not make
something simple to be able query what APIs are present at startup time
for the program where no static DLL bindings etc are even performed?
Then the app. could somehow tell the user that something is missing.
>> The only problem might be devices with no visible/audible output systems
>> (e.g. no display).
For gifing the user some message that some needed component is not
present display or speaker would be sufficient.
Greetings
Markus
Paul G. Tobey [eMVP] - 03 Apr 2006 19:43 GMT
You can generally tell whether an API class is ready yet, IsApiReady() and
time-out on that, if you want, but, again, if your program is linked with an
import library for a given DLL, it doesn't make any sense to load the
application when the DLL is missing. Being able to check if every single
call in the Win32 API is present or not is far beyond the range of
sensibility for a smallish device.
You can code your program so that it won't error out if a given API is
missing. You don't get an exception when P/Invoking something until you
actually do it and the DLL where it's implemented isn't found. If you
carefully handle every possible exception or pretest for the availability of
the APIs that might or might not be there, then your code is pretty capable
of running on any display-based device (.NET CF itself won't launch a
program on a headless device).
Paul T.
> [snip]
>>
[quoted text clipped - 50 lines]
>
> Markus