Installer script... again

[-Oz-]

The installer alraedy needs admin rights since it has to change the registry so putting files in those locations shouldn't be a problem.  My question is how does basecamp know to open the .gmapi files?

[Boyd]

The .gmapi file is actually a directory and not a single file. It is not used on Windows at all. If you copy the .gmapi file to a Macintosh, it does appear as a file and not a directory however, but it's a "package". Double-clicking it on the Mac will simply cause the enclosed .gmap folder hierarchy to be copied to the Basecamp map directory.

Now, on Windows, you need to first open the .gmapi folder and remove the enclosed .gmap folder. As explained earlier, you simply place this folder hierarchy in the designated Mapsource/Basecamp directory (C:\ProgramData\GARMIN\Maps). Both Mapsource and Basecamp know how to read this format. And that's the beauty of it IMO, it is completely self-contained with everything needed to use the map in either Basecamp or Mapsource. If you look inside, you will see that the custom type file (if any) is also included.

So, in other words, it behaves more like I would expect modern software. Mapsource and Basecamp read the files in the .gmap folder and display the enclosed map. If you delete that folder, the map will be gone. The registry is not used for any of this.

I've attached a small (2.4MB) sample .gmap - it is zipped just for the purpose of attaching it to this post. Unzip it and copy it to C:\ProgramData\GARMIN\Maps. The map covers 4 USGS Quads roughly centered on Central Park in New York City. It should appear in both Mapsource and Basecamp as gmap-test.

The install directory location might be different on Windows XP, but it should be C:\ProgramData\GARMIN\Maps on Windows Vista and Windows 7. Looking briefly at the NSIS docs, I think you could select the correct directory like this

Code: [Select]

SetShellVarContext all
 InstallDir "${APPDATA}\GARMIN\Maps\${MAP_SHORT_NAME}"

[Boyd]

Maybe a picture will be worth a thousand words? 



This is the contents of the Info.xml file. Note that 62351 is the FID that I assigned to the original source map using MapsetToolkit. The source map contained the following files that are now represented by folders in the .gmap format: 20120100.img, 20120101.img, 20120117.img, 20120118.img. There's also a custom type file associated with this mapset: 201200.typ

Code: [Select]

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
- <MapProduct xmlns="http://www.garmin.com/xmlschemas/MapProduct/v1">
  <Name>gmap-test</Name>
  <DataVersion>100</DataVersion>
  <DataFormat>Original</DataFormat>
  <ID>62351</ID>
  <TYP>201200.typ</TYP>
- <SubProduct>
  <Name>gmap-test</Name>
  <ID>1</ID>
  <BaseMap>gmap-test</BaseMap>
  <TDB>gmap-test.tdb</TDB>
  <Directory>Product1</Directory>
  </SubProduct>
  </MapProduct>
Finally, this is what the installed maps look like under Windows. Note that City Navigator also uses the .gmap format. The old-style registry-based maps are not stored in the same place.

[-Oz-]

I'll try out the gmapi plan but here is the old installer script.  I'm clearing my 64 bit desktop right now to try out different installers.

[-Oz-]

Okay, the .gmap thing is pretty cool.  I'm going to work on a NSIS script for that and see how that goes.  In win7 the correct directory can be found by just doing %programdata%\garmin\maps

EDIT: this is going to be pretty hard.  I can't find a variable for %programdata% is NSIS, appdata is the wrong directory

[Boyd]

Did you try the command SetShellVarContext all?

I haven't gotten to this yet, but the NSIS docs say

$APPDATA

The application data directory. Detection of the current user path requires Internet Explorer 4 and above. Detection of the all users path requires Internet Explorer 5 and above. The context of this constant (All Users or Current user) depends on the SetShellVarContext setting. The default is the current user.

This constant is not available on Windows 95 with Internet Explorer 4 and Active Desktop not installed.

I have looked on my Vista and Win 7 machines and they both use C:\ProgramData\GARMIN\Maps. I have XP installed on my Mac but haven't fired that up yet to check. Maybe it uses the same location? If not, then maybe a brute force approach would work by setting the variable based on the version of the OS that NSIS detects?

[edit]Just fired up XP under Parallels on my Mac. The correct location under XP appears to be:

C:\Documents and Settings\All Users\Application Data\GARMIN\Maps

C:\Documents and Settings\All Users\Application Data is also the value of the environment variable ALLUSERSPROFILE if you type SET into a command prompt. On unix I would understand how to use this, but not DOS/Windows. Can NSIS access the Windows environment variable somehow?

[-Oz-]

I think I got it...  I have it picking the right directory (at least on win7 but I think it'll work on XP too).  Now I just have to make it read all the directories and install them rather than just the .img files.

Still definitely a learning process but the new script is a lot more lean without all the reg entries.

And yes, NSIS accesses the windows environment variables you just have to make sure its using all users rather than current user to get the right directory.

[Boyd]

That's great, thanks for looking into this. I started on it myself, but with such a limited understanding of NSIS it would take me awhile.

The new gmap format won't work with very old versions of Mapsource or for people who want to use nRoute. But there's a little program called MapReverseConverter that will take the gmap files and convert them back into the registry-based format. That should address any concerns about making the new format compatible with older software.

[-Oz-]

Do we know how old of a version it won't work on so we can post that?  I have to assume that at some point Garmin will get rid of the registry thing as it already has done with the new City Navigator.

I've attached my first try at the NSIS installer script for this.  Obviously it has a lot of customization for icons, side images, etc but if you just comment out lines you don't use I would really be pretty happy if you could test it out with one of your maps and perhaps even on windows xp (I had to use an if statement to get the proper directory).  If you can't test it out I'll break out my old xp laptop tomorrow.

See attached.

EDIT: One problem is that it knows if a previous version is installed (old registry way) but it doesn't properly uninstall it.  Although this doesn't appear to break anything it will definitely cause weird behavior. I'll have to think of a way to do a series of if statements to see if a .reg map is installed and then use its uninstall file (or something like that). (see next post for fix)

[-Oz-]

Attached is a new version that will actually uninstall maps that have already been installed as long as the {short_name} is the same.  So since I always called my map Arizona Topo it will uninstall the .reg version and install the new version.

[Boyd]

I just tried your first version. Works fine under Vista. But there's a problem on XP. It places the map in

C:\Documents and Settings\All Users\Application Data\Application Data\GARMIN

Note the second "application data" directory, which it looks like you are creating when you append it to $APPDATA

Regarding Mapsource compatibility, I'm not sure and I don't see it noted in the Mapsource changelogs. My *guess* is that the change came in version 6.14.1. I know that many die-hards have rolled back to the previous version - 6.13.7 because it renders maps in the "classic" style.

Changes made from version 6.13.7 to 6.14.1:
Updated map rendering to provide visual improvements.
Added support for U.S. National and Swedish SWREF99 grids.
Fixed issue with setting the PC clock on Vista.
Allowed user specified colors for routes.
Added Brazilian Portuguese translation.
Improved interface for managing map products and unlock codes.

[-Oz-]

Can you try out this version for winxp; this actually made it easier.

[Boyd]

The new version works fine for me on Vista 64 and Windows XP.    The ability to remove a previous registry-based map is a great feature.

I see that you're creating a registry entry for gmap files as well, which I assume is so that they can be uninstalled with the Programs and Features control panel? Garmin doesn't do this with their own maps anymore. I can uninstall US Topo 2008, but not City Navigator.

I had already deleted my test map data when I ran this new installer, but I got the dialog saying the map was still installed because of the registry entry. Wasn't a problem, it said it was removing the old copy, then installed the new one. I'm just wondering if we really need an uninstaller for maps that were created in the new format?

Anyway - very nice job!

[-Oz-]

If there isn't an uninstaller how would people clear up hard drive space?  You are correct the registry entries are for the windows installed/uninstalled programs list.

So, between the 32 bit version and the gmap version we should be able to solve all the installer issues.  I think I'll start converting my maps today.

[maps4gps]

Boyd,
 
    I think I follow what you are saying/doing.  What I am still unclear on is will two versions of a mapset still have to be uploaded (one for the PC and one for the MAC)? 

    If I follow correctly, mapsets have to go in a specific folder; currently users with little space on their c: drive can install them to a d: drive or and external drive - they could copy and paste them to and from the specified location to another location.

OZ,

    The final file MapConverter makes is a .tgz file.  This file can be as much as 30% smaller than the total of the .img files (as can also be the .exe file in the Windows .exe installer).  Will the package distributed by this method also be smaller?  And will one format be able to be used on both the PC and MAC?