Is there any guide for MSW application deployment?

193 views
Skip to first unread message

ardi

unread,
May 28, 2012, 12:02:06 PM5/28/12
to wx-users
While tuning my software for OSX, I found the following wiki resource
very valuable, with hints on how to better integrate wxWidgets apps
with OSX, bundle them, add icons, add file associations, etc...
http://wiki.wxwidgets.org/WxMac-specific_topics

I wonder if there's something similar for MSW. I never studied MSW
deeply, so a "basic to the point guide" like that OSX page would be
really helpful. Is there anything like that?

TIA

ardi

Fulvio Senore

unread,
Jun 1, 2012, 12:35:44 PM6/1/12
to wx-u...@googlegroups.com
I do not know where to find that information but, since nobody seems to
know it, I can say something about installers for Windows.

I recommend InnoSetup: it is very easy to use and it works well.

At the time I spent half a day trying to use NSIS with no luck: I was
not even able to understand how to build a setup.
Then I tried InnoSetup and I was able to create one in five minutes.
Since then I used it and I am very satisfied.

I am not saying that NSIS does not work, simply I was not able to
understand how to make it work.

Hope this helps.

Fulvio Senore

David Connet

unread,
Jun 1, 2012, 12:42:17 PM6/1/12
to wx-u...@googlegroups.com
Personally, I like WiX for Windows installers. But it helps to
understand MSI a bit. There are some nice tutorials available online.

Dave

Marian 'VooDooMan' Meravy

unread,
Jun 1, 2012, 1:04:10 PM6/1/12
to wx-u...@googlegroups.com
Greetings,

MS Visual Studio can create .msi installer packages. IIRC it also
supports universal package with 2 versions, both x86 and x64, and
decision which version to install is made at time of installing.

Though, I don't have much experiences with it, I was creating .msi
package like 1 year ago, and this has been my only experience, but I
must say it was really easy and intuitive, while being feature-rich.

Best,
vdm
.
signature.asc

ardi

unread,
Jun 1, 2012, 1:23:15 PM6/1/12
to wx-users

On Jun 1, 6:42 pm, David Connet <d...@agilityrecordbook.com> wrote:
[...]
>
> Personally, I like WiX for Windows installers. But it helps to
> understand MSI a bit. There are some nice tutorials available online.

Well, actually, I don't need any installer at all, since I use the OSX
concept for all platforms (ie: all the internal stuff an application
needs, including its executable, is located on a directory hierarchy
that you can move where you wish except /dev/null :-) My apps locate
their internal data hierarchy relative to the executable directory
(queried through wxStandardPaths). I firmly believe this is one of the
best points of OSX, and I use it on all platforms :-)

So, I wasn't asking about installers, but about tuning your app for
the specifics of the MSW platform (ie: app icons, resource files, and
any MSW-specific stuff that an app needs to consider in order to
"integrate well" with MSW...)

ardi




felix felix

unread,
Jun 1, 2012, 1:40:13 PM6/1/12
to wx-u...@googlegroups.com
if i understand you correctly, your programs binary file would be writable, or you needed write access to, e.g. on windows, %programfiles%. Neither really is a good idea.

Fulvio Senore

unread,
Jun 1, 2012, 1:41:56 PM6/1/12
to wx-u...@googlegroups.com


Il 01/06/2012 19.23, ardi ha scritto:
>
> So, I wasn't asking about installers, but about tuning your app for
> the specifics of the MSW platform (ie: app icons, resource files, and
> any MSW-specific stuff that an app needs to consider in order to
> "integrate well" with MSW...)
>

The first thing that users expect is an entry in the start menu to
execute your program.
You'll need an installer for it, I think.
Then you need an installer to associate your program with your data
files, if any.

The icon is contained in the resource file, it should be easy to find
info about it.

Fulvio

Steve Thompson

unread,
Jun 1, 2012, 1:44:20 PM6/1/12
to wx-u...@googlegroups.com
On Fri, 1 Jun 2012, Fulvio Senore wrote:

> I recommend InnoSetup: it is very easy to use and it works well.
>
> At the time I spent half a day trying to use NSIS with no luck: I was not
> even able to understand how to build a setup.

I use both InnoSetup and NSIS and had the opposite experience; InnoSetup
is quite complex for anything but simple applications (for example, I have
hundreds of lines of Pascal built in to my installers), while NSIS I found
to be much more straightforward. To each his or her own :)

Steve

ardi

unread,
Jun 1, 2012, 1:53:28 PM6/1/12
to wx-users
My apps internal hierarchy consist of files that don't need to be
writable. The executable opens the app internal data as read-only. So,
if the app is placed inside a read-only dir, it works. Note that the
user documents created with app are not expected to be on the app
internal dir, but on the operating system default location for user
data files (ie: "My documents" folder).

ardi

ardi

unread,
Jun 1, 2012, 1:54:40 PM6/1/12
to wx-users


On Jun 1, 7:41 pm, Fulvio Senore <mail...@fsoft.it> wrote:
> Il 01/06/2012 19.23, ardi ha scritto:
>
>
>
> > So, I wasn't asking about installers, but about tuning your app for
> > the specifics of the MSW platform (ie: app icons, resource files, and
> > any MSW-specific stuff that an app needs to consider in order to
> > "integrate well" with MSW...)
>
> The first thing that users expect is an entry in the start menu to
> execute your program.
> You'll need an installer for it, I think.

I just realized I don't use Windows as a Windows user :-))

ardi

The Devils Jester

unread,
Jun 1, 2012, 4:45:43 PM6/1/12
to wx-u...@googlegroups.com
I design my applications in the same manner.  The entire application is in one directory with all non standard dependencies in a directory that folder, as well as all related data files.  Anything created by the user (ini files, data files, etc...) are all stored in their documents directory or a place of their choosing.  I have always felt this was a superior package design, 

> The first thing that users expect is an entry in the start menu to
> execute your program.
> You'll need an installer for it, I think.
Untrue, you can programatically create an entry in the start menu, how do you think installers do it?

>Then you need an installer to associate your program with your data files, if any.
Again, untrue.  It is very simple to associate your program with your data files programatically, all of my applications do so.


Fulvio Senore

unread,
Jun 1, 2012, 5:11:53 PM6/1/12
to wx-u...@googlegroups.com

Il 01/06/2012 22.45, The Devils Jester ha scritto:
>
> > The first thing that users expect is an entry in the start menu to
> > execute your program.
> > You'll need an installer for it, I think.
> Untrue, you can programatically create an entry in the start menu, how
> do you think installers do it?
>

I know that installers are programs. Simply I believe that it's better
to spend my time writing programs and not installers. Those who wrote
the installers are likely to have done that job better than me.
Moreover, virtually all Windows programs are installed using a setup
program, so this is what end users expect.

Or do you expect the average Windows user to manually create a folder in
the Program Files folder and copy your files in it? Then he should
double click your program so that it can create an entry in the start menu?

> >Then you need an installer to associate your program with your data
> files, if any.
> Again, untrue. It is very simple to associate your program with your
> data files programatically, all of my applications do so.
>
Again, why should you waste time reinventing the wheel, since all
installers can do it for free?

Moreover installer writers have more experience so they are likely to
handle in a better way unexpected situations or new versions of the
operating system.

The Devils Jester

unread,
Jun 1, 2012, 5:37:01 PM6/1/12
to wx-u...@googlegroups.com
Or do you expect the average Windows user to manually create a folder in the Program Files folder and copy your files in it? Then he should double click your program so that it can create an entry in the start menu?

No, I expect them to extract it to their home folder and run it there.  If they don't like that, they are free to use another program.

Again, why should you waste time reinventing the wheel, since all installers can do it for free?
I do not understand your comment, as the code required to do this is only a few lines, and takes much less time to do once, than to create an installer application, of which you will have to update with each new version of your app.  It seems like you waste a lot more time than I do.

 
Moreover installer writers have more experience so they are likely to handle in a better way unexpected situations or new versions of the operating system.
I find the opposite to be true.  Since all of my data, and dependencies, even were I to use an installer app, are in my programs directory, there is nothing for an installer to do except copy the folder and make a menu entry.  No chance for unexpected situations, its installers that cause these situations, no chance for OS version issues, since its run directly from the folder you extract it to, and no chance for other applications to install binary incompatible versions of 3rd party libraries you use, breaking your program (this was always fun to deal with). 
 
I find a single, self contained package to be a better design choice.  I may not have the option in the future for Windows users (who knows what future Windows versions will do) but for now, I like this best.

But I did not reply to the OP to start an argument about design choices.  I just wanted him to know that I do the same thing, and that the two big things mentioned in this topic about why an installer is needed, are easily done in code.

 
.


--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.


David Connet

unread,
Jun 1, 2012, 6:07:20 PM6/1/12
to wx-u...@googlegroups.com
On 6/1/2012 2:37 PM, The Devils Jester wrote:
> Or do you expect the average Windows user to manually create a
> folder in the Program Files folder and copy your files in it? Then
> he should double click your program so that it can create an entry
> in the start menu?
>
> No, I expect them to extract it to their home folder and run it there.

I used to do that - the majority of my users couldn't do it. They did
understand running a .msi file.

> If they don't like that, they are free to use another program.
>
> Again, why should you waste time reinventing the wheel, since all
> installers can do it for free?
>
> I do not understand your comment, as the code required to do this is
> only a few lines, and takes much less time to do once, than to create an
> installer application, of which you will have to update with each new
> version of your app. It seems like you waste a lot more time than I do.
>
> Moreover installer writers have more experience so they are likely
> to handle in a better way unexpected situations or new versions of
> the operating system.
>
> I find the opposite to be true. Since all of my data, and dependencies,
> even were I to use an installer app, are in my programs directory, there
> is nothing for an installer to do except copy the folder and make a menu
> entry. No chance for unexpected situations, its installers that cause
> these situations, no chance for OS version issues,

I disagree there - The installer can prevent a package from installing
on an OS I don't support (for instance, anything before XP)

> since its run
> directly from the folder you extract it to, and no chance for other
> applications to install binary incompatible versions of 3rd party
> libraries you use, breaking your program (this was always fun to deal
> with).

Using an installer doesn't expose you to incompatible 3rd party software
any more than this method. (Personally, I static link to avoid the whole
runtime distribution issue)

> I find a single, self contained package to be a better design choice. I
> may not have the option in the future for Windows users (who knows what
> future Windows versions will do) but for now, I like this best.

I went to a preview about Win8 - Metro apps will ONLY be able to be
distributed via the Windows Store. So you won't need to author a .msi
anymore, but you can't author your own distribution either. (Let's just
say I was a little underwhelmed about the whole Metro thing -
considering I'm the type of person who usually has at least 5 programs
actively running and usually a few more simply open)

> But I did not reply to the OP to start an argument about design choices.
> I just wanted him to know that I do the same thing, and that the two
> big things mentioned in this topic about why an installer is needed, are
> easily done in code.

Hijacking of threads... :-) (BTW, to derail it further, Win8 release
preview just came out, along with Visual Studio 2012 RC (VS11 had been
renamed) - I'm just compiling WX in that now, 32bit done, 64bit running
[using makefiles])

The main reason I package my program in an installer is ease-of-install
by my users (most of whom are in the class "what OS are you on? Internet
Explorer." sigh.) And that it puts itself in expected locations (Program
Files, menus, etc) automatically so all users on a machine can use it
(and all UAC issues are handled by MSI). Yes, my program is happy
without an installer, by my users are happier with.

Dave
(I worked exclusively on MSI projects for 3 yrs at my previous job)

Vadim Zeitlin

unread,
Jun 1, 2012, 6:13:55 PM6/1/12
to wx-u...@googlegroups.com
On Fri, 01 Jun 2012 15:07:20 -0700 David Connet wrote:

DC> Dave
DC> (I worked exclusively on MSI projects for 3 yrs at my previous job)

I've had to create my first MSI only recently and I was horrified. It
seems horribly complex for even very simple tasks, at least when using WiX
(which nevertheless was strongly recommended in many places as the best way
to create MSI packages), especially compared to Inno Setup (and, while I
didn't use it much myself, I'm sure the same applies to NSIS too).

I just hope that I don't understand something here and am missing a better
way of creating MSI. As you have a lot of experience with it, could you
please explain how would you create an MSI installer for wxWidgets? I.e.
something that really doesn't have much to do beyond unpacking the files to
a user-specified location, but that does install a lot of files, making
writing <Component><File .../></Component> nonsense for each of them
manually completely impractical?

Thanks,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

David Connet

unread,
Jun 1, 2012, 6:48:30 PM6/1/12
to wx-u...@googlegroups.com
Wix has tools to help with that. (heat) The chm file they include in the
install (I use v3.5) is actually pretty good. (note, I haven't actually
used it - my old job already had the files [hundreds] set up - long term
maintenance is easier that way because of the consistency you need to
keep with guids)

Something like this (WX) is a bit different from normal (binary)
installs since components really want version numbers. There are rules
that you have to observe when authoring components (just hitting a
couple points here):
- a given file should always install to the same location with the same
component guid. Do not change one and not the other.
- never reuse a component guid, new files always get new guids.
- never include a file with an older version number [VERSIONINFO] and
try to replace an existing one (well, you can with some nasty settings,
but highly not recommended unless you really know what you're doing - I
don't go there!)

When we installed headers/lib/dll, we would associate the headers/lib
with the DLL as companion files (or all in the same component) so the
DLL would act as the key file. However, when you group multiple files in
a single component - if the key file for the component does not change,
then NONE of the other files will update either.

I do have to say that it took me a while to get up to speed with MSI.
Wix hides some of the details from you, but you really need to
understand MSI to prevent getting into some bad situations (usually
around upgrades). That knowledge is really needed for anything that
creates MSIs, tho some of the other tools shield you from that a bit
more with wizards (I'm thinking of InstallShield here which is what we
were slowly transitioning away from)

Wix's biggest downside is probably it's lack of a visual editing tool
(When I need to do UI dialogs, I use wixedit to help me lay them out). I
understand Wix has pretty good tools for Visual Studio integration, but
I've tended to use just the command line tools. (my old job used
makefiles, so command line tools were easier)

Dave

Vadim Zeitlin

unread,
Jun 1, 2012, 6:57:15 PM6/1/12
to wx-u...@googlegroups.com
On Fri, 01 Jun 2012 15:48:30 -0700 David Connet wrote:

DC> Wix has tools to help with that. (heat)

I saw this one but I honestly have no idea how am I supposed to maintain
its output. Just copy and paste it anew every time I need to create a
distribution? Because I didn't manage to just include the output it
generates into .wxs directly and I don't see how to deal with files
renaming/deletion otherwise.

DC> Wix's biggest downside is probably it's lack of a visual editing tool

I'm not even there yet... If I could create a simple MSI for wx which
would just ask for the installation directory and copied the files there it
would be already great (ideally without showing the elevation prompt if the
chosen location doesn't require administrative permissions to write to).

Regards,

David Connet

unread,
Jun 1, 2012, 7:26:45 PM6/1/12
to wx-u...@googlegroups.com
(First let me link the tuturial I mentioned before:
http://wix.tramontana.co.hu/)

On 6/1/2012 3:57 PM, Vadim Zeitlin wrote:
> On Fri, 01 Jun 2012 15:48:30 -0700 David Connet wrote:
>
> DC> Wix has tools to help with that. (heat)
>
> I saw this one but I honestly have no idea how am I supposed to maintain
> its output. Just copy and paste it anew every time I need to create a
> distribution? Because I didn't manage to just include the output it
> generates into .wxs directly and I don't see how to deal with files
> renaming/deletion otherwise.

I haven't used this, but this tool would probably help ALOT (Paraffin)...
http://www.wintellect.com/CS/blogs/jrobbins/archive/2010/08/31/zen-of-paraffin.aspx

> DC> Wix's biggest downside is probably it's lack of a visual editing tool
>
> I'm not even there yet... If I could create a simple MSI for wx which
> would just ask for the installation directory and copied the files there it
> would be already great (ideally without showing the elevation prompt if the
> chosen location doesn't require administrative permissions to write to).

If you're going to install to ProgramFiles, elevation is required (no
way around that unless you turn UAC off on the target machine - not your
choice). You have 2 choices: perMachine (UAC), or perUser (no UAC). You
can author a dual package - but that is not supported on all versions of
Windows. For this, I wouldn't go there. Oh, and once you've decided,
don't change. You cannot do an upgrade (v1 to v2) of a peruser to
permachine (or vis-versa).

Some other points
- for a simply UI, Wix has some prebuilt ones - for instance a simple
one that allows directory selection:
<UIRef Id="WixUI_InstallDir" />
- ugradecodes: You will probably want different upgrade codes for each
major version - this will allow coexistence of 2.8 and 2.9 (for
instance) at the some time. Obviously each should have a different
default directory. (And if the user installs both to the same place,
well, you can't control where someone points a gun...) Oh, and since 2.9
is a lead in to 3.0, I wouldn't necessarily plan on coexistence
there.

If you want, I can help put together the framework - probably best to
take this off-list for that.

Dave

The Devils Jester

unread,
Jun 1, 2012, 9:00:00 PM6/1/12
to wx-u...@googlegroups.com
On Fri, Jun 1, 2012 at 5:07 PM, David Connet <dc...@agilityrecordbook.com> wrote:
On 6/1/2012 2:37 PM, The Devils Jester wrote:
   Or do you expect the average Windows user to manually create a
   folder in the Program Files folder and copy your files in it? Then
   he should double click your program so that it can create an entry
   in the start menu?

No, I expect them to extract it to their home folder and run it there.

I used to do that - the majority of my users couldn't do it. They did understand running a .msi file.

See, I am not under the "I want as many users as possible" category.   I want intelligent users, and if they are unable to perform the simplest of tasks, good riddance :)  I develop software because I enjoy it, because I want to create things for other people to use and enjoy, and its a reciprocal.  I get to enjoy the things that my users make with my software, which makes it worth doing.  My software is complex enough that if a user cannot figureout how to double click an executable in a folder, they should probably look else where.  As it is I only support Windows because it takes no effort on my part (selecting a different target platform for compile) since all my code is cross platform.  If this is no longer the case with Win8, I will probably drop all support for Windows in my software, its just not that important to me.

 
 If they don't like that, they are free to use another program.

   Again, why should you waste time reinventing the wheel, since all
   installers can do it for free?

I do not understand your comment, as the code required to do this is
only a few lines, and takes much less time to do once, than to create an
installer application, of which you will have to update with each new
version of your app.  It seems like you waste a lot more time than I do.
>
   Moreover installer writers have more experience so they are likely
   to handle in a better way unexpected situations or new versions of
   the operating system.

I find the opposite to be true.  Since all of my data, and dependencies,
even were I to use an installer app, are in my programs directory, there
is nothing for an installer to do except copy the folder and make a menu
entry.  No chance for unexpected situations, its installers that cause
these situations, no chance for OS version issues,

I disagree there - The installer can prevent a package from installing on an OS I don't support (for instance, anything before XP)

This really isnt an issue with me as I support any version of Windows that wxWidgets does, and my non wxWidgets software supports any 32bit+ version,
 

I can see the situations where installers would be useful, i.e. in Linux I often distribute a minimal version of my apps and let the .deb and .rpm packages force install of the dependencies.  But I do not see them as being better than the "OSX" style, though it would be nice if it actually worked like it does in OSX.  
 

since its run
directly from the folder you extract it to, and no chance for other
applications to install binary incompatible versions of 3rd party
libraries you use, breaking your program (this was always fun to deal
with).

Using an installer doesn't expose you to incompatible 3rd party software any more than this method. (Personally, I static link to avoid the whole runtime distribution issue)

But if I am static linking and/or including all my libs in my app directory, what is the point of an installer?  A gloried copier?  You can keep those users lol.
 
I find a single, self contained package to be a better design choice.  I
may not have the option in the future for Windows users (who knows what
future Windows versions will do) but for now, I like this best.

I went to a preview about Win8 - Metro apps will ONLY be able to be distributed via the Windows Store. So you won't need to author a .msi anymore, but you can't author your own distribution either. (Let's just say I was a little underwhelmed about the whole Metro thing - considering I'm the type of person who usually has at least 5 programs actively running and usually a few more simply open)


But I did not reply to the OP to start an argument about design choices.
 I just wanted him to know that I do the same thing, and that the two
big things mentioned in this topic about why an installer is needed, are
easily done in code.

Hijacking of threads... :-) (BTW, to derail it further, Win8 release preview just came out, along with Visual Studio 2012 RC (VS11 had been renamed) - I'm just compiling WX in that now, 32bit done, 64bit running [using makefiles])

The main reason I package my program in an installer is ease-of-install by my users (most of whom are in the class "what OS are you on? Internet Explorer." sigh.) And that it puts itself in expected locations (Program Files, menus, etc) automatically so all users on a machine can use it (and all UAC issues are handled by MSI). Yes, my program is happy without an installer, by my users are happier with.

Dave
(I worked exclusively on MSI projects for 3 yrs at my previous job)



 

David Connet

unread,
Jun 1, 2012, 9:43:42 PM6/1/12
to wx-u...@googlegroups.com
On 6/1/2012 6:00 PM, The Devils Jester wrote:
> On Fri, Jun 1, 2012 at 5:07 PM, David Connet <dc...@agilityrecordbook.com
> <mailto:dc...@agilityrecordbook.com>> wrote:
> I disagree there - The installer can prevent a package from
> installing on an OS I don't support (for instance, anything before XP)
>
> This really isnt an issue with me as I support any version of Windows
> that wxWidgets does, and my non wxWidgets software supports any 32bit+
> version,

Until you change compilers - for instance VC10 will only create binaries
that work on XPsp2+. Without an installer, a user could take that
Windows exe and try running it on xp (no sp) or Win2000. Oops. Saying
you support anything wxWidgets does doesn't get you out of that.

> Using an installer doesn't expose you to incompatible 3rd party
> software any more than this method. (Personally, I static link to
> avoid the whole runtime distribution issue)
>
>
> But if I am static linking and/or including all my libs in my app
> directory, what is the point of an installer? A gloried copier?

Yup!

(the nice thing is I can easily set up my shortcuts and win7 pinning
stuff and the program itself doesn't need to know how - which makes
supporting xp and win7 much easier [otherwise, you would have to do the
whole loadlib/getprocaddr stuff to enable win7 pinning, which then leads
to more ifdefs in the code since I support Mac too])

> You can keep those users lol.

All in what a program's audience is... :-) Most of mine are
email/browser/document-writer type people, not programmers. Which can
make support interesting at times... (luckily my users are usually a
notch above the stories you read about in various places!)

Dave

The Devils Jester

unread,
Jun 2, 2012, 12:40:35 AM6/2/12
to wx-u...@googlegroups.com
On Fri, Jun 1, 2012 at 8:43 PM, David Connet <dc...@agilityrecordbook.com> wrote:
On 6/1/2012 6:00 PM, The Devils Jester wrote:
On Fri, Jun 1, 2012 at 5:07 PM, David Connet <dc...@agilityrecordbook.com
<mailto:dcon@agilityrecordbook.com>> wrote:
   I disagree there - The installer can prevent a package from
   installing on an OS I don't support (for instance, anything before XP)

This really isnt an issue with me as I support any version of Windows
that wxWidgets does, and my non wxWidgets software supports any 32bit+
version,

Until you change compilers - for instance VC10 will only create binaries that work on XPsp2+. Without an installer, a user could take that Windows exe and try running it on xp (no sp) or Win2000. Oops. Saying you support anything wxWidgets does doesn't get you out of that.

I only use MinGW/GCC so this is not likely to be an issue.  I will never use a MS compiler (for various reasons), and all other compilers (i.e. Borland, etc...) have issues all their own, its easier/best to use the same/similar compiler as the one I use on all other platforms so the compiler issues are all the same.  Granted this is just my situation, which happens to work ideally with what I do, so as with everything YMMV.


   Using an installer doesn't expose you to incompatible 3rd party
   software any more than this method. (Personally, I static link to
   avoid the whole runtime distribution issue)


But if I am static linking and/or including all my libs in my app
directory, what is the point of an installer?  A gloried copier?

Yup!

(the nice thing is I can easily set up my shortcuts and win7 pinning stuff and the program itself doesn't need to know how - which makes supporting xp and win7 much easier [otherwise, you would have to do the whole loadlib/getprocaddr stuff to enable win7 pinning, which then leads to more ifdefs in the code since I support Mac too])
 
Obviously if these things interest you and are important to you, it is more important to me that my users can uninstall my application completely by deleting its folder.  Or backing it up entirely by copying it to another location, or running it directly off of a thumbdrive, or other storage media.  The ability to do this (for all OSes), is much more important to me than pinning an application in a Windows 7 specific taskbar.  So at the end of the day it is about what you do, what you are trying to accomplish and what matters most.
 
My point (going back to the OP) is that installers are not a requirement, they are not always even the best choice depending on your needs, and the single, stand alone app approach that the OP likes, is a design that many people like, and I personally feel is superior to Windows installers.  I only wish Linux and Windows did the double click the folder to execute like OS X does without third party hacks.  

You can keep those users lol.

All in what a program's audience is... :-)  Most of mine are email/browser/document-writer type people, not programmers. Which can make support interesting at times... (luckily my users are usually a notch above the stories you read about in various places!)

Dave
--

Johan Vromans

unread,
Jun 2, 2012, 8:11:15 AM6/2/12
to wx-u...@googlegroups.com
The Devils Jester <thedevi...@gmail.com> writes:

> I design my applications in the same manner. The entire application is
> in one directory with all non standard dependencies in a directory
> that folder, as well as all related data files.

To add a couple of cents: For wxPerl applications the Cava Packager does
a splendid job in solving packaging and install problems. It might be
interesting to steal some ideas from Cava.

www.cavapackager.org (not affiliated)

-- Johan

Vadim Zeitlin

unread,
Jun 3, 2012, 7:11:11 AM6/3/12
to wx-u...@googlegroups.com
On Fri, 01 Jun 2012 16:26:45 -0700 David Connet wrote:

DC> (First let me link the tuturial I mentioned before:
DC> http://wix.tramontana.co.hu/)

Yes, this is the one I read.

DC> On 6/1/2012 3:57 PM, Vadim Zeitlin wrote:
DC> > On Fri, 01 Jun 2012 15:48:30 -0700 David Connet wrote:
DC> >
DC> > DC> Wix has tools to help with that. (heat)
DC> >
DC> > I saw this one but I honestly have no idea how am I supposed to maintain
DC> > its output. Just copy and paste it anew every time I need to create a
DC> > distribution? Because I didn't manage to just include the output it
DC> > generates into .wxs directly and I don't see how to deal with files
DC> > renaming/deletion otherwise.
DC>
DC> I haven't used this, but this tool would probably help ALOT (Paraffin)...
DC> http://www.wintellect.com/CS/blogs/jrobbins/archive/2010/08/31/zen-of-paraffin.aspx

I didn't know about this one, thanks, I only used Heat and as Paraffin
looks to improve on its drawbacks it might be exactly what I needed.
Unfortunately wintellect.com seems to be down right now so it's a bit
difficult to find out more about it but I'll retry later.

DC> If you're going to install to ProgramFiles, elevation is required (no
DC> way around that unless you turn UAC off on the target machine - not your
DC> choice).

The trouble is that it would make a lot of sense to install to
ProgramFiles by default -- and then require elevation, of course -- but not
require it if the user changes the directory to some other location
writable by this user. This would clearly be the best of both worlds and
personally I think it's mind boggling that WiX/MSI doesn't support this at
all (from what I know the only way to do it is to have 3 installers, with
the first one selecting the directory and then running one of the two
others).

DC> If you want, I can help put together the framework - probably best to
DC> take this off-list for that.

Thanks for your off-list message, I didn't have time to look at in
sufficient details yet but will do soon.

Thanks again,

David Connet

unread,
Jun 3, 2012, 10:55:53 AM6/3/12
to wx-u...@googlegroups.com
On 6/3/2012 4:11 AM, Vadim Zeitlin wrote:
> On Fri, 01 Jun 2012 16:26:45 -0700 David Connet wrote:
>
> DC> (First let me link the tuturial I mentioned before:
> DC> http://wix.tramontana.co.hu/)
>
> Yes, this is the one I read.
>
> DC> On 6/1/2012 3:57 PM, Vadim Zeitlin wrote:
> DC> > On Fri, 01 Jun 2012 15:48:30 -0700 David Connet wrote:
> DC> >
> DC> > DC> Wix has tools to help with that. (heat)
> DC> >
> DC> > I saw this one but I honestly have no idea how am I supposed to maintain
> DC> > its output. Just copy and paste it anew every time I need to create a
> DC> > distribution? Because I didn't manage to just include the output it
> DC> > generates into .wxs directly and I don't see how to deal with files
> DC> > renaming/deletion otherwise.
> DC>
> DC> I haven't used this, but this tool would probably help ALOT (Paraffin)...
> DC> http://www.wintellect.com/CS/blogs/jrobbins/archive/2010/08/31/zen-of-paraffin.aspx
>
> I didn't know about this one, thanks, I only used Heat and as Paraffin
> looks to improve on its drawbacks it might be exactly what I needed.
> Unfortunately wintellect.com seems to be down right now so it's a bit
> difficult to find out more about it but I'll retry later.

That really seems to be hit/miss now. Sometimes I get in, sometimes I
don't... I'll send you the paraffin zip off-list which contains a docx
file. Once I started playing with it, I found it pretty sweet!

> DC> If you're going to install to ProgramFiles, elevation is required (no
> DC> way around that unless you turn UAC off on the target machine - not your
> DC> choice).
>
> The trouble is that it would make a lot of sense to install to
> ProgramFiles by default -- and then require elevation, of course -- but not
> require it if the user changes the directory to some other location
> writable by this user. This would clearly be the best of both worlds and
> personally I think it's mind boggling that WiX/MSI doesn't support this at
> all (from what I know the only way to do it is to have 3 installers, with
> the first one selecting the directory and then running one of the two
> others).

Can't do that. MSI works in transactions - only one install at a time.
So you can't use an MSI to spawn an MSI. You would need a bootstrapper
to do that. I think you can force a per-user to install to PF - if you
explicitly elevate (right-click-run-as). If you don't, installing will
simply fail with a permission error. Since the current installer
defaults to c:\wxWidgets-<ver>, I opted for a peruser.

And actually, if you think about it, installing into PF is probably NOT
what most users will want to do. You would need to elevate to admin in
order to compile. If we simply installed pre-built binaries and no one
compiled, then PF would make sense... (just thinking out loud here)

> DC> If you want, I can help put together the framework - probably best to
> DC> take this off-list for that.
>
> Thanks for your off-list message, I didn't have time to look at in
> sufficient details yet but will do soon.
>
> Thanks again,
> VZ
>

Dave

David Connet

unread,
Jun 3, 2012, 11:07:29 AM6/3/12
to wx-u...@googlegroups.com
> On Fri, 01 Jun 2012 16:26:45 -0700 David Connet wrote:
> DC> (First let me link the tuturial I mentioned before:
> DC> http://wix.tramontana.co.hu/)

> DC> (Paraffin)...
> DC> http://www.wintellect.com/CS/blogs/jrobbins/archive/2010/08/31/zen-of-paraffin.aspx

One last link for anyone interested in learning more about Wix:
https://www.packtpub.com/wix-a-developers-guide-to-windows-installer-xml/book

This is a book (real or ebook[pdf]) that is a really great resource. (I
bought the ebook a few years ago) When I first started working with MSI
a few years ago, this and
http://www.amazon.com/Definitive-Guide-Windows-Installer-Experts/dp/1590592972
were my primary go-to resources.

Dave

Kenneth Porter

unread,
Jun 17, 2012, 11:28:08 PM6/17/12
to wx-u...@googlegroups.com
--On Sunday, June 03, 2012 2:11 PM +0200 Vadim Zeitlin
<va...@wxwidgets.org> wrote:

> I didn't know about this one, thanks, I only used Heat and as Paraffin
> looks to improve on its drawbacks it might be exactly what I needed.
> Unfortunately wintellect.com seems to be down right now so it's a bit
> difficult to find out more about it but I'll retry later.

I'm using Paraffin to include my doxygen output in my MSI. In my main .wxs
file I have this:

<!-- see doxygen.wxs generated by Paraffin -->
<!-- use 'paraffin -update doxygen.wxs' to regenerate from Doxygen HTML
output -->
<Feature Id="Documentation" Title="Developer documentation" Level="1">
<ComponentGroupRef Id="group_DoxygenHtml" />
<ComponentGroupRef Id="DocumentationShortcutGroup" />
</Feature>

On first run, I run the command below to create the initial "include" file.
After that, I use "paraffin -update doxygen.wxs", which uses the arguments
recorded in the initial output file. So you'd want to keep doxygen.wxs
checked into revision control. Update the file whenever the list of output
files changes (eg. when adding a new class).

paraffin -dir ..\..\Doc\doxygen\html\ -custom DoxygenHtml -alias
$(var.DoxygenHtml)\ -inc 1 -guids -multiple

In my Visual Studio project file for the WiX project, I have this constant
defined with the relative path to my doxygen output:

DoxygenHtml=../../doc/Doxygen/html

Kenneth Porter

unread,
Jun 17, 2012, 11:33:19 PM6/17/12
to wx-u...@googlegroups.com
--On Saturday, June 02, 2012 12:40 AM -0500 The Devils Jester
<thedevi...@gmail.com> wrote:

> Obviously if these things interest you and are important to you, it is
> more important to me that my users can uninstall my application
> completely by deleting its folder. Or backing it up entirely by copying
> it to another location, or running it directly off of a thumbdrive, or
> other storage media. The ability to do this (for all OSes), is much more
> important to me than pinning an application in a Windows 7 specific
> taskbar. So at the end of the day it is about what you do, what you are
> trying to accomplish and what matters most.

Indeed. You're creating what Mozilla calls a "portable installation", one
that a user can take with him to any machine that allows users to run from
removable media.

Package installers (like MSI, RPM, DEB) are much more useful to corporate
environments where an IT group is responsible for maintaining the machines
and the end user is just using the computer as an appliance in the pursuit
of his job. The installer insures that all machines are set up the same
way, and make it easy to spot "alien" files that don't belong on the
machine.


Reply all
Reply to author
Forward
0 new messages