ms office 97 install: failed to automatically register accwiz.dll

[Jérôme]

Binary package hint: wine1.2

I tried to install a genuine Microsoft Office 97 CD on wine with the Windows 98 flavour of Microsoft Windows.

The install process fails after it copied the files. I have an error windows which tells (translated from french):
"The automatic registration attempt of Accwiz.dll into the system registry database failed".

ProblemType: Bug
Architecture: i386
Date: Mon Nov 9 16:09:25 2009
DistroRelease: Ubuntu 9.10
InstallationMedia: Xubuntu 9.10 "Karmic Koala" - Release i386 (20091028.3)
Package: wine1.2 1.1.31-0ubuntu3
ProcEnviron:
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: wine1.2
Uname: Linux 2.6.31-14-generic i686
XsessionErrors:
 (xfce4-mixer-plugin:1346): libxfce4mixer-CRITICAL **: xfce_mixer_get_track: assertion `GST_IS_MIXER (card)' failed
 (polkit-gnome-authentication-agent-1:1351): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (xfce4-terminal:1376): Terminal-WARNING **: Unable to load terminal preferences.

[Dan Kegel (dank)]

Created an attachment (id=1264)
Log of WINEDEBUG=+ole,+dialog wine \\mnt\\setup.exe

This is with wine as of a few days ago.

[Dan Kegel (dank)]

Same thing with Wine from tonight's cvs.
Here are the fixme's:

fixme:font:WineEngRemoveFontResourceEx :stub
fixme:font:CreateScalableFontResourceA
(0,"c:\\windows\\offsetup.for","c:\\windows\\offsetup.ttf",(null)): stub
fixme:ole:MkParseDisplayName (0x7eb38788, L"stdole32.tlb", 0x7b93ed34, 0x110): stub.
fixme:ole:MkParseDisplayName (0x7eb38908, L"stdole32.tlb", 0x7b93ec60, 0x110): stub.
fixme:ole:MkParseDisplayName (0x7eb38908, L"STDOLE32.TLB", 0x7b93ee88,
0x7eb3ab04): stub.

[Dan Kegel (dank)]

I should have written "Microsoft Office 97". Forgot to mention the vendor.

[Dan Kegel (dank)]

Still happens, same errors, with 0.9.12 (well, Mike McCormack's current git).
(I see this happens on Windows sometimes:
http://support.microsoft.com/kb/q175323/
but that seems to be user error.)

This time around I checked to see if the installation
was successful in spite of the error. Sure enough,
it seems to be. There are a few warnings the first
time you start up winword.exe, but it seems to function.

[Dan Kegel (dank)]

word and excel seem to start ok (ignoring a warning about stdole.tlb not
being registered), but access won't start; it complains there's no license.
I guess that happens later in the setup.

[Dan Kegel (dank)]

Still happening with wine-0.9.15 (though now I no longer
have to use winecfg to set win98 mode; win2k mode
gets me just as far).

[Dan Kegel (dank)]

Oh, and I didn't have to override odbccp32 this time, either.

[James Hawkins (truiken)]

I just ran the MS Office 97 installation, and it crashed at the very end with a
call to unimplemented function mapi32.MAPIOpenLocalFormContainer. I'll send a
stub to wine-patches.

[James Hawkins (truiken)]

Patch accepted.

[Dan Kegel (dank)]

Funny, I'm still seeing the accwiz error message, even
after syncing via git this evening. I'll check again
in the morning, maybe this is a simple case of fuzzyhead.

[Fhj52ads (fhj52ads)]

Why is this marked as RESOLVED FIXED?
There is no fix here.

Because this was showing FIXED I just attempted the Office 97 install. I
received the same error.
The programs are not fully installed and will not run properly.
E.g., Office shows nothing but toolbar and Excel errors-out when trying to
create a graph(my ONLY reason for installing MS OS SW...).

#> wine --version
wine-0.9.28

#> uname -srv
Linux 2.6.18.2-34-default #1 SMP Mon Nov 27 11:46:27 UTC 2006

( Dual AMD Opteron system, x86_64 GNU/Linux = openSUSE 10.2 w/ 32-bit
compatibility )

[James Hawkins (truiken)]

This bug is about the *installer*. If the app being installed doesn't work,
then that's a completely different bug to report.

[Winehq-richardneill (winehq-richardneill)]

This is still *broken*, as of 0.9.31.

Re #12, I think you missed the point of #11. Indeed, the programs don't work
properly once installed, but this is as a result of a failure of the installer.

A workaround for this bug is to copy the dll into place manually. Assuming you
have the install disk (or disk image) mounted at /mnt/cdrom, do:
 cp /mnt/cdrom/OS/System/accwiz.dll .wine/drive_c/windows/system32/
winword.exe will now start normally, and allow you to type some text.

Given how easy the workaround is, presumably it would be pretty easy to fix?

[My system: Ubuntu Edgy, and an absolutely default wine setup, as created by: rm
-rf ~/.wine; winemine]

[Webmaster-marielulingerie (webmaster-marielulingerie)]

With Unbuntu Edgy & wine 0.9.31 had successful install by first copying
accwiz.dll then running custom install of only word + excel + powerpoint.

[Winehq-hypertwins (winehq-hypertwins)]

Copying the accwiz.dll file over does not resolve the installer problem for me
(indeed, the file is already there). See screenshot here:
http://htyp.org/Image:2007-03-10_WINE_and_MS_Office_97.crop.png

[Lesjaw (lesjaw)]

yup..copying accwiz.dll doesn't resolve the installer problem..infact i have
tested without copying it and the result word, excel and powerpoint did works
(i can open, save and edit)..if we custom install and not choose access the
installer seems works fine..i need access to run..its always failed

[Lesjaw (lesjaw)]

btw..if u want to succeed install ms office97 try the old wine version
200...with winetools..for me it works nearly perfect..

[Gon (gon)]

I know its soooo dirty but for those people that doesnt know how to fix this:

I copied the DLL:
cp OS/SYSTEM/ACCWIZ.DLL /home/pcbsd/.wine/drive_c/windows/system32/Accwiz.dll

I installed the MSOffice97 program (I tried this with all wine 0.9.3x and win98/xp):
wine SETUP.EXE
--->Some errors given and ignored.

As Accwiz.dll shows me a little window telling me that the dll cant register
himself, I used a command to register it manually:
wine regsrv32.exe Accwiz.dll (from Accwiz.dll folder in system32)

Once all its done, I had to run more than twice the WINWORD.EXE (ie) in order to
stop warnings (the first one was about missing files, the second one about
serial problem and the third one about..dunno)
Up to the third time I run it, goes perfectly.

[timsoft (tim-tree-of-life)]

i am getting same problem with setup and wine 0.9.37 on slackware 11 with
2.6.21.1 kernel. I can manually register appwiz.dll but winword just shows
splash screen and freezes with following..
fixme:x11drv:X11DRV_GetDeviceCaps (0x30c): CAPS1 is unimplemented, will return 0
fixme:psdrv:PSDRV_DeviceCapabilities DC_BINADJUST: stub.
fixme:psdrv:PSDRV_DeviceCapabilities DC_BINADJUST: stub.
fixme:psdrv:PSDRV_ExtEscape QUERYESCSUPPORT(25) - not supported.
err:winspool:WINSPOOL_GetDriverInfoFromReg Can't find driver L"hp1150" in registry
err:winspool:WINSPOOL_GetDriverInfoFromReg Can't find driver L"hp1150" in registry

[James Hawkins (truiken)]

*** Bug 8929 has been marked as a duplicate of this bug. ***

[James Hawkins (truiken)]

Reopening.

[Aflones (aflones)]

Here is a fix that *works* for the accwiz.dll problem. Installation completes with no problems.

http://wine-review.blogspot.com/2007/09/running-ms-office-97-under-linux-with.html

Maybe this will help others to get MS Office 97 installed. I cannot vouch for whether all the Office apps work correctly. I haven't delved very deeply into the apps, but MS Access will at least start.

[Dan Kegel (dank)]

Arne, thanks for the recipe. Strictly speaking, that's
a workaround, not a fix. But it's still handy until we have a fix.

[James Hawkins (truiken)]

*** Bug 13648 has been marked as a duplicate of this bug. ***

[Alexandre-linuxfr (alexandre-linuxfr)]

Created an attachment (id=13884)
Log without debug option

[Alexandre-linuxfr (alexandre-linuxfr)]

(From update of attachment 13884)
Oops, I attached the file on the wrong bug report (was supposed to be #13822).
Plz delete it.

[Unxed (unxed)]

Reproduced with wine 1.0.0.

[Dimesio (dimesio)]

I tested it on 1.1.1, openSUSE 10.3, clean wineprefix, default Wine settings. Word, Excel, and Powerpoint install fine and all start up without error messages.

If Access is included in the install, the installer gives the error message about being unable to register accwiz.dll. Trying to start Access gives the popup error message "Microsoft Access can't start because there is no license for it on this machine", but there are no messages whatsoever in the console.

[Dimesio (dimesio)]

I did a little more testing, and need to qualify my earlier post (sorry). My previous test was for a custom install; first I installed Word, Excel, and Powerpoint, then I ran the installer again, adding Access. The result was as I reported: Word, Excel, & Powerpoint work fine, Access gives the error message about no license. I have since tried selecting a "Typical" install, and none of the programs install properly under that option.

[Robertshearman (robertshearman)]

Please attach a +ole debug log when reproducing this bug with a recent version of Wine in a fresh ~/.wine directory.

Also, please try adding a builtin-only dlloverride for oleaut32.

[Dimesio (dimesio)]

Created an attachment (id=15462)
+ole log of "Typical" install, current git

Tested with the current git, clean wineprefix, default winecfg settings, "Typical" install.

The message about accwiz.dll is still there at the end. Trying to start the installed programs, Word and Excel show an error message (mostly hidden by the splash screen) the first time they are started, but start up normally thereafter. Powerpoint starts up fine without any error messages. Access still gives the message about not having a valid license.

I also tried with oleaut32 set to builtin only, and it made no difference.

[linux fan (linuxscratch)]

After installing DCOM98.EXE, it installed OK without the "accwiz.dll failed" message.

I also set these DllOverrides in Libraries Tab or by editing user.reg

[Software\\Wine\\DllOverrides]
"itss"="native,builtin"
"ole32"="native,builtin"
"oleaut32"="native,builtin"
"olepro32"="native,builtin"
"rpcrt4"="native,builtin"
"stdole2.tlb"="native,builtin"
"stdole32.tlb"="native,builtin"

[Focht (focht)]

Hello,

random pick, fortunately I got hold of some Office 97 copy ... ;-)
The main problem is Office 97 installer shipping its own version of ole automation library "oleaut32.dll" which is dynamically loaded at install time using a different library alias -> "32autole.dll".

This only happens for installation/registration purpose of "Microsoft Access Wizard Control Library" -> "ACCWIZ.DLL".

--- snip Setup\ACME.LST ---
[Windows 95 Files]
...
os\system\oleaut32.dll = 32autole.dll

[NT3.51 Intel Files]
...
os\system\oleaut32.dll = 32autole.dll
--- snip Setup\ACME.LST ---

In installer OS\system dir:

--- snip ---
$ls -l OS/SYSTEM/OLEAUT32.DLL
-rw-rw-r-- 1 focht focht 491792 1996-11-21 11:37 OS/SYSTEM/OLEAUT32.DLL
--- snip ---

When "accwiz.dll" is loaded, DllRegisterServerEx("32autole.dll") is called.

--- snip ---
0024:Call KERNEL32.LoadLibraryExA(0033f7e8 "C:\\windows\\system32\\ACCWIZ.DLL",00000000,00000008) ret=004076a6
0024:trace:snoop:SNOOP_SetupDLL hmod=0x6e150000, name=accwiz.DLL
0024:Call PE DLL (proc=0x610dc900,module=0x61030000 L"oleaut32.dll",reason=PROCESS_ATTACH,res=(nil))
...
0024:Ret PE DLL (proc=0x6e15e79c,module=0x6e150000 L"ACCWIZ.DLL",reason=PROCESS_ATTACH,res=(nil)) retval=1
0024:Ret KERNEL32.LoadLibraryExA() retval=6e150000 ret=004076a6
0024:Call KERNEL32.GetProcAddress(6e150000,008f96b8 "DllRegisterServerEx") ret=00418211
0024:Ret KERNEL32.GetProcAddress() retval=01250033 ret=00418211
0024:CALL accwiz.DllRegisterServerEx(<unknown, check return>) ret=00418244
0024:Call KERNEL32.LoadLibraryA(008f96d0 "32autole.dll") ret=6e15eb46
0024:trace:snoop:SNOOP_SetupDLL hmod=0x65340000, name=OLEAUT32.dll
0024:Call PE DLL (proc=0x6534b9ac,module=0x65340000 L"32autole.dll",reason=PROCESS_ATTACH,res=(nil))
...
0024:Ret PE DLL (proc=0x6534b9ac,module=0x65340000 L"32autole.dll",reason=PROCESS_ATTACH,res=(nil)) retval=1
0024:Ret KERNEL32.LoadLibraryA() retval=65340000 ret=6e15eb46
0024:Call KERNEL32.GetProcAddress(65340000,6e168378 "LoadTypeLib") ret=6e15eb65
0024:Ret KERNEL32.GetProcAddress() retval=01260aa0 ret=6e15eb65
0024:Call KERNEL32.GetProcAddress(65340000,6e168384 "RegisterTypeLib") ret=6e15eb75
0024:Ret KERNEL32.GetProcAddress() retval=01260ac2 ret=6e15eb75
--- snip ---

All typelib registration stuff goes through "32autole.dll" a.k.a. OLEAUT32.DLL
Wine's builtin one is not used at that time (see previous proc addr resolutions).

Basically it boils down to LoadTypeLib() and RegisterTypeLib() problems of "stdole32.tlb".
It first tries to locate the typelib path using registry:

--- snip ---
...
0024:Call advapi32.RegOpenKeyA(80000000,653b28ac "TypeLib",0033ebc8) ret=65351c33
0024:Ret advapi32.RegOpenKeyA() retval=00000000 ret=65351c33
0024:Call advapi32.RegOpenKeyW(000000f0,653b25dc L"{00020430-0000-0000-C000-000000000046}",0033ebcc) ret=65353360
0024:Ret advapi32.RegOpenKeyW() retval=00000000 ret=65353360
0024:Call advapi32.RegOpenKeyA(000000f4,0033ebb4 "1.0",0033ee18) ret=65351ca2
0024:Ret advapi32.RegOpenKeyA() retval=00000000 ret=65351ca2
0024:Call advapi32.RegOpenKeyA(000000f8,0033ebcc "0",0033eba8) ret=65351bb6
0024:Ret advapi32.RegOpenKeyA() retval=00000000 ret=65351bb6
0024:Call advapi32.RegOpenKeyW(000000fc,...

[Austin English (austinenglish)]

Please retest in current git. If still present, update version field to earliest known version of wine that had this bug. Thanks!

[Winehq-richardneill (winehq-richardneill)]

Re #34,

I'm sorry I can't get the current git to build (it requires the 32-bit X devel libraries, but the package conflicts with my 64-bit system's X-devel libraries).
Anyway, I tested in the most recent wine release, i.e. 1.1.12, from a few days ago, and this bug is still there.

As for your request to "update version field to earliest known version of wine that had this bug", the answer is "the dim-and-distant past". This bug was first reported in 2005, and probably existed a long time before then.

[Austin English (austinenglish)]

(In reply to comment #35)
> Re #34,
>
> I'm sorry I can't get the current git to build (it requires the 32-bit X devel
> libraries, but the package conflicts with my 64-bit system's X-devel
> libraries).
> Anyway, I tested in the most recent wine release, i.e. 1.1.12, from a few days
> ago, and this bug is still there.

Thanks.

> As for your request to "update version field to earliest known version of wine
> that had this bug", the answer is "the dim-and-distant past". This bug was
> first reported in 2005, and probably existed a long time before then.
>

We're deprecating the CVS/GIT tag...I'll just set it to something close.

[Saulius Krasuckas (saulius2)]

In re: #33
|
| All typelib registration stuff goes through "32autole.dll" a.k.a. OLEAUT32.DLL
| Wine's builtin one is not used at that time
  ...
| Basically it boils down to LoadTypeLib() and RegisterTypeLib() problems of
| "stdole32.tlb".
  ...
| It turned out that the shipped ole automation bootstrapper expects
| "stdole32.tlb" in v1 format (ICreateTypeLib/SGLT), not the v2 format wine
| currently provides (ICreateTypeLib2/MSFT).
| When manually generating a v1 typelib using ICreateTypeLib and embedding into
| PE it successfully loads and registers.

Thanks, Anastasius. My first question is: are these dlls the same by their exports? Then Wine could just simply fake one dll with another.

The second is: couldn't that be some other bug in Wine which prevents 32autole.dll from registering "stdole32.tlb" in v2 format correctly? Of course, I could take the TLB from Wine tree and investigate this on real Windows myself.

The third question (not so personal) would be:

Couldn't ITypeLib2_Constructor_SLTG() be used (from dlls/oleaut32/typelib.c) to generate v1 format in Wine?

Here is some links I've stuck upon today that raised these questions up for me:

[5] http://www.winehq.org/wwn/238#Creating%20Type%20Libraries
[6] http://<email address hidden>/msg13906.html

[Focht (focht)]

Hello,

--- quote ---
Thanks, Anastasius. My first question is: are these dlls the same by their
exports?
--- quote ---

At the time of Win95 the Operating System one and Office9x shipped one were probably similar in exports/functionality.
Nowadays oleaut32 versions are much more evolved than Office9x shipped one which dates back to 1996.

--- quote ---
 Then Wine could just simply fake one dll with another.
--- quote ---

As long as Office 97 components don't depend on internal features/quirks/behaviour of that old oleaut32.dll, yes.
For tests just symlink oleaut32.dll.so to 32autole.dll.so and change the load order to builtin-then-native. A placeholder in system32 is not needed.

--- quote ---
The second is: couldn't that be some other bug in Wine which prevents
32autole.dll from registering "stdole32.tlb" in v2 format correctly? Of
course, I could take the TLB from Wine tree and investigate this on real
Windows myself.
--- quote ---

If you question my analysis you are free to investigate.

--- quote ---
The third question (not so personal) would be:

Couldn't ITypeLib2_Constructor_SLTG() be used (from dlls/oleaut32/typelib.c) to
generate v1 format in Wine?
--- quote ---

You refer to the typelib loading part.
What you need is v1 typelib writer code like Wine's IDL compiler does for v2 typelibs (write_msft.c).

Regards

[Saulius Krasuckas (saulius2)]

Thank you. Though symlinking dlls isn't a Wine feature and thus it would stay only in a workaround category, AFAIK.

[Jérôme (jerome-bouat)]

Binary package hint: wine1.2

I tried to install a genuine Microsoft Office 97 CD on wine with the Windows 98 flavour of Microsoft Windows.

The install process fails after it copied the files. I have an error windows which tells (translated from french):
"The automatic registration attempt of Accwiz.dll into the system registry database failed".

ProblemType: Bug
Architecture: i386
Date: Mon Nov 9 16:09:25 2009
DistroRelease: Ubuntu 9.10
InstallationMedia: Xubuntu 9.10 "Karmic Koala" - Release i386 (20091028.3)
Package: wine1.2 1.1.31-0ubuntu3
ProcEnviron:
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: wine1.2
Uname: Linux 2.6.31-14-generic i686
XsessionErrors:
 (xfce4-mixer-plugin:1346): libxfce4mixer-CRITICAL **: xfce_mixer_get_track: assertion `GST_IS_MIXER (card)' failed
 (polkit-gnome-authentication-agent-1:1351): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
 (xfce4-terminal:1376): Terminal-WARNING **: Unable to load terminal preferences.

[Focht (focht)]

Hello,

bug still present with wine 1.1.35, Wine's "stdole32.tlb" is still v2 typelib.

Regards

[Dmitry-codeweavers (dmitry-codeweavers)]

Confirming.

[FMartins (fernando-cmartins)]

present in 1.1.40

[Jack Leigh (leighman)]

Could you confirm whether this is still an issue with the latest wine please?

[rusivi2 (rusivi2-deactivatedaccount)]

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

[Jack Leigh (leighman)]

There's a confirmed upstream bug

[ronny (ronny-standtke)]

Just a friendly reminder that this bug is still present in wine 1.3.4. ;-)

[Butraxz (butraxz)]

This has not been updated for two years. Is this still an issue in 1.5.4 or beyond ?

[Focht (focht)]

Hello,

--- quote ---
This has not been updated for two years. Is this still an issue in 1.5.4 or
beyond ?
--- quote ---

sure, still present.
Wine's widl creates "stdole32.tlb" as v2 (MSFT) typelib.

Regards

[Sebastian Lackner (slackner)]

Dmitry is currently working on this, and shared an early version of his highly experimental work-in-progress patchset. Please give it a try and report back if it works. Please note that SLTG support is still unfinished, and there will be a lot more patches and improvements coming soon.

https://github.com/wine-compholio/wine-staging/tree/master/patches/widl-SLTG_Typelib_Support

[Scott Ritchie (scottritchie)]

Closing ancient wine1.2 bugs