[Bug 45208] Microsoft Office 2010 installer crashes at around 50 % mark

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=45208

--- Comment #26 from Andrew <andrewbb43 at gmail.com> ---
(In reply to Zebediah Figura from comment #25)
> I've been really trying to think of something to do with this, and coming up
> essentially empty.
> 
> Trying to emulate Windows behaviour here means not only adjusting the string
> table heuristics such that the string table is rebuilt during this custom
> action and this one alone—a difficult task if it's even possible—but also
> introducing an artificial slowdown to guarantee that our rebuilding process
> takes at least 5 seconds.
> 
> The installer runs a custom action which checks a global variable, calls
> GetTickCount() if it's unset, then repeatedly calls
> MsiViewModify(MSIMODIFY_INSERT_TEMPORARY), raising an exception when this
> fails due to primary key collision. Trying to introduce a hack to interrupt
> this sequence means, as far as I can tell:
> 
> * keeping old DLLs loaded in the custom action server. But this would
> reintroduce bug 10365. Maybe none of those applications are as widely used
> as Office 2010, but there are several of them, and I'd really like to not do
> this as it means trading one unsolvable problem for another.
> 
> * introducing slowdown somewhere in the normal sequence of operations. This
> would affect a huge amount of installers. The slowdown needs to be 5 whole
> seconds, which is patently absurd.
> 
> * adjusting MSIMODIFY_INSERT_TEMPORARY to not fail when collisions happen.
> This seems very dangerous, and liable to break other installers (if not this
> one). Besides which we'd be dropping entries in the table (and while many of
> them are duplicates, not all of them are).
> 
> The best thing I can think of to do is an application-specific hack. Despite
> that these have always been forbidden (except, for whatever reason, that one
> in winevulkan), I really can't see any better option. At any rate it's not a
> workaround for an undiagnosed problem; the problem is understood and all but
> unsolvable.
> 
> Otherwise I don't think there's anything to do but leave at least one bug in
> our tracker closed as WONTFIX.

On the contrary, I happened upon a Office 2010 copy and decided to install it
through Wine on a 32-bit prefix myself. This Wine prefix was completely stock,
and the installer worked perfectly for me at least on Wine 4.21. I would
recommend that the status of this bug is RESOLVED to anyone interested.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.