[antony@antgel.co.uk: .msi files]

[Kelly Leahy]

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 at antgel.co.uk>
To: "Robert Shearman" <R.J.Shearman at warwick.ac.uk>
Cc: <wine-devel at winehq.org>
Sent: Friday, August 01, 2003 8:05 PM
Subject: Re: [antony at 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 at antgel.co.uk>
> > > To: wine-devel at winehq.com
> > > Subject: [antony at 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
>