Hi,

There has been a lot of downloading but very little feedback, I
suppose I could assume everyone is happy and there have been no
problems.  But how likely is that!

Let me know what you think (or want). Please mention the operating
system being used.

Thanks,
Dennis
----------------------------
Dennis Bareis (dbareis@...)
Melbourne, AUSTRALIA.

http://www.labyrinth.net.au/~dbareis/index.htm

  - Contains heaps of my own FREE software (OS/2, Windows & Linux):
    * PPWIZARD, HTML preprocessor (or rexx/Javascript etc)
      #define, #include, #import, #if and many other commands.
      Powerful macros, programmable, imports SQL, auto tag examples,
      Tested on OS/2, Windows, DOS & Linux (and more).
    * Pure REXX code for CRC16 & CRC32 routines.
  - Heaps of COMMENTED OS/2, HTML, Java and other links
----------------------------

Hi Dennis

You certainly seem to have put some effort into this project!
Great stuff!

This may be trivial but I have been unable to add a new dialog.

I added the following in company.mmh:

<$Table "Dialog">
   #(
      <$Row
                Dialog = "LicenseKeyDlg"
            HCentering = "50"
            VCentering = "50"
                 Width = "370"
                Height = "270"
            Attributes = "3"
                 Title = "[ProductName] v[ProductVersion] [Setup]"
         Control_First = "Next"
       Control_Default = "Next"
        Control_Cancel = "Cancel"
      >
   #)
<$/Table>

The error message says:
There is no column "#1" in the table "Dialog"
Available columns: Dialog(sic!) HCentering etc...

Help appreciated.

Thanks - John

Hi Dennis

Further to my earlier posting, I solved that problem by eliminating
the spaces before and after the '=' signs.

However, I am having difficulty adding more than about 12 Control
Rows for the new Dialog.

MAKEMSI works fine up to about 12 consecutive Row adds, then fails.

I have tried with a set of similar Text type rows and so the problem
is not in my coding.

Is there a limit in MSI or in MAKEMSI.

Unfortunately, the error message scrolls off the screen so fast it is
impossible to read these lines and they do not appear in the console
log or the compile error log.

Is there any way of slowing the console output -- piping it
through "more" doesn't work.

From what I glimpsed, it seemed to indicate a Stack problem.


Thanks - John

Hi,

On 21 May 2003 at 15:24, dumbarton13 wrote:

> You certainly seem to have put some effort into this project!
> Great stuff!

Yes its taken me a long long time...

> <$Table "Dialog">
>   #(
>      <$Row
>                Dialog = "LicenseKeyDlg"

As you have already noticed should not have spaces around the equal
signs. Most of the stuff was taken to be positional parameters, more
PPWIZARD checking may have detected the error, I will probably look
into this when/if I get time..

> The error message says:
> There is no column "#1" in the table "Dialog"
> Available columns: Dialog(sic!) HCentering etc...

Bye,
Dennis
----------------------------
Dennis Bareis (dbareis@...)
Melbourne, AUSTRALIA.

http://www.labyrinth.net.au/~dbareis/index.htm

  - Contains heaps of my own FREE software (OS/2, Windows & Linux):
    * PPWIZARD, HTML preprocessor (or rexx/Javascript etc)
      #define, #include, #import, #if and many other commands.
      Powerful macros, programmable, imports SQL, auto tag examples,
      Tested on OS/2, Windows, DOS & Linux (and more).
    * Pure REXX code for CRC16 & CRC32 routines.
  - Heaps of COMMENTED OS/2, HTML, Java and other links
----------------------------

Hi,

On 21 May 2003 at 20:51, dumbarton13 wrote:

> I am having difficulty adding more than about 12 Control Rows
> for the new Dialog.
>
> MAKEMSI works fine up to about 12 consecutive Row adds, then fails.

Please tell me exactly what is going wrong.  Either cut and paste
error messages or capture the screen as a graphic.  My windows
software links list a few free tools.

If you can send me (zipped) the failing script I can also try it
here.

If you can clean out the "out\?\Log" directory (and maybe "Msi" as
well) and send me whatever files it contains after a failure this
might also tell me more.

Which operating system are you using?

> I have tried with a set of similar Text type rows and so the problem
> is not in my coding.
>
> Is there a limit in MSI or in MAKEMSI.

There are no MAKEMSI limits and I doubt there are any Windows
Installer ones...
Its more likely an issue with the data you are entering into the
tables as I don't know what the error is its hard to say more.


> Unfortunately, the error message scrolls off the screen so fast it is
> impossible to read these lines and they do not appear in the console
> log or the compile error log.

You guessed it please send me these also...


> Is there any way of slowing the console output -- piping it
> through "more" doesn't work.

A screen dump as mentioned above might catch it (if your fast
enough).

If the error happens during the second window which is compressing
the files then it can be paused, add the following at the START of
your ".mm" file:

      #define COMPILE_MAKECAB_EXE_DOS_WAIT_FOR_EXIT /k

On some (most?) operating system you should be able to increase the
screen buffer size so that you can press pause and scroll back.

What color is the text, is it before after or during green text?

> From what I glimpsed, it seemed to indicate a Stack problem.

That doesn't sound good!


Bye,
Dennis
----------------------------
Dennis Bareis (dbareis@...)
Melbourne, AUSTRALIA.

http://www.labyrinth.net.au/~dbareis/index.htm

  - Contains heaps of my own FREE software (OS/2, Windows & Linux):
    * PPWIZARD, HTML preprocessor (or rexx/Javascript etc)
      #define, #include, #import, #if and many other commands.
      Powerful macros, programmable, imports SQL, auto tag examples,
      Tested on OS/2, Windows, DOS & Linux (and more).
    * Pure REXX code for CRC16 & CRC32 routines.
  - Heaps of COMMENTED OS/2, HTML, Java and other links
----------------------------

I was running MAKEMSI under Windows 98SE.

Hence my comment about the console log running through the (fixed) 25-
line DOS Command window too quickly to view the error message (what
was not included in the log files). Also a Notepad window flashed
opened for a short period in the final stages.

The good news is that I have switched to a Win2K development system
and there is no problem with the number of Control Rows.  The exact
same script runs just fine.

When I have a moment, I will put together the scripts and logs so
you can reproduce the problem.

Regards - John

Hi,

On 22 May 2003 at 15:29, dumbarton13 wrote:

> The good news is that I have switched to a Win2K development system
> and there is no problem with the number of Control Rows.
> The exact same script runs just fine.

Thats good to hear.


> I was running MAKEMSI under Windows 98SE.
> When I have a moment, I will put together the scripts and logs so  you
> can reproduce the problem.

I have 98SE in one of my VMWARE boxes so I can test it there.

Thanks,
Dennis
----------------------------
Dennis Bareis (dbareis@...)
Melbourne, AUSTRALIA.

http://www.labyrinth.net.au/~dbareis/index.htm

  - Contains heaps of my own FREE software (OS/2, Windows & Linux):
    * PPWIZARD, HTML preprocessor (or rexx/Javascript etc)
      #define, #include, #import, #if and many other commands.
      Powerful macros, programmable, imports SQL, auto tag examples,
      Tested on OS/2, Windows, DOS & Linux (and more).
    * Pure REXX code for CRC16 & CRC32 routines.
  - Heaps of COMMENTED OS/2, HTML, Java and other links
----------------------------

Hi Dennis

Before I forget, just three points from testing on Win98SE.

As per a previous email, NONE of these problems occur on Win2K.

1.  The complete console message screen is not logged to .CON

The major difficulty I had was that the detailed error message
scrolled off the 25-line DOS Window before I could read it and
attempts to pipe it through More had no effect.

The DOS Window ended with a large "Fatal Error" display, but the
details had already scrolled off.

The detailed error message was not included in the log.


2.  A warning of an illegal switch /Q

Again, this comes up so fast it is impossible to nail with certainty
but, from about 100 glimpses, it seems to be in module VbsCa.mmh.

I don't now whether that makes any sense.

The warning does not appear in either log file.


3.  Wrong character set in Help Files

Using MakeMsi.chm, the font on Win98SE in the left-hand pane (used
for Contents/Index/Search/Favorites) on my development PC, has
resorted to the very first font in the alphabetical lists of fonts on
the system.

This PC has hundreds of fonts (mainly for use in developing graphics
with Adobe Illustrator).

Unfortunately, the first is "Adobe AltBold" which is a ancillary font
with special ligatures instead of regular characters.  As a result
the Contents, Index, etc. are completely unintelligible!!

This may be my PC but other help (*.chm") do not have this problem.

There must be a way of setting the default font for Windows Help.


Regards - John

Hi,

On 23 May 2003 at 3:55, dumbarton13 wrote:

> Before I forget, just three points from testing on Win98SE.
> As per a previous email, NONE of these problems occur on Win2K.
>
> 1.  The complete console message screen is not logged to .CON

Only PPWIZARD generated output goes to the CON file.


> The major difficulty I had was that the detailed error message
> scrolled off the 25-line DOS Window before I could read it and
> attempts to pipe it through More had no effect.


> The DOS Window ended with a large "Fatal Error" display, but the
> details had already scrolled off.

You can probably catch it (except for any stderr and there are tools
for this also) with:

     command.com /c mm testmsi.mm > output.txt

However this seemed to cause the compile step problems assuming you
get that far, and at least my VMWARE box I rebooted (however it
causes me problems like this occassionaly anyway).

How long is your "PATH"?

If you send me the script you are executing and perhaps the output
from:

      set > setwin98.txt

I might be able to reproduce the problem here.

> 2.  A warning of an illegal switch /Q

Ignore this, know issue as documented in the manual.

This will be from an external command which can't be captured.


> 3.  Wrong character set in Help Files
>
> Using MakeMsi.chm, the font on Win98SE in the left-hand pane (used for
> Contents/Index/Search/Favorites) on my development PC, has resorted to
> the very first font in the alphabetical lists of fonts on the system.
> This PC has hundreds of fonts (mainly for use in developing graphics
> with Adobe Illustrator).
> Unfortunately, the first is "Adobe AltBold" which is a ancillary font
> with special ligatures instead of regular characters.  As a result the
> Contents, Index, etc. are completely unintelligible!!
> This may be my PC but other help (*.chm") do not have this problem.
> There must be a way of setting the default font for Windows Help.

I have had no reports of this from anyone else, perhaps a standard
font has been removed.  I know of no way to change the font in the
left pane, I will investigate when I have some time.

Thanks,
Dennis

----------------------------
Dennis Bareis (dbareis@...)
Melbourne, AUSTRALIA.

http://www.labyrinth.net.au/~dbareis/index.htm

  - Contains heaps of my own FREE software (OS/2, Windows & Linux):
    * PPWIZARD, HTML preprocessor (or rexx/Javascript etc)
      #define, #include, #import, #if and many other commands.
      Powerful macros, programmable, imports SQL, auto tag examples,
      Tested on OS/2, Windows, DOS & Linux (and more).
    * Pure REXX code for CRC16 & CRC32 routines.
  - Heaps of COMMENTED OS/2, HTML, Java and other links
----------------------------

In our current project, we had a number of situations where I had,
for example, to add identical ControlConditions for a subset of
Dialogs.

I had my hands full learning Windows Installer and so coded the Row
entries in the VS Editor, using its editing facilities.

The scenario is:

For all the Dialogs in the Dialog Table
   Those that meet a particular Condition (eg presence of a Control)
     Add a standard Row entry into another Table

With your expertise in PPwizard/Rexx, would it be possible to code
such a macro or would you suggest a different solution, perhaps,
using embedded VBscript.

The development process is all about speedy iterations!

Suggestion #1
~~~~~~~~~~~~~
In using MAKEMSI, I have several times "wasted" a test iteration for
two particular reasons:

   1.  The target MSI was still open in Orca
   2.  The edited .mm/.mmh files had not been saved.

I know you probably can't determine whether either of these
conditions are true.

However, in my case, a reminder with an option to continue or abort
at the beginning of the MM compile process would be a very worthwhile
tradeoff for a 10-minute testing cycle wasted!

Suggestion #2
~~~~~~~~~~~~~
I am very particular about testing on non-development systems and so
the testing cycle includes a network transfer or CD-RW burning of the
resulting .msi and .cab's.

Again I have "wasted" several test iterations because the MM had not
been run on the changed scripts!

It would help enormously if you could add the time (and date) to
the "Summary" which appears at the end of MM run.

This would provide a record in the Command Prompt window of when the
setup had been last compiled.

I appreciate this might be a more appropriate topic for the
public.platformsdk.msi group but I would appreciate your views and
whether I can adjust a security setting from within MAKEMSI.

I will post a public message if you advise.

The question is:
~~~~~~~~~~~~~~~~
It seems to me that, using Orca (for example), anyone can view, edit
or re-use an MSI installation file.

Coming from a long IS Pro background, this seems the antithesis of
the Installshield approach!  (and, maybe, is Microsoft's intent,
since Installshield really only re-packages Microsoft OS install
functionality)

The bottom line is:  Can I prevent others from viewing or, even
worse, maliciously editing my MSI file?

Hi,


On 5 Jun 2003 at 2:03, dumbarton13 wrote:
> It seems to me that, using Orca (for example), anyone can view,
> edit or re-use an MSI installation file.

This is I believe a major design goal of Windows Installer
technology...


> Coming from a long IS Pro background, this seems the antithesis of
> the Installshield approach!  (and, maybe, is Microsoft's intent,
> since Installshield really only re-packages Microsoft OS install
> functionality)
> The bottom line is:  Can I prevent others from viewing or, even
> worse, maliciously editing my MSI file?


MAKEMSI will not limit what you can do with an MSI.  It simply
doesn't have all the GUI tools that a commercial tool might have but
it makes up for this in automation etc.

As for your issue, I'm not happy with this particularly where
passwords are concerned.
There is a read-only bit in one of the summary items perhaps this
might prevent people using ORCA to update it?  That is not security
just better than nothing.

I think it is now also possible to attach certificates but I don't
know the details, but again anyone can edit.

You can hide certain things, for example in the _Streams table as
demonstrated in one of the MAKEMSI tips.

You can also "hide" in script such as a encoded VBS (CA  over
external file) but again this is "better than nothing" security.

If you think of anything or find out more I'd be very interested in
what you find out and end up doing.

Bye
Dennis

----------------------------
Dennis Bareis (dbareis@...)
Melbourne, AUSTRALIA.

http://www.labyrinth.net.au/~dbareis/index.htm

  - Contains heaps of my own FREE software (OS/2, Windows & Linux):
    * PPWIZARD, HTML preprocessor (or rexx/Javascript etc)
      #define, #include, #import, #if and many other commands.
      Powerful macros, programmable, imports SQL, auto tag examples,
      Tested on OS/2, Windows, DOS & Linux (and more).
    * Pure REXX code for CRC16 & CRC32 routines.
  - Heaps of COMMENTED OS/2, HTML, Java and other links
----------------------------

Hi,

On 5 Jun 2003 at 1:41, dumbarton13 wrote:

> The development process is all about speedy iterations!
>
> Suggestion #1
> ~~~~~~~~~~~~~
> In using MAKEMSI, I have several times "wasted" a test iteration for
> two particular reasons:
>
>   1.  The target MSI was still open in Orca

I can't tell but I can make it fail early and with a better message
which I have now done it will be in the next release.
For now you could create a batch file, copy MM's contents and add a
delete command and checking if you want.

>   2.  The edited .mm/.mmh files had not been saved.

I can't do anything about this...

> However, in my case, a reminder with an option to continue or abort at
> the beginning of the MM compile process would be a very worthwhile
> tradeoff for a 10-minute testing cycle wasted!

My suggestion is either to create your own batch file or your own
header which front ends "makemsi.mmh", a quick hack job follows:

;--- Check files ----
#info "PLEASE CHECK THAT ALL FILES HAVE BEEN SAVED"
#evaluate ^^ ^Fred = linein()^
#if Fred <> ""
    ;--- Anything but ENTER on its own ---
     #error "You aborted the MAKEMSI build"
#endif

;--- Include MAKEMSI ---
#include "MAKEMSI.MMH"


> Suggestion #2
> ~~~~~~~~~~~~~
> I am very particular about testing on non-development systems and so
> the testing cycle includes a network transfer or CD-RW burning of the
> resulting .msi and .cab's.

You might also consider using VMWARE or similar virtual machine
software.

You could add a step to the end of your batch file or build to do
this.

Have a look at the "Enable Platform Definition Creation" section, the
directory could be on a network drive.


> Again I have "wasted" several test iterations because the MM had not
> been run on the changed scripts!


> It would help enormously if you could add the time (and date) to the
> "Summary" which appears at the end of MM run.

Maybe for your specific situation more generically it would need to
do this for MM and MMH files.  Note that the generated MSI should
contain this information also.

If you do create a header or even just place in your script (not as
nice) then add (one line):

#evaluate ^^ ^call Summary "MM DATED",
FileQueryDateTime('<?InputFile>')^

Bye,
Dennis
----------------------------
Dennis Bareis (dbareis@...)
Melbourne, AUSTRALIA.

http://www.labyrinth.net.au/~dbareis/index.htm

  - Contains heaps of my own FREE software (OS/2, Windows & Linux):
    * PPWIZARD, HTML preprocessor (or rexx/Javascript etc)
      #define, #include, #import, #if and many other commands.
      Powerful macros, programmable, imports SQL, auto tag examples,
      Tested on OS/2, Windows, DOS & Linux (and more).
    * Pure REXX code for CRC16 & CRC32 routines.
  - Heaps of COMMENTED OS/2, HTML, Java and other links
----------------------------

Hi,

On 5 Jun 2003 at 1:20, dumbarton13 wrote:

> In our current project, we had a number of situations where I had, for
> example, to add identical ControlConditions for a subset of Dialogs.


> I had my hands full learning Windows Installer and so coded the Row
> entries in the VS Editor, using its editing facilities.

You can use msidiff to get it back into "MAKEMSI" format if you wish.


> The scenario is:
>
> For all the Dialogs in the Dialog Table
>   Those that meet a particular Condition (eg presence of a Control)
>     Add a standard Row entry into another Table
>
> With your expertise in PPwizard/Rexx, would it be possible to code
> such a macro or would you suggest a different solution, perhaps, using
> embedded VBscript.

Rather than work backwards, if would be much similer to create a
macro which adds the dialog controls AND updates the other table at
the same time.

Macros can be simply templates for eample:

#(
       #define MyMacro
         <$Table "Control">
              <$Row  .... {$Parm1}    ... {$Parm2}>
          <$/Table>

         <$Table "OtherTable">
              <$Row  .... {$Parm3}>
          <$/Table>
#)

To use the above macro

        <$MyMacro Parm1="1" Parm2="2" Parm3="3">

Otherwise if you can put the query in a where clause on a single
table the the "Row" command can handle it, in which case the "CODE"
parameter could also be used and you could use imbedded VBSCRIPT
(don't try to use MAKEMSI macros/routines) to update the second
table.

If you need more help let me know and/or send failed attempts.

Bye,
Dennis
----------------------------
Dennis Bareis (dbareis@...)
Melbourne, AUSTRALIA.

http://www.labyrinth.net.au/~dbareis/index.htm

  - Contains heaps of my own FREE software (OS/2, Windows & Linux):
    * PPWIZARD, HTML preprocessor (or rexx/Javascript etc)
      #define, #include, #import, #if and many other commands.
      Powerful macros, programmable, imports SQL, auto tag examples,
      Tested on OS/2, Windows, DOS & Linux (and more).
    * Pure REXX code for CRC16 & CRC32 routines.
  - Heaps of COMMENTED OS/2, HTML, Java and other links
----------------------------

I have an .MM file which provides the basic installation information
for a program. The program comes in several flavours which are
differentiated by the contents of a data directory.

The plan was to use the the original .MM file (a.mm - for the sake of
argument) as a base and import it into numerous other .MM files to
add this remaining information.

A.mm built fine and produced an .msi file with the required
information. But this required modifying a.mm when I wanted to build
a different version. I first tried moving the data stuff into another
file (b.mm) and importing a.mm from that file.

This produced an error which was near identical to the one shown
below. I then removed everything from b.mm except the import.

The result was the following error:

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!
!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!![ Fatal
Error ]!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!
Location  : line 467 of "F:\Work\Restless
Lemon\projects\Cameon\DGCheckmate V2\I nstall\RLD.MMH" File Stack:
Army.MM(3) -> DGCheckmate.MM(1) -> Dept.mmh(100) ->
RLD.MMH(467)
File Line : #DefineRexx
More Info?: out\Army.CON (console file)
           : PPWIZARD.ERR (error file)
Detected @: Line 11,092 of PPWIZ4MM.4MM (v03.103)
PPWIZARD  : Length 423,369 bytes.  TimeStamped 20030413083622 Running
In: WIN32 ("WIN2K"), REXX-Regina_2.2 4.80 17 Jun 2001 Reason ~~~~~~
I/O failure on "F:\Work\Restless Lemon\projects\Cameon\DGCheckmate V2
\Install\DG CmLicence.rtf"
(). !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!
!!!!

DGCmLicence.rtf is the name of the licence file. "DGCheckmate.MM"
is "a.MM" "Army.MM" is "b.MM" "RLD.MMH" is a modified version
of "company.mmh"

Line 3 from Army.MM is:

#include DGCheckmate.MM

Er... Any suggestions as to why importing should cause this behaviour?

Jon Senior

Hi,

On 11 Jun 2003 at 22:57, jcodous wrote:
> Detected @: Line 11,092 of PPWIZ4MM.4MM (v03.103)
> PPWIZARD  : Length 423,369 bytes.  TimeStamped 20030413083622 Running
> In: WIN32 ("WIN2K"), REXX-Regina_2.2 4.80 17 Jun 2001 Reason ~~~~~~
> I/O failure on "F:\Work\Restless Lemon\projects\Cameon\DGCheckmate V2
> \Install\DG CmLicence.rtf" ().
> !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> !!!!!! !!!!
>
> DGCmLicence.rtf is the name of the licence file. "DGCheckmate.MM" is
> "a.MM" "Army.MM" is "b.MM" "RLD.MMH" is a modified version of
> "company.mmh"
>
> Line 3 from Army.MM is:
>
> #include DGCheckmate.MM
>
> Er... Any suggestions as to why importing should cause this behaviour?

No I don't know what causes if (I will have to look into it) however
I have a solution which worked for me when I had similar the other
day.  I will send a zip containing an updated file directly to you
please try and let me know if it fixes it.

Also its only a convention but I use ".MMH" for header (included)
files which are not meant to be used standalone.

Bye,
Dennis
----------------------------
Dennis Bareis (dbareis@...)
Melbourne, AUSTRALIA.

http://www.labyrinth.net.au/~dbareis/index.htm

  - Contains heaps of my own FREE software (OS/2, Windows & Linux):
    * PPWIZARD, HTML preprocessor (or rexx/Javascript etc)
      #define, #include, #import, #if and many other commands.
      Powerful macros, programmable, imports SQL, auto tag examples,
      Tested on OS/2, Windows, DOS & Linux (and more).
    * Pure REXX code for CRC16 & CRC32 routines.
  - Heaps of COMMENTED OS/2, HTML, Java and other links
----------------------------

Hi,

In case you haven't realised I have been making regular updates and
I'm currently uploading the latest changes.

This includes some suggestions and issues from recent feedback.

Bye,
Dennis
----------------------------
Dennis Bareis (dbareis@...)
Melbourne, AUSTRALIA.

http://www.labyrinth.net.au/~dbareis/index.htm

  - Contains heaps of my own FREE software (OS/2, Windows & Linux):
    * PPWIZARD, HTML preprocessor (or rexx/Javascript etc)
      #define, #include, #import, #if and many other commands.
      Powerful macros, programmable, imports SQL, auto tag examples,
      Tested on OS/2, Windows, DOS & Linux (and more).
    * Pure REXX code for CRC16 & CRC32 routines.
  - Heaps of COMMENTED OS/2, HTML, Java and other links
----------------------------

The MAKEMSI run produces a cabinet file which I presume is a
necessary step before it is added back into the MSI database.

My MSI database is currently over 20Mb, the majority of which are,
of course, compressed files.

What is best practice?  Should I leave everything in the MSI
database or extract the cabinet stream and distribute the resultant,
smaller MSI database plus the cabinet file?


On how to do the latter, I noted somewhere in your sources or
documentation that MAKEMSI does not currently do this step.

I presume I would use msidb with the '-k' switch to remove the
stream and then fixup the Cabinet field in the Media Table with the
name of the external cabinet file (with no '#').  Is that all?  The
MSI docs are very confusing!

Thanks - John

I note your error reports on the MSI forum!

Here's another you can check and post:

The MSI docs says that the entry for summary.security should be 2
for 'read-only recommended' and 4 for 'read-only enforced'.

I think these should be 1 and 2 respectively.

Regards - John

Hi,

On 13 Jun 2003 at 15:06, dumbarton13 wrote:

> The MAKEMSI run produces a cabinet file which I presume is a
> necessary step before it is added back into the MSI database.

It is required as currently it is the only supported method. Other
possibilities are one or more external cabs (I personally don't like)
or all files external but not in cabs at all (and I think compressed
or uncompressed - haven't looked at this for a while).

> My MSI database is currently over 20Mb, the majority of which are, of
> course, compressed files.
>
> What is best practice?  Should I leave everything in the MSI
> database or extract the cabinet stream and distribute the resultant,
> smaller MSI database plus the cabinet file?

I can't see the advantage, you must see one, please tell me!
I can see disadvatages, the cab file could get lost or worse swapped
(2 files to transfer).


> On how to do the latter, I noted somewhere in your sources or
> documentation that MAKEMSI does not currently do this step.

You could create a second step to tweek the generated MSI to
extract/remove the cab etc to do what you wish.

If I know exactly what you want to do and why then I could look at
making the changes.  And between us we can test that the changes are
OK...


> I presume I would use msidb with the '-k' switch to remove the
> stream and then fixup the Cabinet field in the Media Table with the
> name of the external cabinet file (with no '#').  Is that all?  The
> MSI docs are very confusing!

Don't I know it (I think they are actually pretty hopeless)!  I think
that is it, as you are leaving the files compressed and still have 1
only cab, no other Media table bits will need tweeking and you won't
need to touch the summary stream or each file entry.
The CAB I think will need top be placed in the same directory as the
MSI.

I am really interested in the perceived advantage with this approach.

Bye,
Dennis



----------------------------
Dennis Bareis (dbareis@...)
Melbourne, AUSTRALIA.

http://www.labyrinth.net.au/~dbareis/index.htm

  - Contains heaps of my own FREE software (OS/2, Windows & Linux):
    * PPWIZARD, HTML preprocessor (or rexx/Javascript etc)
      #define, #include, #import, #if and many other commands.
      Powerful macros, programmable, imports SQL, auto tag examples,
      Tested on OS/2, Windows, DOS & Linux (and more).
    * Pure REXX code for CRC16 & CRC32 routines.
  - Heaps of COMMENTED OS/2, HTML, Java and other links
----------------------------

Hi Dennis

Thanks for your reply.

I guess my question came from using IS Pro where one or more cabinet
files is the norm.

I was interested to find out how it was generally being done in
Windows Installer.

The notion of cabinet files comes, of course, from the historical
use of 1.44Mb floppy disks as the distribution media (ending with MS-
Office on 20+ floppies!).

With CD/DVD distribution and Web downloading, there is now no such
size contraints.

I agree with you one all-inclusive file is safer and will go that
route.


Regards - John

Hi Dennis

Two hassles with the MS-supplied template which I am sure you have
noticed long ago!

1. Control Width > 370 (the Wizard width)

The Controls BannerLine, BannerBitmap, BottomLine all have widths
set to 374.

I know (in the case of the lines, anyway) that this is done so that
the line appears to join up with the vertical window frame at the
right-hand side.  If you set the width to 370 there is a small but
visible gap and the lines don't join neatly.

However, if you use 374, Windows Installer generates a error message
in the log each time.  This doesn't appear to do any harm but these
errors could potentially confuse the issue when an installation goes
wrong for a real reason.

I notice that commercial install packages do not exceed the window
width and accept the small gap.


2. "repaires"

This is mis-spelt in the Control Table entry for MaintenanceTypeDlg,
RepairButton, [Progress2].


Fortunately with MakeMSI it is very a simple matter to make the
corrections!

Regards - John

Hi,

On 13 Jun 2003 at 15:08, dumbarton13 wrote:
> I note your error reports on the MSI forum!

I don't have much confidence but I'm giving it a go...

> Here's another you can check and post:
> The MSI docs says that the entry for summary.security should be 2 for
> 'read-only recommended' and 4 for 'read-only enforced'.

I have noticed something a bit suss here before and I will report it
as I have validated it again, but in general I'd prefer it you
reported it instead in future, for starters you know the details and
coming from more than one source looks better, I don't want them to
ignore me completely.

Bye,
Dennis
----------------------------
Dennis Bareis (dbareis@...)
Melbourne, AUSTRALIA.

http://www.labyrinth.net.au/~dbareis/index.htm

  - Contains heaps of my own FREE software (OS/2, Windows & Linux):
    * PPWIZARD, HTML preprocessor (or rexx/Javascript etc)
      #define, #include, #import, #if and many other commands.
      Powerful macros, programmable, imports SQL, auto tag examples,
      Tested on OS/2, Windows, DOS & Linux (and more).
    * Pure REXX code for CRC16 & CRC32 routines.
  - Heaps of COMMENTED OS/2, HTML, Java and other links
----------------------------

Hi,

On 14 Jun 2003 at 1:56, dumbarton13 wrote:

> Two hassles with the MS-supplied template which I am sure you have
> noticed long ago!
>
> 1. Control Width > 370 (the Wizard width)
>
> The Controls BannerLine, BannerBitmap, BottomLine all have widths set
> to 374.
>
> I know (in the case of the lines, anyway) that this is done so that
> the line appears to join up with the vertical window frame at the
> right-hand side.  If you set the width to 370 there is a small but
> visible gap and the lines don't join neatly.
>
> However, if you use 374, Windows Installer generates a error message
> in the log each time.  This doesn't appear to do any harm but these
> errors could potentially confuse the issue when an installation goes
> wrong for a real reason.
>
> I notice that commercial install packages do not exceed the window
> width and accept the small gap.
>
>
> 2. "repaires"
>
> This is mis-spelt in the Control Table entry for MaintenanceTypeDlg,
> RepairButton, [Progress2].
>
>
> Fortunately with MakeMSI it is very a simple matter to make the
> corrections!

If you send me these corrections I can include them in the next
version.

Bye,
Dennis
----------------------------
Dennis Bareis (dbareis@...)
Melbourne, AUSTRALIA.

http://www.labyrinth.net.au/~dbareis/index.htm

  - Contains heaps of my own FREE software (OS/2, Windows & Linux):
    * PPWIZARD, HTML preprocessor (or rexx/Javascript etc)
      #define, #include, #import, #if and many other commands.
      Powerful macros, programmable, imports SQL, auto tag examples,
      Tested on OS/2, Windows, DOS & Linux (and more).
    * Pure REXX code for CRC16 & CRC32 routines.
  - Heaps of COMMENTED OS/2, HTML, Java and other links
----------------------------

Hi,

On 14 Jun 2003 at 1:20, dumbarton13 wrote:

> I was interested to find out how it was generally being done in
> Windows Installer.

I don't really know how it is "generally" done but I have my own
ideas about what is best.


> The notion of cabinet files comes, of course, from the historical use
> of 1.44Mb floppy disks as the distribution media (ending with MS-
> Office on 20+ floppies!).
>
> With CD/DVD distribution and Web downloading, there is now no such
> size contraints.

Eventually I do wish to support multiple cabs for those situations
where it might take more than a CD. An then they would need to be
external.

> I agree with you one all-inclusive file is safer and will go that
> route.

I have added support for the 1 cab file to be external as well as
internal.

Bye,
Dennis
----------------------------
Dennis Bareis (dbareis@...)
Melbourne, AUSTRALIA.

http://www.labyrinth.net.au/~dbareis/index.htm

  - Contains heaps of my own FREE software (OS/2, Windows & Linux):
    * PPWIZARD, HTML preprocessor (or rexx/Javascript etc)
      #define, #include, #import, #if and many other commands.
      Powerful macros, programmable, imports SQL, auto tag examples,
      Tested on OS/2, Windows, DOS & Linux (and more).
    * Pure REXX code for CRC16 & CRC32 routines.
  - Heaps of COMMENTED OS/2, HTML, Java and other links
----------------------------

Hi Dennis

As per my suggestion, I have added the following line to PpWiz4MM.4mm

     call AddSummaryLine 'Completed at', NiceDateTime()

in two places before the existing line

     call GenerateSummaryLines

Together with your addition of a line showing the modification date
of the .MM file in MakeMsi v03.164, this provides the extra summary
info I was looking for.

Regards - John

Hi,

On 15 Jun 2003 at 2:50, dumbarton13 wrote:

> As per my suggestion, I have added the following line to PpWiz4MM.4mm
>
>     call AddSummaryLine 'Completed at', NiceDateTime()
> in two places before the existing line
>     call GenerateSummaryLines

We must have got our wires crossed, I did not mean to say that you
needed to update "PpWiz4MM.4mm". You would need to update the version
for every release...

I have a "dennis.mmh" which includes "dept.mmh" etc.  That is where I
would generally place that sort of code. However I don't think that
would work for your case, the date/time would be as at the time the
"AddSummaryLine" was added. Maybe I should allow the execution to be
delayed...

Bye,
Dennis

----------------------------
Dennis Bareis (dbareis@...)
Melbourne, AUSTRALIA.

http://www.labyrinth.net.au/~dbareis/index.htm

  - Contains heaps of my own FREE software (OS/2, Windows & Linux):
    * PPWIZARD, HTML preprocessor (or rexx/Javascript etc)
      #define, #include, #import, #if and many other commands.
      Powerful macros, programmable, imports SQL, auto tag examples,
      Tested on OS/2, Windows, DOS & Linux (and more).
    * Pure REXX code for CRC16 & CRC32 routines.
  - Heaps of COMMENTED OS/2, HTML, Java and other links
----------------------------

Hi Dennis

Your MakeMsi installation adds a system-wide entry called "Display
MD5" in the dropdown menu which appears when you right-click a file
in Windows Explorer.

This I have found more of a hassle than a help (what do you do with
the MD5 value anyway?)

The hassle is caused because
1. The vbs script behind it is immediately flagged as malicious by
our AntiVirus program and quarantined.
2. For system files (eg DLL's), "Display MD5" is activated when the
filename is double-clicked rather than the Dependency analyzer we
are used to seeing.

I have removed the entries from the registry to solve the problem.
These were created by your RegKey006 and RegKey007 rows in the
Registry Table in MakeMsi.msi.

For the v03.164 update, I used Orca to delete these rows before
running the install.

Could you make this functionality a custom Feature?  This would be
more in line with "good practice".


While on this, can I suggest you install to C:\Program Files\MakeMsi.
All capital folder names such as MAKEMSI are so ugly!

Also, we have so many folders under C:\Program Files that taking two
for your installation is positively greedy!  Why not just put the
MakeMsi.htm file in the MakeMsi folder as well?


Please take the above as constructive criticism -- having now become
very familiar with your methodology and scripts, I think you are
making a terrific contribution!  I hope others out there using
MakeMsi will give you feedback and encouragement as I have.


Regards - John

Hi Dennis

Further to my earlier posting, I see you have already made
GenerateMD5 a Feature but as a sub-feature of Complete.

By going to a 'Custom' installation and de-selecting this sub-
feature, I can eliminate my 'Display MD5' problem without resorting
to Orca!

However, I think you should set the default on this sub-feature to
Absent so that it is not installed automatically in a 'Typical'
installation.

Regards - John