http://bugs.winehq.org/show_bug.cgi?id=14334
Summary: WordPerfect Office 2002: Unable to Install Product: Wine Version: 1.0.0 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: pbronline-wine@yahoo.co.uk
Attempt to install WordPerfect Office 2002 from OEM CD.
First reports
"You do not have administrator privileges on this machine." "Setup cannot continue."
Set Windows version to win98 in order to get past this.
Installer (Setup32) then checks to see if any WPO programs are running and offers to close them for you. The only WPO program it finds running is itself ! If you choose No, it exits anyway. If you choose Yes, it commits suicide.
Unable to progress further.
The console log is very short:
$ wine 'f:\intro.exe' fixme:advapi:LookupAccountNameW (null) L"allusers" (nil) 0x33e4a0 (nil) 0x33e4a4 0x33e498 - stub fixme:advapi:LookupAccountNameW (null) L"allusers" 0x12da00 0x33e4a0 0x12d768 0x33e4a4 0x33e498 - stub fixme:msi:ACTION_HandleStandardAction unhandled standard action L"SetODBCFolders" fixme:msi:msi_unimplemented_action_stub BindImage -> 3 ignored L"BindImage" table values fixme:msiexec:main Unknown parameter /D fixme:msiexec:main Unknown function, ignoring Successfully registered dll L"C:\windows\system32\msi.dll"
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #1 from Forester pbronline-wine@yahoo.co.uk 2008-08-21 14:12:51 --- This appears to be a case of regression. See
http://appdb.winehq.org/objectManager.php?sClass=version&iId=5821 http://appdb.winehq.org/objectManager.php?sClass=version&iId=7121
These test results strongly suggest that WordPerfect Office 2002 did install as long ago as Wine 0.9.27.
When did it stop installing ? Using an old Kubuntu 6.06 live CD, the Ubunutu Wine package archive and a binary chop, we come up with:
0.9.27 installs 0.9.59 doesn't 0.9.43 doesn't 0.9.37 doesn't 0.9.33 installs 0.9.35 installs 0.9.36 doesn't
So my guess is that stopped installing with 0.9.36 and hasn't installed since.
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #2 from James Hawkins truiken@gmail.com 2008-08-21 14:15:35 --- Please run a complete regression test between 0.9.35 and 0.9.36:
http://wiki.winehq.org/RegressionTesting
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #3 from Forester pbronline-wine@yahoo.co.uk 2008-08-21 15:13:02 --- The console log for the install under 0.9.36 reads
Log file name:c:\windows\Corel\Setup.log fixme:advapi:GetFileSecurityW (L"c:\windows\profiles\ubuntu\My Documents") : returns fake SECURITY_DESCRIPTOR fixme:advapi:GetFileSecurityW (L"c:\windows\profiles\ubuntu\Start Menu") : returns fake SECURITY_DESCRIPTOR fixme:advapi:GetFileSecurityW (L"c:\windows\profiles\All Users\Start Menu") : returns fake SECURITY_DESCRIPTOR fixme:advapi:GetFileSecurityW (L"c:\windows\profiles\ubuntu\Desktop") : returns fake SECURITY_DESCRIPTOR fixme:advapi:GetFileSecurityW (L"c:\windows") : returns fake SECURITY_DESCRIPTOR fixme:advapi:GetFileSecurityW (L"c:\") : returns fake SECURITY_DESCRIPTOR fixme:advapi:GetFileSecurityW (L"c:\windows\Fonts") : returns fake SECURITY_DESCRIPTOR fixme:advapi:GetFileSecurityW (L"c:\windows\system32") : returns fake SECURITY_DESCRIPTOR fixme:advapi:GetFileSecurityW (L"c:\Program Files") : returns fake SECURITY_DESCRIPTOR
Which ties in with what I've found using the wine debugger on the Wine 1.1.1 code base.
The installer routine that issues the message box signalling its refusal to go any further does some 19 checks after calling advapi::PrivilegeCheck. Nine fail, corresponding to the nine directories lists above. The nine checks are 'short circuited' when emulating Windows 98.
What 'fails' is a call to advapi::GetSecurityDescriptorDacl (yes Dacl, not Sacl). It returns lpbDaclPresent as false. This is not surprising since the security descriptor passed in is only 0x14 bytes big, which is the bare minimum, and so there can't be a dacl present.
Earlier, the installer calls advapi::GetFileSecurityA in order to find out how much memory to allocate for the security descriptor. This routine returns 0x14 so the later fail is a certainty.
advapi::GetFileSecurityA calls ntdll::NtQuerySecurityObject. In Wine 0.9.37 a fixme claims this is a stub. In the Wine 1.1.1 code base, the implementation looks complete, assuming the potential infinite loop is deliberate aping of Windows behaviour.
ntdll::NtQuerySecurityObject calls the Wine server. An fprintf added to handle.c::DECL_HANDLER(get_security_object) confirms that the object that corresponds to the handle for the directory has no security descriptor. That is sd->obj is 0.
I've gone as far with this on my own as I think I can.
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #4 from Forester pbronline-wine@yahoo.co.uk 2008-08-21 15:14:13 --- James, I'll have a look at doing the regression you ask for. Its my first time so it may take a while.
http://bugs.winehq.org/show_bug.cgi?id=14334
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #5 from Forester pbronline-wine@yahoo.co.uk 2008-09-01 00:55:52 --- (In reply to comment #2)
Please run a complete regression test between 0.9.35 and 0.9.36:
$ git bisect good 481de9d82de559426eb8909eac9535cfe1e1712f is first bad commit commit 481de9d82de559426eb8909eac9535cfe1e1712f Author: Dmitry Timoshkov dmitry@codeweavers.com Date: Sat Apr 21 18:12:36 2007 +0900
advapi32: Thunk GetFileSecurityW to NtQuerySecurityObject.
:040000 040000 da93ad78bb0b5c24ee5ca3d66652040044127a14 049f76e4fe177c160dc16608096001e34dbc3778 M dlls
I trust this is what you wanted.
http://bugs.winehq.org/show_bug.cgi?id=14334
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #6 from Dmitry Timoshkov dmitry@codeweavers.com 2008-09-02 04:21:37 --- (In reply to comment #3)
ntdll::NtQuerySecurityObject calls the Wine server. An fprintf added to handle.c::DECL_HANDLER(get_security_object) confirms that the object that corresponds to the handle for the directory has no security descriptor. That is sd->obj is 0.
That's the real reason of the regression. Looks like the code at server/file.c, file_get_sd() should be improved for directories.
I've gone as far with this on my own as I think I can.
Thanks for the great analysis. Taking into account how far you have come with your journey into Wine code perhaps you could have a go with fixing it?
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #7 from Forester pbronline-wine@yahoo.co.uk 2008-09-03 00:56:59 --- (In reply to comment #6)
Thanks for the great analysis. Taking into account how far you have come with your journey into Wine code perhaps you could have a go with fixing it?
Thank you. Yes, I would very much like to have a go at fixing if you are offering to help me produce a fix that will meet Alexandre's high standards. While there is an awful lot information on the Wiki, some of it is obviously out and date which calls into question currency of all of it. I don't know where to start and messing around in the server wasn't exactly what I had in mind for my first Wine fix.
http://bugs.winehq.org/show_bug.cgi?id=14334
Dmitry Timoshkov dmitry@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dmitry@codeweavers.com
--- Comment #8 from Dmitry Timoshkov dmitry@codeweavers.com 2008-09-03 05:01:04 --- (In reply to comment #7)
Thank you. Yes, I would very much like to have a go at fixing if you are offering to help me produce a fix that will meet Alexandre's high standards. While there is an awful lot information on the Wiki, some of it is obviously out and date which calls into question currency of all of it. I don't know where to start and messing around in the server wasn't exactly what I had in mind for my first Wine fix.
Certainly I'll try to help. Working on the wineserver code is not harder than any other places. First thing to investigate would be to find out why server/file.c,file_get_sd() fails for a directory. +file,+server trace should help with that. If you need further help don't hesitate to ask.
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #9 from Forester pbronline-wine@yahoo.co.uk 2008-09-07 17:08:27 --- (In reply to comment #8)
Certainly I'll try to help.
Many thanks
Working on the wineserver code is not harder than any other places.
No, but I guess if I break it a lot more people will notice.
I find that working out what is wrong is the easy part. Working out what is right is harder, knowing when to stop harder sill, testing things properly hardest of all.
First thing to investigate would be to find out why server/file.c,file_get_sd() fails for a directory.
It doesn't. It doesn't get called for a directory. Neither does the default_get_sd() referenced in the directory_ops structure in server/directory.c. The one we are after is in server/change.c. In here we again have an _ops structure that references the default_get_sd() and default_set_sd(). So that the problem - it's never been implemented.
A first pass might be to implement server/change.c,dir_get_sd() and dir_set_sd() by analogy. Actually, server/file.c,sd_to_mode() factors out the common, hard bit on the set side and after factoring out a mode_to_sd() for the get side, the implementation by analogy is quite easy. But is this right ?
A read of the Microsoft web site was its usual illuminating experience. Back in Wine, I note that for files that is no attempt to handle POSIX group membership and until there is, there seems little point in trying to map between inherited ACEs and the POSIX set-gid for directories so I guess the implementation by analogy will do as a first fix.
That is where I'd like to stop but even my modest setup has access to directories and files on server storage controlled by group membership so I guess this is something someone will have to fix before Wine goes mainstream.
I note also that on the set side of things, there is a FIXME suggesting a call to fchown is missing. Should not such calls fail until this is fixed ? I can't see fchown working unless root is running Wine.
On the get side of things, what I find curious is:
ada->Mask |= FILE_GENERIC_WRITE | DELETE;
My recollection of POSIX file systems is that the ability to delete files is determined by the user's write access to the parent directory. Write access to the file itself is irrelevant so the assignment above just wrong to me.
Anyway, what I really wanted to ask is how I go about testing my fix. How do you test the server ? Indirectly by testing the dll API ? That would be advapi32 in this case ? Do I need to be looking a chapter 5 of the Wine Developer's Guide ? Is it ethical to install Windows from an old OEM disk on a new computer even in a virtual machine ?
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #10 from Dmitry Timoshkov dmitry@codeweavers.com 2008-09-10 06:09:17 --- (In reply to comment #9)
Anyway, what I really wanted to ask is how I go about testing my fix. How do you test the server ? Indirectly by testing the dll API ? That would be advapi32 in this case ? Do I need to be looking a chapter 5 of the Wine Developer's Guide ?
Yes, the server code is tested indirectly by calling appropriate Win32 APIs. I'd write a test which calls GetTempPath(), creates a file there, then calls GetFileSecurity() on both - temp directory and a temp file, and examines returned data. Since the temp directory is supposed to be world writable that should emulate the case of this bug.
Is it ethical to install Windows from an old OEM disk on a new computer even in a virtual machine ?
Does the license explicitly forbid that?
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #11 from Forester pbronline-wine@yahoo.co.uk 2008-09-16 13:44:34 --- (In reply to comment #10)
Yes, the server code is tested indirectly by calling appropriate Win32 APIs. I'd write a test which calls GetTempPath(), creates a file there, then calls GetFileSecurity() on both - temp directory and a temp file, and examines returned data. Since the temp directory is supposed to be world writable that should emulate the case of this bug.
I've hit another snag. I built advapi32_crosstest.exe using the cross compiler and have run it in a Windows VM. It says:
CreateWellKnownSid is not available
and skips all the interesting tests.
The VM has a new installation of W2K SP2. Is this telling me I need to install SP4 ?
Is it ethical to install Windows from an old OEM disk on a new computer even in a virtual machine ?
Does the license explicitly forbid that?
No. But how do I affix the COA to a VM ?
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #12 from Dmitry Timoshkov dmitry@codeweavers.com 2008-09-16 21:12:07 --- (In reply to comment #11)
I've hit another snag. I built advapi32_crosstest.exe using the cross compiler and have run it in a Windows VM. It says: CreateWellKnownSid is not available and skips all the interesting tests. The VM has a new installation of W2K SP2. Is this telling me I need to install SP4 ?
According to MSDN CreateWellKnownSid has been introduced in XP, so installing Win2k SP4 won't help. Any way, not all the tests are skipped, but only those depending on CreateWellKnownSid.
Is it ethical to install Windows from an old OEM disk on a new computer even in a virtual machine ?
Does the license explicitly forbid that?
No. But how do I affix the COA to a VM ?
Sorry, I don't know.
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #13 from Forester pbronline-wine@yahoo.co.uk 2008-09-19 13:51:21 --- (In reply to comment #12)
According to MSDN CreateWellKnownSid has been introduced in XP, so installing Win2k SP4 won't help. Any way, not all the tests are skipped, but only those depending on CreateWellKnownSid.
It looks like MS back-ported CreateWellKnownSid() into Win2k SP4 but that's beside the point.
I have added a simple (I mean really dumb) test case that mimics what I think my application does and it passes under Wine and Win2k. So I think I'm ready to submit.
However, I tried calling SetFileSecurity() with the sd returned by GetFileSecurity(). This passes under both Wine and Win2k too. However, my trace in the wine server suggests file_set_sd() bugs out early having hit
/* FIXME: get Unix uid and call fchown */
which just can't be right. I think this arises because I'm using Get & Set FileSecurity. Each call open and closes the file so creating and destroying the file object so, by definition, obj->sd is 0 on entry to file_set_sd(). Ditto for my new dir_set_sd().
Can I still submit the work I've done ?
In the conformance tests, advapi32/tests/security.c, test_GetSecurityInfo() provokes four server calls to file_get_sd(). The (old) tests provoke no server calls to file_set_sd().
The routine test_GetNamedSecurityInfoA() appears to acquire a security descriptor for a directory. This test passes but it does not provoke a server call to my new dir_get_sd() nor a call to the file_get_sd() I began with.
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #14 from Dmitry Timoshkov dmitry@codeweavers.com 2008-09-20 03:38:14 --- By all means please go ahead and send your patches. Break the patches into small self contained parts. I'd send the test first, surrounding the tests failing under Wine with todo_wine, then send small patches and remove todo's when necessary.
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #15 from Forester pbronline-wine@yahoo.co.uk 2008-11-04 02:07:20 --- Patches finally submitted. Feedback welcome. Getting GetFileSecurity() to work for directories did not, on its own, allow the application to install. Figuring out what else has to be done explains most of the delay.
http://bugs.winehq.org/show_bug.cgi?id=14334
Ken Berland ken@hero.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ken@hero.org
--- Comment #16 from Ken Berland ken@hero.org 2008-12-07 14:48:26 --- (In reply to comment #15)
Patches finally submitted. Feedback welcome. Getting GetFileSecurity() to work for directories did not, on its own, allow the application to install. Figuring out what else has to be done explains most of the delay.
Does this patch allow WordPerfect Office 2002 to install?
I'd love to get a copy of the patch. I just downloaded the most recent version from git and this bug still exists.
-KB
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #17 from Forester pbronline-wine@yahoo.co.uk 2008-12-08 11:52:28 --- (In reply to comment #16)
Does this patch allow WordPerfect Office 2002 to install?
I'd love to get a copy of the patch. I just downloaded the most recent version from git and this bug still exists.
-KB
The patches discussed above necessary, but alas, not sufficient.
WPO 2002 will install with a further patch that adds a stub for a routine that isn't documented on MSDN. That patch was not accepted. No surprises there. It probably isn't necessary as the real problem must lie elsewhere.
Patches to LookUpAccountNameW() that may be necessary were accepted up to the point at which they might make a material difference. Lots of applications install and run the way things are so why risk breaking them for one obscure program ?
The root of the problem probably lies in the SID returned by GetFileSecurityW() and how that changed when the stub in Wine 0.9.35 was replaced with a real implementation. However, again, lots of application install and run with things the way they are ....
http://bugs.winehq.org/show_bug.cgi?id=14334
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |dank@kegel.com
--- Comment #18 from Dan Kegel dank@kegel.com 2009-01-31 14:20:46 --- Don't be too pessimistic - let's get some conformance tests in that show the problem, I bet we can fix it without breaking other apps.
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #19 from Forester pbronline-wine@yahoo.co.uk 2009-02-09 01:02:55 --- Created an attachment (id=19345) --> (http://bugs.winehq.org/attachment.cgi?id=19345) Analysis of Problem under Wine 1.1.14
Here's the current state of my understanding of the issue. Suggestions for Conformance Tests or other ways forward would be appreciated.
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #20 from Dan Kegel dank@kegel.com 2009-02-09 09:17:37 --- Is this commit related, advapi32: Support the computer name as an account name in LookupAccountNameW http://www.winehq.org/pipermail/wine-cvs/2009-February/052769.html ?
What's the full set of proposed patches needed (links to wine-patches best)?
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #21 from Forester pbronline-wine@yahoo.co.uk 2009-02-09 16:53:13 --- (In reply to comment #20)
Is this commit related, advapi32: Support the computer name as an account name in LookupAccountNameW http://www.winehq.org/pipermail/wine-cvs/2009-February/052769.html ?
What's the full set of proposed patches needed (links to wine-patches best)?
No, I don't think so. Thanks for drawing it to my attention. I note Juan has used subroutines as a way of refactoring. Noted for next time. If there is a next time.
Here's a reference (I hope) to the patches I submitted ...
http://www.nabble.com/-PATCH-01-12--(resend)-LookupAccountNameW()---add-got-...
That's the first of a series of 12. I don't know how to navigate nabble, so I searched for:
Paul Bryan Roberts resend
and that pulled up all 12. If memory serves, only the first nine were accepted and so only my first two objectives were met. The routine was in serious need of refactoring. The corrections to existing conformance tests were accepted but the refactoring was not. I got no feedback as to why, I'd spent way to much time on the problem and the patches weren't the break-through I'd been hoping for so I let it drop.
Since I've concluded that my later patches fell into the 'obviously not obviously correct' category, obviously and that further progress on this bug would be dependent on coming up with new conformance tests that fail.
Looking back, it seems I did add a couple more conformance tests that Wine doesn't pass without my patches. Ho, hum.
Here's the stub
http://www.nabble.com/advapi%3A-add-stub-for-GetNamedSecurityInfoExA()-to203...
Other patches, notably those that made GetFileSecurity cope with directories, were all accepted.
Does this help ?
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #22 from Dan Kegel dank@kegel.com 2009-02-09 16:56:02 --- Yes, thanks.
It would be great if you could resend the remaining patches to wine-patches (updated, of course). I promise to try to get Alexandre to explain what's wrong if he doesn't apply them.
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #23 from Forester pbronline-wine@yahoo.co.uk 2009-02-11 01:29:04 --- I'll try to get something in at the weekend (based on 1.1.15).
I wondering ... under Wine I can use WINEDEBUG=+relay to find out what WIN API calls the installer makes. What is the native WindowsTM equivalent and does it have a free download ? It would be really nice to know whether the native installation calls GetNamedSecurityInfoExA() under 'normal' circumstances or not.
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #24 from Dan Kegel dank@kegel.com 2009-02-11 08:24:24 --- http://www.internals.com/articles/apispy/apispy.htm has some references. You can download one tool, apispy32, from http://www.wheaty.net I haven't tried it (lately) so I don't know how well it works.
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #25 from Dmitry Timoshkov dmitry@codeweavers.com 2009-02-11 10:46:59 --- Another one is logger.exe provided by Debugging Tools For Windows (Microsoft).
http://bugs.winehq.org/show_bug.cgi?id=14334
Forester pbronline-wine@yahoo.co.uk changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #19345|0 |1 is obsolete| |
--- Comment #26 from Forester pbronline-wine@yahoo.co.uk 2009-02-15 14:32:06 --- Created an attachment (id=19480) --> (http://bugs.winehq.org/attachment.cgi?id=19480) Analysis 14/02/2009 Wine 1.1.15
Attached is another analysis. Hopefully a little more cogent than the last.
Thanks for the suggestions on how to trace API calls under WindowsTM. I got nothing at all out of apisys and logger.exe only traced calls from advapi32, not calls to advapi32. I was, however, able to confirm that WindowsTM calls GetNamedSecurityInfoExA() by running the installer under the MS debugger and using break points.
That (and Juan's changes) renders resubmission of any patches for LookupAccountName() moot until and unless there is an n&s implementation of GetNamedSecurityInfoExA().
I could submit a patch containing a stub implementation of GetNamedSecurityInfoExA() again and maybe we could prevail upon Alexandre to give us his reasons for why this it is not acceptable.
I expect his reasoning would run as follows: your application checks for the existence of this routine and fails because it isn't there. How do we know there are not other applications that make the same check and still install ? Your application installs with this stub even though the stub returns an error. How can we know that this stub will not stop those other applications from installing ?
We can not know without trying. The only way to reduce risk is to try to implement GetNamedSecurityInfoExA() fully even though we have no evidence that this would be a productive use of time and resources. The questions I would ask Alexandre is a) Does he think GetNamedSecurityInfoExA() can be implemented in terms of what already exists or would it involve something essentially new being added to Wine ? b) Does he think GetNamedSecurityInfoExA() can be implemented entirely client side or would it require messing around with server internals ?
And last, but not least, no, I don't know of anyone else who has used this stub to install this application.
Anyway, one patch containing a stub implementation of GetNamedSecurityInfoExA() ready for submission. Just give the word.
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #27 from Dan Kegel dank@kegel.com 2009-02-15 15:23:54 --- I guess the question is whether the stub would fix more apps than it breaks. Hard to tell without trying it out.
http://bugs.winehq.org/show_bug.cgi?id=14334
--- Comment #28 from Austin English austinenglish@gmail.com 2009-08-26 13:15:07 --- Is this still present in current (1.1.28 or newer) wine?
http://bugs.winehq.org/show_bug.cgi?id=14334
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |ABANDONED
--- Comment #29 from Austin English austinenglish@gmail.com 2010-05-19 16:54:38 --- Abandoned. If you still have a problem in current (1.1.44 or newer) wine, and can provide the needed information, feel free to reopen.
http://bugs.winehq.org/show_bug.cgi?id=14334
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #30 from Austin English austinenglish@gmail.com 2010-05-19 16:55:23 --- Closing.
-
wine-bugs＠winehq.org