Support Navigon MN 7.7.5 Build 447 in navigon 2110(ohne max)

[tommy_gun]

Hi tischler3 kannst du mir eine originale MN6.5.2 hardwarelayer.dll zukommen lassen? Dann kann ich mir das mal anschauen (Was ist ein Profi?)

 

[Siki78]

@tommy gun
bitte schön

 

[Underground]

Ich habe noch eine MN6.5.1 wenn sie gebraucht wird.

 

[Siki78]

noch einmall test
Da ist erste unterschide was ich sehe
SetBrightness@@YA_NII@Z in orginall
SetBrightness@@YA_NI@Z in mn7.7.5

 

[tischler3]

nein leider auch nicht, genau das gleiche wie die davor.

 

[tischler3]

hier mal eine von MN 6.5.2.
mir ist aufgefallen das die schreibweise unterschiedlich ist.
HardwareLayer.dll = MN 6.5.2.
Hardwarelayer.dll = MN 7.7.5.

@tommy gun
ich weiß nur das ich kein profi bin, naja die leute von navigon hätten das sicher schnell erledigt:emoticon-0105-wink:

 

[Siki78]

noch mall:emoticon-0179-headb

 

[MiniMe]

Groß- u. Kleinschreibung in Dateinamen spielen keine Rolle. Es ist schließlich ein Windows (CE) System. Ansonsten: Weiter so, ich liebe Euch!

 

[TomKeller]

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

Das ist unerheblich. SetBrightness@@YA_NI@Z ist der Name der Export-Funktion in der MN7 Hardwarelayer.dll und er findet sich auch als Import-Funktion namens SetBrightness@@YA_NI@Z in der MN7 Navigon.exe wieder. Nur DAS ist wichtig: entsprechend dem Schlüssel/Schloss-Prinzip muss der Funktionsname in der EXE und der zugehörigen DLL identisch sein! Benennt man ihn in einer der beiden Dateien um, wird sich MN7 beim Aufruf der Funktion darüber beschweren, dass sie nicht in der DLL existiert (und halt crashen).

Dass die Funktion in der MN6 Hardwarelayer.dll SetBrightness@@YA_NII@Z hieß, ist dementsprechend weder wichtig, noch hilfreich. Denn auch in der MN6.exe findet sie sich als SetBrightness@@YA_NII@Z wieder -> EXE und DLL passen zusammen (wäre ja auch komisch, wenn nicht).

Kurz: man könnte die Funktion auch in ALLEN DLLs mal eben HubbaBubba nennen - solange man sie in den EXE-Dateien ebenfalls zu HubbaBubba ändert, macht es keinen Unterschied :emoticon-0105-wink: . Denn die Navigon.exe bzw. MN6.exe sucht dann halt nach einer Funktion namens HubbaBubba in der Hardwarelayer.dll - und solange die vorhanden ist, ist sie zufrieden. Im Grunde genommen ist das nur so, als ob du in einem Buch die Kapitelüberschrift über dem Kapitel selbst und im Inhaltsverzeichnis änderst => das hat auch keinen Einfluss auf den Inhalt des Kapitels.

Fazit: mal eben mit 'nem Hex-Editor im Export-Bereich der Hardwarelayer.dll rum zu editieren bringt nichts. Meist (wenn man ohne Rücksicht bzw. Hintergrundwissen vorgeht) zerstört man dadurch sogar die Dateiintegrität und macht die DLL unbrauchbar. Die DLL enthält nämlich auch Angaben darüber, in welchem Adressbereich die einzelnen Funktionsnamen zu finden sind... und in welchem Adressbereich die Funktionen selbst zu finden sind. Ersetzt man also einen Funktionsnamen mit einer längeren Bezeichnung und verschiebt dabei mal eben alle folgenden Funktionsnamen, stimmen alle nachfolgenden Adressen nicht mehr und die DLL-Datei wird ungültig.

Am besten nimmt man sich mal ein simples Tool wie den CFF-Explorer (einfach googlen - ist Freeware) und wirft damit einen Blick in EXE und DLL. Wenn ich z.B. damit in die letzte hier verlinkte Hardwarelayer.dll rein sehe, merke ich, dass die scheinbar zerstört ist (keine der Import/Export-Funktionen werden gefunden):

Bei der vorherigen Hardwarelayer.dll wurden hingegen "nur" drei Exportfunktionsnamen zu 1½ unbrauchbaren Bezeichnungen verwurstet:

Und nur um das klar zu sagen: ich hab eigentlich auch keinen Schimmer von der Materie. Jemand mit richtig Ahnung lacht mich also mit Sicherheit aus. Aber es bringt halt nunmal nicht viel, wenn sich jemand hieran versucht, der sich noch weniger damit beschäftigt hat als ich :emoticon-0106-cryin .

 

[tommy_gun]

Per Reverse-Engineering sollte man aber an die Funktionen rankommen.
Die Frage ist nur in welcher Sprache die Funktionen mal geschrieben wurden und mit was die dll kompiliert wurde. :good:

 

[TomKeller]

Sprich: wir brauchen einen Spezi mit Wissen und Erfahrung auf diesem Gebiet:laie_14:! Ich hatte ja mit meinem peinlichen Laien-Wissen auch schon einiges versucht: über die "Function RVA" (RVA = Relative Virtual Address) kann man ja den Bereich in der DLL finden, der die Funktion enthält. Nur versteht meinereiner (logischerweise) halt nicht, was da geschieht. Ich kann dann zwar diesen Bereich gegen sein Pendant aus der MN 6.5.2 DLL austauschen - doch als Ergebnis crasht dann halt MN7 beim Versuch die Helligkeit zu verstellen mit einer Fehlermeldung, anstatt einzufrieren. Die Funktionsaufrufe der MN 6.5.2 DLL gegen die der MN7 DLL aus zu tauschen, um dann die MN 6.5.2 DLL mit MN7 zu verwenden, geht auch nicht - denn nicht nur die Funktionsnamen unterscheiden sich... es sind auch viele notwendige Funktionen hinzu gekommen, die es in der MN 6.5.2 DLL gar nicht gab (die aber zum Starten von MN7 notwendig sind - z.B. die Überprüfung der CPU).

Eventuell wäre es auch einfacher machbar, nur die beiden Brightness-Funktionsaufrufe der Navigon.exe auf die alte MN 6.5.2 Hardwarelayer.dll um zu leiten?! Dafür müsste man dann aber in der Navigon.exe rum pfuschen... oder man benennt die MN7 Hardwarelayer.dll in HL.dll um, gibt der MN 6.5.2 Hardwarelayer.dll den Namen MN6.dll und baut dann eine Dummy-Hardwarelayer-DLL, die alle Funktionsaufrufe an die HL.dll weiter leitet... AUSSER Set- und GetBrightness, welche über die MN6.dll laufen müssten.

Ideen gäb's da viele - aber grundsätzlich ist nunmal einer mit genug Ahnung auf dem Gebiet notwendig .

 

[master3101]

aber mal nicht zuvergessen die HWL aus der 7.4.3 ging ja auch zum einstellen der Helligkeit oder die automatische tag und nacht umstellung

 

[TomKeller]

Nö, die ging mit Sicherheit auch nicht. Das Problem mit der funktionsuntüchtigen Helligkeitseinstellung existiert definitiv bei ALLEN MN7-Versionen auf Navigons 21x0 Geräten. Die original Hardwarelayer.dll aus der 7.4.3 sorgt auch für ein Einfrieren - nach unzähligen Tests diverser DLLs aus verschiedenen MN7-Versionen hat aber irgendjemand eine Hardwarelayer.dll gefunden (ich glaube: aus der PDA-Version von MN7!?!?), bei der das 21x0 nicht einfriert, sondern einfach nur nichts passiert, wenn die Helligkeit verstellt wird.

Das ist deshalb auch die Hardwarelayer.dll, welche man üblicherweise in den MN 7.4.x Komplettpaketen für's 21x0 findet - denn auch wenn die Helligkeitseinstellung damit ebenfalls nicht klappt, friert damit wenigstens das Navi nicht beim Umstellungsversuch ein. Leider funktioniert diese DLL aber nicht mit der 7.7.5... und eine passende alternative DLL scheint für die 7.7.5 auch nicht zu existieren.

 

[tischler3]

aber die automatische tag-nacht umstellung ging bei 7.4.3.:ja ich finde damit konnte man leben.

 

[TomKeller]

Als ich zuletzt die 7.7.5 ausprobiert hatte, ging die Tag/Nacht-Umschaltung auch dort. Man musste nur vorher in der UserSettings.xml den <BrightnessDay> und <BrightnessNight> Wert auf die selbe Zahl einstellen. Das Problem scheint nämlich einzig und allein zu sein: das Navi friert beim Umstellen der Helligkeit ein => sind für Tag- und Nacht-Modus verschiedene Helligkeitswerte vorgegeben, friert es logischerweise auch bei der Tag/Nacht-Umschaltung ein. Daher: identische Werte in die XML eintragen...