Updating Melt to extract files from the Binary table for patching

classic Classic list List threaded Threaded
38 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Updating Melt to extract files from the Binary table for patching

scubasteve2

Hello all,

 

So I’m working on this melt issue where I would like to extract the binaries from the Binary table out to disk and update the wixpdb file as to their location.

 

I have a few concerns and I’m sure someone has a better idea as to what to do with regard to these issues

 

1)      I’m currently extracting the files to wherever –x specifices + a “Binary” subdirectory.  This could potentially conflict with a base folder named Binary that someone may have in their MSI/MSM.  Where should I put this data?  Should I prepend with a special character?

2)      Should this sub-path value be overridable by a command line switch (ex. –xbinary to go with the –x naming convention)?

3)      I’m currently wrapping this extraction in a new private method called by InstallPackage::ExtractFIles(ICollection<string>).  Would it be preferred that since this is only used by melt.cs that it be put elsewhere?

 

Thanks, and happy new year!

Stephen Tunney

Nuance Communications, Inc.

Solutions Architect, Imaging Division

Waterloo, Ontario, Canada
[hidden email]

519-880-7463      Office
NUANCE.COM
The experience speaks for itself ™

 


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

Rob Mensching-7

1.       What does dark.exe do?

2.       I’d do what dark.exe does.

3.       Need more information about why you need a new method.

 

_______________________________________________________________

FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

 

From: Tunney, Stephen [mailto:[hidden email]]
Sent: Wednesday, December 31, 2014 9:23 AM
To: [hidden email]
Subject: [WiX-devs] Updating Melt to extract files from the Binary table for patching

 

Hello all,

 

So I’m working on this melt issue where I would like to extract the binaries from the Binary table out to disk and update the wixpdb file as to their location.

 

I have a few concerns and I’m sure someone has a better idea as to what to do with regard to these issues

 

1)      I’m currently extracting the files to wherever –x specifices + a “Binary” subdirectory.  This could potentially conflict with a base folder named Binary that someone may have in their MSI/MSM.  Where should I put this data?  Should I prepend with a special character?

2)      Should this sub-path value be overridable by a command line switch (ex. –xbinary to go with the –x naming convention)?

3)      I’m currently wrapping this extraction in a new private method called by InstallPackage::ExtractFIles(ICollection<string>).  Would it be preferred that since this is only used by melt.cs that it be put elsewhere?

 

Thanks, and happy new year!

Stephen Tunney

Nuance Communications, Inc.

Solutions Architect, Imaging Division

Waterloo, Ontario, Canada
[hidden email]

519-880-7463      Office
NUANCE.COM
The experience speaks for itself ™

 


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

scubasteve2

Dark does things differently than melt I’m afraid.

 

When you specified –xo in dark, it created a folder structure like this

 

.\Binary

.\File

.\Icon

 

And everything is put in as flat a directory structure as possible, so Melt does things to mimic an administrative install (ie. there is no File directory, only the masked directory values from the .:. format in the name for directories and files)

 

So since there is no “File” directory for everything that gets extracted from the CAB file(s) I need a way to ensure that there are no conficts.  Should melt perhaps change a little to include this table name as a top-level folder for consistency?

 

Stephen Tunney

Nuance Communications, Inc.

Solutions Architect, Imaging Division

Waterloo, Ontario, Canada
[hidden email]

519-880-7463      Office
NUANCE.COM
The experience speaks for itself ™

 

From: Rob Mensching [mailto:[hidden email]]
Sent: December-31-14 1:34 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

 

1.       What does dark.exe do?

2.       I’d do what dark.exe does.

3.       Need more information about why you need a new method.

 

_______________________________________________________________

FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

 

From: Tunney, Stephen [[hidden email]]
Sent: Wednesday, December 31, 2014 9:23 AM
To: [hidden email]
Subject: [WiX-devs] Updating Melt to extract files from the Binary table for patching

 

Hello all,

 

So I’m working on this melt issue where I would like to extract the binaries from the Binary table out to disk and update the wixpdb file as to their location.

 

I have a few concerns and I’m sure someone has a better idea as to what to do with regard to these issues

 

1)      I’m currently extracting the files to wherever –x specifices + a “Binary” subdirectory.  This could potentially conflict with a base folder named Binary that someone may have in their MSI/MSM.  Where should I put this data?  Should I prepend with a special character?

2)      Should this sub-path value be overridable by a command line switch (ex. –xbinary to go with the –x naming convention)?

3)      I’m currently wrapping this extraction in a new private method called by InstallPackage::ExtractFIles(ICollection<string>).  Would it be preferred that since this is only used by melt.cs that it be put elsewhere?

 

Thanks, and happy new year!

Stephen Tunney

Nuance Communications, Inc.

Solutions Architect, Imaging Division

Waterloo, Ontario, Canada
[hidden email]

519-880-7463      Office
NUANCE.COM
The experience speaks for itself ™

 


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

Rob Mensching-7

I’ll let Bob weigh in on the breaking change about adding a top level folder. Another idea, use a “.Binaries” folder with hope that dot folder names are rare.

 

_______________________________________________________________

FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

 

From: Tunney, Stephen [mailto:[hidden email]]
Sent: Wednesday, December 31, 2014 12:13 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

 

Dark does things differently than melt I’m afraid.

 

When you specified –xo in dark, it created a folder structure like this

 

.\Binary

.\File

.\Icon

 

And everything is put in as flat a directory structure as possible, so Melt does things to mimic an administrative install (ie. there is no File directory, only the masked directory values from the .:. format in the name for directories and files)

 

So since there is no “File” directory for everything that gets extracted from the CAB file(s) I need a way to ensure that there are no conficts.  Should melt perhaps change a little to include this table name as a top-level folder for consistency?

 

Stephen Tunney

Nuance Communications, Inc.

Solutions Architect, Imaging Division

Waterloo, Ontario, Canada
[hidden email]

519-880-7463      Office
NUANCE.COM
The experience speaks for itself ™

 

From: Rob Mensching [[hidden email]]
Sent: December-31-14 1:34 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

 

1.       What does dark.exe do?

2.       I’d do what dark.exe does.

3.       Need more information about why you need a new method.

 

_______________________________________________________________

FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

 

From: Tunney, Stephen [[hidden email]]
Sent: Wednesday, December 31, 2014 9:23 AM
To: [hidden email]
Subject: [WiX-devs] Updating Melt to extract files from the Binary table for patching

 

Hello all,

 

So I’m working on this melt issue where I would like to extract the binaries from the Binary table out to disk and update the wixpdb file as to their location.

 

I have a few concerns and I’m sure someone has a better idea as to what to do with regard to these issues

 

1)      I’m currently extracting the files to wherever –x specifices + a “Binary” subdirectory.  This could potentially conflict with a base folder named Binary that someone may have in their MSI/MSM.  Where should I put this data?  Should I prepend with a special character?

2)      Should this sub-path value be overridable by a command line switch (ex. –xbinary to go with the –x naming convention)?

3)      I’m currently wrapping this extraction in a new private method called by InstallPackage::ExtractFIles(ICollection<string>).  Would it be preferred that since this is only used by melt.cs that it be put elsewhere?

 

Thanks, and happy new year!

Stephen Tunney

Nuance Communications, Inc.

Solutions Architect, Imaging Division

Waterloo, Ontario, Canada
[hidden email]

519-880-7463      Office
NUANCE.COM
The experience speaks for itself ™

 


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

scubasteve2

I have some good news regarding the work I’m doing with melt.

 

It appears as though all other steps (light, torch, pyro) all seem to carry the changes forward from melt and applying the patch in Orca shows that the Binary data has been updated.

 

All I need is some weigh in from Bob as to what to call the sub folder OR create a breaking change in melt for 3.10 or 4+ (I’ve currently forked 3x on github).

 

I will generate a pull request and let Bob review my code changes.

 

Thanks!

Stephen Tunney

Nuance Communications, Inc.

Solutions Architect, Imaging Division

Waterloo, Ontario, Canada
[hidden email]

519-880-7463      Office
NUANCE.COM
The experience speaks for itself ™

 

From: Rob Mensching [mailto:[hidden email]]
Sent: December-31-14 4:16 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

 

I’ll let Bob weigh in on the breaking change about adding a top level folder. Another idea, use a “.Binaries” folder with hope that dot folder names are rare.

 

_______________________________________________________________

FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

 

From: Tunney, Stephen [[hidden email]]
Sent: Wednesday, December 31, 2014 12:13 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

 

Dark does things differently than melt I’m afraid.

 

When you specified –xo in dark, it created a folder structure like this

 

.\Binary

.\File

.\Icon

 

And everything is put in as flat a directory structure as possible, so Melt does things to mimic an administrative install (ie. there is no File directory, only the masked directory values from the .:. format in the name for directories and files)

 

So since there is no “File” directory for everything that gets extracted from the CAB file(s) I need a way to ensure that there are no conficts.  Should melt perhaps change a little to include this table name as a top-level folder for consistency?

 

Stephen Tunney

Nuance Communications, Inc.

Solutions Architect, Imaging Division

Waterloo, Ontario, Canada
[hidden email]

519-880-7463      Office
NUANCE.COM
The experience speaks for itself ™

 

From: Rob Mensching [[hidden email]]
Sent: December-31-14 1:34 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

 

1.       What does dark.exe do?

2.       I’d do what dark.exe does.

3.       Need more information about why you need a new method.

 

_______________________________________________________________

FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

 

From: Tunney, Stephen [[hidden email]]
Sent: Wednesday, December 31, 2014 9:23 AM
To: [hidden email]
Subject: [WiX-devs] Updating Melt to extract files from the Binary table for patching

 

Hello all,

 

So I’m working on this melt issue where I would like to extract the binaries from the Binary table out to disk and update the wixpdb file as to their location.

 

I have a few concerns and I’m sure someone has a better idea as to what to do with regard to these issues

 

1)      I’m currently extracting the files to wherever –x specifices + a “Binary” subdirectory.  This could potentially conflict with a base folder named Binary that someone may have in their MSI/MSM.  Where should I put this data?  Should I prepend with a special character?

2)      Should this sub-path value be overridable by a command line switch (ex. –xbinary to go with the –x naming convention)?

3)      I’m currently wrapping this extraction in a new private method called by InstallPackage::ExtractFIles(ICollection<string>).  Would it be preferred that since this is only used by melt.cs that it be put elsewhere?

 

Thanks, and happy new year!

Stephen Tunney

Nuance Communications, Inc.

Solutions Architect, Imaging Division

Waterloo, Ontario, Canada
[hidden email]

519-880-7463      Office
NUANCE.COM
The experience speaks for itself ™

 


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

Bob Arnson-6
On 02-Jan-15 11:50, Tunney, Stephen wrote:

I have some good news regarding the work I’m doing with melt.

 

It appears as though all other steps (light, torch, pyro) all seem to carry the changes forward from melt and applying the patch in Orca shows that the Binary data has been updated.

 

All I need is some weigh in from Bob as to what to call the sub folder OR create a breaking change in melt for 3.10 or 4+ (I’ve currently forked 3x on github).

Here's what I left on the pull request:

Can't make this change [DTF change] in v3.x since it's a significant behavior change for all users of this method in DTF. I think the best approach for v3.x is to add a switch to melt to specify the binary output directory. If not specified, don't extract binaries. And that could be all internal to melt rather than a DTF change. Another approach would be to do kinda what dark does and extract files and binaries to their own subdirectories. That's also a behavior change but I could be convinced it's OK...

Anyone care if we changed how Melt wrote its output? On the surface, Melt still does what it did: Extract the content and update the .wixpdb to match. The output tree would be different, so it would require someone using it to change how they update the output tree with new binaries.

The more I talk about it, the bigger a change it seems...
-- 
sig://boB
http://joyofsetup.com/

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

scubasteve
Ok, so here's my pitch:

v3.x would get a couple of new flags
-xn (extract in new directory format) <patch>
-xb (extract binaries, does not get squashed by -sextract and uses old path format) <path>

Execution of the ExtractBinaries method would happen in Melt exclusively even though the actual Method is in DTF (no one else would call it).  This makes it an easier merge to 4.x.

Options are mutually exclusive.  This would maint

v4.x
Just change to match dark and accept it as a breaking change.  -sextract would suppress all extraction, including Binary, Icon, etc.

Thoughts?

On Sat Jan 03 2015 at 4:12:39 PM Bob Arnson <[hidden email]> wrote:
On 02-Jan-15 11:50, Tunney, Stephen wrote:

I have some good news regarding the work I’m doing with melt.

 

It appears as though all other steps (light, torch, pyro) all seem to carry the changes forward from melt and applying the patch in Orca shows that the Binary data has been updated.

 

All I need is some weigh in from Bob as to what to call the sub folder OR create a breaking change in melt for 3.10 or 4+ (I’ve currently forked 3x on github).

Here's what I left on the pull request:

Can't make this change [DTF change] in v3.x since it's a significant behavior change for all users of this method in DTF. I think the best approach for v3.x is to add a switch to melt to specify the binary output directory. If not specified, don't extract binaries. And that could be all internal to melt rather than a DTF change. Another approach would be to do kinda what dark does and extract files and binaries to their own subdirectories. That's also a behavior change but I could be convinced it's OK...

Anyone care if we changed how Melt wrote its output? On the surface, Melt still does what it did: Extract the content and update the .wixpdb to match. The output tree would be different, so it would require someone using it to change how they update the output tree with new binaries.

The more I talk about it, the bigger a change it seems...

-- 
sig://boB
http://joyofsetup.com/
------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

Rob Mensching-7

1.       Is there real value putting the method in DTF if only Melt uses it?

2.       I agree with you and Bob about not breaking WiX v3.

3.       Do we need the “-sextract” (what kind of tract?) in v4? Can’t we just do what it does and not bother with suppression? Or is suppression a *really* important feature?

 

_______________________________________________________________

FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

 

From: Stephen Tunney [mailto:[hidden email]]
Sent: Saturday, January 3, 2015 5:36 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

 

Ok, so here's my pitch:

v3.x would get a couple of new flags
-xn (extract in new directory format) <patch>

-xb (extract binaries, does not get squashed by -sextract and uses old path format) <path>

 

Execution of the ExtractBinaries method would happen in Melt exclusively even though the actual Method is in DTF (no one else would call it).  This makes it an easier merge to 4.x.

 

Options are mutually exclusive.  This would maint

 

v4.x

Just change to match dark and accept it as a breaking change.  -sextract would suppress all extraction, including Binary, Icon, etc.

 

Thoughts?

 

On Sat Jan 03 2015 at 4:12:39 PM Bob Arnson <[hidden email]> wrote:

On 02-Jan-15 11:50, Tunney, Stephen wrote:

I have some good news regarding the work I’m doing with melt.

 

It appears as though all other steps (light, torch, pyro) all seem to carry the changes forward from melt and applying the patch in Orca shows that the Binary data has been updated.

 

All I need is some weigh in from Bob as to what to call the sub folder OR create a breaking change in melt for 3.10 or 4+ (I’ve currently forked 3x on github).

Here's what I left on the pull request:

Can't make this change [DTF change] in v3.x since it's a significant behavior change for all users of this method in DTF. I think the best approach for v3.x is to add a switch to melt to specify the binary output directory. If not specified, don't extract binaries. And that could be all internal to melt rather than a DTF change. Another approach would be to do kinda what dark does and extract files and binaries to their own subdirectories. That's also a behavior change but I could be convinced it's OK...

Anyone care if we changed how Melt wrote its output? On the surface, Melt still does what it did: Extract the content and update the .wixpdb to match. The output tree would be different, so it would require someone using it to change how they update the output tree with new binaries.

The more I talk about it, the bigger a change it seems...



-- 
sig://boB
http://joyofsetup.com/

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

scubasteve

1.  I put the new method right beside other methods that serve the same purpose for the file table.  I'm not emotionally attached to the placement so moving it into melt would be fine with me.

3.the suppression of extraction is an optimisation switch.  I can save hours of build time per day by zipping up the output of the melt process and using that in our distributed build cluster + the wixpdb instead of extracting from cabs every time.  Our MSIs are quite large (8x 460mb) and we generate test patches for QA with every build for smoke and regession.  Also eliminates manual steps when an rtm is released.


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

Bob Arnson-6
In reply to this post by scubasteve
On 03-Jan-15 20:36, Stephen Tunney wrote:
> Ok, so here's my pitch:
>
> v3.x would get a couple of new flags
> -xn (extract in new directory format) <patch>
> -xb (extract binaries, does not get squashed by -sextract and uses old
> path format) <path>
Do we need both? I like -xn -- subdirectories for files and binaries a
la Dark, right? That provides binaries and prompts users to update their
scripts and/or existing melt output.

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

scubasteve2
Quick side question for 4.x

Why do we have melt AND dark?  The two of you seem to want them to act the same, don't they really do the same thing (decompile a MS* database)?  Melt updates/generates a .wixpdb as well which is the only real difference I can see.

Should it be considered to merge the two tools together perhaps?  Just a thought exercise perhaps but the questions you two both raised have put a smell in my nose.
Stephen
________________________________________
From: Bob Arnson [[hidden email]]
Sent: January 5, 2015 6:51 PM
To: [hidden email]
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

On 03-Jan-15 20:36, Stephen Tunney wrote:
> Ok, so here's my pitch:
>
> v3.x would get a couple of new flags
> -xn (extract in new directory format) <patch>
> -xb (extract binaries, does not get squashed by -sextract and uses old
> path format) <path>
Do we need both? I like -xn -- subdirectories for files and binaries a
la Dark, right? That provides binaries and prompts users to update their
scripts and/or existing melt output.

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

scubasteve2
In reply to this post by Bob Arnson-6
I like just -xn

Not -xaladark  ??  No?
________________________________________
From: Bob Arnson [[hidden email]]
Sent: January 5, 2015 6:51 PM
To: [hidden email]
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

On 03-Jan-15 20:36, Stephen Tunney wrote:
> Ok, so here's my pitch:
>
> v3.x would get a couple of new flags
> -xn (extract in new directory format) <patch>
> -xb (extract binaries, does not get squashed by -sextract and uses old
> path format) <path>
Do we need both? I like -xn -- subdirectories for files and binaries a
la Dark, right? That provides binaries and prompts users to update their
scripts and/or existing melt output.

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

Bob Arnson-6
Just -xn works for me.

On 05-Jan-15 22:32, Tunney, Stephen wrote:

> I like just -xn
>
> Not -xaladark  ??  No?
> ________________________________________
> From: Bob Arnson [[hidden email]]
> Sent: January 5, 2015 6:51 PM
> To: [hidden email]
> Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching
>
> On 03-Jan-15 20:36, Stephen Tunney wrote:
>> Ok, so here's my pitch:
>>
>> v3.x would get a couple of new flags
>> -xn (extract in new directory format) <patch>
>> -xb (extract binaries, does not get squashed by -sextract and uses old
>> path format) <path>
> Do we need both? I like -xn -- subdirectories for files and binaries a
> la Dark, right? That provides binaries and prompts users to update their
> scripts and/or existing melt output.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> WiX-devs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> WiX-devs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

Bob Arnson-6
In reply to this post by scubasteve2
Dark extracts to a flat list of files named after their ids. Melt
extracts to a source tree, which makes it easier to update. Plus Melt
does the .wixpdb updating.

Putting the extraction/updating in Melt was a bad idea. (Whoever it was
who had that idea, I certainly can't remember.) It mixes two very
different things. Adding the functionality to Dark is a little better
but not by much. (Dark is *mostly* about decompiling; extraction is
something else tacked on.) I think it would make it easier to discover
the patching benefits if it were its own tool.

To be honest, if you wanted to do that for v4, it could start in v3:
Leave Melt.exe alone, copy the extraction/updating code to NewTool, add
the Binary extraction, and merge it (almost) as-is to v4.

The only downside: It will take significant research, discussion, and
heated debate to come up with a new tool name...

On 05-Jan-15 22:21, Tunney, Stephen wrote:

> Quick side question for 4.x
>
> Why do we have melt AND dark?  The two of you seem to want them to act the same, don't they really do the same thing (decompile a MS* database)?  Melt updates/generates a .wixpdb as well which is the only real difference I can see.
>
> Should it be considered to merge the two tools together perhaps?  Just a thought exercise perhaps but the questions you two both raised have put a smell in my nose.
> Stephen
> ________________________________________
> From: Bob Arnson [[hidden email]]
> Sent: January 5, 2015 6:51 PM
> To: [hidden email]
> Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching
>
> On 03-Jan-15 20:36, Stephen Tunney wrote:
>> Ok, so here's my pitch:
>>
>> v3.x would get a couple of new flags
>> -xn (extract in new directory format) <patch>
>> -xb (extract binaries, does not get squashed by -sextract and uses old
>> path format) <path>
> Do we need both? I like -xn -- subdirectories for files and binaries a
> la Dark, right? That provides binaries and prompts users to update their
> scripts and/or existing melt output.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> WiX-devs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> WiX-devs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

scubasteve2
molten.exe or lava.exe

dark and melty all in one :)  I'm not really sure how you guys come up with names.  It all made sense when I saw light, dark, melt, torch, etc.

Now I see Lux, retina, etc. and I'm confused.

I like Lava!  Put me in a +1 vote for that.
________________________________________
From: Bob Arnson [[hidden email]]
Sent: January 5, 2015 10:51 PM
To: [hidden email]
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

Dark extracts to a flat list of files named after their ids. Melt
extracts to a source tree, which makes it easier to update. Plus Melt
does the .wixpdb updating.

Putting the extraction/updating in Melt was a bad idea. (Whoever it was
who had that idea, I certainly can't remember.) It mixes two very
different things. Adding the functionality to Dark is a little better
but not by much. (Dark is *mostly* about decompiling; extraction is
something else tacked on.) I think it would make it easier to discover
the patching benefits if it were its own tool.

To be honest, if you wanted to do that for v4, it could start in v3:
Leave Melt.exe alone, copy the extraction/updating code to NewTool, add
the Binary extraction, and merge it (almost) as-is to v4.

The only downside: It will take significant research, discussion, and
heated debate to come up with a new tool name...

On 05-Jan-15 22:21, Tunney, Stephen wrote:

> Quick side question for 4.x
>
> Why do we have melt AND dark?  The two of you seem to want them to act the same, don't they really do the same thing (decompile a MS* database)?  Melt updates/generates a .wixpdb as well which is the only real difference I can see.
>
> Should it be considered to merge the two tools together perhaps?  Just a thought exercise perhaps but the questions you two both raised have put a smell in my nose.
> Stephen
> ________________________________________
> From: Bob Arnson [[hidden email]]
> Sent: January 5, 2015 6:51 PM
> To: [hidden email]
> Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching
>
> On 03-Jan-15 20:36, Stephen Tunney wrote:
>> Ok, so here's my pitch:
>>
>> v3.x would get a couple of new flags
>> -xn (extract in new directory format) <patch>
>> -xb (extract binaries, does not get squashed by -sextract and uses old
>> path format) <path>
> Do we need both? I like -xn -- subdirectories for files and binaries a
> la Dark, right? That provides binaries and prompts users to update their
> scripts and/or existing melt output.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> WiX-devs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> WiX-devs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

scubasteve2
In reply to this post by Bob Arnson-6
Also, I would say that we should do the *least* amount of work in v3 (ie. adding a simple switch to melt).

I could work on newtool.exe in v4 in my spare time.
________________________________________
From: Bob Arnson [[hidden email]]
Sent: January 5, 2015 10:51 PM
To: [hidden email]
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

Dark extracts to a flat list of files named after their ids. Melt
extracts to a source tree, which makes it easier to update. Plus Melt
does the .wixpdb updating.

Putting the extraction/updating in Melt was a bad idea. (Whoever it was
who had that idea, I certainly can't remember.) It mixes two very
different things. Adding the functionality to Dark is a little better
but not by much. (Dark is *mostly* about decompiling; extraction is
something else tacked on.) I think it would make it easier to discover
the patching benefits if it were its own tool.

To be honest, if you wanted to do that for v4, it could start in v3:
Leave Melt.exe alone, copy the extraction/updating code to NewTool, add
the Binary extraction, and merge it (almost) as-is to v4.

The only downside: It will take significant research, discussion, and
heated debate to come up with a new tool name...

On 05-Jan-15 22:21, Tunney, Stephen wrote:

> Quick side question for 4.x
>
> Why do we have melt AND dark?  The two of you seem to want them to act the same, don't they really do the same thing (decompile a MS* database)?  Melt updates/generates a .wixpdb as well which is the only real difference I can see.
>
> Should it be considered to merge the two tools together perhaps?  Just a thought exercise perhaps but the questions you two both raised have put a smell in my nose.
> Stephen
> ________________________________________
> From: Bob Arnson [[hidden email]]
> Sent: January 5, 2015 6:51 PM
> To: [hidden email]
> Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching
>
> On 03-Jan-15 20:36, Stephen Tunney wrote:
>> Ok, so here's my pitch:
>>
>> v3.x would get a couple of new flags
>> -xn (extract in new directory format) <patch>
>> -xb (extract binaries, does not get squashed by -sextract and uses old
>> path format) <path>
> Do we need both? I like -xn -- subdirectories for files and binaries a
> la Dark, right? That provides binaries and prompts users to update their
> scripts and/or existing melt output.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> WiX-devs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> WiX-devs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

Rob Mensching-7
I'm really not at all excited about *another* tool in v4. I'd much rather we be able to use the MSI and the cabs as the source without having to preprocess them. Maybe melt.exe keeps the functionality or maybe dark.exe is the best place for it but you only use it to optimize the process. Otherwise, the patch unbinder stuff can just use the original build output.

I guess that's where I'd like to see this in v4 (or later if it can't make v4): patching should operate off the standard build output: msi, external cabs/files, and .wixpdb. If we can't patch from that, we should enhance what we're outputting to patch it.

Having to think ahead makes in so many different ways makes patching terribly unapproachable.

_______________________________________________________________
 FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

-----Original Message-----
From: Tunney, Stephen [mailto:[hidden email]]
Sent: Monday, January 5, 2015 8:01 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

Also, I would say that we should do the *least* amount of work in v3 (ie. adding a simple switch to melt).

I could work on newtool.exe in v4 in my spare time.
________________________________________
From: Bob Arnson [[hidden email]]
Sent: January 5, 2015 10:51 PM
To: [hidden email]
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

Dark extracts to a flat list of files named after their ids. Melt extracts to a source tree, which makes it easier to update. Plus Melt does the .wixpdb updating.

Putting the extraction/updating in Melt was a bad idea. (Whoever it was who had that idea, I certainly can't remember.) It mixes two very different things. Adding the functionality to Dark is a little better but not by much. (Dark is *mostly* about decompiling; extraction is something else tacked on.) I think it would make it easier to discover the patching benefits if it were its own tool.

To be honest, if you wanted to do that for v4, it could start in v3:
Leave Melt.exe alone, copy the extraction/updating code to NewTool, add the Binary extraction, and merge it (almost) as-is to v4.

The only downside: It will take significant research, discussion, and heated debate to come up with a new tool name...

On 05-Jan-15 22:21, Tunney, Stephen wrote:

> Quick side question for 4.x
>
> Why do we have melt AND dark?  The two of you seem to want them to act the same, don't they really do the same thing (decompile a MS* database)?  Melt updates/generates a .wixpdb as well which is the only real difference I can see.
>
> Should it be considered to merge the two tools together perhaps?  Just a thought exercise perhaps but the questions you two both raised have put a smell in my nose.
> Stephen
> ________________________________________
> From: Bob Arnson [[hidden email]]
> Sent: January 5, 2015 6:51 PM
> To: [hidden email]
> Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary
> table for patching
>
> On 03-Jan-15 20:36, Stephen Tunney wrote:
>> Ok, so here's my pitch:
>>
>> v3.x would get a couple of new flags
>> -xn (extract in new directory format) <patch> -xb (extract binaries,
>> does not get squashed by -sextract and uses old path format) <path>
> Do we need both? I like -xn -- subdirectories for files and binaries a
> la Dark, right? That provides binaries and prompts users to update
> their scripts and/or existing melt output.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
> ----------------------------------------------------------------------
> -------- Dive into the World of Parallel Programming! The Go Parallel
> Website, sponsored by Intel and developed in partnership with Slashdot
> Media, is your hub for all things parallel software development, from
> weekly thought leadership blogs to news, videos, case studies,
> tutorials and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net 
> _______________________________________________
> WiX-devs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
> ----------------------------------------------------------------------
> -------- Dive into the World of Parallel Programming! The Go Parallel
> Website, sponsored by Intel and developed in partnership with Slashdot
> Media, is your hub for all things parallel software development, from
> weekly thought leadership blogs to news, videos, case studies,
> tutorials and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net 
> _______________________________________________
> WiX-devs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

scubasteve

I think at the end of the day we need to consolidate functionality as we have two tools that do the exact same thing (more or less).

Dark should be defined as a tool that deconstructs a database (msi or msm) into a wxs + exportable tables.  If this is the case then melt's functionality should be truncated to limit it to modifying the wixpdb.  Or melt essentially gets dropped and that wixpdb modification is put into dark if the wixpdb is supplied.

Having two tools that essentially do the same thing makes little sense and confuses patching which is what we want to get away from.

Stephen


On Mon, 19 Jan 2015 16:14 Rob Mensching <[hidden email]> wrote:
I'm really not at all excited about *another* tool in v4. I'd much rather we be able to use the MSI and the cabs as the source without having to preprocess them. Maybe melt.exe keeps the functionality or maybe dark.exe is the best place for it but you only use it to optimize the process. Otherwise, the patch unbinder stuff can just use the original build output.

I guess that's where I'd like to see this in v4 (or later if it can't make v4): patching should operate off the standard build output: msi, external cabs/files, and .wixpdb. If we can't patch from that, we should enhance what we're outputting to patch it.

Having to think ahead makes in so many different ways makes patching terribly unapproachable.

_______________________________________________________________
 FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

-----Original Message-----
From: Tunney, Stephen [mailto:[hidden email]]
Sent: Monday, January 5, 2015 8:01 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

Also, I would say that we should do the *least* amount of work in v3 (ie. adding a simple switch to melt).

I could work on newtool.exe in v4 in my spare time.
________________________________________
From: Bob Arnson [[hidden email]]
Sent: January 5, 2015 10:51 PM
To: [hidden email]
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

Dark extracts to a flat list of files named after their ids. Melt extracts to a source tree, which makes it easier to update. Plus Melt does the .wixpdb updating.

Putting the extraction/updating in Melt was a bad idea. (Whoever it was who had that idea, I certainly can't remember.) It mixes two very different things. Adding the functionality to Dark is a little better but not by much. (Dark is *mostly* about decompiling; extraction is something else tacked on.) I think it would make it easier to discover the patching benefits if it were its own tool.

To be honest, if you wanted to do that for v4, it could start in v3:
Leave Melt.exe alone, copy the extraction/updating code to NewTool, add the Binary extraction, and merge it (almost) as-is to v4.

The only downside: It will take significant research, discussion, and heated debate to come up with a new tool name...

On 05-Jan-15 22:21, Tunney, Stephen wrote:
> Quick side question for 4.x
>
> Why do we have melt AND dark?  The two of you seem to want them to act the same, don't they really do the same thing (decompile a MS* database)?  Melt updates/generates a .wixpdb as well which is the only real difference I can see.
>
> Should it be considered to merge the two tools together perhaps?  Just a thought exercise perhaps but the questions you two both raised have put a smell in my nose.
> Stephen
> ________________________________________
> From: Bob Arnson [[hidden email]]
> Sent: January 5, 2015 6:51 PM
> To: [hidden email]
> Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary
> table for patching
>
> On 03-Jan-15 20:36, Stephen Tunney wrote:
>> Ok, so here's my pitch:
>>
>> v3.x would get a couple of new flags
>> -xn (extract in new directory format) <patch> -xb (extract binaries,
>> does not get squashed by -sextract and uses old path format) <path>
> Do we need both? I like -xn -- subdirectories for files and binaries a
> la Dark, right? That provides binaries and prompts users to update
> their scripts and/or existing melt output.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
> ----------------------------------------------------------------------
> -------- Dive into the World of Parallel Programming! The Go Parallel
> Website, sponsored by Intel and developed in partnership with Slashdot
> Media, is your hub for all things parallel software development, from
> weekly thought leadership blogs to news, videos, case studies,
> tutorials and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net
> _______________________________________________
> WiX-devs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
> ----------------------------------------------------------------------
> -------- Dive into the World of Parallel Programming! The Go Parallel
> Website, sponsored by Intel and developed in partnership with Slashdot
> Media, is your hub for all things parallel software development, from
> weekly thought leadership blogs to news, videos, case studies,
> tutorials and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net
> _______________________________________________
> WiX-devs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

Rob Mensching-7

The purpose of the tools today are:

 

1.       dark.exe – decompile stuff back into source code. The ideal is perfectly round trippable source code but we’ve been lazy with bundles since no one really needs to round trip a bundle today. Of course, round tripping MSIs/MSMs is very important when converting from one MSI/MSM creation technology to the WiX toolset.

2.       melt.exe – make unpatchable stuff patchable. It started by transforming Merge Modules into .wixlibs because Merge Modules are not patchable but .wixlibs are. Later melt.exe was taught to update paths in .wixpdbs for those that did not use bind paths everywhere.

 

IMHO, those two tools serve different purposes today. They certainly share code underneath (pulling files out of the “MergeModule.CABinet”, for example) but I’m not sure that makes them the same tool.

 

For example, if you did “dark.exe foo.wixpdb –o output” today, I’d expect an “output” folder to be created with a bunch of .wxs code that I could compile with candle.exe. And today, “dark.exe foo.msm –o output” creates a bunch of .wxs files in the “output” folder... it does not create a .wixlib the way melt.exe does.

 

_______________________________________________________________

FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

 

From: Stephen Tunney [mailto:[hidden email]]
Sent: Monday, January 19, 2015 4:19 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

 

I think at the end of the day we need to consolidate functionality as we have two tools that do the exact same thing (more or less).

Dark should be defined as a tool that deconstructs a database (msi or msm) into a wxs + exportable tables.  If this is the case then melt's functionality should be truncated to limit it to modifying the wixpdb.  Or melt essentially gets dropped and that wixpdb modification is put into dark if the wixpdb is supplied.

Having two tools that essentially do the same thing makes little sense and confuses patching which is what we want to get away from.

Stephen

 

On Mon, 19 Jan 2015 16:14 Rob Mensching <[hidden email]> wrote:

I'm really not at all excited about *another* tool in v4. I'd much rather we be able to use the MSI and the cabs as the source without having to preprocess them. Maybe melt.exe keeps the functionality or maybe dark.exe is the best place for it but you only use it to optimize the process. Otherwise, the patch unbinder stuff can just use the original build output.

I guess that's where I'd like to see this in v4 (or later if it can't make v4): patching should operate off the standard build output: msi, external cabs/files, and .wixpdb. If we can't patch from that, we should enhance what we're outputting to patch it.

Having to think ahead makes in so many different ways makes patching terribly unapproachable.

_______________________________________________________________
 FireGiant  |  Dedicated support for the WiX toolset  |  http://www.firegiant.com/

-----Original Message-----
From: Tunney, Stephen [mailto:[hidden email]]
Sent: Monday, January 5, 2015 8:01 PM
To: WiX toolset developer mailing list
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

Also, I would say that we should do the *least* amount of work in v3 (ie. adding a simple switch to melt).

I could work on newtool.exe in v4 in my spare time.
________________________________________
From: Bob Arnson [[hidden email]]
Sent: January 5, 2015 10:51 PM
To: [hidden email]
Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary table for patching

Dark extracts to a flat list of files named after their ids. Melt extracts to a source tree, which makes it easier to update. Plus Melt does the .wixpdb updating.

Putting the extraction/updating in Melt was a bad idea. (Whoever it was who had that idea, I certainly can't remember.) It mixes two very different things. Adding the functionality to Dark is a little better but not by much. (Dark is *mostly* about decompiling; extraction is something else tacked on.) I think it would make it easier to discover the patching benefits if it were its own tool.

To be honest, if you wanted to do that for v4, it could start in v3:
Leave Melt.exe alone, copy the extraction/updating code to NewTool, add the Binary extraction, and merge it (almost) as-is to v4.

The only downside: It will take significant research, discussion, and heated debate to come up with a new tool name...

On 05-Jan-15 22:21, Tunney, Stephen wrote:
> Quick side question for 4.x
>
> Why do we have melt AND dark?  The two of you seem to want them to act the same, don't they really do the same thing (decompile a MS* database)?  Melt updates/generates a .wixpdb as well which is the only real difference I can see.
>
> Should it be considered to merge the two tools together perhaps?  Just a thought exercise perhaps but the questions you two both raised have put a smell in my nose.
> Stephen
> ________________________________________
> From: Bob Arnson [[hidden email]]
> Sent: January 5, 2015 6:51 PM
> To: [hidden email]
> Subject: Re: [WiX-devs] Updating Melt to extract files from the Binary
> table for patching
>
> On 03-Jan-15 20:36, Stephen Tunney wrote:
>> Ok, so here's my pitch:
>>
>> v3.x would get a couple of new flags
>> -xn (extract in new directory format) <patch> -xb (extract binaries,
>> does not get squashed by -sextract and uses old path format) <path>
> Do we need both? I like -xn -- subdirectories for files and binaries a
> la Dark, right? That provides binaries and prompts users to update
> their scripts and/or existing melt output.
>
> --
> sig://boB
> http://joyofsetup.com/
>
>
> ----------------------------------------------------------------------
> -------- Dive into the World of Parallel Programming! The Go Parallel
> Website, sponsored by Intel and developed in partnership with Slashdot
> Media, is your hub for all things parallel software development, from
> weekly thought leadership blogs to news, videos, case studies,
> tutorials and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net
> _______________________________________________
> WiX-devs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
> ----------------------------------------------------------------------
> -------- Dive into the World of Parallel Programming! The Go Parallel
> Website, sponsored by Intel and developed in partnership with Slashdot
> Media, is your hub for all things parallel software development, from
> weekly thought leadership blogs to news, videos, case studies,
> tutorials and more. Take a look and join the conversation now.
> http://goparallel.sourceforge.net
> _______________________________________________
> WiX-devs mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net _______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs

------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
Reply | Threaded
Open this post in threaded view
|

Re: Updating Melt to extract files from the Binary table for patching

Bob Arnson-6
In reply to this post by Rob Mensching-7
On 19-Jan-15 16:13, Rob Mensching wrote:
> I'm really not at all excited about *another* tool in v4.
Why do we have Light and Lit? :)
> I guess that's where I'd like to see this in v4 (or later if it can't make v4): patching should operate off the standard build output: msi, external cabs/files, and .wixpdb. If we can't patch from that, we should enhance what we're outputting to patch it.
The current model seems like a bad fit for magicking the .wixpdbs. I
think we need a higher-level model to squeeze that in. I'm not at all
opposed to that, fwiw. :)

--
sig://boB
http://joyofsetup.com/


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
_______________________________________________
WiX-devs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/wix-devs
12