Harmonize *.rgs files


I find in a lot of *.rgs files in MapWinGIS code like this:

With a version number which is still set to v4.9. Should I change them to v5.0?
And do we really need a version number in these files?

In older *.rgs files I see this:

No version number is set, but VersionIndependentProgID is used.
Can the rgs-files be changed to not use Version?
It will be less maintenance.


Jerry Faust
July 5, 2019, 8:29 PM

Submitted changes to 15 RGS files that were in an older format, inconsistent with the rest; removing the version reference, and including the VersionIndependentProgID, among other changes. The changed files were:

  1. DrawingRectangle.rgs

  2. Expression.rgs

  3. Function.rgs

  4. GdalDataset.rgs

  5. GdalDriver.rgs

  6. GdalDriverManager.rgs

  7. GdalRasterBand.rgs

  8. GdalUtils.rgs

  9. Histogram.rgs

  10. Identifier.rgs

  11. OgrDatasource.rgs

  12. OgrLayer.rgs

  13. SelectionList.rgs

  14. UndoList.rgs

  15. WmsLayer.rgs



Jerry Faust
July 5, 2019, 5:42 PM
Notes from email dated June 27, 2019::

Here are the results of my analysis and my recommendation.

  1. The version number for the TypeLib of MapWinGIS is in the IDL file, and should be kept up to date. It is currently set at 5.0.

  2. I removed all version numbers from the RGS files of the individual objects

    1. Many were at 4.9

    2. OgrLayer and OgrDatasource were back at 1.0

    3. Many were unspecified

    4. With these removed, my VB6 application continued to behave properly.

  3. I verified the consistency of all TypeLib references within the RGS files. OgrLayer and OgrDatasource referenced a TypeLib GUID that did not exist in the registry. I changed them all to match the TypeLib for MapWinGIS.

  4. I have confirmed that an object without a ProgID CANNOT be created as a late-bound object (using VB6's CreateObject, which I believe is equivalent to the CoCreateInstance API function).

    1. As such, all objects should specify a ProgID. Some libraries specifically expose 'noncreatable' objects (they cannot be created by the caller, but can only be created by a function of another object), but our library does not appear to have any (at least according to the IDL).

  5. Many of the RGS files also specify a VersionIndependentProgID. I believe this is the norm, and we should always include this as well

    1. All of our ProgID's have a version of 1 (e.g. "MapWinGIS.Shapefile.1"). Based on how we manage this library, I think these should always stay at version 1.

    2. The VersionIndependentProgID is simply the ProgID without the version number (e.g. "MapWinGIS.Shapefile"). This is typically used to create the object if you don't want or need a specific version. Ours objects will always only have one version.

  6. The Shape.rgs file has a format that I think represents a 'standard' that we should apply to all of the RGS files. There are 54 of them to review, and we need to make sure all of the GUIDs are not modified (watching for copy/paste errors).

Here is the format of the Shape.rgs file:


Paul Meems
July 5, 2019, 1:14 PM

I’ve made a PowerShell script that is just calling {{New-Object -ComObject MapWinGIS.*;}} for each ComObject.

It shows several ComObjects cannot be found. One of them was {{MapWinGIS.GdalUtils}}. I changed its .rgs file and now it can be found.
See my

Now we can change the other rgs-files as well.



Jerry Faust


Paul Meems



Epic Link


Affects versions


Fix versions