GPSFileDepot Forums

I'm getting ready to release a new map but got lost somewhere in the various threads about installer issues. Do we think that the current template file in mapmaking tutorial number 8 has resolved the various Windows 7 issues? http://www.gpsfiledepot.com/tools/map_install.zip

I guess the question is, "Is there any downside to using an old installer script?"

I always put off creating the install script as long as I can, because it takes awhile to wrap my brain around the concepts each time. I just started comparing the version in the link above to the old script I adapted before, and it's clearly much newer. My old script doesn't check for 32 bit vs 64 bit for example. But I was thinking of the many reports we've seen about Windows 7/64 where the maps don't appear in Mapsource.

The more I look at all the registry manipulation in the script, the more I want to try my hand writing a .gmap installer that uses Garmin's new format to avoid all these issues. I just don't know if I'm up to the challenge though. :)

If you mean the one in part 9 dated 7 Mar 2010, that is the one I download in March/May, 2011 and it has the issue.  I have not seen anything from OZ that the issue was corrected.

I'm going to look at this soon, after I read the NSIS documentation again. Seems like making an installer for the new registry-free format should be pretty straightforward, it should only involve copying files to the user's machine.

On my own machine, install everything with MSTK as usual, then use Garmin Mapconverter like I would to make a Mac version (which is needed anyway). The next part is a little muddy to me... I think I'd have to actually install the map on my Mac, then copy the installation directory tree back to my Windows machine. The NSIS script would just copy that directory tree to C:\Users\All Users\GARMIN\Maps on the user's machine.

Can't think of any downside to this approach, but maybe I'm missing something. :)

Just curious but is NSIS better than Inno Setup.  I use Inno Setup and to my knowledge no one has had installation issues. 

Bob

I can not answer which is 'better'.  OZ provided a templete for NSIS about 2 1/2 years ago so the rest of us could provide self-installing versions of the mapsets we were going to share with others.

Quote from: maps4gps on October 08, 2011, 08:40:50 AM
I can not answer which is 'better'.  OZ provided a templete for NSIS about 2 1/2 years ago so the rest of us could provide self-installing versions of the mapsets we were going to share with others.

I've been using variants of Oz's old Windows template, and haven't heard any complaints.   I was under the impression that Win7-64 handled the old 32 bit installers pretty well.  And MapSource and BaseCamp are both 32 bit apps aren't they?

Basecamp and MapSource are both 64-bit.  The latest script checks and modifies the registry entries according to 64-bit or 32-bit but recently something has been happening that stops the 64bit computers from seeing the maps in BaseCamp.  I would say that that is the only issue but I haven't been able to replicate it on my win7-64 thus far.

Do we know why installing jbensman's "myTrails" seems to fix this issue? What installer script is being used for that map?

'My trails' is using an older (pre-64bit) version of OZ's installer.  I also encountered this issue on my new 64bitWIN7 machine and had to use one of my pre-64bit installer mapsets.  Once this was done, the mapsets using the 64bit installer would work.

After the 1st 64bit mapset was installed, I uninstalled the 32bit installer mapset and continued to install 64bit installer mapsets without any issues.  It appears to be a first time issue.  I would guess all mapsets need to be removed from the computer and perhaps the registry 'cleaned' to duplicate the issue.

Hmm, so maybe I'm better off sticking with my existing install script that was based on Oz's old version?  ???

I do not recall anyone reporting a problem with the 32-bit installer mapsets on a 64-bit machine.  Unfortunately, I had to replace my computer (and it's replacement) shortly after making my State topo maps in May/June and may not have a copy of the older version; and woulld not have the time to recreate and reupload 38 State topo mapsets.

@Boyd: yes i would use the old one.

I remember people have issues with the 32bit installer which is why the 64bit was made.  I wonder what has changed but I'll have to do tests.

I'm looking at Garmin's .gmap format, and so far I can't see any downside to distributing maps in this form (other than, maybe, people with really old computers and old versions of mapsource). Here's how to create and install a .gmap version of your own existing mapset.

First, create your mapset as usual and install with MapsetToolkit. Now create the Mac version of your map using Garmin Mapconverter - this is something you would need to do anyway.

Let's say your mapset name (the one displayed in Mapsource) is "test". Garmin Mapconverter will create a file named test.gmapi. However, you will see that is actually a folder under windows and not a "file". Open the test.gmapi folder and you will see a folder inside named "test.gmap". THIS IS ALL YOU NEED!

If you're doing this on the same machine, you'll need to use MapsetToolkit to UNINSTALL "test" before proceeding, since it has the same FID as the new gmap version. After doing this, simply copy the test.gmap folder to C:\Users\All Users\GARMIN\Maps

You have now installed the map "test" in Mapsource and Basecamp. No registry entries are involved. You can confirm by starting Mapsource. To completely remove this map, just delete the "test.gmap" folder from C:\Users\All Users\GARMIN\Maps and it will be gone.

So an installer script for "test" just needs to do a few things -

1. Check for the existence of C:\Users\All Users\GARMIN\Maps (see note below for possible issues)

2. Create this folder if it doesn't exist

3. Copy the test.gmap directory heirarchy to C:\Users\All Users\GARMIN\Maps

4. Provide an uninstaller to remove test.gmap

I believe that different versions of windows might store the maps in different places - I need to look into this. Under Vista, I can access the same folder at C:\ProgramData\GARMIN\Maps. If I use a command prompt and type "set", I see

ALLUSERSPROFILE=C:\ProgramData

I believe this can be used to determine the correct location on different Windows versions, but not sure how to incorporate that into an install script.

I'm not clear on whether there are permissions issues, etc that need to be addressed when installing as well. I'm really not a "windows guy" so  I may need some help here. :)

What do you guys think?...   

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?

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

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

Maybe a picture will be worth a thousand words?  :)

(http://stephencreek.com/gpsfd/gmap01.png)

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

<?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.


(http://stephencreek.com/gpsfd/gmap02.png)

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.

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

Did you try the command SetShellVarContext all?

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

Quote$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?

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.

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.

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)

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.

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.

QuoteChanges 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.

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

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!

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.

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?

It hadn't occurred to me about people who want to install these on a different drive.  That definitely isn't possible with the new Garmin way.

As far as I can tell we will still need two files, a mac .gmapi and a windows .exe that is actually the contents of gmapi.  The .tgz is not any smaller than the .exe file because nsis compresses it.  With the new setup file I even force a better compression.

So the question is: is it worth it to start using the new script or just use the old 32-bit version which solves the basecamp issues 64bit users were having.

As far as I can tell:
PROS:
* Uses Garmin's new format
* Less messing with the registry
* Appears to have no family id conflicts (untested)
* Easy setup script

CONS:
* Doesn't work with nRoute or old MapSource
* Doesn't allow you to install to a different drive
* Solves no real problem (since 64 bit issue is solved with the old install script which I still had)

However perhaps at some point Garmin will stop supporting the registry method.

For my mapsets in the 100-200Mb range the .tgz is about 1 Mb smaller for somereason.
For CA & TX there is a 2 MB difference.

It would be very, very nice to only have to upload one version of a mapset.  It was very time consuming to upload 2 versions of 38 mapsets in May/June, especially when there is only about 1 MAC download per 8 PC downloads. 

When I first started making MAC versions, Indrid point out that the then current Mapconverter did not work and I should use the previous version.  Making a .tgz file is an option in that version.
I had DOS programs which handled .tgz and .tar files.  However, Microsoft decided that supporting older 8-bit programs in Windows 7 was not useful to most users and require purchasing a 'higher' level of Windows 7 which opens a XP window to run those programs. 

Garmin hasn't updated Mapconverter for a long time. It doesn't make .tgz files anymore, but it works fine on the Mac. The only issue that I recall is that the GPSFileDepot uploader won't accept .gmapi files, only .tgz and .dmg files.

I just did some Googling, and it turns out that making a .tgz file on Windows with 7-zip is trivially simple - who knew?  :) Assuming you have a folder named MyMap.gmapi that was created by Mapconverter, right-click, choose 7-zip > add to archive. In 7-zip, choose Tar in the Archive Format dropdown and hit OK. This creates a file named MyMap.gmapi.tar.

Now right-click the MyMap.gmapi.tar file and choose 7-zip > add to archive again. Choose GZip from the Archive Format dropdown this time. The default filename will be MyMap.gmapi.tar.zip, so just change this to MyMap.tgz and hit OK. This creates a .tgz file that works as expected on the Mac (I just tried it). I assume that you already have 7-zip? If not: http://www.7-zip.org/

I think the new .gmap format addresses a couple issues that we see in the forums all the time. It may be true that a small number of people want to store their maps in a special place, but it seems to just confuse most people. Since they choose a location for the map, they assume that they need to "open" the .img files in that folder. When that doesn't work, their next stop is usually the tutorial for adding .img files to MapsetToolkit and now they're really lost. We see posts about this every couple days. For most users, I think it would be better not to give them a choice of where to store the maps and just use Garmin's default location. If they want the maps somewhere else, let them ask that question in the forums.

Another issue that I have seen (less frequently though) is that people sometimes just delete the .img files if they want to remove the maps. With the registry based maps, this confuses mapsource and it gives you a message about improperly installed maps and then quits. With the .gmap format, the user can just delete the folder and the maps will be gone.

I think trouble-shooting would also be easier with .gmap. If a user doesn't see the map in Mapsource, the first question would be to ask him to look in the Maps folder to see if it was properly installed.

But regardless, I can see the value to both types of maps. I am going to publish my next map in this .gmap format myself and see how it goes. I really appreciate the work Oz has done here in creating the installer, since that would have taken a LOT of trial and error for me.  :)

I hear you and OZ on the new method and agree that the benifits outway staying with the older method.

Also some users cause problems by moving a mapset after it was installed - they may get the idea of being able to put a mapset anywhere when they see that option during install and do not realize the registry also needs to be changed.

I've updated a lot of my maps to the old installer script so they won't have the 64 bit issue.  My Florida Topo is using the new gmap install process so we'll see if I get any complaints.  I'm going to add some IF statements and then release the scripts on the actual website. I want to make it so if NSIS doesn't see the left side graphic or icons it won't "break".

Just tried the installer and it worked fine for me, uninstalled my old FL Topo and everything.
System is Win7-64 w/ 16GB RAM.  Is the new script ready for distribution?  If not, when can we expect it?  And will it support address search (Find Places in MapSource)?

Quote from: maps4gps on October 17, 2011, 05:10:03 PMAnd will one format be able to be used on both the PC and MAC?

Just realized that it should be very easy to create a universal download package. I believe it will only require one small change to Oz's script... don't have time to look now but will try to get to it tonight.

Instead of embedding the .gmapi file in the NISIS script, it would need to be accessed as an external file. So the universal download would be a zipped folder named for your map, such as MissouriTopo.zip. Inside the folder would be the .gmapi file, named MacInstall.gmapi and the NISIS script file named WinInstall.exe.

A Mac user would doubleclick MacInstall.gmapi which automatically launches Garmin Mapmanager and installs the map. A Windows user would double-click WinInstall.exe which would run the NSIS script, read the map from MacInstall.gmapi and install.

Thoughts?

I can understand using this process for most maps on this site.  However, from my understanding of what would be required, there is no way I would use it for any of my maps-particularly My Trails.  If you make the mapset once, no big deal, but if it is a mapset that is regulalry updated, it makes things way to hard.  While I update the installer for my trails about once a month, I update it several times a week on my computer.  So first I would have to create the imgs, use mapsettoolkit, use mapconverter, uninstal the first version, create the installer, uninstall the gmapi version, then reinstall the imgs.  To be able to constantly update My Trails, it has to be imgs.  If there was a way to directly create gmapi files, that would be one thing.  But I need to have my maps as imgs on my system. 

I don't see why this changes anything. You need to have a "classic" map installed on your own computer anyway (using Mapsettoolkit). So you would keep that as your working copy and make all your updates there. Then when you are ready to upload, you'd make the .gmapi version. And I don't think that really involves any extra work as long as you're making a Mac version, since you need to run Mapconverter for that anyway.

And the payoff would be you only need to do one upload because it would work on both platforms, so you cut your upload time in half and Oz only needs to store half as much data on his servers.

Will this installer automaticy uninstall the older version of My Trails already installed?

So I would just keep doing things the same way on my computer with the img files.  When I am ready to make an updated installer, I would run the macconverter and the new install script?  That's all I would have to do?  If so, that does not sound bad.  I thought I would have to uninstall and reinstall the img version.

Oz added an uninstaller for previous versions (read back a bit in this thread). I think the only issue is that the .gmapi version is going to have the same FID as your working version. So it would be best not to install both on the same computer or you would need to change the FID of your working copy to avoid a conflict (I assume there would be a conflict but haven't actually tested that myself).

That would be great to be uploading the .img files only once.

Is this installer script available for download (with instructions)?  I'd like to try it out on my routable maps.  Address search gets lost when I use OZ's old NSIS script.

Also, do I describe the workflow correctly below?

Compile the IMG files with cgpsmapper and install the map on my PC.
Run MapConverter to create a MAC compatible file.
Run an NSIS on the MAC compatible file to create a combined file.
Test the installer (this should uninstall the original IMG based map).

Why would I want to have both versions of the map installed on my machine at the same time?  Therefore, why would I need to change the FID on the original IMG based map?

I believe Oz's most recent update is attached to his post here: http://forums.gpsfiledepot.com/index.php/topic,2383.msg13980.html#msg13980

I think your workflow is correct, however we need to tweak the one thing I mentioned above for this to be a "universal" solution. Oz's NSIS script embeds the .gmapi file in the installer but it needs to be an external file for Mac users to access it. I will try to look at this soon.

The only thing about the workflow you describe is that it would remove your original source .img files from your computer when you test the script. Is that what you want? For me, I want to keep all the source files in the original .img formate, so I can continue to update my map one tile at a time.

Therefore, I would not install the .gmap version on my work computer. I would create the Mac version and Windows installer, then test actually installing the map on another Windows machine so that my original files are not affected.

If I wanted to do it all on the same machine, I would first change the FID of my source version to something else, then install the .gmap version.

Since I need to keep my img version, is there any need to actually install the .gmap version on my computer?  Or could I just create the installer without actually installing it on my computer?

Does anyone know if anyone is working on something that would compile a mp to the .gmap  format?  That would make things much easier.

I don't see any need to install the .gmap version on your own machine, but it's probably a good idea to test it somehow before uploading. The installer script is just like the old ones - tweak as needed in a text editor and compile it with NSIS.

It would be nice to go directly from .mp to gmap, but I don't think it's possible. I don't follow developments in the OSM project... is this something they are looking at maybe?

I think I'm going to need Oz's NSIS expertise to figure this out.... In the current script, the following line puts the .gmapi files into the output path

File /r "${DIRECTORY}${MAP_SHORT_NAME}.gmapi\${MAP_SHORT_NAME}.gmap\*.*"

I think this needs to be replaced with the CopyFiles command (see http://nsis.sourceforge.net/Docs/Chapter4.html#4.9.3) But there doesn't seem to be a recursive option ( /r ) for CopyFiles. I still don't have a very good grasp of NSIS scripts unfortunately.

It will be necessary to keep the .exe file separate from the .gmapi file (actually a folder on windows) in order to make the universal installer.

Why should I have to remove the IMG files from my PC rather than simply have them in a separate folder from the MAC files? 

What I do now is use MapsetToolkit to do installs of works in progress.  (That keeps my address search working better.)  I then make up an installer, run it to test it, uninstall it, and re-install my working copy. 

Would that have to change?

When you run Mapconverter, it makes a .gmap version of the original .img based map which retains the same FID. This will be invisible to Mapsource and Basecamp unless the .gmap folder is moved to C:\ProgramData\GARMIN\Maps. With the .gmap format, that is all you need to do to "install" a map and that's what the NSIS installer does.

So unless you run the installer on your machine, or move the files to that location, there would be no conflict.

Doesn't sound like a problem then, since my map projects all live someplace else.

Quote from: BobT on October 08, 2011, 07:48:30 AM
Just curious but is NSIS better than Inno Setup.  I use Inno Setup and to my knowledge no one has had installation issues. 

Bob

Here's a simple Inno Setup script I made to install gmap type maps into XP, Vista and Win 7.  Also creates an uninstall entry in Start>All Programs and in Control Panel>Programs & Features

Cool - will have to look more closely at this. I had already downloaded inno and started playing with it because it seems a little easier to understand. The "external" file flag looks like just what we need to make a universal installer, such that Mac users just double-click the .gmapi file while Windows users run the .exe file

Quoteexternal
This flag instructs Inno Setup not to statically compile the file specified by the Source parameter into the installation files, but instead copy from an existing file on the distribution media or the user's system.

From what I can tell, it's not so straightforward to do this with NSIS. But Oz needs to create a separate category for "universal version (Mac+ Windows) before we can take advantage of such an installer.

Quote from: Boyd on November 22, 2011, 03:23:19 PM
I think I'm going to need Oz's NSIS expertise to figure this out.... In the current script, the following line puts the .gmapi files into the output path

File /r "${DIRECTORY}${MAP_SHORT_NAME}.gmapi\${MAP_SHORT_NAME}.gmap\*.*"

I think this needs to be replaced with the CopyFiles command (see http://nsis.sourceforge.net/Docs/Chapter4.html#4.9.3) But there doesn't seem to be a recursive option ( /r ) for CopyFiles. I still don't have a very good grasp of NSIS scripts unfortunately.

It will be necessary to keep the .exe file separate from the .gmapi file (actually a folder on windows) in order to make the universal installer.

Why do we need to copy files? I don't think I get it.  Macs can't even open .exe so that is what I can't understand.  How would a mac know to just do whatever it does with a .gmapi whereas the Windows computer just run the .exe which contains a .gmap folder.

I can easily create a universal installer table entry.

Sorry I lost track of this thread.

I actually looked at InnoSetup when I was working on the new NSIS script.

Quote from: Boyd on December 02, 2011, 12:10:28 PM
Cool - will have to look more closely at this. I had already downloaded inno and started playing with it because it seems a little easier to understand. The "external" file flag looks like just what we need to make a universal installer, such that Mac users just double-click the .gmapi file while Windows users run the .exe file

Here is what I can't wrap my head around.  This means that there is still a .gmapi file and .exe file.  How is that different than current?

On Windows, the .gmapi appears as a folder.

On the Mac, the .gmapi appears as a file and not a folder. If you double-click the .gmapi on the Mac, it launches Garmin Mapmanager and asks if you want to install the map. So on the Mac, the "installer" is already resident on the system and is associated with .gmapi files.

So, my thought is to have a .zip archive containing two things:

1. The .gmapi
2. The NSIS .exe file

To install on Windows, double-click the NSIS .exe file, which reads its data from the .gmapi
To install on the Mac, double-click the .gmapi file, which is self-installing

Only one copy of the map data is needed to install on both operating system.

Quote from: -Oz- on December 03, 2011, 02:53:07 PM
Here is what I can't wrap my head around.  This means that there is still a .gmapi file and .exe file.  How is that different than current?

It is confusing, sorry! The difference is that the current installer encapsulates the .gmapi *inside* the .exe file. It needs to be a separate file so it can be installed on the Mac.

I think I understand now.  That would be awesome because it would really cut down the amount of space the server needs by half (and make it so we don't have to upload two copies).  So has anyone figured out how to do it?  Now that I get it I may start playing around with NSIS but it is really a pain-in-the-butt "language"

I downloaded the Inno Setup script that rws posted above (thanks!) and am going through it now just to be sure I understand it. Should be an easy modification  - add Flags: external to the source command so it will read the .gmapi from a separate file.

Inno seems a little easier for me to understand than NSIS, and the script the rws wrote chooses the correct install location for XP and Win7 by using the %APPDATA environment variable.

See http://www.jrsoftware.org/isinfo.php

I just updated the tutorial (finally) with the "old method" installer script that at least handles the 64 bit errors.  I won't post the new .gmap version until we figure out if we can do this universal installer method.

And wow that innoscript is much much shorter than NSIS.

Side note: I got a PM from a member asking how to move the maps out of ProgramData since his C: drive is small.  I think that problem could be a lot more common, especially with the advent of SSDs.  my only suggestion was to symlink the directory.

Ah, you are correct.

Inno Setup script that uses external gmapi folder to install Windows maps.

Place the gmapi folder and the resulting setup exe from this script together and you have the Mac and Windows installers in one package.

Actually I just modified your old script and made some changes. It was using the {app} parameter and {%APPDATA}. This resulted in the maps going into C:\Users\ostroff\AppData\Roaming\GARMIN\Maps on my Vista system. I think the correct location is: {commonappdata}\GARMIN\Maps, which expands to C:\ProgramData\GARMIN\Maps (this is where Garmin says they belong).

Since it's such a short script, here's my version. Have to say, I like inno *much* more than NSIS. :)


#define MyAppName "TestMap.gmap"

#define MyAppVersion "1.0"

#define MyAppPublisher "Universal Installer Test"

[Setup]
; NOTE: The value of AppId uniquely identifies this application.
; Do not use the same AppId value in installers for other applications.
; (To generate a new GUID, click Tools | Generate GUID inside the IDE.)
AppId={{20D3F074-9197-4F00-9EAC-82231547B9EC}
AppName={#MyAppName}
AppVersion={#MyAppVersion}
AppPublisher={#MyAppPublisher}
; writes maps files to proper directories in XP, Vista and Win 7 so Mapsource and Basecamp can find them.
DefaultDirName={commonappdata}\GARMIN\Maps
DisableDirPage=yes
DefaultGroupName={#MyAppName}
DisableProgramGroupPage=yes
; optional custom image you want displayed on your installer
WizardImageFile=TestMap.bmp
; your license agreement that requires acceptance before installer will continue with installation.
LicenseFile=license.txt
; folder you want the installer written to.
OutputDir=C:\Users\ostroff\Desktop\inno
; installer name
OutputBaseFilename=Windows Installer
Compression=lzma
SolidCompression=yes

[Languages]
Name: "english"; MessagesFile: "compiler:Default.isl"

[Files]
; location of your maps .gmap folder
Source: "C:\Users\ostroff\Desktop\inno\TestMap.gmapi\*"; DestDir: "{commonappdata}\GARMIN\Maps"; Flags: external ignoreversion recursesubdirs createallsubdirs

[Icons]
Name: "{group}\{cm:UninstallProgram,{#MyAppName}}"; Filename: "{uninstallexe}"


It is working properly on Vista and also on my Mac. Haven't yet tried XP. I have attached a zipped folder, which is what I would upload at GPSFileDepot for a universal installer. I would probably add a README file for Mac users and create a custom Mac icon in an actual upload.

It will put a small map named "TestMap" on your computer that covers the New York City area. The uninstaller (programs and features control panel) works as expected. On the Mac, double-clicking TestMap.gmapi starts MapManager and asks if you want to install. MapManager also has the option to uninstall maps on the Mac.

I haven't attempted any of your fancy checking for old versions and registry entries Oz, just wanted to get the basics working for now.  :D

Boyd

Your installer did not work...came up with an error during install with an invalid directory.  This directory would not be on anyone's machine.

Source: "C:\Users\ostroff\Desktop\inno\TestMap.gmapi\*"

On other matters:

%APPDATA works for installing in XP, Vista and Win 7 but requires the latest version of Mapsource.

I tried commonappdata and it works in Vista and Win 7, didn't try XP yet...so if it works in XP and with older versions of Mapsource that is a change to make.

Here's a script I used on your map to get it to work from any install location.  I also attached a zip file using the Install created with this script and your test map files.

; Script generated by the Inno Setup Script Wizard.
; SEE THE DOCUMENTATION FOR DETAILS ON CREATING INNO SETUP SCRIPT FILES!

#define MyAppName "TestMap.gmap"
#define MyAppVersion "1"
#define MyAppPublisher "Universal Installer Test"

[Setup]
; NOTE: The value of AppId uniquely identifies this application.
; Do not use the same AppId value in installers for other applications.
; (To generate a new GUID, click Tools | Generate GUID inside the IDE.)
AppId={{E0C3F85D-FF39-4355-A3BD-59A5A278C775}
AppName={#MyAppName}
AppVersion={#MyAppVersion}
;AppVerName={#MyAppName} {#MyAppVersion}
AppPublisher={#MyAppPublisher}
DefaultDirName={commonappdata}\GARMIN\Maps\{#MyAppName}
DisableDirPage=yes
DefaultGroupName={#MyAppName}
DisableProgramGroupPage=yes
; WizardImageFile=c:\junk\RWS Custom Maps\RWSCustomMaps.bmp
; LicenseFile=C:\Junk\RWS Custom Maps\MNlicense.txt
OutputDir=C:\Junk\RWS Custom Maps
OutputBaseFilename=TestMap INSTALL
Compression=lzma
SolidCompression=yes

[Languages]
Name: "english"; MessagesFile: "compiler:Default.isl"

[Files]
Source: "{src}\TestMap.gmapi\TestMap.gmap\*"; DestDir: "{app}"; Flags: external ignoreversion recursesubdirs createallsubdirs
; NOTE: Don't use "Flags: ignoreversion" on any shared system files

[Icons]
Name: "{group}\{cm:UninstallProgram,{#MyAppName}}"; Filename: "{uninstallexe}"

Yes, you are right, and I realized that it was only working on my own machine because of the file location last night, but it was too late to fix. Thanks a lot for catching this!

According to Garmin, the location you were using is where map unlock codes go, but not the maps. I will test it on XP shortly and report back.

commonappdata places the gmap folder as follows:

Vista and Win 7
C:\ProgramData\Maps
works with the latest versions of Mapsource and Basecamp
was not able to test with older versions

XP
C:\Documents and Settings\All Users\Application Data\Garmin\Maps
works with the latest versions of Mapsource and Basecamp
did not work with Mapsource v 6.12.4...I'm wondering if older versions were capable of opening gmap files? (once updated to the latest version 6.16.3 it worked)

I always recommend in my map documentation for users to obtain the latest versions of Mapsource and their unit software.

Great - thanks for testing. See: http://forums.gpsfiledepot.com/index.php/topic,2383.msg13979.html#msg13979

I guessed that .gmap compatibility might have started with Mapsource 6.14.1. Of course, Mapsource is no longer being developed, so 6.16.3 is "as good as it gets". Personally, I've been suggesting that new users skip Mapsource completely and go directly to Basecamp. Unless you're already familiar with it, not much point in starting now and it doesn't work properly with the new devices either.

If somebody does want to use the older versions, or if they want to use gmap files with nRoute (which isn't compatible), there's a program called "MapReverseConverter" that will put these new files in the correct format.

Some further testing confirms gmap format map files starting working in Windows Basecamp v2.08 and Mapsource version 6.14.1

Using the install exe created with this Inno Setup script bundled with a gmapi map folder will produce a basic dual installation package for Mac and Windows (XP, Vista, Win 7 ) users adhering to the above Mapsource and Basecamp minimum versions.  The script produces an installer that can be run from any drive or folder.

Edit the attached script as noted.

rws, I also use Inno Setup and think it is very easy.  I am trying to download your attached script to look at it but it saves as a .php file.  What do I do with it or what am I doing wrong.

Quote from: BobT on December 06, 2011, 08:13:46 PM
rws, I also use Inno Setup and think it is very easy.  I am trying to download your attached script to look at it but it saves as a .php file.  What do I do with it or what am I doing wrong.

rename the .php extension to .zip

When I am asking someone for thier trail data to add to My Trails, I like to tell them how many people have downloaded the map.  I think seeing a counter with thousands of downloads makes them more likely to share thier data.  In my lawsuit with the National Park Service, my attorney used the numbers from the counter.  When you are trying to get a fee wavier for a FOIA request, numbers of downloads can help you meet the standard.  So my concern is if we go to a single installer, will the page be able to still show total downloads or would the download total start at zero?  My request would be for the download counter for the single installer to include all the previous Windows and MAC downloads. 

Throughout this discussion I have assumed that the "universal" installer would just be another option for those of us who wanted to use it - not a requirement.

If Oz will just provide a new category for "universal installer" that allows the upload of a .zip file, I will give it a try soon with a map I'm finishing.

Quote from: Boyd on December 07, 2011, 01:31:09 PM
Throughout this discussion I have assumed that the "universal" installer would just be another option for those of us who wanted to use it - not a requirement.

If the universal installer is bulletproof, why shouldn't it be the only one?  The only reason that comes to mind is that the upload/download burden will be significantly larger.  (Assuming Oz can work out some way of updating download stats for those of you with significant numbers.  For me, it doesn't make a whole lot of difference until I can find a lawyer who'll work pro bono.)

Alright, I will add the universal downloader option today.  At this point I foresee keeping the other two download options since the maps have those already.  However, I will give an option to "convert to universal downloader" where after you upload the universal download it will delete the other two version and add their "count" to the universal count.

Excellent - thanks Oz! I should have a map ready to upload in the next day or two.  :)

Question: Will these installers uninstall the other versions of the same map? Including the old .reg and any new versions that may need to be uninstalled to install a new one?

If not I can't see how it is ready for public consumption.

I've gotten so far as the backend for the universal installer.  It is currently limited to: Indrid Cold, Boyd, jbensen, seldom, and rws.  Once it is tested out I can open it up (and the tutorial is written).  The frontend that actually lets people click the link is in progress.

Quote from: -Oz- on December 09, 2011, 05:15:10 PM
If not I can't see how it is ready for public consumption.

A downside I see is what are windows users going to do with the .gmapi file once it's displayed as a folder as opposed to embedded within an .exe? Read the readme.txt file, who does that?

I was going to make a custom Mac icon for the gmapi that says "Mac Install". But I'm not sure if the same icon would be visible on a PC. Will be ready to test all this soon, just fixing up a few last minute things on my map. I think the .exe file should be named "Windows Installer". Hopefully that would give people the idea to double-click it. But you're right, some people will just charge off in whatever direction they feel like...

The Inno script doesn't check for previous versions but Oz's script does. However it isn't "universal" because Mac users cannot access the .gmapi inside the .exe file.

Quote from: Indrid Cold on December 09, 2011, 05:59:10 PM

Quote from: -Oz- on December 09, 2011, 05:15:10 PM
If not I can't see how it is ready for public consumption.

A downside I see is what are windows users going to do with the .gmapi file once it's displayed as a folder as opposed to embedded within an .exe? Read the readme.txt file, who does that?

my worry too; as this forum and my email shows most people don't read the tutorials even though the correct ones now come up when you download a map.

I will look at the innoscript and see if there is a way I can make it check the registry for installed programs and add/remove as required.  I wonder if we "hid" the .gmapi file/folder inside the .zip would mac users see it and the majority of windows users not?

Can't wait for one to be ready Boyd for testing.

Quote from: -Oz- on December 09, 2011, 09:42:27 PM
my worry too; as this forum and my email shows most people don't read the tutorials even though the correct ones now come up when you download a map.

That and this

:)

LOL. Over at GPSReview, it never ceases to amaze me how many people accidentally reformat their Nuvi's and wipe everything out (and of course they don't have backups). You get a warning message about that too.

I think Garmin may be addressing that in their 2012 automotive models because they are treated as "MTP" devices by Windows now and not as USB disks. You have to jump through a bunch of hoops and access the hidden developer menu to change this behavior and reveal the map and system files.

Quote from: Boyd on December 10, 2011, 05:54:09 AM
I think Garmin may be addressing that in their 2012 automotive models because they are treated as "MTP" devices by Windows now and not as USB disks. You have to jump through a bunch of hoops and access the hidden developer menu to change this behavior and reveal the map and system files.

Sounds like that could be a problem for mapmakers.

Why would it be a problem? Garmin hides their own map (gmapprom.img) and system files. Third party maps are installed in the \Map folder which is not hidden (that is where Mapsource and Basecamp will put them). I haven't used any of the new models, but Garmin has been hiding these files for the past two years or more in an invisible folder. Now they have changed the default behavior to a Media Transfer Protocol (MTP) device. I really don't understand the fine points of that, but I think Windows treats it like a digital camera or mp3 player instead of a disk.

FWIW, here's how to make it behave like a USB disk: http://forums.gpsreview.net/viewtopic.php?p=165763#165763

Quote from: Boyd on December 10, 2011, 05:54:09 AM
You have to jump through a bunch of hoops and access the hidden developer menu to change this behavior and reveal the map and system files.

I read you as saying that we'd need to access the hidden developer menu to upload maps we create.

Sorry if I wasn't clear. You need to change the settings in that menu to make the Nuvi behave as a disk instead of MTP device. Probably the only reason for doing that would be to backup everything on the device (which is a good idea).

Mapsource and Basecamp should still work the same as always for sending maps and other data.

Quote from: Indrid Cold on December 09, 2011, 05:59:10 PMA downside I see is what are windows users going to do with the .gmapi file once it's displayed as a folder as opposed to embedded within an .exe?

Am slowly putting this all together. I have my mac setup to access my Windows machine over the LAN. The Mac does not show the same icons as the Windows machine, but it looks like I can customize them for each machine such that each operating system can have its own look (or use the same ones if desired, but they are stored separately).

To address your concern however, if I select the .gmapi folder on Windows and go to the properties window, I can turn it into a hidden folder. This does not affect its display under MacOSX (from what I see over my LAN). So this is perfect - we can hide the .gmapi from Windows users. And on the Mac side, I can make the .exe file (Windows Installer) invisible with a unix shell command.

So I think this is the best of both worlds - Windows users will see the Windows Installer with a custom icon, but not the .gmapi folder. Mac Users will see the .gmapi file with a custom icon, but not the Windows installer. Of course, if somebody sets their Windows folder options to show hidden files, they would see the .gmapi folder, but not much I can do about that. Also, I suspect you would actually need a Mac to customize the folder/file appearance of the Mac version. Maybe there's some Windows utility that can do that however?

When I get this all sorted out, I can write up some instructions. Shooting to upload my map before the end of the weekend.

Oz - will I be able to post an update of an existing map as a "universal version" and then remove the old Windows and Mac versions that previously existed?

Well I've spent a lot of time on this now, and the main lesson has been "it's not a multi-platform world quite yet."  ;) It's possible to create a multi-platform installer, but customizing it to my taste on both platforms has a lot of pitfalls.

On Windows, I was able to hide the .gmapi folder without issue and also to customize the installer script icon (.exe file). The latter is done through the inno script itself using the SetupIconFile directive in the Setup section of the script. Hiding the .gmapi folder just involves clicking the "hidden" box in the folder properties dialog. So this is what the unzipped file folder looks like under Windows - pretty much achieved my goal here.

(http://stephencreek.com/gpsfd/wininstall.png)


Now it gets more complicated on the Mac. I can customize the .gmapi icon there, but this creates some hidden files that are used by MacOSX. These turned out to be a problem for making a universal zip file. If I zip the file using the Mac OSX archive utility (right-click > compress), I can open the archive on Windows but there is now a different folder structure that includes the Mac resources. This seemed ugly and confusing.

If I use the standard Windows right-click > Send To > Compressed Folder command, I get an error message saying it cannot be compressed because of illegal characters in file names. I was able to use 7-zip to compress the folder under Windows, however when I tried unzipping that folder on the Mac, I got an error about unsupported file types (or something) halfway through unzipping.

So after spending a lot of time messing around, I decided not to customize the look of the Mac icons. After stripping these all out, I used the regular Windows right-click > Send To > Compressed Folder command. When unzipped on the Mac, this is what it looks like. Note that double-clicking the .zip file on the Mac causes it to automatically unzip to a folder in the same directory using the Archive Utility which is standard on all Macs.

(http://stephencreek.com/gpsfd/macinstall.png)

Note that I have Windows XP installed on my Mac using "Parallels" and I believe that's why you see the windows icon for the Windows installer. Parallels would automatically boot windows and open that file. A "plain vanilla" Mac should just show a generic document icon and give an error message if you double-clicked the Windows Installer.

There are two ways that I could have made the Windows Installer invisible on the Mac, but neither was acceptable. The first method is adding a period to the beginning of the filename (eg: .Windows Installer.exe). That method also makes the file invisible to Windows unless you enable the option to show protected operating system files. Not good.

The other way to hide the file on MacOSX is to use the unix shell command chflags hidden [filename]. Unfortunately, this has the same effect as checking the "hidden" box in the Windows properties. No good there either - it makes the installer invisible on Windows. There are various shareware programs on the Mac to hide files, but I'm pretty sure they use the same techniques.

Finally, for those of you without Macs, when you double-click the .gmapi file on the Mac it launches Garmin MapManager (which is included in the Mac Basecamp package) and this is what you see.

(http://stephencreek.com/gpsfd/mapmanager.png)

MapManager also allows you to uninstall the map.

So this is what I've learned so far. It's been interesting, although often frustrating. I think we have a usable system now for the universal download format, but maybe I can eventually find a way to customize the Mac version a bit more with additional research and testing.

I still need to test this on Windows 7 and Windows XP, which I'll do shortly and then upload the map this evening.

Quote from: Boyd on December 11, 2011, 12:00:27 PM
Note that I have Windows XP installed on my Mac using "Parallels" and I believe that's why you see the windows icon for the Windows installer. Parallels would automatically boot windows and open that file. A "plain vanilla" Mac should just show a generic document icon and give an error message if you double-clicked the Windows Installer.

FWIW, I tried this on my old, old PowerBook G4 which is a Mac with the IBM/PowerPC CPU (before Apple switched to Intel). The Windows installer does just appear as a blank document icon. Double-clicking it attempts to open the file in the text editor (TextEdit) and displays a page full of garbage binary characters.

I was not able to use the map on this old system because it has MacOSX 10.3 and even the Legacy version of Mac Basecamp requires MacOSX 10.4. I tried, and was unable to install that version. Of course, if I really wanted to, I could upgrade that old machine to 10.4, maybe even 10.5, but it wouldn't be worth it.

Anyway, the following screenshot is more representative of what somebody would see when opening the universal install folder on a Mac that doesn't have Windows installed

(http://stephencreek.com/gpsfd/macinstall2.png)

I have now tested the map package on Windows 7 and Windows XP and everything works properly. Here's what the unzipped download folder looks like on XP

(http://stephencreek.com/gpsfd/xpinstall.png)



And this is a screenshot from Windows 7

(http://stephencreek.com/gpsfd/win7install.png)


Now I will try to upload the file and update the map info page.

I just successfully uploaded the universal version of this map: http://www.gpsfiledepot.com/maps/view/294/

I don't see any way to download the new file however, which is what I think Oz mentioned in an earlier post. On the upload page there was a link to remove the old separate Mac/PC versions and I clicked that but it didn't seem to do anything.

So the file is there... if you can find it.  ;D

Yea, the link isn't there yet.  I actually needed one map with the universal installer so I could make the look and everything look correct. It'll go live tomorrow because I'm a bit tired right now.

Does this handle uninstalling (at least of itself).  I'm gonna try it out.

It will uninstall itself, but does not check for previous (registry based) versions. I really still don't understand this Windows stuff with program groups, etc., but it creates a group for your map such that it appears under "All programs" and can be located by the uninstaller. If you used that group for other maps, I think they would also be included.

Pay notice to thispart of the script

Quote; NOTE: The value of AppId uniquely identifies this application.
; Do not use the same AppId value in installers for other applications.
; (To generate a new GUID, click Tools | Generate GUID inside the IDE.)
AppId={{20D3F074-9197-4F00-9EAC-82231547B9EC}

I tweaked a few things in the script to customize it for myself. I'm afraid I did this in a rather inelegant way, but I just wanted to get it done. I like the Inno installer because I find it easier to understand for some reason. It seems very flexible and powerful from what I've seen so far.

Here's the inno script that was used to create my installer, FWIW

I thnk not being able to uninstall the existing regestry based instalation is a big deal. If its not uninstalled, you would have two differnt vesions of the same map.  Cannot you just tell it to run the uninstaller?

Universal installer is live.  I am downloading yours right now and still making some back end tweaks.

Boyd: I already made it so your map only has the universal installer because I was testing.  The link is active though on the universal upload page for the other (limited) people who can do universal installers.

So as much as I like this idea the whole having to extract then install is kind of annoying.

Do you mean that you dislike having to unzip the folder first? That took awhile on my Slate 500 which I used to test it on Win 7, which is a netbook class machine. The gmap format creates a lot of files and folders, probably something like 4 for each .img file in the original mapset.

jbensman, I don't think it would be a big deal to add an uninstaller. Remember, we have just thrown this together quickly. I'm afraid that the Windows registry is still like alchemy to me, so I may not be the right guy for the job. But it looks like all the tools you'd need are available with inno setup.

http://www.jrsoftware.org/ishelp/index.php?topic=registrysection

Quote[Registry] section

This optional section defines any registry keys/values you would like Setup to create, modify, or delete on the user's system.

Oz, I don't see my map anywhere in the list. Maybe I'm not looking in the right place, or maybe you're still working on it? If I go to "Your Account/Files", the map is on the list but says "No file exists for this map".

Oh crap; I think I know whats wrong; fixing now...

EDIT: All fixed, let me see if you notice where it doesn't show up.

Cool, seems to be there now. I see it on the list of new maps, on the "all states" page and on the NJ page. Thanks!

Nice map, shows up in my MapSource 6.16.3, but not in 6.13.7.

Couldn't find Nucky Thompson's house though...

Thanks, this has been an ongoing labor of love for me. Maybe I need to add some Jersey Shore POI's? :)

As we determined earlier,

Quote from: rws on December 05, 2011, 02:17:34 PM
Some further testing confirms gmap format map files starting working in Windows Basecamp v2.08 and Mapsource version 6.14.1

Quote from: Boyd on December 12, 2011, 06:22:04 PM
Thanks, this has been an ongoing labor of love for me. Maybe I need to add some Jersey Shore POI's? :)

As we determined earlier,

Quote from: rws on December 05, 2011, 02:17:34 PM
Some further testing confirms gmap format map files starting working in Windows Basecamp v2.08 and Mapsource version 6.14.1

I was thinking that now you have contemporary NJ nailed you might try a New Jersey during Prohibition project.

I read the rws quote, and the note in your ReadMe.  Thought it was worth mentioning since both versions were running side by side on the same system. 

Ah, ok I just looked up Nucky Thompson. Sorry I missed the reference, I thought it was somebody from Jersey Shore. I don't have cable or satellite and stopped watching TV (except DVD and BluRay) when I moved out to the sticks 6 years ago, so I'm kind of out of the loop.  :D

I love old maps, recently found this map of New Jersey from the Federal Writers Project in 1939 in an antique shop and have it on my wall: http://stephencreek.com/njpb/oldmap02.jpg

I doownloaded the universal installer on my Win 7 laptop.

It open a folder called BoydMapNJ

I had to double click on it to open it.  I worry others may not know to do this.

Once I opened that folder I had the windows installer readme and gmapi folder.  The installer worked great. 

After installing it, I downloaded and ran the installer again.  It installed again without asking to uninstall the existing map.

Did you have two maps list then or still just one?

Yeah, after uploading I realized that I had created a second nested folder (guess I zipped the whole folder instead of selecting all the files and zipping them). Will have to update that so that the files are all there when you first open the folder. But that's my screw-up, not a problem with the installer. And it seemed pretty obvious that you need to open the folder, which is why I didn't jump right in and fix it. Anyway, your point is well taken.

If you run the installer again, it will just copy the same files to the same place, it won't install anything twice. As mentioned above, this is just a bare-bones installer script that doesn't do anything like checking to see if the map is already installed or if there's a previous version.

It's not a limitation of the installer program (inno), it's just a script that needs more work to deal with these issues. Join in the fun and help customize the script so that it handles these things.  :)

I think it would be very simple to make the script uninstall a previous universal version of the map. That value of AppID uniquely identifies your map (you need to generate this yourself using a function of Inno Setup Compiler). If you create a new map and keep this same ID, it should just be a case of having the script do an uninstall first, then install the new map.

Earlier in this thread I posted a little test map while working on this script. I used the same AppID for that map, and when I ran the uninstaller for my "real" map I noticed that it removed that little test map as well as the real one since the ID was the same.

What gets a little more complicated is uninstalling a previous registry-based map. As I said, I'm sure that is quite possible since the tools to work with the registry are all there. But I just don't have a grasp of how the registry works. Will try to study this some more.

Here's what I've learned so far about uninstalling previous versions:

If the previous version was in the gmap (universal) format:

1. If the map has the same name, you can have the installer just over-write the old folders and files

2. If the map has a different name you can add an [InstallDelete] section that will be executed before the installer to remove any folders/files that you specify

If the previous version was in registry format AND you know where it was installed: You can use a [Run] section to run the uninstaller program (uninstall.exe) for the old version. This might be a problem because the GPSFD installer allowed the user to choose a custom install location.

If the previous version was in registry forum and you don't know where it was installed:

Here's where I get confused. It looks like you can use the [registry] section to find and delete any registry entries for the old map. I guess that would be good enough to remove the map from Mapsource. But I don't see a way to find and delete the actual .img files using the registry (which is what Oz was doing in his NSIS script)

Further thoughts...
Seems like the best way to remove an old registry based map is to simply run the uninstall.exe file that was created by NSIS when the old map was installed. That can easily be done in the inno [run] section. What I don't understand is how to FIND that old uninstall.exe unless you know where the user originally installed his map.   :-\

Quote from: Boyd on December 14, 2011, 05:49:10 PM
Here's what I've learned so far about uninstalling previous versions:

If the previous version was in the gmap (universal) format:

1. If the map has the same name, you can have the installer just over-write the old folders and files

2. If the map has a different name you can add an [InstallDelete] section that will be executed before the installer to remove any folders/files that you specify

What happens when you add tiles to the same mapset (or delete them or change their names)?  It seems to me that it would be safer to make the Delete standard.

I'd think you would want to replace the whole mapset when you change any part of it, because that could get confusing otherwise. But since the gmap format is just a collection of directories and files, you could drill down and replace individual tiles if you really wanted to.

The current version of the inno installer (that I used for my new map) is really simple. It just copies the folders and files to the right location on your computer. That's all you need to "install" a gmap. To "uninstall", you just delete the folders and files. That can be done by replacing them with new ones with the same names, or by explicitly deleting them.

Maybe this is a more clear answer. This inno script section installs a map named "MyMap"

Quote[Files]
Source: "{src}\MyMap.gmapi\*"; DestDir: "{commonappdata}\GARMIN\Maps"; Flags: external ignoreversion recursesubdirs createallsubdirs

If you make a new version and also name it "MyMap", then that same command will replace the old version with the new version.

If your new version is named "MyNewMap", then you would add the following to first remove MyMap

Quote[InstallDelete]
Type: filesandordirs; Name: "{commonappdata}\GARMIN\Maps\MyMap.gmapi"

Then you would install the new map with

Quote[Files]
Source: "{src}\MyNewMap.gmapi\*"; DestDir: "{commonappdata}\GARMIN\Maps"; Flags: external ignoreversion recursesubdirs createallsubdirs

OK, looks like there's a way to uninstall the registry based map, but I'm gonna need Oz's help with this.  :D

With NSIS, I think this is how Oz would remove a registry-based map named "OldMap"

QuoteReadRegStr $R0 HKLM \"Software\Microsoft\Windows\CurrentVersion\Uninstall\OldMap\UninstallString"
  ExecWait '$R0'

In inno, we have this syntax (scroll way down this man page: http://www.jrsoftware.org/ishelp/index.php?topic=consts)

Quote{reg:HKxx\SubkeyName,ValueName|DefaultValue}

    Embeds a registry value.

So, would something like this accomplish the same thing in inno? Specifying a Filename in the [run] section simply causes that program (ie: uninstall.exe) to be run.

Quote[Run]
Filename: {reg: HKLM \"Software\Microsoft\Windows\CurrentVersion\Uninstall\OldMap\UninstallString"}

I just don't understand this registry stuff, and I'm reluctant to start experimenting with scripts that might mess up my own registry. I'm not completely clear on what "UninstallString" represents in that NSIS script. Is that a value that is read from the registry itself (ie: the full pathname of the uninstaller)? If so, I assume that inno could also read it. Or is it some kind of variable or constant from NSIS that wouldn't work in inno?  :-\

Attached is my IS script that I have been using for years.  It was before the new version that allows you define variables.  I would just use find/replace to change the names.  In this script you will see a section called [Type] and [components] that let a user select certain items they wanted copied to their computer, mainly original gps tracks.  You need these to view in Google Earth.  The sections is the registry section where I write to the registry.  I did not use the new gmap format.  This may are may not be of any help to you in your quest.  You can install one of my maps on this site to see how it works.

Boyd:

Yes, you're definitely on the right track.  That installer string gives the location of the uninstall file.  The $R0 for NSIS just is the variable the value from the registry gets saved to.

Based on

Quote{reg:HKxx\SubkeyName,ValueName|DefaultValue}

    Embeds a registry value.

This code may not work:

Quote[Run]
Filename: {reg: HKLM \"Software\Microsoft\Windows\CurrentVersion\Uninstall\OldMap\UninstallString"}

I think it should actually look like:

Quote[Run]
Filename: {reg: HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\OldMap,UninstallString}

Note the comma before uninstall string since that is how the template appears to be.

However I can't test it yet because I really have to finish my real work before I screw with this.  The good news for testing though is you should just be able to run that line in Inno and see if it opens the uninstaller.  It won't actually modify the registry.

NOTE: After re-reading I think that is the command for edit the registry.  You need to find the command to read data from the registry.

Will look at this tonight, but I think his:

{reg: HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall\OldMap,UninstallString}

is not a "command" at all. It's way to read a registry value into a variable so that it can be used in a command.  I am assuming that it would expand to the full pathname of the uninstaller .exe. Thanks for the syntax corrections!

By placing it in the [run] section and using the File command, it should just execute the uninstaller. In other words, it's the equivalent of;

ExecWait '$R0'

in NSIS... or at least I think so  :) Will post back tonight, am working outside on home renovation on this warm winter day.

@BobT: thanks for posting that, will have a look.

Another syntax one; remove the space between HKLM and \Software

It is confusing. But I have tested that map on Windows7.  XP, and Vista and it worked properly. Are you sure you aren't running an old version of Mapsource?

To find the correct directory, open a Windows Explorer Window and paste the following into the address bar at the top

%ALLUSERSPROFILE%\Garmin\Maps

This works for me. Give it a try.

Huh, was someone having a problem?  The install worked fine for me (all I have to test with is win 7 32 and 64bit).

Oops, I'm sorry! I meant to respond to a PM on this topic that maps4gps sent me about problems with the universal installer. So I reviewed this thread to try and remember how I did things and somehow I got confused and posted the response here. 

This is what happens when it try to do something quickly late in the evening.... :-[

Not a problem with a mapset, but not sure if a procedure for doing this has been decided on.

In reviewing the posts in this thread,  'c:\users\all users\garmin\maps' was indicated for the location of the xxx.gmap file/folder
Seldom had just posted  'c:\programdata\garmin\maps' for your FL topo
I did not find where 'Boyd's Map of New Jersey 2012' got installed to.

Quote from: maps4gps on January 27, 2012, 04:15:43 AM
Seldom had just posted  'c:\programdata\garmin\maps' for your FL topo
I did not find where 'Boyd's Map of New Jersey 2012' got installed to.

Open a command prompt window and type

SET

See what path is shown for ALLUSERSPROFILE. On Windows 7 and Vista, it should be: C:\ProgramData. On Windows XP it should be C:\Documents and Settings\All Users\Application Data. That is how my installer determines where to install the maps.

On my Vista machine, my map is installed in C:\ProgramData\GARMIN\Maps\Boyds Map of NJ 2012.gmap. There have been about 200 downloads since I posted that map and I haven't seen any reports of problems yet. In Mapsource go to Utilities > Manage Map Products and you can see where everything is actually installed.

What version of Windows are you running and what do you see when you type SET?

Windows 7
ALLUSERSPROFILE=C:\ProgramData

Neither Windows Explorer/Library nor the dir nor attrib commands in a command prompt window 'see' this folder. 

I was trying to transfer a small test.gmap file and view it in MapSource and BaseCamp.
Interesting that I misread Seldom's post and created a 'Program Data' folder (as in the two Program Files folders on the computer) and both MS & BC displayed the test data.

Top folder is C:\ProgramData.  It's hidden in Win7.  The only way I got it to show is to default all folders to show hidden.  Don't know how to write to it.

(http://imghst.gpsfiledepot.com/1327692665.jpg)

I thought it was hidden, but was unable to find how to display hidden folders in Windows 7.
Using the attrib command in a command prompt window would list hidden files and could change the attribute, i.e. to not hidden.  It did not show ProgramData, so it must not work that way for hidden folders.

I was able to access both hidden folders (ProgramData and AllUsers) by doing a cd to that folder.  I could then make the subfolders and xcopy the test.gmap folder from where it was built.  The problem was then deleting the test.gmap folder as each quad/segment subfolder  needed to be entered to delete the files.  Glad I only had four quads in the test.gmap folder.

Quote from: maps4gps on January 27, 2012, 12:51:21 PM
I thought it was hidden, but was unable to find how to display hidden folders in Windows 7.

You should be able to do this with Control Panel > Folder Options > View > Show hidden files and folders. There's also an option to hide protected operating system files that is enabled by default. I think the only thing this changes is that it will enable you to see files and folders that have names beginning with a dot (period). That's necessary if you want to backup a Nuvi, for example, because the maps are stored in a hidden folder named .System.

(http://stephencreek.com/gpsreview/folders.png)

On my Win7 machine Control Panel>Appearance and Personalization>Folder Options>View>Show Hidden Files, Folders, AND DRIVES!

Depends on how you have things set. I have mine set for view by small icons because it's easier for me to find things that way and it takes less clicks.  :)

Quote from: Boyd on January 27, 2012, 03:03:13 PM
Depends on how you have things set. I have mine set for view by small icons because it's easier for me to find things that way and it takes less clicks.  :)

Your way is a lot nicer.  Thanks for the tip.

I'll have to try out small icons; I've been using details view for years.

Is this still being worked on?

Boyd's NJ multiplatform mapset works on my PC.
Is OZ working on an installer using NSIS to do the same?

The roadblock we hit with NSIS is that I couldn't figure out a way to keep the map data separate from the Windows installer. It needs to be located in a separate file so that it can be accessed on a Mac without running the .exe (which isn't Mac compatible).

My installer works fine, but I haven't implemented a system for removing a previous version of the same map. If you read back, you'll see that I was very close to this but got distracted by other things and haven't gotten back to it, since I don't need that feature.

But I will eventually get back to it...

As Boyd pointed out.  You can't do a "universal" installer (one file) with NSIS.  However, in this thread there is the script that will put the map files in the new location (the gmap files) and handle install/uninstall of the old map (even a non-gmap map as long as it has the same name).

I do not understand much about the installers.

This tread has become so long and what is being found was changing so often, code and ideas and corrections with Boyd, OZ and TobT, NSIS and INNO installer, PC & MAC, I was unable to tell if it was still in-the-works or something was ready for use.

I interpret Boyd's and OZ's last posts to mean neither NSIS nor INNO installer would rrently be good to use for mapsets - as in redoing my nearly 40 State topo maps which have the 64-bit Windows 7 installer issue.

OZ: is that the script (universal.txt) in Boyd's Dec 11 post?

Yes, this thread is long and confusing. Here is the inno installer for my most recent map: http://www.gpsfiledepot.com/maps/view/276/

This script will work fine to create a universal version of any map if you customize it with the correct info for your map. The only thing it doesn't do is remove an older map. But as long as you're creating new maps and not updates, it should be fine. Here are a few notes

1. You must generate your own unique AppID using the Inno Setup compiler. Do NOT use the ID below. The purpose of this ID is to create an uninstaller for the map.

2. the .gmapi folder, installer script, license and any other support files all must be in the same directory. The support files are listed below - if you don't want any of them, just comment the appropiate lines out of the script.

3. If you would like the installer (.exe file) to have a custom icon, it must be an .ico file. I used the free GreenFish icon editor to create one myself.

4. Create a text file named license.txt containing your license.

5. You can create a custom image to be displayed during installation. It needs to be a .bmp file 164 pixels wide x 314 pixels high.

6. Change the value of OutputDir to something that makes sense on your own system.

7. After creating the Windows installer and compiling with Inno Setup Compiler, create a folder named for your map and put both Windows Installer.exe  and your .gmapi folder into it. Now compess that folder as a .zip archive and you should be all set.



#define MyAppName "Boyds Map of the Pines LE"

#define MyAppVersion "1.0"

#define MyAppPublisher "Boyd's Maps"

[Setup]
; NOTE: The value of AppId uniquely identifies this application.
; Do not use the same AppId value in installers for other applications.
; (To generate a new GUID, click Tools | Generate GUID inside the IDE.)
AppId={{91A47A34-7409-455D-967E-A632501AFF80}
AppName={#MyAppName}
AppVersion={#MyAppVersion}
AppPublisher={#MyAppPublisher}
; writes maps files to proper directories in XP, Vista and Win 7 so Mapsource and Basecamp can find them.
DefaultDirName={commonappdata}\GARMIN\Maps
DisableDirPage=yes
DefaultGroupName={#MyAppName}
DisableProgramGroupPage=yes
;optional custom icon for the installer
SetupIconFile=PinesMap.ico
; optional custom image you want displayed on your installer
WizardImageFile=PinesMapLE.bmp
; your license agreement that requires acceptance before installer will continue with installation.
LicenseFile=license.txt
; folder you want the installer written to.
OutputDir=C:\Users\ostroff\Desktop\mapping\ned19\pines map\work\inno
; installer name
OutputBaseFilename=Windows Installer
Compression=lzma
SolidCompression=yes

[Languages]
Name: "english"; MessagesFile: "compiler:Default.isl"

[Messages]
FinishedLabel=Setup has finished the installation of Boyd's Map of the Pines LE on your computer. You may now run Garmin Basecamp or Mapsource and choose "Boyds Map of the Pines LE" from the dropdown menu to view the map. To remove this map, use the uninstall option in the Programs and Features control panel (Windows 7 and Vista) or Add/Remove Programs (Windows XP)

WelcomeLabel2=This will install Boyd's Map of the Pines LE on your computer.%n%nIt is recommended that you close all other applications before continuing. NOTE: You must install Garmin BaseCamp or Mapsource in order to use this map. You may download BaseCamp from: http://www8.garmin.com/support/download_details.jsp?id=4435

[Files]
;copy .gmapi folder from install folder to user's Maps folder
Source: "{src}\Boyds Map of the Pines LE.gmapi\*"; DestDir: "{commonappdata}\GARMIN\Maps"; Flags: external ignoreversion recursesubdirs createallsubdirs

[Icons]
Name: "{group}\{cm:UninstallProgram,{#MyAppName}}"; Filename: "{uninstallexe}"
;


It depends.  If you want to remake the installers for just the 64-bit issue I posted an updated script here: http://www.gpsfiledepot.com/tools/map_install.zip  This one uses the "old" registry method.

If you want to use the gmap method (new) here is the current script: http://forums.gpsfiledepot.com/index.php/topic,2383.msg13980.html#msg13980

With that said if you go with Boyd's method you can actually have one file for mac and pc.  Mine still needs a separate mac file.

Boyd - thanks for the notes and script.

The INNO script is so much shorter than NSIS, I had been thinking there must be more to it.
For starters I only need the license and perhaps a readme file.
Now to get some time to begin the learing curve.

Do you know what happens if a gmap type mapset is installed with INNO while the same(or older version) of the mapset is still installed in the registry? 
Does MapSource/BaseCamp recognize them both, only one, none, freeze the computer, or worse?

Just did a couple quick tests. I converted a map I'm working on to .gmap, then placed it in the C:\ProgramData\GARMIN\Maps folder. A registry based version of the same map was already installed. When I started Mapsource, only one version of the map was shown in the dropdown menu.

When I went to Utilities > Manage Maps it only listed the .gmap version - you can tell because the install location is listed. I also used the map tool to select the entire map, and there was only one copy of each tile listed on the map tab.

So I *think* Mapsource is ignoring the old registry based version after the .gmap version was installed. You can try for yourself and see what happens.

If this is true, then it actually addresses the issue of removing old maps... you could just leave the registry based map there and it would no longer be used. Then, if you wanted to do an update of the new .gmap, just be sure to name it the same. The new .gmap would simply overwrite the old one since it would be installed in the same place.

[edited to add]
I also just tried this on the Mac. Installing a new version of the .gmapi file replaces the old version. This might be either good or bad depending on what you want. Double-clicking the .gmapi starts MapManager as usual and asks if you want to install. It does not warn you or ask if you want to replace the old map, it just over writes it.

I'm new to this process.  I've recently created my first map and sent it to my father using the INNO setup script that Boyd provided in this thread.  It left me with a question that I'm having trouble figuring out on my own.  Is there any way with INNO script to make it so that the gmap folder is bundled in the windows exe file so that I could simply put the single file on my ftp site for my father to download?  I only need the windows version but I chose to use INNO setup because I already had the software and couldn't find the NSIS compiler to download, plus, I saw that there is some concern that Garmin might go farther in the direction of the gmap installation system so I didn't want to have to change later.

The project is to make routable snowmobile trail maps for the Lake Louise Snowmachine Club in Alaska.  I'm fine making the maps, I've got routing working and everything but now we need to be able to allow club members to download the maps and install them in Mapsource and most of them are barely computer literate so I need to make it as simple as possible for the end user.

My ultimate goal is to have one file that the end user downloads giving them an EXE file to double click and that would do it all.  No WIN-rar or WIN-zip or anything else as they may not have the software or know how to use it properly.  Also, the map is very small (only about 5MB) so it doesn't need to be compressed anyway.  Does anybody know how I can get INNO to hold all the source files that it needs so that the end user only has one button to double click and it would install just like most other software that can be purchased?

Thanks

Thumper, you may want to check this out.  It has a link to the NSIS installer at the top and a sample setup template file about half way down the page.

http://www.gpsfiledepot.com/tutorials/how-to-create-garmin-topo-maps---part-9---compiling-data/

You really might want to use the script as-is, because it would allow any members of your group to install the maps on a Macintosh. No special software (such as WinRAR or WinZip) is needed to use this script. Every Windows machine has the ability to open .zip files right out of the box, simply right-click them and choose "extract all".

But if you really want a windows-only, simple inno version, see the one that rws has attached to his post here: http://forums.gpsfiledepot.com/index.php/topic,2383.msg14536.html#msg14536

Thanks for your help on this.  With a bit more trial and error (actually quite a bit) I was able to figure out how to do what I needed.  I'm fine with having two seperate files served on the snowmobile club's website (they're small files anyway) for the MAC and Windows versions.  I need to be able to upload a single file for each of them and I'm not sure how to make that happen for the MAC version.  I don't have a MAC but I have a friend who has one and is familiar with building web-sites so I'll check with him first.

Also, one of the reasons I chose to use INNOSetup and the gmapi version of the installer is that earlier in the post there was some concern that the registry installation system might get phased out by GARMIN.  If that happens, will there be a new version of the cGPSmapper software?  I might be wrong but if GARMIN makes it so the registry installed maps don't work then cGPSmapper would stop working and the current process of using cGPSmapper followed by MapConverter to get the files and folder structure needed for the gmapi installation wouldn't work either.  Is there an update to cGPSmapper in the works to possibly compile the maps directly into a gmapi structure?

Unless Stan changed his mind; he ended serious development of cgpsmapper about two years ago. 

If Garmin ended support for registry mapsets, one could still use cgpsmapper to make the .img files, then mapsettoolkit for a registry install, then mapconverter to make the  gmapi format files.  I would expect Garmin's mapsets may be distributed in the gmapi format, but a lot of their purchasers would be very upset if their registry mapsets became unusable.

And I suspect they get as a decent chunk of revenue from GPS hobbyists who buy handhelds but  who use free maps.  Also, at least for now, all the exports from BaseCamp are called gmapsupp.IMG.

I really don't think the old registry-based maps are going to disappear anytime soon. I think the main attraction of the gmap format is that it's multi-platform.

If you want to make a Mac version of any map installed on a Windows system, just run Garmin Mapconverter. This produces a file that can be installed on a Mac:

If I may ask a question concerning Inno...

All of the scripts posted here have helped me tweak my own setup immensely; I can't thank you guys enough.

But none of the scripts involve registry entries, which I utilize.

I guess I use registry entries because my file locations are not defaulted to a Garmin directory, but my own 'family' of maps.

My question is, how does MapSource know the map is there if the registry isn't altered? Does the physical file location matter?

Sorry to keep this topic dragging on...  ;)

The gmap format doesn't use the registry. Basecamp and Mapsource will read any maps it finds from the standard location. If you want to install one of these maps in a non-standard location, have a look at JaVaWa GMTK which is a utility program that will allow you to move maps anywhere that you want.

I'll give it a shot. Boyd (and everyone), thanks.

And Boyd, your maps are the BOMB. A little off topic, but are your methods explained in this (http://forums.gpsfiledepot.com/index.php/topic,2579.0.html) post?

Thanks. Yes, that thread is sort of a "blog", written as I developed my technique for creating shaded terrain. I have another map using those techniques that has been essentially finished for quite awhile now, but I just need to proof it and fix a few glitches. Can't seem to get my brain back into that mode recently though... my background is that of an artist, and we need to be "inspired" to get things accomplished.  ::)