Windows Embedded - Versionsgeschichte

B-M-N: /* Graphische Windows Shell oder Explorer */ Rechtschreibung und Link

2019-12-27T13:41:59Z

Graphische Windows Shell oder Explorer: Rechtschreibung und Link

← Nächstältere Version		Version vom 27. Dezember 2019, 13:41 Uhr
Zeile 24:		Zeile 24:

	= Graphische Windows Shell oder Explorer =		= Graphische Windows Shell oder Explorer =

	In der GoPal- oder WindowsCE-Community findet man Beschreibungen, wie man das erste Manko einer fehlenden graphischen Windows Shell oder eines fehlenden File Explorers umgehen kann. Daher hier nur Verweise dahin ohne weitere Details:		In der GoPal- oder WindowsCE-Community findet man Beschreibungen, wie man das erste Manko einer fehlenden graphischen Windows Shell oder eines fehlenden File Explorers umgehen kann. Daher hier nur Verweise dahin ohne weitere Details:

	* [[Kompatible_Software#toosten ShowTaskBar V1.1\|toosten ShowTaskBar V1.1]]		* [[Kompatible_Software#toosten ShowTaskBar V1.1\|toosten ShowTaskBar V1.1]]
	*Im Hintergrund läuft bei GoPals offenbar schon eine Shell, also den Vordergrundprozess killen, um zur graphischen Shell zu gelangen:		*Im Hintergrund läuft bei GoPals offenbar schon eine Shell, also den Vordergrundprozess killen, um zur graphischen Shell zu gelangen:
	**Mittels Remote Tools in Microsoft Entwicklungsumgebunden für Smart Devices,		**Mittels Remote Tools in Microsoft Entwicklungsumgebunden für Smart Devices,
	**Mit Task Managern, z. B. [[Kompatible_Software#toosten Task-Manager V1.0\|toosten Task-Manager V1.0]] und [~~http://www~~.~~iaccarino~~.~~de/silvio/stuff/TaskMgrSetup.exe~~ TaskManager 1.4.5]		**Mit Task Managern, z. B. [[Kompatible_Software#toosten Task-Manager V1.0\|toosten Task-Manager V1.0]] und [[Kompatible_Software#Mobile TaskManager 1.4.5\|Mobile TaskManager 1.4.5]]
	*Mit Remote Registry Editor (Remote Tools in Microsoft ~~Entwicklungsumgebunden~~ für Smart Devices) unter HKLM\init einen ~~Hilfprogramm~~ wie die bereits erwähnten von Smart Card beim Boot-Vorgang starten		*Mit Remote Registry Editor (Remote Tools in Microsoft Entwicklungsumgebungen für Smart Devices) unter <code>HKLM\init</code> einen Hilfsprogramm wie die bereits erwähnten von Smart Card beim Boot-Vorgang starten
	*Verwendung von bekannten Easter-Eggs (Tasten so und so halten während Boot, hier und da auf heimliche Schaltflächen drücken)		*Verwendung von bekannten Easter-Eggs (Tasten so und so halten während Boot, hier und da auf heimliche Schaltflächen drücken)
	**Kann die mal jemand auflisten und sagen auf welchem Gerät und Software-Version die gelten?		**Kann die mal jemand auflisten und sagen auf welchem Gerät und Software-Version die gelten?
	**~~[[GoPal 4.x FAQ#Wie_komme_ich_ins_WinCE.3F\|~~Ab GoPal 4.1 kann man im Hauptmenü oben in das "o" von Gopal klicken (dreimal wiederholen) und dadurch wird der Explorer gestartet.]] Achtung dieser Trick funktioniert nicht bei Centrality Geräten.		**Ab GoPal 4.1 kann man im Hauptmenü oben in das "o" von Gopal klicken (dreimal wiederholen) und dadurch wird der Explorer gestartet. (siehe [[GoPal 4.x FAQ#Wie_komme_ich_ins_WinCE.3F\|GoPal 4.x FAQ]]) Achtung dieser Trick funktioniert nicht bei Centrality Geräten.

	= Dynamic Linked Libraries nachinstallieren =		= Dynamic Linked Libraries nachinstallieren =

B-M-N: RS , {{adsense}} entfernt, toten Link gefixt

2019-12-26T12:13:36Z

RS , {{adsense}} entfernt, toten Link gefixt

← Nächstältere Version		Version vom 26. Dezember 2019, 12:13 Uhr
Zeile 19:		Zeile 19:
	Die billigere '''Core Runtime License''' wird auf Navigationsgeräten durch die Hersteller bevorzugt verwendet, besonders wenn es nicht vorgesehen ist, dass der Endbenutzer auf die Shell des Betriebssystems zugreifen darf und dadurch einen erweiterten Funktionsumfang nutzen kann. Das haben übrigens andere Navigationslösungen mit GoPal gemeinsam.		Die billigere '''Core Runtime License''' wird auf Navigationsgeräten durch die Hersteller bevorzugt verwendet, besonders wenn es nicht vorgesehen ist, dass der Endbenutzer auf die Shell des Betriebssystems zugreifen darf und dadurch einen erweiterten Funktionsumfang nutzen kann. Das haben übrigens andere Navigationslösungen mit GoPal gemeinsam.

	Eine '''Professional Runtime License''' findet man eher bei z.B. Mobiltelefonen bei denen die grafische Microsoft-Shell mit bekanntem Start-Button etc. auch für die Benutzung durch den Endanwender vorgesehen ist.		Eine '''Professional Runtime License''' findet man eher bei z. B.. Mobiltelefonen bei denen die grafische Microsoft-Shell mit bekanntem Start-Button etc. auch für die Benutzung durch den Endanwender vorgesehen ist.

	Da nur selten ein Endbenutzer auf eine '''Core Runtime License''' vollen Zugriff hat (sondern halt auf eine '''Professional Runtime License'''), existieren vermehrt Windows Embedded CE Programme im Freeware, Open Source und kommerziellen Umfeld, die Bibliotheken, bzw. API-Funktionen verwenden, die auf den GoPal-Geräten so erst mal nicht vorhanden sind.		Da nur selten ein Endbenutzer auf eine '''Core Runtime License''' vollen Zugriff hat (sondern halt auf eine '''Professional Runtime License'''), existieren vermehrt Windows Embedded CE Programme im Freeware, Open Source und kommerziellen Umfeld, die Bibliotheken, bzw. API-Funktionen verwenden, die auf den GoPal-Geräten so erst mal nicht vorhanden sind.
Zeile 30:		Zeile 30:
	*Im Hintergrund läuft bei GoPals offenbar schon eine Shell, also den Vordergrundprozess killen, um zur graphischen Shell zu gelangen:		*Im Hintergrund läuft bei GoPals offenbar schon eine Shell, also den Vordergrundprozess killen, um zur graphischen Shell zu gelangen:
	**Mittels Remote Tools in Microsoft Entwicklungsumgebunden für Smart Devices,		**Mittels Remote Tools in Microsoft Entwicklungsumgebunden für Smart Devices,
	**Mit Task Managern, z.B. [~~http://~~toosten.~~com/index.php?id=9&file=zip~~\|toosten Task-Manager V1.0], [http://www.iaccarino.de/silvio/stuff/TaskMgrSetup.exe\|TaskManager 1.4.5]		**Mit Task Managern, z. B. [[Kompatible_Software#toosten Task-Manager V1.0\|toosten Task-Manager V1.0]] und [http://www.iaccarino.de/silvio/stuff/TaskMgrSetup.exe TaskManager 1.4.5]
	*Mit Remote Registry Editor (Remote Tools in Microsoft Entwicklungsumgebunden für Smart Devices) unter HKLM\init einen Hilfprogramm wie die bereits erwähnten von Smart Card beim Boot-Vorgang starten		*Mit Remote Registry Editor (Remote Tools in Microsoft Entwicklungsumgebunden für Smart Devices) unter HKLM\init einen Hilfprogramm wie die bereits erwähnten von Smart Card beim Boot-Vorgang starten
	*Verwendung von bekannten Easter-Eggs (Tasten so und so halten während Boot, hier und da auf heimliche Schaltflächen drücken)		*Verwendung von bekannten Easter-Eggs (Tasten so und so halten während Boot, hier und da auf heimliche Schaltflächen drücken)
Zeile 54:		Zeile 54:
	Typisches Beispiel, dass so etwas praktiziert wird, ist die aygshell.dll. Davon kann man mit etwas Suche im Netz der Netze viele Varianten finden. Gemeinsam haben sie die gleiche Schnittstelle. Nur die Implementierung weicht häufig untereinander ab. Also führt es zu unterschiedlichem Erfolg, ob und wie das zugehörige Programm läuft. Das die Mistkiste dann nicht genau das macht, was sie soll, liegt dann nicht an Microsoft, sondern an demjenigen, der die abgespeckte Aygshell nur an seine eigenen Bedürfnisse angepasst hat und bloß nicht mehr machen wollte. So zum richtigen Download an fester Adresse mit Homepage findet man solch eine Aygshell.dll freilich nicht. Das machen so CE-Entwickler mehr inoffiziell für sich selbst. Ob das rechtlich wieder ok ist, die Aygshell.dll so nachzuäffen und/oder weiterzugeben bleibt fragwürdig. Mir sind aber auch keine Gerichtsentscheidungen hierzu bekannt. Irgendwie ist das aber auch alles in allem noch sehr "unsauber".		Typisches Beispiel, dass so etwas praktiziert wird, ist die aygshell.dll. Davon kann man mit etwas Suche im Netz der Netze viele Varianten finden. Gemeinsam haben sie die gleiche Schnittstelle. Nur die Implementierung weicht häufig untereinander ab. Also führt es zu unterschiedlichem Erfolg, ob und wie das zugehörige Programm läuft. Das die Mistkiste dann nicht genau das macht, was sie soll, liegt dann nicht an Microsoft, sondern an demjenigen, der die abgespeckte Aygshell nur an seine eigenen Bedürfnisse angepasst hat und bloß nicht mehr machen wollte. So zum richtigen Download an fester Adresse mit Homepage findet man solch eine Aygshell.dll freilich nicht. Das machen so CE-Entwickler mehr inoffiziell für sich selbst. Ob das rechtlich wieder ok ist, die Aygshell.dll so nachzuäffen und/oder weiterzugeben bleibt fragwürdig. Mir sind aber auch keine Gerichtsentscheidungen hierzu bekannt. Irgendwie ist das aber auch alles in allem noch sehr "unsauber".

	Siehe [[Kompatible Software]] für Beispiele, die mit einer Aygshell versuchen, rumzutricksen. Um die verschienden Aygshells zu unterscheiden, wird eine Größe in Byte mit angegeben. Diese Angabe ist aber gegebenenfalls nur mittelprächtig aussagekräftig.		Siehe [[Kompatible Software]] für Beispiele, die mit einer ''Aygshell'' versuchen, rumzutricksen. Um die verschienden Aygshells zu unterscheiden, wird eine Größe in Byte mit angegeben. Diese Angabe ist aber gegebenenfalls nur mittelprächtig aussagekräftig.

	Im schlechtesten Fall heißt das jetzt, dass das eine Programm diese, das andere Programm jene Aygshell braucht. Spätestens dann ist es umständlich die Aygshell im /Windows-Verzeichnis zu hinterlegen, wie es manchmal empfohlen wird. Da müsste man ja DJ spielen, also die Aygshell je nach Programm, das man gerade starten möchte, austauschen und und und... Und da reden wir ~~immernoch~~ von nur einer einzigen bestimmten, wenn auch häufig verwendeten DLL. Und von der Sorte gibt es ja noch mehr. Je größer also die Softwaresammlung von Fremdsoftware dieser Art wird, desto nerviger und umständlicher wird die Sache dann auch.		Im schlechtesten Fall heißt das jetzt, dass das eine Programm diese, das andere Programm jene Aygshell braucht. Spätestens dann ist es umständlich die Aygshell im /Windows-Verzeichnis zu hinterlegen, wie es manchmal empfohlen wird. Da müsste man ja DJ spielen, also die Aygshell je nach Programm, das man gerade starten möchte, austauschen und und und... Und da reden wir immer noch von nur einer einzigen bestimmten, wenn auch häufig verwendeten DLL. Und von der Sorte gibt es ja noch mehr. Je größer also die Softwaresammlung von Fremdsoftware dieser Art wird, desto nerviger und umständlicher wird die Sache dann auch.

	Das Tool, das man benutzt, um die DLL-Abhängigkeiten von Executables (ausführbaren Dateien) und weiteren DLLs zu sehen, nennt sich übrigens Dependency Walker. Ein Dependency Walker geht in statischer Analyse die ausführbaren Programmanteile durch und zeigt fehlende wie auch erfüllte Abhängigkeiten zu Bibliotheksfunktionen an. Dadurch braucht man also nicht mehr raten, welche DLL eigentlich fehlt.		Das Tool, das man benutzt, um die DLL-Abhängigkeiten von Executables (ausführbaren Dateien) und weiteren DLLs zu sehen, nennt sich übrigens Dependency Walker. Ein Dependency Walker geht in statischer Analyse die ausführbaren Programmanteile durch und zeigt fehlende wie auch erfüllte Abhängigkeiten zu Bibliotheksfunktionen an. Dadurch braucht man also nicht mehr raten, welche DLL eigentlich fehlt.
Zeile 78:		Zeile 78:
	Auch ist anzunehmen, dass man DLLs braucht, die in der '''Core Runtime License''' nicht enthalten sind.		Auch ist anzunehmen, dass man DLLs braucht, die in der '''Core Runtime License''' nicht enthalten sind.

	Wenn das aber klappt, könnte man [[MS Visual Studio 2008 Express Edition]] für die C#-Entwicklung eigener Programme verwenden, die dann gegebenenfalls auch unter Windows CE laufen. [[MS Visual Studio 2008 Express Edition]] unterstützt selbst keine '''Smart Device'''-Entwicklung (z.B. auch in C/C++). So heißt das auf Microsoft-Slang, wenn man Windows-Embedded-Programme schreiben mag.		Wenn das aber klappt, könnte man [[MS Visual Studio 2008 Express Edition]] für die C#-Entwicklung eigener Programme verwenden, die dann gegebenenfalls auch unter Windows CE laufen. [[MS Visual Studio 2008 Express Edition]] unterstützt selbst keine '''Smart Device'''-Entwicklung (z. B.. auch in C/C++). So heißt das auf Microsoft-Slang, wenn man Windows-Embedded-Programme schreiben mag.

	== Programmieren in C/C++ ==		== Programmieren in C/C++ ==

	*[[Programmieren in C und C++\|Programmieren]] unter Windows CE für unseren GoPal		*[[Programmieren in C und C++\|Programmieren]] unter Windows CE für unseren GoPal

	~~<br>~~

	~~<br>~~

	~~<br>{{adsense}}~~

	[[Category:Entwicklung]]		[[Category:Entwicklung]]

B-M-N: /* Graphische Windows Shell oder Explorer */ toten Link gefixt

2019-12-26T11:29:54Z

Graphische Windows Shell oder Explorer: toten Link gefixt

← Nächstältere Version		Version vom 26. Dezember 2019, 11:29 Uhr
Zeile 27:		Zeile 27:
	In der GoPal- oder WindowsCE-Community findet man Beschreibungen, wie man das erste Manko einer fehlenden graphischen Windows Shell oder eines fehlenden File Explorers umgehen kann. Daher hier nur Verweise dahin ohne weitere Details:		In der GoPal- oder WindowsCE-Community findet man Beschreibungen, wie man das erste Manko einer fehlenden graphischen Windows Shell oder eines fehlenden File Explorers umgehen kann. Daher hier nur Verweise dahin ohne weitere Details:

	*[~~http://~~toosten.~~com/index.php?id=9&file=zip~~\|toosten ShowTaskBar V1.1]		* [[Kompatible_Software#toosten ShowTaskBar V1.1\|toosten ShowTaskBar V1.1]]
	*Im Hintergrund läuft bei GoPals offenbar schon eine Shell, also den Vordergrundprozess killen, um zur graphischen Shell zu gelangen:		*Im Hintergrund läuft bei GoPals offenbar schon eine Shell, also den Vordergrundprozess killen, um zur graphischen Shell zu gelangen:
	**Mittels Remote Tools in Microsoft Entwicklungsumgebunden für Smart Devices,		**Mittels Remote Tools in Microsoft Entwicklungsumgebunden für Smart Devices,

B-M-N: /* Allgemeines */

2019-11-26T15:32:47Z

Allgemeines

Neue Seite

<br>

Die derzeitigen GoPal-Geräte laufen unter dem Betriebssystem Microsoft Windows CE.

Eine Übersicht aller Embedded Betriebssysteme von Microsoft findet man unter:
http://www.microsoft.com/windowsembedded/en-us/default.mspx

Spezielles zu Microsoft Windows Embedded CE findet sich unter:
http://www.microsoft.com/windowsembedded/en-us/products/windowsce/default.mspx

Die von Microsoft Windows CE unterstützten Prozessoren sind MIPS, SH4, x86 und ARM. Die GoPal-Geräte haben eine CPU mit ARM-Core.

= Lizenz =

Sieht man sich den Funktionsumfang, die mitgelieferten DLLs und Applikationen, etc. an, nachdem man im Explorer in das /Windows-Verzeichnis des GoPal-Gerätes bei einer ActiveSync-Verbindung reingeschaut hat, so kann man mit etwas Recherche-Arbeit erkennen, dass hier die '''Core Runtime License''' und nicht die wesentlich umfangreichere '''Professional Runtime License''' verwendet wird.

Diese Einschränkung ist dafür verantwortlich, dass eine Reihe von Pocket-PC-Programmen oder Windows-CE-Applikationen, die auf anderen Geräten entwickelt wurden, nicht laufen können, selbst wenn hardware-technisch das Portable Navigation Device in der Lage wäre, das Programm laufen zu lassen. Gerade hier steckt manchmal eine Menge Frust für den GoPal-Besitzer begraben, solange dieser Lizenz-Unterschied noch nicht verstanden ist.

Die billigere '''Core Runtime License''' wird auf Navigationsgeräten durch die Hersteller bevorzugt verwendet, besonders wenn es nicht vorgesehen ist, dass der Endbenutzer auf die Shell des Betriebssystems zugreifen darf und dadurch einen erweiterten Funktionsumfang nutzen kann. Das haben übrigens andere Navigationslösungen mit GoPal gemeinsam.

Eine '''Professional Runtime License''' findet man eher bei z.B. Mobiltelefonen bei denen die grafische Microsoft-Shell mit bekanntem Start-Button etc. auch für die Benutzung durch den Endanwender vorgesehen ist.

Da nur selten ein Endbenutzer auf eine '''Core Runtime License''' vollen Zugriff hat (sondern halt auf eine '''Professional Runtime License'''), existieren vermehrt Windows Embedded CE Programme im Freeware, Open Source und kommerziellen Umfeld, die Bibliotheken, bzw. API-Funktionen verwenden, die auf den GoPal-Geräten so erst mal nicht vorhanden sind.

= Graphische Windows Shell oder Explorer =

In der GoPal- oder WindowsCE-Community findet man Beschreibungen, wie man das erste Manko einer fehlenden graphischen Windows Shell oder eines fehlenden File Explorers umgehen kann. Daher hier nur Verweise dahin ohne weitere Details:

*[http://toosten.com/index.php?id=9&file=zip|toosten ShowTaskBar V1.1]
*Im Hintergrund läuft bei GoPals offenbar schon eine Shell, also den Vordergrundprozess killen, um zur graphischen Shell zu gelangen:
**Mittels Remote Tools in Microsoft Entwicklungsumgebunden für Smart Devices,
**Mit Task Managern, z.B. [http://toosten.com/index.php?id=9&file=zip|toosten Task-Manager V1.0], [http://www.iaccarino.de/silvio/stuff/TaskMgrSetup.exe|TaskManager 1.4.5]
*Mit Remote Registry Editor (Remote Tools in Microsoft Entwicklungsumgebunden für Smart Devices) unter HKLM\init einen Hilfprogramm wie die bereits erwähnten von Smart Card beim Boot-Vorgang starten
*Verwendung von bekannten Easter-Eggs (Tasten so und so halten während Boot, hier und da auf heimliche Schaltflächen drücken)
**Kann die mal jemand auflisten und sagen auf welchem Gerät und Software-Version die gelten?
**[[GoPal 4.x FAQ#Wie_komme_ich_ins_WinCE.3F|Ab GoPal 4.1 kann man im Hauptmenü oben in das "o" von Gopal klicken (dreimal wiederholen) und dadurch wird der Explorer gestartet.]] Achtung dieser Trick funktioniert nicht bei Centrality Geräten.

= Dynamic Linked Libraries nachinstallieren =

Die Lizenzwahl - wie oben erwähnt - beschreibt bei fehlenden DLLs oder APIs natürlich nur die halbe Wahrheit. Bei der Zusammenstellung des Betriebssystems im PlatformBuilder hat der Betriebssystementwickler die Möglichkeit, recht feingranular API sets dem Betriebssystemdesign hinzuzufügen oder wegzunehmen. Dadurch kann das Betriebsystem auf den Anwendungsfall sehr schlank zugeschnitten werden, wie es ja auch eines der Designziele im Bereich eingebetteter Systeme ist.

[[Image:OSDesignSelctionFromCatalog.jpg|Screenshot des OSDesign-View (links) und des Feature-Catalog (rechts) des PlatformBuilders Windows CE 5]]

Im Beispiel sehen wir, dass links im OSDesign-View die Aygshell fehlt, diese aber rechts aus dem Feature-Catalog rübergezogen werden könnte. Die Designauswahl links hat übrigens nichts mit unseren GoPal-Geräten zu tun. So fehlt beim GoPal-Gerät das Konsolen-Fenster, das hier auch selektiert ist. Aber zurück zu unseren fehlenden DLLs:

Einige nicht laufende Programme lassen sich lauffähig bekommen, in dem fehlende DLLs (Dynamic Linked Libraries) nachinstalliert werden. Dabei wird es gegebenenfalls rechtlich heikel: Verwende ich einfach die offiziellen DLL(s) von Microsoft, die ja bei meinem Gerät fehlt/fehlen, so kann ohne weiteres ein Softwarelizensverstoß vorliegen.

Es geht aber noch weiter: häufig haben DLLs untereinander Abhängigkeiten, so dass nicht nur eine DLL nachinstalliert werden muss, sondern sich ein Ratenschwanz an Nachinstallationen hinterherzieht.

Im Bereich eingebetteter Systeme wird im Gegensatz zum PC-Desktop-Bereich das abstrahierte Betriebssystem mit einer Adaptionsschicht zur Hardware-Plattform gemeinsam entwickelt. Beides gemeinsam wird als Board-Support-Package (kurz: BSP) bezeichnet. Solche Plattformanpassungen und die höhere Flexibilität Betriebssystem-Features im Windows CE rein oder raus zu konfigurieren, führen dazu, dass einge Kern-DLLs von Windows CE sehr an die Hardware-Plattform oder die Betriebssystem-Feature-Wahl angepasst sind. Anzunehmen, eine core.dll des einen Windows CE-Gerätes läuft (problemlos) auf einem anderen Gerät, geht dadurch im Allgemeinen deutlich schief.

Nachdem es oft einfach nur laufen soll, man aber die originalen Microsoft DLLs rechtlich nicht wirklich verwenden darf, oder auch nur die Nachinstallation mit Rattenschwanz zu aufwändig ist, gab es bisher auch noch einen anderen Ansatz, um ein nicht lauffähiges Programm einfach laufen zu lassen: Man programmiert die fehlende DLL einfach selbst und kennt ja aus dem Microsoft Developer Network oder durch entsprechende Analyse der originialen DLL die Schnittstellenbeschreibung (Vorsicht! Wieder ein Rechtsverstoß, wenn das als Reverse Engineering ausgelegt wird). Dass der Aufruf klappt, ist dabei wichtig. Ob der Inhalt der aufgerufenen Funktion stimmt, ist erst mal sekundär.

Typisches Beispiel, dass so etwas praktiziert wird, ist die aygshell.dll. Davon kann man mit etwas Suche im Netz der Netze viele Varianten finden. Gemeinsam haben sie die gleiche Schnittstelle. Nur die Implementierung weicht häufig untereinander ab. Also führt es zu unterschiedlichem Erfolg, ob und wie das zugehörige Programm läuft. Das die Mistkiste dann nicht genau das macht, was sie soll, liegt dann nicht an Microsoft, sondern an demjenigen, der die abgespeckte Aygshell nur an seine eigenen Bedürfnisse angepasst hat und bloß nicht mehr machen wollte. So zum richtigen Download an fester Adresse mit Homepage findet man solch eine Aygshell.dll freilich nicht. Das machen so CE-Entwickler mehr inoffiziell für sich selbst. Ob das rechtlich wieder ok ist, die Aygshell.dll so nachzuäffen und/oder weiterzugeben bleibt fragwürdig. Mir sind aber auch keine Gerichtsentscheidungen hierzu bekannt. Irgendwie ist das aber auch alles in allem noch sehr "unsauber".

Siehe [[Kompatible Software]] für Beispiele, die mit einer Aygshell versuchen, rumzutricksen. Um die verschienden Aygshells zu unterscheiden, wird eine Größe in Byte mit angegeben. Diese Angabe ist aber gegebenenfalls nur mittelprächtig aussagekräftig.

Im schlechtesten Fall heißt das jetzt, dass das eine Programm diese, das andere Programm jene Aygshell braucht. Spätestens dann ist es umständlich die Aygshell im /Windows-Verzeichnis zu hinterlegen, wie es manchmal empfohlen wird. Da müsste man ja DJ spielen, also die Aygshell je nach Programm, das man gerade starten möchte, austauschen und und und... Und da reden wir immernoch von nur einer einzigen bestimmten, wenn auch häufig verwendeten DLL. Und von der Sorte gibt es ja noch mehr. Je größer also die Softwaresammlung von Fremdsoftware dieser Art wird, desto nerviger und umständlicher wird die Sache dann auch.

Das Tool, das man benutzt, um die DLL-Abhängigkeiten von Executables (ausführbaren Dateien) und weiteren DLLs zu sehen, nennt sich übrigens Dependency Walker. Ein Dependency Walker geht in statischer Analyse die ausführbaren Programmanteile durch und zeigt fehlende wie auch erfüllte Abhängigkeiten zu Bibliotheksfunktionen an. Dadurch braucht man also nicht mehr raten, welche DLL eigentlich fehlt.

Tipp & Fazit: Wer programmieren kann, programmiert lieber selbst. Wer ein Programm einfach nur verwenden mag, sollte nach einer Version Ausschau halten, die zu Gerät, BSP und der Lizenz des Betriebssystems passt.

= Programmieren des GoPals =

Das Schreiben von eigener Software ist eigentlich eine feine Sache auf dem GoPal-Gerät. Aber schon stehen wir vor dem nächsten Problem: Kein GoPal-Gerät wird mit einer Programmierumgebung ausgeliefert. Auch setze ich mal voraus, dass nicht nur die Verwendung von Fremd- oder Drittsoftware, sondern auch die Eigenentwicklung von Software auf möglichst legaler Schiene geschehen soll.

== Programmierumgebung für C/C++ ==

*[[Programmierumgebungen für C und C++|Programmierumgebungen]] unter Windows CE für unseren GoPal

== Programmierumgebung für C# ==

Hierzu müsste man das '''.NET Compact Framework''' von Microsoft auf dem GoPal installieren. Dabei handelt es sich um die .NET Framework Version für Embedded Systems unter Windows CE und Derivate. Wer das schafft, kann hier bitte mal die Vorgehensweise beschreiben. Bin sehr interessiert...

Das ist mit Sicherheit nicht unmöglich, aber ein sportliches Vorhaben. Auch das 320x240 Display sollte bei der Installation auf den kleinen GoPal-Geräten ein wenig störend sein. Vielfach werden die Installationsfenster größer als das Display sein und eine Bedienung erschweren.

Auch ist anzunehmen, dass man DLLs braucht, die in der '''Core Runtime License''' nicht enthalten sind.

Wenn das aber klappt, könnte man [[MS Visual Studio 2008 Express Edition]] für die C#-Entwicklung eigener Programme verwenden, die dann gegebenenfalls auch unter Windows CE laufen. [[MS Visual Studio 2008 Express Edition]] unterstützt selbst keine '''Smart Device'''-Entwicklung (z.B. auch in C/C++). So heißt das auf Microsoft-Slang, wenn man Windows-Embedded-Programme schreiben mag.

== Programmieren in C/C++ ==

*[[Programmieren in C und C++|Programmieren]] unter Windows CE für unseren GoPal

<br>

<br>

<br>{{adsense}}

[[Category:Entwicklung]]

B-M-N am 9. Januar 2010 um 16:58 Uhr

2010-01-09T16:58:12Z

Neue Seite

[[Kategorie:Entwicklung]]

= Allgemeines =

Die derzeitigen GoPal-Geräte laufen unter dem Betriebssystem Microsoft Windows CE.

Eine Übersicht aller Embedded Betriebssysteme von Microsoft findet man unter:

http://www.microsoft.com/windowsembedded/en-us/default.mspx

Spezielles zu Microsoft Windows Embedded CE findet sich unter:

http://www.microsoft.com/windowsembedded/en-us/products/windowsce/default.mspx

Die von Microsoft Windows CE unterstützten Prozessoren sind MIPS, SH4, x86 und ARM. Die GoPal-Geräte haben eine CPU mit ARM-Core.

= Lizenz =

Sieht man sich den Funktionsumfang, die mitgelieferten DLLs und Applikationen, etc. an, nachdem man im Explorer in das /Windows-Verzeichnis des GoPal-Gerätes bei einer ActiveSync-Verbindung reingeschaut hat, so kann man mit etwas Recherche-Arbeit erkennen, dass hier die '''Core Runtime License''' und nicht die wesentlich umfangreichere '''Professional Runtime License''' verwendet wird.

Diese Einschränkung ist dafür verantwortlich, dass eine Reihe von Pocket-PC-Programmen oder Windows-CE-Applikationen, die auf anderen Geräten entwickelt wurden, nicht laufen können, selbst wenn hardware-technisch das Portable Navigation Device in der Lage wäre, das Programm laufen zu lassen. Gerade hier steckt manchmal eine Menge Frust für den GoPal-Besitzer begraben, solange dieser Lizenz-Unterschied noch nicht verstanden ist.

Die billigere '''Core Runtime License''' wird auf Navigationsgeräten durch die Hersteller bevorzugt verwendet, besonders wenn es nicht vorgesehen ist, dass der Endbenutzer auf die Shell des Betriebssystems zugreifen darf und dadurch einen erweiterten Funktionsumfang nutzen kann. Das haben übrigens andere Navigationslösungen mit GoPal gemeinsam.

Eine '''Professional Runtime License''' findet man eher bei z.B. Mobiltelefonen bei denen die grafische Microsoft-Shell mit bekanntem Start-Button etc. auch für die Benutzung durch den Endanwender vorgesehen ist.

Da nur selten ein Endbenutzer auf eine '''Core Runtime License''' vollen Zugriff hat (sondern halt auf eine '''Professional Runtime License'''), existieren vermehrt Windows Embedded CE Programme im Freeware, Open Source und kommerziellen Umfeld, die Bibliotheken, bzw. API-Funktionen verwenden, die auf den GoPal-Geräten so erst mal nicht vorhanden sind.

= Graphische Windows Shell oder Explorer =

In der GoPal- oder WindowsCE-Community findet man Beschreibungen, wie man das erste Manko einer fehlenden graphischen Windows Shell oder eines fehlenden File Explorers umgehen kann. Daher hier nur Verweise dahin ohne weitere Details:

* [http://toosten.com/index.php?id=9&file=zip|toosten ShowTaskBar V1.1]
* Im Hintergrund läuft bei GoPals offenbar schon eine Shell, also den Vordergrundprozess killen, um zur graphischen Shell zu gelangen:
** Mittels Remote Tools in Microsoft Entwicklungsumgebunden für Smart Devices,
** Mit Task Managern, z.B. [http://toosten.com/index.php?id=9&file=zip|toosten Task-Manager V1.0], [http://www.iaccarino.de/silvio/stuff/TaskMgrSetup.exe|TaskManager 1.4.5]
* Mit Remote Registry Editor (Remote Tools in Microsoft Entwicklungsumgebunden für Smart Devices) unter HKLM\init einen Hilfprogramm wie die bereits erwähnten von Smart Card beim Boot-Vorgang starten
* Verwendung von bekannten Easter-Eggs (Tasten so und so halten während Boot, hier und da auf heimliche Schaltflächen drücken)
** Kann die mal jemand auflisten und sagen auf welchem Gerät und Software-Version die gelten?
** [[GoPal_4.x_FAQ#Wie_komme_ich_ins_WinCE.3F|Ab GoPal 4.1 kann man im Hauptmenü oben in das "o" von Gopal klicken (dreimal wiederholen) und dadurch wird der Explorer gestartet.]] Achtung dieser Trick funktioniert nicht bei Centrality Geräten.

= Dynamic Linked Libraries nachinstallieren =

Die Lizenzwahl - wie oben erwähnt - beschreibt bei fehlenden DLLs oder APIs natürlich nur die halbe Wahrheit. Bei der Zusammenstellung des Betriebssystems im PlatformBuilder hat der Betriebssystementwickler die Möglichkeit, recht feingranular API sets dem Betriebssystemdesign hinzuzufügen oder wegzunehmen. Dadurch kann das Betriebsystem auf den Anwendungsfall sehr schlank zugeschnitten werden, wie es ja auch eines der Designziele im Bereich eingebetteter Systeme ist.

[[Bild:OSDesignSelctionFromCatalog.jpg|Screenshot des OSDesign-View (links) und des Feature-Catalog (rechts) des PlatformBuilders Windows CE 5]]

Im Beispiel sehen wir, dass links im OSDesign-View die Aygshell fehlt, diese aber rechts aus dem Feature-Catalog rübergezogen werden könnte. Die Designauswahl links hat übrigens nichts mit unseren GoPal-Geräten zu tun. So fehlt beim GoPal-Gerät das Konsolen-Fenster, das hier auch selektiert ist. Aber zurück zu unseren fehlenden DLLs:

Einige nicht laufende Programme lassen sich lauffähig bekommen, in dem fehlende DLLs (Dynamic Linked Libraries) nachinstalliert werden. Dabei wird es gegebenenfalls rechtlich heikel: Verwende ich einfach die offiziellen DLL(s) von Microsoft, die ja bei meinem Gerät fehlt/fehlen, so kann ohne weiteres ein Softwarelizensverstoß vorliegen.

Es geht aber noch weiter: häufig haben DLLs untereinander Abhängigkeiten, so dass nicht nur eine DLL nachinstalliert werden muss, sondern sich ein Ratenschwanz an Nachinstallationen hinterherzieht.

Im Bereich eingebetteter Systeme wird im Gegensatz zum PC-Desktop-Bereich das abstrahierte Betriebssystem mit einer Adaptionsschicht zur Hardware-Plattform gemeinsam entwickelt. Beides gemeinsam wird als Board-Support-Package (kurz: BSP) bezeichnet. Solche Plattformanpassungen und die höhere Flexibilität Betriebssystem-Features im Windows CE rein oder raus zu konfigurieren, führen dazu, dass einge Kern-DLLs von Windows CE sehr an die Hardware-Plattform oder die Betriebssystem-Feature-Wahl angepasst sind. Anzunehmen, eine core.dll des einen Windows CE-Gerätes läuft (problemlos) auf einem anderen Gerät, geht dadurch im Allgemeinen deutlich schief.

Nachdem es oft einfach nur laufen soll, man aber die originalen Microsoft DLLs rechtlich nicht wirklich verwenden darf, oder auch nur die Nachinstallation mit Rattenschwanz zu aufwändig ist, gab es bisher auch noch einen anderen Ansatz, um ein nicht lauffähiges Programm einfach laufen zu lassen: Man programmiert die fehlende DLL einfach selbst und kennt ja aus dem Microsoft Developer Network oder durch entsprechende Analyse der originialen DLL die Schnittstellenbeschreibung (Vorsicht! Wieder ein Rechtsverstoß, wenn das als Reverse Engineering ausgelegt wird). Dass der Aufruf klappt, ist dabei wichtig. Ob der Inhalt der aufgerufenen Funktion stimmt, ist erst mal sekundär.

Typisches Beispiel, dass so etwas praktiziert wird, ist die aygshell.dll. Davon kann man mit etwas Suche im Netz der Netze viele Varianten finden. Gemeinsam haben sie die gleiche Schnittstelle. Nur die Implementierung weicht häufig untereinander ab. Also führt es zu unterschiedlichem Erfolg, ob und wie das zugehörige Programm läuft. Das die Mistkiste dann nicht genau das macht, was sie soll, liegt dann nicht an Microsoft, sondern an demjenigen, der die abgespeckte Aygshell nur an seine eigenen Bedürfnisse angepasst hat und bloß nicht mehr machen wollte. So zum richtigen Download an fester Adresse mit Homepage findet man solch eine Aygshell.dll freilich nicht. Das machen so CE-Entwickler mehr inoffiziell für sich selbst. Ob das rechtlich wieder ok ist, die Aygshell.dll so nachzuäffen und/oder weiterzugeben bleibt fragwürdig. Mir sind aber auch keine Gerichtsentscheidungen hierzu bekannt. Irgendwie ist das aber auch alles in allem noch sehr "unsauber".

Siehe [[Kompatible_Software]] für Beispiele, die mit einer Aygshell versuchen, rumzutricksen. Um die verschienden Aygshells zu unterscheiden, wird eine Größe in Byte mit angegeben. Diese Angabe ist aber gegebenenfalls nur mittelprächtig aussagekräftig.

Im schlechtesten Fall heißt das jetzt, dass das eine Programm diese, das andere Programm jene Aygshell braucht. Spätestens dann ist es umständlich die Aygshell im /Windows-Verzeichnis zu hinterlegen, wie es manchmal empfohlen wird. Da müsste man ja DJ spielen, also die Aygshell je nach Programm, das man gerade starten möchte, austauschen und und und... Und da reden wir immernoch von nur einer einzigen bestimmten, wenn auch häufig verwendeten DLL. Und von der Sorte gibt es ja noch mehr. Je größer also die Softwaresammlung von Fremdsoftware dieser Art wird, desto nerviger und umständlicher wird die Sache dann auch.

Das Tool, das man benutzt, um die DLL-Abhängigkeiten von Executables (ausführbaren Dateien) und weiteren DLLs zu sehen, nennt sich übrigens Dependency Walker. Ein Dependency Walker geht in statischer Analyse die ausführbaren Programmanteile durch und zeigt fehlende wie auch erfüllte Abhängigkeiten zu Bibliotheksfunktionen an. Dadurch braucht man also nicht mehr raten, welche DLL eigentlich fehlt.

Tipp & Fazit: Wer programmieren kann, programmiert lieber selbst. Wer ein Programm einfach nur verwenden mag, sollte nach einer Version Ausschau halten, die zu Gerät, BSP und der Lizenz des Betriebssystems passt.

= Programmieren des GoPals =

Das Schreiben von eigener Software ist eigentlich eine feine Sache auf dem GoPal-Gerät. Aber schon stehen wir vor dem nächsten Problem: Kein GoPal-Gerät wird mit einer Programmierumgebung ausgeliefert. Auch setze ich mal voraus, dass nicht nur die Verwendung von Fremd- oder Drittsoftware, sondern auch die Eigenentwicklung von Software auf möglichst legaler Schiene geschehen soll.

== Programmierumgebung für C/C++ ==

* [[Programmierumgebungen für C und C++|Programmierumgebungen]] unter Windows CE für unseren GoPal

== Programmierumgebung für C# ==

Hierzu müsste man das '''.NET Compact Framework''' von Microsoft auf dem GoPal installieren. Dabei handelt es sich um die .NET Framework Version für Embedded Systems unter Windows CE und Derivate. Wer das schafft, kann hier bitte mal die Vorgehensweise beschreiben. Bin sehr interessiert...

Das ist mit Sicherheit nicht unmöglich, aber ein sportliches Vorhaben. Auch das 320x240 Display sollte bei der Installation auf den kleinen GoPal-Geräten ein wenig störend sein. Vielfach werden die Installationsfenster größer als das Display sein und eine Bedienung erschweren.

Auch ist anzunehmen, dass man DLLs braucht, die in der '''Core Runtime License''' nicht enthalten sind.

Wenn das aber klappt, könnte man [[MS Visual Studio 2008 Express Edition]] für die C#-Entwicklung eigener Programme verwenden, die dann gegebenenfalls auch unter Windows CE laufen. [[MS Visual Studio 2008 Express Edition]] unterstützt selbst keine '''Smart Device'''-Entwicklung (z.B. auch in C/C++). So heißt das auf Microsoft-Slang, wenn man Windows-Embedded-Programme schreiben mag.

== Programmieren in C/C++ ==

* [[Programmieren in C und C++|Programmieren]] unter Windows CE für unseren GoPal

{{adsense}}

Omerkel: /* Dynamic Linked Libraries nachinstallieren */

2008-12-04T13:37:38Z

Dynamic Linked Libraries nachinstallieren

← Nächstältere Version		Version vom 4. Dezember 2008, 13:37 Uhr
Zeile 46:		Zeile 46:
	[[Bild:OSDesignSelctionFromCatalog.jpg\|Screenshot des OSDesign-View (links) und des Feature-Catalog (rechts) des PlatformBuilders Windows CE 5]]		[[Bild:OSDesignSelctionFromCatalog.jpg\|Screenshot des OSDesign-View (links) und des Feature-Catalog (rechts) des PlatformBuilders Windows CE 5]]

	Im Beispiel sehen wir, dass links im OSDesign-View die Aygshell fehlt, diese aber rechts aus dem Feature-Catalog rübergezogen werden könnte. Die Designauswahl links hat übrigens nichts mit unseren GoPal-Geräten zu tun. So fehlt beim GoPal-~~gerät~~ das Konsolen-Fenster, das hier auch selektiert ist. Aber zurück zu unseren fehlenden DLLs:		Im Beispiel sehen wir, dass links im OSDesign-View die Aygshell fehlt, diese aber rechts aus dem Feature-Catalog rübergezogen werden könnte. Die Designauswahl links hat übrigens nichts mit unseren GoPal-Geräten zu tun. So fehlt beim GoPal-Gerät das Konsolen-Fenster, das hier auch selektiert ist. Aber zurück zu unseren fehlenden DLLs:

	Einige nicht laufende Programme lassen sich lauffähig bekommen, in dem fehlende DLLs (Dynamic Linked Libraries) nachinstalliert werden. Dabei wird es gegebenenfalls rechtlich heikel: Verwende ich einfach die offiziellen DLL(s) von Microsoft, die ja bei meinem Gerät fehlt/fehlen, so kann ohne weiteres ein Softwarelizensverstoß vorliegen.		Einige nicht laufende Programme lassen sich lauffähig bekommen, in dem fehlende DLLs (Dynamic Linked Libraries) nachinstalliert werden. Dabei wird es gegebenenfalls rechtlich heikel: Verwende ich einfach die offiziellen DLL(s) von Microsoft, die ja bei meinem Gerät fehlt/fehlen, so kann ohne weiteres ein Softwarelizensverstoß vorliegen.

Omerkel: /* Dynamic Linked Libraries nachinstallieren */

2008-12-04T13:36:33Z

Dynamic Linked Libraries nachinstallieren

← Nächstältere Version		Version vom 4. Dezember 2008, 13:36 Uhr
Zeile 42:		Zeile 42:
	= Dynamic Linked Libraries nachinstallieren =		= Dynamic Linked Libraries nachinstallieren =

	Die Lizenzwahl - wie oben erwähnt - beschreibt bei fehlenden DLLs oder APIs natürlich nur die halbe Wahrheit. Bei der Zusammenstellung des Betriebssystems im PlatformBuilder hat der Betriebssystementwickler die Möglichkeit recht feingranular API sets dem Betriebssystemdesign hinzuzufügen oder wegzunehmen. Dadurch kann das Betriebsystem auf den Anwendungsfall sehr schlank zugeschnitten werden, wie es ja auch eines der Designziele im Bereich eingebetteter Systeme ist.		Die Lizenzwahl - wie oben erwähnt - beschreibt bei fehlenden DLLs oder APIs natürlich nur die halbe Wahrheit. Bei der Zusammenstellung des Betriebssystems im PlatformBuilder hat der Betriebssystementwickler die Möglichkeit, recht feingranular API sets dem Betriebssystemdesign hinzuzufügen oder wegzunehmen. Dadurch kann das Betriebsystem auf den Anwendungsfall sehr schlank zugeschnitten werden, wie es ja auch eines der Designziele im Bereich eingebetteter Systeme ist.

	[[Bild:OSDesignSelctionFromCatalog.jpg\|Screenshot des OSDesign-View (links) und des Feature-Catalog (rechts) des PlatformBuilders Windows CE 5]]		[[Bild:OSDesignSelctionFromCatalog.jpg\|Screenshot des OSDesign-View (links) und des Feature-Catalog (rechts) des PlatformBuilders Windows CE 5]]

Omerkel: /* Dynamic Linked Libraries nachinstallieren */

2008-12-04T13:36:04Z

Dynamic Linked Libraries nachinstallieren

← Nächstältere Version		Version vom 4. Dezember 2008, 13:36 Uhr
Zeile 42:		Zeile 42:
	= Dynamic Linked Libraries nachinstallieren =		= Dynamic Linked Libraries nachinstallieren =

	Die Lizenzwahl beschreibt bei fehlenden DLLs oder APIs natürlich nur die halbe Wahrheit. Bei der Zusammenstellung des Betriebssystems im PlatformBuilder hat der Betriebssystementwickler die Möglichkeit recht feingranular API sets dem Betriebssystemdesign hinzuzufügen oder wegzunehmen. Dadurch kann das Betriebsystem auf den Anwendungsfall sehr schlank zugeschnitten werden, wie es ja auch eines der Designziele im Bereich eingebetteter Systeme ist.		Die Lizenzwahl - wie oben erwähnt - beschreibt bei fehlenden DLLs oder APIs natürlich nur die halbe Wahrheit. Bei der Zusammenstellung des Betriebssystems im PlatformBuilder hat der Betriebssystementwickler die Möglichkeit recht feingranular API sets dem Betriebssystemdesign hinzuzufügen oder wegzunehmen. Dadurch kann das Betriebsystem auf den Anwendungsfall sehr schlank zugeschnitten werden, wie es ja auch eines der Designziele im Bereich eingebetteter Systeme ist.

	[[Bild:OSDesignSelctionFromCatalog.jpg\|Screenshot des OSDesign-View (links) und des Feature-Catalog (rechts) des PlatformBuilders Windows CE 5]]		[[Bild:OSDesignSelctionFromCatalog.jpg\|Screenshot des OSDesign-View (links) und des Feature-Catalog (rechts) des PlatformBuilders Windows CE 5]]

Omerkel: /* Dynamic Linked Libraries nachinstallieren */

2008-12-04T13:35:36Z

Dynamic Linked Libraries nachinstallieren

← Nächstältere Version		Version vom 4. Dezember 2008, 13:35 Uhr
Zeile 41:		Zeile 41:

	= Dynamic Linked Libraries nachinstallieren =		= Dynamic Linked Libraries nachinstallieren =

			Die Lizenzwahl beschreibt bei fehlenden DLLs oder APIs natürlich nur die halbe Wahrheit. Bei der Zusammenstellung des Betriebssystems im PlatformBuilder hat der Betriebssystementwickler die Möglichkeit recht feingranular API sets dem Betriebssystemdesign hinzuzufügen oder wegzunehmen. Dadurch kann das Betriebsystem auf den Anwendungsfall sehr schlank zugeschnitten werden, wie es ja auch eines der Designziele im Bereich eingebetteter Systeme ist.

			[[Bild:OSDesignSelctionFromCatalog.jpg\|Screenshot des OSDesign-View (links) und des Feature-Catalog (rechts) des PlatformBuilders Windows CE 5]]

			Im Beispiel sehen wir, dass links im OSDesign-View die Aygshell fehlt, diese aber rechts aus dem Feature-Catalog rübergezogen werden könnte. Die Designauswahl links hat übrigens nichts mit unseren GoPal-Geräten zu tun. So fehlt beim GoPal-gerät das Konsolen-Fenster, das hier auch selektiert ist. Aber zurück zu unseren fehlenden DLLs:

	Einige nicht laufende Programme lassen sich lauffähig bekommen, in dem fehlende DLLs (Dynamic Linked Libraries) nachinstalliert werden. Dabei wird es gegebenenfalls rechtlich heikel: Verwende ich einfach die offiziellen DLL(s) von Microsoft, die ja bei meinem Gerät fehlt/fehlen, so kann ohne weiteres ein Softwarelizensverstoß vorliegen.		Einige nicht laufende Programme lassen sich lauffähig bekommen, in dem fehlende DLLs (Dynamic Linked Libraries) nachinstalliert werden. Dabei wird es gegebenenfalls rechtlich heikel: Verwende ich einfach die offiziellen DLL(s) von Microsoft, die ja bei meinem Gerät fehlt/fehlen, so kann ohne weiteres ein Softwarelizensverstoß vorliegen.

Omerkel: /* Programmieren des GoPals */

2008-12-01T15:58:25Z

Programmieren des GoPals

← Nächstältere Version		Version vom 1. Dezember 2008, 15:58 Uhr
Zeile 77:		Zeile 77:

	Wenn das aber klappt, könnte man [[MS Visual Studio 2008 Express Edition]] für die C#-Entwicklung eigener Programme verwenden, die dann gegebenenfalls auch unter Windows CE laufen. [[MS Visual Studio 2008 Express Edition]] unterstützt selbst keine '''Smart Device'''-Entwicklung (z.B. auch in C/C++). So heißt das auf Microsoft-Slang, wenn man Windows-Embedded-Programme schreiben mag.		Wenn das aber klappt, könnte man [[MS Visual Studio 2008 Express Edition]] für die C#-Entwicklung eigener Programme verwenden, die dann gegebenenfalls auch unter Windows CE laufen. [[MS Visual Studio 2008 Express Edition]] unterstützt selbst keine '''Smart Device'''-Entwicklung (z.B. auch in C/C++). So heißt das auf Microsoft-Slang, wenn man Windows-Embedded-Programme schreiben mag.

			== Programmieren in C/C++ ==

			* [[Programmieren in C und C++\|Programmieren]] unter Windows CE für unseren GoPal