Browser unter MacOSX geht nicht

[Silas]

Ist jetzt jedenfalls mein Wissensstand. Ich meine mal nachgeguckt zu haben und die landen sowieso alle am Ende in nmwin32_c.c:12546 im ewe-Code für Windows.

 

[Silas]

Ggf. könnte man auch ENI nutzen, um das Problem zu umgehen, aber da bräuchten wir auch eine native DLL für WinCE (also jemanden mit Compiler). Oder kann man mit ENI auch direkt auf die coredll.dll zugreifen, um CreateProcess aufzurufen?

Das scheint mir eine super Idee zu sein!

Gruß,
Pfeffer.

Kurzes googlen sagt mir, dass man bei JNI/ENI die native Library auch selbst implementieren und dann auf den Java-Code mappen muss, verstehe ich das richtig? Dann wäre es natürlich schlecht mit dem Aufrufen bestehender Methoden. Sorry, falls die Frage dumm ist, aber ich komme aus der .NET-Ecke und da braucht man das für Interop nicht...

 

[pfeffer]

1. es ist richtig, dass auf Windows Mobile es mit keiner Aufruf-Variante funktioniert.
2. ich habe noch nie was mit eni gemacht und - so weit ich weiß - auch keiner der anderen Cachewolf-Entwickler. Also, wenn Du dafür eine Lösung finden würdest, wäre es großartig!

Gruß,
Pfeffer.

 

[Silas]

Ich hab mal bisschen rumgespielt und immerhin einen Linux-PocketPC-Crosscompiler gefunden (http://cegcc.sourceforge.net/), der mehr oder weniger funktioniert. Mehr oder weniger, da man mindestens eine DLL mitliefern muss und unter Windows Mobile 6.1 noch ein Registry-Eintrag nötig ist, damit die DLL auch korrekt geladen wird. Bei älteren Versionen soll das nicht der Fall sein.

Jetzt muss das nur noch irgendwie mit ENI klappen...

Edit: Leider bekomme ich den ewe-NativeBuilder nicht richtig ans Laufen. Man muss die .class-Datei wählen und den Klassennamen. Er meldet jedoch immer "java.lang.NoClassDefFoundError: IllegalName: utils/CWWrapper". Dabei spielts keine Rolle, ob ich als Klasse "CWWrapper" oder "utils.CWWrapper" angebe.

Falls das jemand mal unter Windows (wegen des Slashs in der Fehlermeldung) ausprobieren möchte, bitte vorher diese beiden Zeilen direkt in der Klasse CWWrapper ergänzen:

static {ewe.sys.Vm.loadLibrary("CWWrapper");}
private static native void ppcExec(String cmd, String arg);

Grüße, Silas

 

[MiK]

Ich habe heute ausnahmsweise mal ein Garmin-Gerät hier. Mit der aktuellen Version bleibt leider "zu Garmin" grau. Mit der einer alten CW-Version (1.0.1532) ging es dann problemlos.

 

[UncleOwen]

Und Du hast gpsbabel irgendwo im Pfad (bzw. unter Windows auch im Cachewolf-Verzeichnis) installiert?

Wie dem auch sei, das liegt vermutlich an meinen Änderungen aus http://www.geoclub.de/viewtopic.php?f=40&t=31994, also die Diskussion auch dahin

Zum Thema dieses Threads... ich werd mich hier erstmal raushalten, da ich von ENI keine Ahnung hab...

 

[Silas]

Leider funktioniert der NativeBuilder aus dem ewe SDK bei mir nicht. Ich vermute, der ist nicht wirklich Platform-unabhängig, da in der Fehlermeldung Slashes als Verzeichnistrennzeichen vorkommen (siehe mein letztes Posting). Ich hab jetzt extra noch mal das Beispiel aus der ENI-Doku ausprobiert, um Fehler meinerseits auszuschließen, mit dem gleichen Ergebnis.

Könnte jemand mit Windows, der das SDK auch installiert hat, bitte mal ausprobieren, ob der NativeBuilder (kann aus Jewel aus dem SDK auf der Karteikarte "Developer Tools" aufgerufen werden) bei ihm funktioniert? Ihr müsstet einfach die angehängte class-Datei entzippen und in einen Ordner "utils" (ist wichtig, Verzeichnisstruktur muss dem Package entsprechen!) speichern. Das Ergebnis sollte dann etwa so aussehen (siehe hier):

Vielen Dank und Gruß,
Silas

 

[pfeffer]

ok, bei so einer genauer Beschreibung bekomme ich es hin, es zu versuchen. Ergbnis: das gleiche wie bei Dir. Ich bin mir recht sicher, dass der Grund ist, dass man das Verzeichnis, in dem das Verzeichnis "utils" liegt auswählen müsste. Aber da ist natürlich keine .class
Das mit "/" "\" (und evlt. ".") als Pfad-trenner nimmt ewe normalerweise nicht so genau.

Ich probiere damit mal noch ein bißchen rum.

PS: Bist Du per Instant-Messanger zu erreichen?

Gruß,
Pfeffer.

 

[pfeffer]

so:
wenn ich es ohne utils davor mache, dann geht es, bestimmt auch bei Dir ;-)

ich bekomme zB das hier:

//########################################################################
/*
To compile this under Windows, select a project that produces a Win32 or WinCE
Dynamic Linked Library.

To compile under Linux use the -shared option with the gcc compiler
to produce a shared library.
e.g.
	gcc -shared -o MyNativeLibrary.so ThisFile.cpp

If you define NO_ENI_THREADS then you will not need the pthread.so library to run it under LInux.*/
#ifdef _WIN32_WCE
#define NO_JNI_METHODS
#endif
//
//Other possible definitions:
//#define NO_EWE_METHODS
//#define NO_JNI_METHODS
//#define NO_ENI_THREADS
//
// Keep the eni.h file along with this file.

#include "eni.h"
//########################################################################
/**

  Implement this function: CWWrapper.ppcExec()

**/
//===================================================================
void CWWrapper_ppcExec(object_access &obj,ObjectRef par1,ObjectRef par2)
//===================================================================
{

}
//..................................................................
extern "C" {
EWEEXPORT void EWECALL Eni_CWWrapper_ppcExec(ClassRef clazz,JValue * pars)
{
  ewe_object eo(Eni);
  CWWrapper_ppcExec(eo.setClass(clazz),pars[0].l,pars[1].l);
}
#ifndef NO_JNI_METHODS
JNIEXPORT void JNICALL Java_CWWrapper_ppcExec(void *Jni,ClassRef clazz,ObjectRef par1,ObjectRef par2)
{
  java_object jo(Jni);
  CWWrapper_ppcExec(jo.setClass(clazz),par1,par2);
}
#endif //NO_JNI_METHODS
} //extern "C"
//..................................................................

was fehlt dann noch?

Gruß,
Pfeffer.

 

[Silas]

Vielen Dank, dann probier ich mal, das auszufüllen, zu kompilieren und aufzurufen.

Bei mir wollte es auch nicht ohne utils davor. Gleiche Fehlermeldung (inkl. "utils" im Fehlertext). Aber vielleicht habe ichs einfach nicht richtig bedient...

Ich bin theoretisch auch per Jabber ([email protected]) und ICQ (923778752) zu erreichen, aber nicht immer online.

Grüße, Silas

 

[Silas]

Schlechte Nachrichten: Ich glaube das ist eine Sackgasse. Mit CeGCC lässt sich das leider nicht kompilieren, tausende Fehler in eni.h Mit gcc für Linux klappts dagegen einwandfrei. Also bräuchte man wahrscheinlich auch hier VC++/eVC++, um das für WinCE zu kompilieren, aber damit könnten wir dann wohl auch gleich ewe fixen...

Jemand noch ne Idee?

Grüße, Silas

 

[Harry1999]

<--------EWE-Sourcecode:
The various WindowsCE versions are built using eMbedded Visual C++ 3.0 and 4.0. The workspace for projects produced with version 3.0 are located in the directory vm/ProjectFiles/eVC-Mobile and the workspace for version 4.0 is in vm/ProjectFiles/eVC4-Mobile.
-------->
<--------
eMbedded Visual C++ 4.0
Brief Description
The Microsoft® eMbedded Visual C++ 4.0 tool delivers a complete desktop development environment for creating applications and system components for Windows® CE .NET-powered devices.
Licence: Free to try
Use the following CD key when installing this software: ****** steht auf der WEB-Seite von Microsoft: http://www.download.com/Microsoft-eMbedded-Visual-C-/3000-2212_4-10108490.html
-------->

hmmm ich hab ne MSDN-Lizenz und könnte Visual-Studio Sachen kompilieren und das Ergebnis Mitcrosoft-Lizenzfrei nutzen, verkaufen, Open Source draus machen, sofern mir einer sagt, was wie wo wann...bin halt kein Programmierer.
Grüße, Harry1999

 

[Silas]

Ja, eVC++ ist mittlerweile kostenlos zu haben. Um ewe zu kompilieren braucht man aber auch noch VC++ und ich glaube, das ist nachwievor zu bezahlen. Aber ich hoffe, ich komme am WE oder so mal dazu ne VM mit Windows -- drückt meiner alten Hardware die Daumen! -- aufzusetzen, um darin dann mit eVC++ an dem ENI-Wrapper weiterzumachen.

Grüße, Silas

Edit: Ist bei deiner MSDN Lizenz auch Visual C++ 6 bei? Falls ja, hättest du theoretisch alles, um ewe für Win32 und WinCE zu kompilieren, aber ich glaube, das ist nicht soooo unkompliziert. Falls du möchtest, kannst du dir den Quelltext ja mal runterladen und schauen, ob du aus der enthaltenen Anleitung im HTML-Format schlau wirst.

 

[Harry1999]

das ist ein Ausschnitt aus dem Sourcecode und dessen HTML den ich runtergeladen habe... und daraus habe ich ja geschlossen, dass nur für die Windows XP, Vista etc. Variante VC++6 benötigt wird und für die CE-Varianten eben die beiden anderen.
Wenn es ein reines VC++6 Project wäre, dann könnte man einfach auf einer vorhandenen Datei doppelklicken, einmal auf run klicken und viola... aber soeinfach ist das hier nicht. Ich finde keine Projectdatei...

 

[Silas]

Stimmt, ich habs mir auch noch mal durchgelesen, für die CE-Version sollte eVS++ reichen, die Projektdateien sollen unter vm/ProjectFiles/eVC4-Mobile liegen.

Generell ist aber wohl wirklich bisschen mehr zu tun, als wo doppelzuklicken, hier die Anleitung in Kurzform:

Building the release VM involves the following steps:

   1. Compile the Ewe class library as necessary. The library is in the vm_classes directory.
   2. Use Jewel to create the ewe.ewe file for that platform. The EweConfig.ewe file is already provided for you and should not be changed.
   3. Build the MakePool utility for the Windows desktop.
   4. Use MakePool to convert ewe.ewe into a Class Pooled version (explained below).
   5. Build the executable that optionally will link with the Class Pooled ewe.ewe and EweConfig.ewe.


Steps 3 and 4 are optional and can be skipped if you are in the process of modifying or debugging the VM. However it is recommended that you do them for final production versions of the VM. These two steps involve “Class Pooling” – which will be explained in a later section.

Ich werd mal schauen, dass ich mir ne Win-VM aufsetze und dann meld ich mich nochmal.

Gruß, Silas