Menu
▾
▴
[WiX-devs] [ wix-Bugs-1445483 ] No support for Long Filenames in COM Registry entries
|
From: SourceForge.net <no...@so...> - 2006-04-07 09:32:40
|
Bugs item #1445483, was opened at 2006-03-08 09:24 Message generated for change (Comment added) made by tcassisi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1445483&group_id=105970 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: candle Group: v3.0 Status: Closed Resolution: Rejected Priority: 5 Submitted By: tcassisi (tcassisi) Assigned to: Derek (derekc) Summary: No support for Long Filenames in COM Registry entries Initial Comment: Non-advertised COM Registry entries are generated from the <ProgId>, <Class>, etc XML tags as per the Schema documentation. 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]. ---------------------------------------------------------------------- >Comment By: tcassisi (tcassisi) Date: 2006-04-07 10:32 Message: 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. ---------------------------------------------------------------------- Comment By: Derek (derekc) Date: 2006-04-07 03:43 Message: 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. ---------------------------------------------------------------------- Comment By: tcassisi (tcassisi) Date: 2006-03-31 16:33 Message: 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) ---------------------------------------------------------------------- Comment By: Derek (derekc) Date: 2006-03-24 18:31 Message: 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. ---------------------------------------------------------------------- Comment By: tcassisi (tcassisi) Date: 2006-03-24 18:14 Message: 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. ---------------------------------------------------------------------- Comment By: Derek (derekc) Date: 2006-03-08 18:47 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=642714&aid=1445483&group_id=105970 |