Noob
bezeichnet einen Neuling meist bei Online-Spielen, der als lernunwillig erscheint (Wikipedia)
http://www.naviboard.de/vb/showthread.php?t=39743
Da ich ungeachtet des Verhaltens von extremcarver seine Arbeit schätze und es für Noobs nicht so einfach ist die Maps zu installieren eröffne ich diesen Post.
Inhalt sollen Installationsprobleme in den verschiedenen Betriebssystemen und deren Lösungen sein.
Gruss Oeschi
Nachdem ich die Zeile nach der Anweisung von openmetbmap für x64 Systeme (if not errorlevel 1 goto key_ok set KEY=HKLM\SOFTWARE\Garmin\Mapsource) mit dem Editor entfernt hatte, funktionierte die Installation der openmtbmap und ich konnte in der MS 6.13.6 (Parallelinstallation) die Karten öffnen, jedoch in der MS 6.15.7 bekam ich einen Runtime Error. Ich sehe derzeit meinen Fehler nicht. Könnte mir da bitte wer weiterhelfen?
Gruß Oeschi
hallo oeschi,
nachdem extremecarver sich inzwischen mit Mapsource 6.15.7 "anfreundet" gibt es vielleicht (hoffentlich 
) bald eine GMAP-Version.
Damit wären alle Installations-Probleme Firnschnee von gestern . . .
Grüsse - Anton
PS: als work-around kannst du dir die GMAP-Installation von einer auf WindowsXP funktionierenden IMG-Version selbermachen.
ausgeschlossen dass nicht andere Karten oder verweiste Eintraege am Runtime error Schuld sind?
als work-around kannst du dir die GMAP-Installation von einer auf WindowsXP funktionierenden IMG-Version selbermachen.
Danke das probier ich aus
Nachdem ich die Zeile nach der Anweisung von openmetbmap für x64 Systeme (if not errorlevel 1 goto key_ok set KEY=HKLM\SOFTWARE\Garmin\Mapsource) mit dem Editor entfernt hatte, funktionierte die Installation der openmtbmap und ich konnte in der MS 6.13.6 (Parallelinstallation) die Karten öffnen, jedoch in der MS 6.15.7 bekam ich einen Runtime Error. Ich sehe derzeit meinen Fehler nicht. Könnte mir da bitte wer weiterhelfen?
Gruß Oeschi
Es ist leider so, daß die bat-files von extremecarver nicht wirklich das Betriebssystem analysieren, sondern einfach in der Registry nach dem Wow6432Node schauen. Falls vorhanden, dann sollte es ein 64 bit OS sein. Was aber nicht stimmen muß. Um endlich das Gefummel mit batfiles zu beenden, habe ich img2ms weiterentwickelt, so daß die aktuelle IMG2MS2-32/64 Version automatisch analysiert, ob Mapsource als 32 Bit auf einer 64 er Machine läuft. Sollte es zukünftig mal native 64 Bit-Mapsource geben, so wir das damit auch richtig funktionieren. Und dann die Registry entsprechend schreibt. Weiterhin können eventuell vorhandene idx und _mdr.img Files registriert werden. Typfiles waren ja schon lange zu registrieren möglich. Speziell die openmtb-Map bringt ja solche idx und _mdr.img -Files mit.
Mit dieser img2ms2-32/64 Version können also die openmtb Maps, wie alle anderen osm -Maps unabhängig von Betriebssystemversion und bat-Files in Mapsource eingebunden werden. Eine Vorabversion ist unter http://www.img2ms.de/IMG2MSDemo2-32-64.zip downloadbar. Es ist nur das exe-File und keine komplette Installation; die kommt später. Zur Verwendung sollte man das IMG2MSDemo2-32-64.zip File in den Ordner einer vorhandenen IMG2MS-Installation entpacken. Die enthaltene Laufzeit_verlängern.exe ausführen und dann IMG2MSDemo2-32-64.exe verwenden. Es können mit der eingebauten Funktion 'Mapsource6.14.1-compatibility# auch Registryfehler in 64 Bit OS bereinigt werden.
Zur Einbindung der openmtb-Maps dann oben links die Variante 'tdb+preview schon vorhanden' auswählen.
Rückmeldungen, Bugs usw.sind sehr erwünscht.
Dies Vorabversio0n setzt noch voraus, daß Mapsource unter C:\Garmin\ installiert ist. In der Endversion kann Mapsource beliebig gespeichert sein.
morgen1
ich hab das seit dem Update vom 1.11 geaendert, und checke nun vorab ob %windir%/sysWow64/cmd.exe vorhanden ist, wenn ja geh ich von x64 aus. Ich nehm nicht an dass irgendein x32 User sich diese Datei anlegt im %windir% (und sollte jemand dies machen, kennt er sich hoffentlich gut genug aus - wobei ich nicht wuesste wozu). Damit funktioniert es auch, bei Kartenerstinstallation auf x64 Systemen.
Was wuerde eigentlich passieren wenn man immer beide Registry Eintraege anlegt? Sollte prinzipiell nicht stoeren, oder (außer das gmaptool erzeugte batches generell auf soetwas angepasst werden muessten)?
Dein Verfahren ist logisch nicht sauber, weil: Den Schlüssel Wow6432Node gibt es nur für 32 Bit Programme die in einer 64er Machine laufen. Sollte es aber ein natives 64 er Programm auf einer 64 er Machine sein, so heißt der Schlüssel wieder HKLM_LOCAL_MACHINE\Software\Garmin\Mapsource.. also ohne den \Wow6432Node\-Knoten. Sauber ist nur, wenn man prüft, ob das Zielprogramm (in unserem Fall MapSource) als 32bit unter 64 Bit Machine läuft. Das Vorhandensein der %windir%/sysWow64/cmd.exe ist lediglich ein starkes Indiz, aber keine Gewissheit. Sprichwort: "Dummheit kennt keine Grenzen". Damit meine ich nicht etwa Dich, sondern gewisse User. Es ist unglaublich, was ich schon für verbogene Computer zu sehen bekam.Da fragte ich mich oftmals ,wie kann man so was nur machen und bekann die naivsten Antworten.
Zum testen der Vorabversion img2msDemo2-32-64 habe ich Deine mtb-Sachsen verwendet. Funktionierte wunderbar. Ich habe bei den Auswahldialogen Voreinstellungen benutzt, die nach der Wahl des TDB-files schon die anderen Files anzeigen. Auch die sonst meist hinter Nummern vesrsteckte Preview. Damit sollte es leicht zu bedienen sein.
morgen1
Jip, ich weiß schon das dies zurzeit so ist. Die Wahrscheinlichkeit fuer die Bloedheit eine x64 Ordnerstruktur ins aktive %windir% zu packen, duerfte aber nicht so groß sein, und wer dies absichtlich macht (was weiß ich wofuer) - sollte sich eh gut genug auskennen, wer es unabsichtlich macht weil er glaubt dass er damit Probleme loesen koennte/etwas kompatible machen, der sollte am besten wohl eh seinen PC neuinstallieren....
Wie kann man denn schlauer mit cmd.exe ueberpruefen ob x64 oder x86 verwendet wird? Der Ort an dem Mapsource.exe liegt ist ja komplett egal, muss ja schließlich nicht installiert werden! (sondern eben stattdessen nur die Karten in der Registry registriert werden). Darauf zu pruefen ob Wow6432 in der Registry angelegt ist (generell nicht Mapsource) halte ich fuer fehleranfaelliger. Und zu pruefen ob das Standardmaeßige cmd.exe x64 ist oder nicht ist noch anfaelliger, da viele Systemoptimierprogramme hier rumpfuschen und es schon zig Leute gibt bei denen auf x64 windows cmd.exe Standardmaeßig als 32 bit (eben vom folder /sysWow64 aufgerufen wird).
Ich mache das so: ich starte Mapsource und hole mir ein Handle auf die taskId. Im kernel32.dll ist dann eine Function eingebaut , die True zurückgibt, wenn es ein 32er anwendung auf 64er Machine ist. Andernfalls gibt die Function false zurück. das werte ich aus. Das wird nur einmal beim 1.Start gemacht und dann in der Registry gemerkt.Im code steht schon der Text für die Endversion, wo Mapsource irgendwo gespeichert sein kann.
' Gibt an, ob die Anwendung auf Windows 64bit unter WOW64 ausgeführt wird.
Public Property Get Is64BitOS() As Boolean
Dim FS As New FileSystemObject
Dim vPfadMS As String
Dim hMod As Long
Dim lIsWow64Process As Long
hMod = LoadLibrary("kernel32.dll")
Dim hTask
Dim nTaskID As Long
Dim nHandle As Long
Dim lResult As Long
If FS.FileExists("C:\Garmin\MapSource.exe") = True Then
nTaskID = Shell("C:\Garmin\Mapsource.exe", vbHide)
Else
33: MsgBox ImgToolDemoTDB.Satz61
vPfadMS = BrowseForFolder(Me.hwnd, "Folder with MapSource.exe")
If FS.FileExists(vPfadMS & "\MapSource.exe") = True Then
nTaskID = Shell(vPfadMS & "\MapSource.exe")
Else: MsgBox "Wrong Folder"
GoTo 33
End If
End If
nHandle = OpenProcess(SYNCHRONIZE, False, nTaskID)
If CBool(GetProcAddress(hMod, "IsWow64Process")) Then
If CBool(IsWow64Process(nHandle, lIsWow64Process)) Then 'GetCurrentProcess()
Is64BitOS = CBool(lIsWow64Process)
End If
Select Case Is64BitOS
Case True
fStringSpeichern HKEY_CURRENT_USER, "Software\IMG2MS", "Wow64", "wahr"
Case False
fStringSpeichern HKEY_CURRENT_USER, "Software\IMG2MS", "Wow64", "falsch"
End Select
End If
FreeLibrary hMod
hTask = OpenProcess(PROCESS_TERMINATE, 0&, nTaskID)
lResult = TerminateProcess(hTask, 1&)
lResult = CloseHandle(hTask)
Call CloseHandle(nHandle)
End PropertyNachtrag:
falls du zukünftig gmap Versionen erzeugst und bereitstellst, bist Du allen Ärger los. Nur die altmodischen MS6.13-user werden ins leere schauen.
morgen1
Hi,
ich habe kein 64bit Windows laufen... Was sagt denn der Batchbefehl: "Ver"
unter den 64bittern an?
z.B.:
Bei Windows XP 32bit: Microsoft Windows XP [Version 5.1.2600]
bei Windows 7 32bit: Microsoft Windows [Version 6.1.7100]
Vielleicht lässt sich daran das Betriebssystem klassifizieren.
Das Problem 32 oder 64 Bit zu erkennen, hat Microsoft nicht einfach gemacht. Falls du die 'Windows'-Taste + 'Pause' drückst, bekommst Du viele Informationen zu der OS Version, nur keine Angabe zu 32 /64 Bit. Ich habe z.B. auf meinem PC einen 64 Bit AthlonProzessor , aber 32 Bit XP laufen. der Athlon kann das von Natur aus. Bei Intel Titanum bin ich mir nicht sicher. Ich habe noch keinen anderen sicheren Weg gefunden an Hand der Versionsangabe (W 7 ist Version 6.1, genauso wie Server 2008R2) auf die Bit zu schließen. Wenn es einfacher geht, so sagt es mir bitte. Im MSDN-Developer network steht in den Dokumentationen zu den einzelnen Funktionen der DLL's z.B natives betriebssytem lakonisch dahinter sinngemäß "...dies ist keine sichere Methode die bit zu bestimmen. " Aber nirgend unter www.msdn.com habe ich die Beschreibung einer konkreten Methode gefunden. Mein Code geht in weiten Teilen auf einen gewissen Dörfler zurück. Die Methode ist eineindeutig.
morgen1
Hmm, und was passiert wenn Mapsource erst gar nicht installiert ist? (es gibt viele Leute die erst nach der Installation meiner Karten draufkommen, dass sie die Karten erst mit Mapsource oder anderen Progs benutzen koennen).
Gmap Versionen finde ich SCHROTT.
1. groeßerer Speicherbedarf
2. Sind fuer Noobs nicht beliebig am PC platzierbar
3. Brauchen zum erstellen fuers ans GPS etwa die 4 fache Zeit - da sie eben in .img umgewandelt werden muessen vor dem senden.
4. ist ein zusaetzlicher Schritt fuer mich
5. Arbeite ich und empfehle ich 6.13.6 zu benutzen...
6. schlechter komprimierbar = groeßere Downloads (.img komprimiert zu 64-66% mit 7zip.).
Die leichtere Installierbarkeit koennte auch bei .img von Mapsource identisch gehandhabt werden (es muesste einfach beim ersten Start einer Karte gescannt werden - welches .img die basemap ist)...
Hi,
das einfachste wäre doch, daß nur die gmapsupp.img auf den Rechner
kopiert wird. Eine entsprechend angepasste MapSource-Version könnte dann
daraus ebenso die benötigten Kacheln und Indexdaten extrahieren und auf die
Geräte übertragen.
Das sieht man alleine schon daran, daß (zumindest in den Geräten der etrex
und 60er-Reihen) die Kachelgrenzen angezeigt werden. Somit sollte jede
Software in der Lage sein mit einer kompletten Datei umzugehen.
gmaptool macht es vor, auch wenn die Umsetzung zur Zeit leider noch immer
nicht ganz Fehlerfrei ist.
In einer entsprechend angepassten MapSource-Version würde man dann die
Karten über ein ganz normales Datei-Menü öffnen. Damit wäre dann der Ort
der Installation vollkommen frei wählbar.
- jip, da hast du eindeutig Recht.
Nur ist es halt so, dass so Daten wie Lane_Assist oder 3d_Buildings .... dann fuer alle Geraete mit ins gmapsupp.img muessten, oder sind die sowieso außerhalb der gmapsupp.img? Ausserdem muesste man dann fuer alle Karten Autorouting inkludieren - wobei dies ja schon bei fertig gekauften SD Karten der Fall ist (hier werden wenige mit gmaptool unbenutzte Daten rausextrahieren)...
Die Sinnvollste Variante waere es auf jeden Fall (aber wohl einiges an Aufwand - etwa umschreiben der Adresssuche, die ja reversiert wird von Mapsource...
3D-Buildings sind in einer extra Datei (gmap3d.img).
Zitat...Lane_Assist oder 3d_Buildings...
Im Grunde genommen wären das alles Aufgaben, die die fiktive MapSource-
Version erledigen müsste. Das Gerät zu erkennen auf das die Daten
übertragen werden sollen, erledigen einige Updater für spezielle
Kartenprodukte (Aviation..) sowieso schon jetzt. Alles andere (Routingdaten,
3D-Gebäude usw.) läge per Parameter in der Hand des Nutzers.
Die Daten sind ja auch so schon alle auf der Festplatte, ob ich sie für mein
Gerät nutzen kann oder nicht. Insofern wäre eine Datei für alles eine schöne
Lösung. In einem weiteren Dialog ließen sich dann z.B. auch für ein und
dieselbe Karte unterschiedliche TPY-Dateien auswählen, damit der User auch
dort mit unterschiedlichen Designs arbeiten könnte.
moin,
mit Interesse verfolge ich die Expertendiskussion. Vorab auch mir gelingt es jetzt die obenmtbmap zu installieren und Mapsource läuft mit den Maps in beiden Versionen , wenn ich jedoch die Höhenlinien im 2ten Step einbinden möchte bekomme ich wieder den Runtime Error.
Defender deaktiviert
UAC deaktiviert
Zeilen wie vorgeschrieben aus install.bat entfernt
Regedit auf Programmlaichen gesichtet (nichts gefunden)
install.bat als admin ausgeführt
Gruß Oeschi
Der Installationsvorgang im 2ten Step läßt sich auch ohne Fehlermeldungen durchführen, erst beim Start von MS kommt der Fehler.
Gmap Versionen finde ich SCHROTT.
hallo extremecarver,
IMHO hast du dich hier in alten Technologien verhakt . . .
Die Entwicklung hat dich bereits überholt (so wie die Neandertaler).
Mit meinem Mac und meinem Dakota20 brauche ich das ganze Registry-Gedöns nicht :p
Dafür habe ich zusätzlich zu meinen Vektorkarten in GMAP-Installation die 25k-Topo als Rasterkarte - für Wanderer ein Traum
Grüsse - Anton