maybe you have an NT version of MSI installed?
It seems to be trying to access the NT security APIs. Maybe the problem is that it may be testing for existence of these APIs by trying to call GetProcAddress on them. Wine's native DLLs are likely going to be a problem for any app that tends to do this for testing for the existence of an API. I've seen a lot of apps do this in the past, though I never really thought about it as a problem until I started looking at wine. Of course, this process of "looking up" a function to see if it exists works fine in windows, since MS doesn't provide (stub) the function in versions of DLLs that don't have it.
Kelly
----- Original Message ----- From: "Antony Gelberg" antony@antgel.co.uk To: "Robert Shearman" R.J.Shearman@warwick.ac.uk Cc: wine-devel@winehq.org Sent: Friday, August 01, 2003 8:05 PM Subject: Re: [antony@antgel.co.uk: .msi files]
On Fri, Aug 01, 2003 at 10:52:03PM +0100, Robert Shearman wrote:
Date: Fri, 1 Aug 2003 16:03:01 +0100 From: Antony Gelberg antony@antgel.co.uk To: wine-devel@winehq.com Subject: [antony@antgel.co.uk: .msi files]
Does Windows Installer work?
Yes, I have installed MSN Messenger using it.
I've tried installing bout the 98 and 2K versions under wine, but only get:
cdrom $ /usr/local/bin/wine ./instmsiw.exe fixme:win32:PE_CreateModule Security directory ignored fixme:process:CreateProcessA (X:\IXP000.TMP\msiinst.exe,...): NORMAL_PRIORITY_CLASS ignored
This is your problem. Only the Win9x version of MSI works at the moment
and
only if your version is set to Win9x in your config file. I submitted a
few
patches a while ago to get the WinNT version a bit further but it needs
a
load of security functions which aren't implemented (properly) yet.
There
was talk a while ago about reimplementing MSI in Wine, but we rejected
the
idea on the grounds that it was undocumented, very complicated and not needed yet.
On another note, I'm really surprised that the wine-users list is so quiet as it's such an important bit of software.
I apologise for this. We do have a few developers that regularly post
there
(including me on occasions), it just seems you caught us at a busy
moment.
Rob
Thanks Rob. It installed straight away. I've changed "Windows" = "win98" in my config now. I suppose it doesn't matter that much as long as I can run apps - I had it set to winxp from a stability point of view, which seems a little stupid, the more I think about it.
However, my app (Championship Manager 4) still won't install.
src $ wine /cdrom/setup.exe fixme:ntdll:NtOpenThreadToken (0xfffffffe,0x00000004,0x00000001,0x406907f4): stub fixme:advapi:SetThreadToken ((nil), (nil)): stub (NT impl. only) fixme:ntdll:NtOpenProcessToken (0xffffffff,0x00000008,0x406907f0): stub fixme:ntdll:NtQueryInformationToken (0xcafe,1,0x4069062c,80,0x4069067c): stub fixme:advapi:SetThreadToken ((nil), 0xcafe): stub (NT impl. only) wine: Unhandled exception (thread 0009), starting debugger... err:seh:start_debugger Couldn't start debugger ("debugger/winedbg 8 68") (2) Read the Wine Developers Guide on how to set up winedbg or another debugger src $
I then ran it with winedbg, producing this: Stopped on breakpoint 1 at 0x00415d7f (setup.exe.EntryPoint in setup.exe) Wine-dbg>cont No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\MSI.DLL' (0x410d0000) fixme:ntdll:NtOpenThreadToken (0xfffffffe,0x00000004,0x00000001,0x406907f4): stub fixme:advapi:SetThreadToken ((nil), (nil)): stub (NT impl. only) fixme:ntdll:NtOpenProcessToken (0xffffffff,0x00000008,0x406907f0): stub fixme:ntdll:NtQueryInformationToken (0xcafe,1,0x4069062c,80,0x4069067c): stub fixme:advapi:SetThreadToken ((nil), 0xcafe): stub (NT impl. only) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\CABINET.DLL' (0x410e0000) Loaded debug information from ELF '/usr/local/lib/wine/cabinet.dll.so' (0x410d0000) First chance exception: page fault on read access to 0xfffffff5 in 32-bit code (0x004036e1). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:008f GS:0000 EIP:004036e1 ESP:4068ec1c EBP:00000001 EFLAGS:00010246( R- 00 I Z- -P1 ) EAX:00000000 EBX:40ec5040 ECX:4068e8bc EDX:400d5d84 ESI:00000001 EDI:00000000 Stack dump: 0x4068ec1c (NTDLL.DLL.sqrt+0x36986c): 00000000 0040365e 00403683 40690bc8 0x4068ec2c (NTDLL.DLL.sqrt+0x36987c): 0041ec48 ffffffff 40690bd4 00407d0c 0x4068ec3c (NTDLL.DLL.sqrt+0x36988c): 4068fd60 000003e8 40ec5040 00000001 0x4068ec4c (NTDLL.DLL.sqrt+0x36989c): 00690000 00700000 00000000 00000000 0x4068ec5c (NTDLL.DLL.sqrt+0x3698ac): 00000000 00000000 00000000 00000000 0x4068ec6c (NTDLL.DLL.sqrt+0x3698bc): 00000000 00000000 00000000 00000000 0x4068ec7c (NTDLL.DLL.sqrt+0x3698cc):
0011: sel=008f base=400e9940 limit=00000fff 32-bit rw- Backtrace: =>0 0x004036e1 (setup.exe..text+0x26e1 in setup.exe) (ebp=00000001)
0x004036e1 (setup.exe..text+0x26e1 in setup.exe): movl 0xfffffff4(%ebp),%ecx Wine-dbg>
I have since run it (within script) with -debugmsg +relay, but the output file was 3 megs, and I don't even know exactly what I'm looking for. Doesn't help that the stack trace gets interspersed with the function calls.
Having said that, there are lots of calls like: 0009:Call kernel32.GetStdHandle(fffffff5) ret=4049f965 in the log.
I have no idea about Windows programming (but I learn fast!). I'd understand if it fell over because 0xfffffff5 was protected, but as it's been doing that all the way through, I'm a little confused. Also, I don't know why it's using NTDLL.DLL when I am running as win98?
I know I'm kind of in at the deep end, but I'd really like to get this to run, so if anyone can give me some pointers that would be great (no pun intended!).
Antony