#518 No support for Long Filenames in COM Registry entries

[tcassisi]

Non-advertised COM Registry entries are generated from
the <progid>, <class>, etc XML tags as per the Schema
documentation.</class></progid>

However, when following the latest naming trends, quite
long filenames are used that differ at the end and not
the beginning:

MyCompany.MyProduct.Name1.exe
MyCompany.MyProduct.Name2.dll
MyCompany.MyProduct.Name3.dll

In my case, I have 4 of these with more on the way.

My understanding is that the shortname mappings for
these are not guaranteed to be unique across all
systems (i.e. the assigning of ~1, ~2, et al is not
always a unique mapping depending on the nature of the
long names being mangled).

Two examples from the registry of my own machine:

D:\Program Files\Microsoft Office\Office10\MSE7.EXE
/JITDebug

and

"D:\Program Files\Common Files\Microsoft
Shared\VSA\8.0\VsaEnv\vsaenv.exe" VSM

Personally, it makes more sense to place double quotes
around the part to execute only if arguments are requested.

---

Given it is unclear what precisely the syntax is on all
O/S platforms, I suggest adding an optional attribute
to the AppId, Class, Typelib and Interface to control
long name production.

An alternative could be a Candle switch to indicate
this MSI only supports long file names?

If there is no long-name equivalent MSI syntax to [!X],
perhaps the relevant Directory property name could be
inserted and the name of the file added?

Unfortunately my knowledge of MSI is not sufficient to
suggest a single alternative to [!X].

[Derek]

Logged In: YES
user_id=518766

The [!fileId] syntax should always be correct for the system
on which the msi file was installed. It does not use the
short file name specified in the wix/msi authoring. It uses
the actual short file name assigned by the file system.
Therefore, these short file names will always be correct and
map to only the proper file being registered.

WiX uses the short file for COM registration because at one
point in time (and perhaps even now), there were issues with
mixing long and short file names for the COM registration of
a given file. To guarantee the proper behavior, WiX adopted
the short file name as a canonicalized solution to this
issue. While the registration may look ugly - it should
work 100% of the time.

[tcassisi]

Logged In: YES
user_id=1453673

I'm going to have to bring this up again I'm afraid.

If short file names references are put there by WiX, then
when COM creates that process, the visible name will be the
mangled short name.

E.g. in all crash dialogs, in the task manager, et al, u
will find it very hard to determine which file is which if u
follow the new conventions of companyname.x[.y].exe|.dll.

The request is to allow a switch to turn on the use of long
names only in all places automatically generated by WiX --
which is the COM Registry at a minimum.

Thanks.

[Derek]

Logged In: YES
user_id=518766

Do you have any screen shots of the task manager or crash
dialog issue? If we offer this option, we'll need to have
really, really strong justification for it. The only reason
I'm so hesitant is that supporting long file names can
actually be a security risk in some scenarios.

[tcassisi]

Short file names

[tcassisi]

Logged In: YES
user_id=1453673

As requested, example of stack trace for a COM Server
installed via current Wix short-name keys:

a) Notice the FINCDA~1.EXE references, making it downright
difficult to distinguish different EXE's.

b) Notice the DLL which is not a COM Server
(FincData.Utilities-d.dll).

FINCDA~1.EXE caused an EXCEPTION_NONCONTINUABLE_EXCEPTION in
module kernel32.dll at 001B:77E738B2, RaiseException()+0080
byte(s)
EAX=0012F724 EBX=7FFDF000 ECX=00000000 EDX=10312BF8
ESI=00000000
EDI=0012F858 EBP=0012F774 ESP=0012F720 EIP=77E738B2
FLG=00000246
CS=001B DS=0023 SS=0023 ES=0023 FS=003B GS=0000
001B:77E738B2 kernel32.dll, RaiseException()+0080 byte(s)
001B:60024BD1 FincData.Utilities-d.dll,
GetSuperAssertionCount()+48087 byte(s)
001B:102137A9 MSVCR80D.dll, raise()+0665 byte(s)
001B:10218683 MSVCR80D.dll, abort()+0067 byte(s)
001B:0065661C FINCDA~1.EXE, rtrfail()+0044 byte(s)
001B:00631634 FINCDA~1.EXE, RTRTimerCmd::deactivate()+0036
byte(s)
001B:005B55CA FINCDA~1.EXE, CDDEServer::Shutdown()+0106 byte(s)
001B:005DD895 FINCDA~1.EXE, wWinMain()+0661 byte(s)
001B:007C8F79 FINCDA~1.EXE, wWinMainCRTStartup()+0681 byte(s)
001B:007C8CDD FINCDA~1.EXE, wWinMainCRTStartup()+0013 byte(s)
001B:77E8141A kernel32.dll, GetCurrentDirectoryW()+0068 byte(s)

[tcassisi]

Short file names

[tcassisi]

Short file names

[Derek]

Logged In: YES
user_id=518766

I definitely agree that the screenshots are less than
desirable, however, upon further investigation, the security
implications of using long file names in COM registration
and particularly shortcuts dictate that we protect users by
default and always use short file names.

Here's the detailed explanation that I recieved:
Shortcuts get created with short paths (for
security/createprocess issues with spaces on createprocess)
That means modules that are loaded by the exe’s static dll
references also get short names.
Then if you load the same modules with COM – if you don’t
also use short names for that registration, you will get a
second copy of the module loaded into your process since the
NT loader isn’t smart enough to do short vs long path
conversions when checking if a module is already loaded.
There are probably more reasons, but I remember these as a
big ones in windows installer v1:
Shortcuts launching the wrong thing when they had spaces
and you put ‘program’ or something in the root of c:
Major perf issues with modules getting loaded twice in a
process and the second one getting rebased, etc

If you'd still like to use long file names despite the
potential for security and performance issues, please use
the Registry elements directly.

[tcassisi]

Logged In: YES
user_id=1453673

Unfortunately the comments regarding this seem considerably
pre Activation Contexts, embedded manifests as implemented
in and my target O/S, WXP and compiler, VS8.

Moreover, I'm only talking COM registry keys here, not
shortcuts (which are not related in this case), but anyway
there's no harm in adding them to the mix :)

Take this scenario:

The screen shots clearly show that my VS8 built binary has
links to the LFN. Changing this is technically difficult, so
clearly not something Microsoft seems currently concerned
about in VS8.

So if I were to use COM to subsequently load that binary via
WiX's MSI today, if the comment regarding the loader is
still correct in WXP SP1+, then I'd get another copy loaded
via the SFN.

Now this is clearly a problem I agree.

But I'm saying that a) VS8 links to my LFN but b) WiX uses
the SFN for COM registration.

Surely it is up to WiX to be compliant with what comes out
of VS8 on WXP+ and not vice-versa.

Given this new Activation Context we live in, and the
enforcement of Manifests in VS8 binaries (both of which use
the full names of entitites btw), it seems sensible that:
a) WiX dispenses with the SFN "Name" entries completely or
just uses the sequence number instead to keep the MSI happy
b) All entries generated including shortcuts will be the LFNs

However, allowing the generated MSI references ([!X] et al)
to be controllable via a command line switch to stop the
reputed dual-loading problem described for VS8 COM binaries
seems reasonable.

The alternative of "rolling u're own" registry keys for
large numbers of coclasses + interfaces is not pleasant.

Unless u're saying it is possible to a) leave the existing
WiX entries and b) add in a Registry tag only to overwrite
the errant entry.

But is this a supported mechanism in Wix (so unlikely to
change in future versions)?

Thanks.

[Derek]

Logged In: YES
user_id=518766

It is not possible to doubly-author registry keys in
strongly-typed COM classes and Registry elements.

If you'd like, please start a thread on wix-users to open up
this dicusssion to the community.

[tcassisi]

Logged In: YES
user_id=1453673

As requested, reopened.

[Derek]

Logged In: YES
user_id=518766

MSI appears to use the long file name settings of a package
to determine whether to write long or short file names. WiX
can't do this, but the fact that MSI allows the long file
names likely means that it should be safe to use as the
default in WiX 3.0. We will still need to support short
file names for compatibility, but that's not very difficult.

[Derek]

Logged In: YES
user_id=518766

Should be fixed in the next drop. Hopefully this doesn't up
any security issues due to spaces in paths.

[tcassisi]

Logged In: YES
user_id=1453673

That's great news, thanks! Btw, you had mentioned
short-cuts as another area of debate over the long/short
names: what was the conclusions in the end?

Or will one switch/option/attribute globally provide
consistently long/short names?

Thanks.

[Derek]

Logged In: YES
user_id=518766

Non-advertised shortcuts will use long file names.
Advertised shortcuts should use long or short names
depending upon whether the target machine supports long file
names, the SHORTFILENAME property is set, etc...

For additional questions related to this bug, please post to
wix-users instead so that everyone can participate in the
conversation (unless of course the fix regresses in which
case re-activating is completely appropriate).