[wix-devs] WIXBUG3704 - Allow access to persisted variables from related bundles

[Rob Mensching]

Random thought: The Windows Installer uses prefixes for registry values (https://docs.microsoft.com/en-us/windows/win32/msi/registry-table) to preserve type.

-----Original Message-----
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean Hall via wix-devs
Sent: Friday, April 30, 2021 11:00 AM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Cc: Sean Hall <r.sean.hall at gmail.com>
Subject: Re: [wix-devs] WIXBUG3704 - Allow access to persisted variables from related bundles

>  but I am not sure what behavior changes assigning a string to a 
> version
variable would cause.

The only difference is their comparison logic in conditions. I just took a deeper look (CompareOperands in condition.cpp), and it looks like this wouldn't work. Strings would be compared using versioning logic (or vice versa depending on which one Burn chose). So sharing REG_SZ is a bad idea.

I'm just trying to throw out ideas that are simple to implement that don't require throwing variables into a binary format. I think it's worth using EXPAND_SZ for a purpose other than its intended purpose - that it signifies unexpanded environment variables - but maybe other people feel differently.

If VERSION isn't REG_SZ, then maybe we can put it in EXPAND_SZ even though there is nothing to expand. This would have the additional benefit that version strings really shouldn't have '%' chars so if someone did try to expand it there would be no change.

>  why do we need to differentiate between STRING and FORMATTED?

These definitely need to be differentiated. The point of STRING is to hold paths like C:\[pathwithbrackets]\ that don't get formatted. Given that FORMATTED variables are expected to have unexpanded variables, there's probably a lot less value in having them available transparently so maybe FORMATTED should continue to be stored with REG_BINARY like you have it right now.

On Fri, Apr 30, 2021 at 11:11 AM Hoover, Jacob wrote:

> If you don’t have a unique registry type per variable type, then on 
> restore you would end up loosing that.  IE, round tripping a version 
> variant through the registry, on restore we would no longer know it’s 
> a version, so it would get assigned as a string. I know you recently 
> did a lot of rework on VERSION to support semantic versioning, but I 
> am not sure what behavior changes assigning a string to a version variable would cause.
>
>
>
> For FORMATTED vs EXPAND_SZ, while they seem similar, we don’t have 
> environment variables to expand in the value. If VERSION can be 
> assigned as a string, why do we need to differentiate between STRING and FORMATTED?
>
>
>
> Either way, it seems that reg_none (no helper methods in regutil, so I 
> missed this option) results in a hex(0): and reg_expand_sz results in 
> a hex(2):…
>
>
>
> *From:* wix-devs *On Behalf Of *Sean Hall via wix-devs
> *Sent:* Thursday, April 29, 2021 11:04 PM
> *To:* WiX Toolset Developer Mailing List
> *Cc:* Sean Hall
> *Subject:* Re: [wix-devs] WIXBUG3704 - Allow access to persisted 
> variables from related bundles
>
>
>
> We discussed this issue in
>
> https://www.firegiant.com/blog/2020/10/15/wix-online-meeting-198-highl
> ights/ (starts at 39:03). Most of that discussion was settling the
> hidden+persisted issue (compiler error - done) and the encryption 
> hidden+issue
> (don't do it, pull the existing variable encryption - done). We agreed 
> that the registry would be a good place to persist the variables but 
> kicked the issue back to wix-devs to design how to store the types of the variables.
> That never happened, so here we are. Jacob has a draft PR at 
> https://github.com/wixtoolset/burn/pull/56.
>
> The current variant types are NONE, NUMERIC, STRING, FORMATTED, and 
> VERSION. I think we can map these to the registry types REG_NONE, 
> REG_QWORD, REG_SZ, REG_EXPAND_SZ, and REG_SZ, respectively. You might 
> notice that REG_SZ is used for both STRING and VERSION. The only 
> difference between these types is their comparison logic in 
> conditions. When we designed FORMATTED, we decided to keep the v3 API 
> surface where the BA was not able to ask what the current type of a 
> variable is. So I think there's no problem here. This would mean that 
> all types are stored transparently and easily consumable with minimal 
> code. It also leaves REG_BINARY reserved in case something changes in the future, like adding new variable types.
>
> This does have implications on the APIs Jacob is adding to allow 
> looking up arbitrary variables for arbitrary bundles. There is 
> currently a method in those APIs that returns the type of the 
> variable. It is currently returning a DWORD but I think that it should 
> be returning an enum. This brings up a question I had about how to 
> share an enum between the Burn headers and the dutil headers, which 
> don't have any relationship today (I don't remember the context of 
> that earlier discussion). I think we can sidestep that issue again by 
> either removing the ability to query the type, or simply return the 
> registry type. I think we should probably leave it in the dutil API 
> but remove it from the engine API. Either way, I think the engine API needs to do the same coercion that it does for the normal variable get methods.
>
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/