September 2005 - Wine-Devel

Re: Perform automatic bitmap font configuration. Take 4

by Huw D M Davies

On Tue, Sep 13, 2005 at 04:45:30PM +0900, Dmitry Timoshkov wrote: > > +static const struct nls_update_font_list > +{ > + UINT ansi_cp; > + const char *oem, *fixed, *system; > + const char *courier, *serif, *small, *sserif; > +} nls_update_font_list[] = Hi Dmitry, I think you also need to take into account the OEM codepage here. For example in the UK the OEM font would be vga850.fon while in the US it would be vgaoem.fon. Huw.

Sept. 13, 2005

Re: OpenOffice 2.0 beta 2 installs ok but locks up in File Open dialog with wine-20050830 + 2 patches

by Mike McCormack

Dan Kegel wrote: > installs properly, and the app even appears to come up normally! > However, when you use the File Open dialog box, > it seems to lock up. Here's a session log: It seems to be an ole32 problem. Installing dcom95 makes it work fine for me. Maybe Rob or somebody more knowledgable about ole can help out... > I'm doing a talk on Open Source this Thursday night. Mike's > amazing turnaround time on the two MSI patches will be > a nice story to tell during the talk. > Is there any hope of continuing the run of good luck, > and actually getting Wine to run OOo2.0 by Thursday? > I dare not hope... Well, if you cheat and use dcom95 then you'll have a good demo :) Mike

Sept. 13, 2005

Re: Looking for bugs in Wine's Microsoft Installer (MSI) implementation

by Ivan Gyurdiev

Mike McCormack wrote: > > Hi All, > > If anybody is aware of any cases of Wine's Microsoft Installer code > not working, please log them in Wine's bugzilla > (http://bugs.winehq.org/) assign them to me, and I will attempt to > fix them. > > Make sure to set "msi" = "builtin", "*msiexec" = "builtin" when > testing your installers, and if possible test with the latest Wine CVS. > > If the installer is available as a free download, please include a > link to it. What about Half Life 2. See comment #4 (and below): http://bugs.winehq.org/show_bug.cgi?id=2899 Current status is that it doesn't set the font properly, and no buttons can be read... and also the radio buttons for accepting the EULA aren't activated when the user scrolls to the end.

Sept. 12, 2005

Looking for bugs in Wine's Microsoft Installer (MSI) implementation

by Mike McCormack

Hi All, If anybody is aware of any cases of Wine's Microsoft Installer code not working, please log them in Wine's bugzilla (http://bugs.winehq.org/) assign them to me, and I will attempt to fix them. Make sure to set "msi" = "builtin", "*msiexec" = "builtin" when testing your installers, and if possible test with the latest Wine CVS. If the installer is available as a free download, please include a link to it. thanks, Mike

Sept. 12, 2005

Re: GetIDsOfNames

by Walt Ogburn

On Mon, 12 Sep 2005, Robert Shearman wrote: > Walt Ogburn wrote: > > >... > >2. Call GetTypeInfo to get an ITypeInfo, and call DispGetIDsOfNames on > >that. I think this means that the information should be extracted from > >stdole32.tlb. Currently this doesn't find any match for these property > >names. Do they need to be added to stdole32.tlb somehow? > > > > Yes, the typelib approach is the correct one. You need to use > stdole2.tlb instead of stdole32.tlb though. > Right, thanks. I think that means that OLEFontImpl_GetTypeInfo needs to get IFontDisp from stdole2.tlb instead of IDispatch from stdole32.tlb. That way, you can use GetTypeInfo and DispGetIDsOfNames together to implement GetIDsOfNames. I'll submit some tests and proposed patches soon. - Walter

Sept. 12, 2005

Re: Need help debugging a memory corruption bug in shfldr_unixfs.c

by Phil Krylov

On Fri, 9 Sep 2005 15:09:24 -0400 "Dimi Paun" <dimi(a)lattica.com> wrote: > From: "Phil Krylov" <phil(a)newstar.rinet.ru> > > OK, should we then make a patch which adds an IsWindow() check after every > > notification in every control? This one fixes a really annoying bug, while > > the other places are not proved to crash. > > Well, if it's a entire class of bugs, we should fix them all. I think that we should check if it's a class of bugs or a single bug first. > I guess we need a bit of experimentation on windows to see > if we need to protect all notifications or only a few ones. > I guess we can protect all of them, in which case we have > to look to see how we can do it centrally, in the notification > function itself. I don't see a way to do it clean enough. So, here's a new version of the patch (enhanced comment, WARN changed to a TRACE). ChangeLog: Protect against wrong memory access if a listview is destroyed during processing of its NM_DBLCLK notification (a.k.a. file dialog GPF). -- Ph.

Sept. 12, 2005

winspool: EnumPrinterDrivers (resend)

by Detlef Riekenberg

Am Samstag, den 10.09.2005, 15:27 +0100 schrieb Huw D M Davies: > > This Patch is not in CVS yet: > > > > http://www.winehq.org/pipermail/wine-patches/2005-August/019671.html > > > > > Changelog: > > > Let EnumPrinterDrivers return the number of drivers. > > > > Looks good to me. I suggest you resend the patch. > > Huw. > Here is the resend -- By By ... ... Detlef

Sept. 12, 2005

Re: wine/dlls wininet/wininet.spec uxtheme/uxtheme ...

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > Before a 64bit integer was declared as 'long long'. This means both of > these prototypes would be considered to match reset_int64(long long): > > WINAPI void reset_int64(INT v1, INT v2); > WINAPI void reset_int64(LONGLONG v); > > And indeed there were some errors. Now it means winapi_check will think > the following is a correct prototype: > > WINAPI void reset_int64(DOUBLE v); Both LONGLONG and DOUBLE are rare enough in the API that checking for them is not that useful. There are a million other possible mismatches that are much more likely and that winapi_check doesn't check for. > Might be unlikely but since the previous type of error actually happened > I think it is still in the realm of the possible. That's why a longlong > type would be nice. Then we'd have the following types: > > * word any 16 bit integer (for 16 bit APIs) > * long any 32 bit integer (or less in 32bit APIs because of padding) > * longlong any 64 bit integer (signed, unsigned, etc) > * double floating point value > * segptr segmented pointers (for 16 bit APIs) > * ptr 32bit pointer > * str 32bit pointer to an Ansi string > * wstr 32bit pointer to a Unicode string > > Actually I guess this little review raises some questions: > * Do we need an integer type which is 32bit on a 32bit platform and > 64bit on a 64bit platform? > * Do we need to worry about 64bit pointers? I guess ptr, str and wstr > will automatically be interpreted as 64bit pointers on a 64bit platform? > * Can we have 32bit floating point values, i.e. floats? Are these > declared as 'long'? Actually things are not as clean as that. For instance handles are declared long even though they are actually pointers. It really doesn't matter because the only thing that is using the info is the relay debugging code that only works on x86 anyway. On other platforms all we care about is the number of arguments. If we wanted portable relay debugging then we would need a lot more info anyway, and extracting it directly from the source would be a much better approach. -- Alexandre Julliard julliard(a)winehq.org

Sept. 12, 2005

Re: wine/dlls wininet/wininet.spec uxtheme/uxtheme ...

by Francois Gouget

On Mon, 12 Sep 2005, Alexandre Julliard wrote: > Francois Gouget <fgouget(a)free.fr> writes: > >> That's from memory so it should be checked, but I believe winapi_check >> had a hack to check consistency between the spec file and the function >> prototypes in the C files. This patch likely breaks that hack, but more >> importantly winapi_check is going to think that the argument should be a >> double now :-( >> >> A longlong would be nice. > > winapi_check can be taught that a long long is specified as 'double' > too. It doesn't really make sense to add a new type for the sole > purpose of checking that the new type is used properly... Before a 64bit integer was declared as 'long long'. This means both of these prototypes would be considered to match reset_int64(long long): WINAPI void reset_int64(INT v1, INT v2); WINAPI void reset_int64(LONGLONG v); And indeed there were some errors. Now it means winapi_check will think the following is a correct prototype: WINAPI void reset_int64(DOUBLE v); Might be unlikely but since the previous type of error actually happened I think it is still in the realm of the possible. That's why a longlong type would be nice. Then we'd have the following types: * word any 16 bit integer (for 16 bit APIs) * long any 32 bit integer (or less in 32bit APIs because of padding) * longlong any 64 bit integer (signed, unsigned, etc) * double floating point value * segptr segmented pointers (for 16 bit APIs) * ptr 32bit pointer * str 32bit pointer to an Ansi string * wstr 32bit pointer to a Unicode string Actually I guess this little review raises some questions: * Do we need an integer type which is 32bit on a 32bit platform and 64bit on a 64bit platform? * Do we need to worry about 64bit pointers? I guess ptr, str and wstr will automatically be interpreted as 64bit pointers on a 64bit platform? * Can we have 32bit floating point values, i.e. floats? Are these declared as 'long'? -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ $live{free} || die "";

Sept. 12, 2005

Re: Office97 Install issue

by Detlef Riekenberg

Am Montag, den 12.09.2005, 02:38 -0400 schrieb Steven Edwards: > > See Also: > > > > wineprefixcreate is fixed to "c:\windows" and english Names: > > http://bugs.winehq.org/show_bug.cgi?id=2844 > > If you still have your modified wineprefixcreate can you attach it to > the bug? Attachment created with comments in Bug #2844: http://bugs.winehq.org/attachment.cgi?id=1025&action=view Feel free to ask about Details. -- By By ... ... Detlef

Sept. 12, 2005

Re: wine/dlls wininet/wininet.spec uxtheme/uxtheme ...

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > That's from memory so it should be checked, but I believe winapi_check > had a hack to check consistency between the spec file and the function > prototypes in the C files. This patch likely breaks that hack, but more > importantly winapi_check is going to think that the argument should be a > double now :-( > > A longlong would be nice. winapi_check can be taught that a long long is specified as 'double' too. It doesn't really make sense to add a new type for the sole purpose of checking that the new type is used properly... -- Alexandre Julliard julliard(a)winehq.org

Sept. 12, 2005

Re: wine/dlls wininet/wininet.spec uxtheme/uxtheme ...

by Francois Gouget

On Mon, 12 Sep 2005, Alexandre Julliard wrote: > Robert Shearman <rob(a)codeweavers.com> writes: > >> Wouldn't it be better to extend the spec format to allow for a longlong >> type instead? I was wondering about that too. > I considered doing that, but I decided it would just add complexity > for no real reason. If we really need more detailed parameter info > then we need to retrieve that directly from the source code IMO. That's from memory so it should be checked, but I believe winapi_check had a hack to check consistency between the spec file and the function prototypes in the C files. This patch likely breaks that hack, but more importantly winapi_check is going to think that the argument should be a double now :-( A longlong would be nice. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ You can have my guns when you pry them from my kids cold, dead hands.

Sept. 12, 2005

Re: wine/dlls wininet/wininet.spec uxtheme/uxtheme ...

by Alexandre Julliard

Robert Shearman <rob(a)codeweavers.com> writes: > Wouldn't it be better to extend the spec format to allow for a longlong > type instead? I considered doing that, but I decided it would just add complexity for no real reason. If we really need more detailed parameter info then we need to retrieve that directly from the source code IMO. -- Alexandre Julliard julliard(a)winehq.org

Sept. 12, 2005

Re: GetIDsOfNames

by Robert Shearman

Walt Ogburn wrote: >Hi guys, > >Eric Tanguy asked on wine-users a while back about getting some geography >games (http://olivier.leflon.free.fr/jeux/jeux.htm) to run. These seem to >be Visual Basic, so oleaut32 issues come up. We succeeded with the first >one (departments of France - font size problem fixed). Next, there is the >issue that some of them call GetIDsOfNames on ole font objects (countries >of Europe, http://olivier.leflon.free.fr/jeux/europe.htm) >OLEFontImpl_GetIDsOfNames is currently a stub. What's needed is basically >just to convert the strings "Name", "Size", "Bold", etc. into >DISPID_FONT_NAME, etc. In particular, this game only needs "Size." > >It's not hard to code that, and make the game work. I'm not sure, though, >what the proper approach would be for an acceptable patch: > >... >2. Call GetTypeInfo to get an ITypeInfo, and call DispGetIDsOfNames on >that. I think this means that the information should be extracted from >stdole32.tlb. Currently this doesn't find any match for these property >names. Do they need to be added to stdole32.tlb somehow? > Yes, the typelib approach is the correct one. You need to use stdole2.tlb instead of stdole32.tlb though. -- Rob Shearman

Sept. 12, 2005

Re: wine/dlls wininet/wininet.spec uxtheme/uxtheme ...

by Robert Shearman

Alexandre Julliard wrote: >Log message: > Specify 64-bit integers as double instead of long long in spec files > so that we get the correct number of arguments. > Wouldn't it be better to extend the spec format to allow for a longlong type instead? -- Rob Shearman

Sept. 12, 2005

OpenOffice 2.0 beta 2 installs ok but locks up in File Open dialog with wine-20050830 + 2 patches

by Dan Kegel

With wine-20050830 and Mike's two MSI patches (thanks, Mike!), http://openoffice.mirrors.pair.com/ftp/stable/2.0beta2/OOo_2.0beta2_Win32In… installs properly, and the app even appears to come up normally! However, when you use the File Open dialog box, it seems to lock up. Here's a session log: [dank(a)localhost program]$ wine soffice.exe fixme:advapi:LookupAccountSidW ((null),sid=0x7ad47428,0x7b949ac4,0x7b949bcc(256),0x7b9497c0,0x7b949bc8(256),0x7b949bc4): semi-stub fixme:font:GetKerningPairsW (0x6dc4,0,(nil)): almost empty stub! fixme:font:GetKerningPairsW (0x6dc4,0,(nil)): almost empty stub! fixme:font:GetKerningPairsW (0x6dc4,0,(nil)): almost empty stub! fixme:font:GetKerningPairsW (0x733c,0,(nil)): almost empty stub! fixme:imm:ImmGetContext (0x10030): stub fixme:imm:ImmReleaseContext (0x10030, 0x7bca5658): stub err:ole:CoInitializeEx Attempt to change threading model of this apartment from 0x2 to 0x0 err:ole:CoInitializeEx Attempt to change threading model of this apartment from 0x2 to 0x0 err:ole:CoInitializeEx Attempt to change threading model of this apartment from 0x0 to 0x2 fixme:commdlg:GetFileName95 Flags 0x02800000 not yet implemented That CoInitializeEx error sounds bad. The error is probably very easy to reproduce, perhaps a wine developer should try it out him/herself. Now to go rescue my wife so she can get some sleep. Having a two-year-old son seriously cuts down the amount of time I have for hacking. I'm doing a talk on Open Source this Thursday night. Mike's amazing turnaround time on the two MSI patches will be a nice story to tell during the talk. Is there any hope of continuing the run of good luck, and actually getting Wine to run OOo2.0 by Thursday? I dare not hope... - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

Sept. 12, 2005

Re: OOo2.0beta2 installer crashes wine-20050830 in MultiByteToWideChar in msi_process_pending_messages

by Dan Kegel

Mike McCormack wrote: >> Here's a log of wine-20050830 crashing while running the >> setup.exe in the directory created by unpacking >> http://openoffice.mirrors.pair.com/ftp/stable/2.0beta2/OOo_2.0beta2_Win32In… > > > The attached patch (hack) should fix the problem. > We load a dll in a thread (in an MSI custom action), and that dll does a > SendMessageTimeout(HWND_BROADCAST, WM_WININICHANGE, .., &ptr, ...), then > exits, and our thread unloads the dll. > > user32.SendMessageTimeoutA(0000ffff,0000001a,0000002a,62840730,00000002,00000000,00000000) > ret=6282b827 > > By the time our GUI receives the broadcast message, the pointer in the > message is invalid, and the message marshalling code accesses it and > crashes. > > So we need to figure out whether we need to delay unloading of the dll > until we have a chance to process all the messages or whether the > message marshalling code needs to be fixed. That let it complete the install! Thanks, Mike! Now the app comes up ok, but is unusable. I'll post about that problem separately. -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

Sept. 12, 2005

Re: Empire Earth continued

by Stefan Dösinger

> Best would be to write a 'DDraw' test (integrated in the test suite) to be > able to check reference counting in some 'standard' cases (surface > creation, D3D object creation, ...). I am afraid this will have to wait a few days, as I don't have access to any Windows machine the next days. > Well, as we call a DDraw 'method' to create the surface, you should add the > AddRef call there. For the release, it should be in the 'final_release' > call for the surface (AFAIK, each surface already stores a pointer to its > parent DDraw object). How about this one? It increases the refcount in Main_DirectDraw_AddSurface and decreases it in Main_DirectDraw_RemoveSurface, the places where the surface is attached / removed from the DirectDraw7's surface list.

Sept. 12, 2005

Re: [Now ns7] Dragon ns8 problem

by Jean Magnan de Bornier

Le 10 septembre à 20:20:50 Jean Magnan de Bornier <jean(a)bornier.net> écrit notamment: | Le 09 septembre à 23:32:23 peter(a)piments.com écrit notamment: > | | On Fri, 09 Sep 2005 16:27:47 +0200, Jean Magnan de Bornier | | <jean(a)bornier.net> wrote: | > | | > Now it won't start, but I'm being confident: this thing accepts one more | | > thing every day, not more; so maybe tomorrow, after a reboot (probably | | > unneeded, but there seems to be a real addiction about reboot for these | | > strange animals!), it will run ok, if not I might post the logs... | | > | | > thanks, | > | | A reboot is hardly ever needed on Linux is you know what to kill/restart. | | If you dont , it can often be the quickest solution on a desktop system. | > | | I've got my WINE/NS closing down pretty cleanly from the menu now. I let | | it spew out a few messages to the console and then I have to cntl_c it. A | | couple of seconds later there is no debris on "ps ax" . Re-running wine | | natspeak afterwards is as good as new. | > | | I think that is pretty impressive , hats of to all who have contributed to | | this effort over the years. > | [...] > | Well, here, dns still refuses to start; OK, I added rpcrt4.dll in c/windows/system, and now dns starts all right, although slowly and with strange messages, and WORKS! I have not figured out I could save the output that is written on the "dragon editor"; if I try to save in a file dns crashes, if I try to save to clipboard (C-c) and then open it in e.g. emacs, I have nothing. Any ideas? Thanks, -- Jean Magnan de Bornier | Cours Victor Hugo e-mots: jean at bornier.net | 13980 Alleins France T 08 70 39 34 03 | P 06 09 17 35 87

Sept. 12, 2005

GetOutlineTextMetrics on terminal without X

by FirmOS

Hi, we have a pdf generator running with wine, started on an X Server the results are as we expected. Running on a terminal without X, the fonts are rendered useless and acrobat complains about the file. I found out, that GetOutlineTextMetrics delivers very different results with our test programm: On an X Term: Font Arial, 20, PixperInch 96 Font:Arial OTM SIZE:246 OTM HEIGHT:1117 OTM ASCEND:905 OTM DESCEND:212 OTM INTLEAD:117 OTM EXTLEAD:33 OTM ACWIDTH:441 OTM MAXCW:2693 OTM WEIGHT:400 OTM OHANG:0 OTM DIGASPX:300 OTM DIGASPY:300 OTM ITALIC:0 OTM UL:0 OTM STRUCKO:0 OTM PFAMILY:39 OTM CSET:0 FILLER:0 FS SEL:64 FS TYPE:0 CSLOPERISE:1 CSLOPERUN:0 IT ANGLE:0 EMSQUARE:2048 ASCEND:728 DESENT:-210 LINEGAP:150 CAP EM HEIGHT:0 XHEIGHT:0 FONTBOX L:-665 FONTBOX T:1037 FONTBOX R:2028 FONTBOX B:-325 On a terminal without X: Font:Arial OTM SIZE:212 OTM HEIGHT:1 OTM ASCEND:0 OTM DESCEND:0 OTM INTLEAD:0 OTM EXTLEAD:0 OTM ACWIDTH:1 OTM MAXCW:1 OTM WEIGHT:500 OTM OHANG:0 OTM DIGASPX:1 OTM DIGASPY:1 OTM ITALIC:0 OTM UL:0 OTM STRUCKO:0 OTM PFAMILY:9 OTM CSET:0 FILLER:0 FS SEL:0 FS TYPE:0 CSLOPERISE:0 CSLOPERUN:0 IT ANGLE:0 EMSQUARE:0 ASCEND:0 DESENT:0 LINEGAP:0 CAP EM HEIGHT:0 XHEIGHT:0 FONTBOX L:0 FONTBOX T:0 FONTBOX R:0 FONTBOX B:0 Values are useless running without X. Is there any solution to this problem ? Setting fonts, etc ? You can get the test application from me. Thanks a lot, Franz Schober franz.schober(a)firmos.at

Sept. 12, 2005

Re: OOo2.0beta2 installer crashes wine-20050830 in MultiByteToWideChar in msi_process_pending_messages

by Mike McCormack

Dan Kegel wrote: > Here's a log of wine-20050830 crashing while running the > setup.exe in the directory created by unpacking > http://openoffice.mirrors.pair.com/ftp/stable/2.0beta2/OOo_2.0beta2_Win32In… The attached patch (hack) should fix the problem. We load a dll in a thread (in an MSI custom action), and that dll does a SendMessageTimeout(HWND_BROADCAST, WM_WININICHANGE, .., &ptr, ...), then exits, and our thread unloads the dll. user32.SendMessageTimeoutA(0000ffff,0000001a,0000002a,62840730,00000002,00000000,00000000) ret=6282b827 By the time our GUI receives the broadcast message, the pointer in the message is invalid, and the message marshalling code accesses it and crashes. So we need to figure out whether we need to delay unloading of the dll until we have a chance to process all the messages or whether the message marshalling code needs to be fixed. Mike > wine: Unhandled exception (thread 000b), starting debugger... > WineDbg starting on pid 0xa > Unhandled exception: page fault on read access to 0x62840730 in 32-bit > code (0x7bbb0953). <snip> > =>1 0x7bbb0953 MultiByteToWideChar+0x16f(page=0x0, flags=0x0, > src=0x62840730, srclen=0xffffffff, dst=0x0, dstlen=0x0) > [/home/dank/wine-20050830/dlls/kernel/locale.c:1527] in kernel32 > (0x7b92f304) > 2 0x7b58b3a8 WINPROC_MapMsg32ATo32W+0x270(hwnd=0x30024, msg=0x1a, > pwparam=0x7b92f388, plparam=0x7b92f38c) > [/home/dank/wine-20050830/dlls/user/winproc.c:668] in user32 (0x7b92f36c) > 3 0x7b58f4e4 CallWindowProcA+0xa0(func=0x7b5e9226, hwnd=0x30024, > msg=0x1a, wParam=0x2a, lParam=0x62840730) > [/home/dank/wine-20050830/dlls/user/winproc.c:2952] in user32 (0x7b92f39c) > 4 0x7b564d5c call_window_proc+0xd0(wparam=0x2a, lparam=0x62840730, > unicode=0x0, same_thread=0x0) > [/home/dank/wine-20050830/dlls/user/message.c:1520] in user32 (0x7b92f3fc) > 5 0x7b56539b peek_message+0x26f(first=0x0, last=0xffffffff, flags=0x1) > [/home/dank/wine-20050830/dlls/user/message.c:2053] in user32 (0x7b92f794) > 6 0x7b5693de PeekMessageW(msg_out=0x7b92f7fc, hwnd=0x0, first=0x0, > last=0x0, flags=0x1) [/home/dank/wine-20050830/dlls/user/message.c:2694] > in user32 (0x7b92f7e0) > 7 0x7b7f9812 msi_process_pending_messages+0x2a > [/home/dank/wine-20050830/dlls/msi/dialog.c:1807] in msi (0x7b92f828)

Sept. 12, 2005

Re: Office97 Install issue

by Steven Edwards

Hi, On Sun, 2005-09-11 at 13:18 +0200, Detlef Riekenberg wrote: > When I started with wine (in march), I changes wineprefixcreate to > support additional options, but there where to much things fixed to > "c:\windows" (including the Settings above). > > > See Also: > > wineprefixcreate is fixed to "c:\windows" and english Names: > http://bugs.winehq.org/show_bug.cgi?id=2844 If you still have your modified wineprefixcreate can you attach it to the bug? I will try to make some more time to play around with this in the coming week and keep my results posted there. Thanks Steven

Sept. 12, 2005

Re: hhctrl: Load the default Url in the HTML Pane [take 2]

by James Hawkins

On 9/9/05, James Hawkins <truiken(a)gmail.com> wrote: > Hi, > > Cleaned some smudges spotted by Jacek. > > Changelog > * Add the WebBrowser implementation. > * Load the default Url in the HTML Pane. > Is there anything wrong with this patch? -- James Hawkins

Sept. 12, 2005

OOo2.0beta2 installer crashes wine-20050830 in MultiByteToWideChar in msi_process_pending_messages

by Dan Kegel

Here's a log of wine-20050830 crashing while running the setup.exe in the directory created by unpacking http://openoffice.mirrors.pair.com/ftp/stable/2.0beta2/OOo_2.0beta2_Win32In… (This is on FC3, with wine-20050830 compiled from source tarball, with Mike's patch to fix the ACTION_VerifyComponentForAction crash.) ... fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"StartServices" fixme:msi:ACTION_RegisterProduct Flesh out more information fixme:msi:ACTION_RegisterProduct Write real Estimated Size when we have it fixme:msi:ACTION_HandleStandardAction UNHANDLED Standard Action L"MsiPublishAssemblies" fixme:msi:ACTION_PublishProduct Need to write more keys to the user registry wine: Unhandled exception (thread 000b), starting debugger... WineDbg starting on pid 0xa Unhandled exception: page fault on read access to 0x62840730 in 32-bit code (0x7bbb0953). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:7bbb0953 ESP:7b92f2f8 EBP:7b92f304 EFLAGS:00010246( - 00 -RIZP1) EAX:00000000 EBX:7bbf75dc ECX:ffffffff EDX:00000000 ESI:ffffffff EDI:62840730 Stack dump: 0x7b92f2f8: 7b5b32a8 7b92f388 62840730 7b92f36c 0x7b92f308: 7b58b3a8 00000000 00000000 62840730 0x7b92f318: ffffffff 00000000 00000000 7bed88d6 0x7b92f328: 00000005 7bef1e18 7b92f6e8 7b92f37c 0x7b92f338: 7b92f408 7bed8a13 00000002 7b92f37c 0x7b92f348: 00000000 002d0043 7b58a73f 7b5b32a8 Backtrace: =>1 0x7bbb0953 MultiByteToWideChar+0x16f(page=0x0, flags=0x0, src=0x62840730, srclen=0xffffffff, dst=0x0, dstlen=0x0) [/home/dank/wine-20050830/dlls/kernel/locale.c:1527] in kernel32 (0x7b92f304) 2 0x7b58b3a8 WINPROC_MapMsg32ATo32W+0x270(hwnd=0x30024, msg=0x1a, pwparam=0x7b92f388, plparam=0x7b92f38c) [/home/dank/wine-20050830/dlls/user/winproc.c:668] in user32 (0x7b92f36c) 3 0x7b58f4e4 CallWindowProcA+0xa0(func=0x7b5e9226, hwnd=0x30024, msg=0x1a, wParam=0x2a, lParam=0x62840730) [/home/dank/wine-20050830/dlls/user/winproc.c:2952] in user32 (0x7b92f39c) 4 0x7b564d5c call_window_proc+0xd0(wparam=0x2a, lparam=0x62840730, unicode=0x0, same_thread=0x0) [/home/dank/wine-20050830/dlls/user/message.c:1520] in user32 (0x7b92f3fc) 5 0x7b56539b peek_message+0x26f(first=0x0, last=0xffffffff, flags=0x1) [/home/dank/wine-20050830/dlls/user/message.c:2053] in user32 (0x7b92f794) 6 0x7b5693de PeekMessageW(msg_out=0x7b92f7fc, hwnd=0x0, first=0x0, last=0x0, flags=0x1) [/home/dank/wine-20050830/dlls/user/message.c:2694] in user32 (0x7b92f7e0) 7 0x7b7f9812 msi_process_pending_messages+0x2a [/home/dank/wine-20050830/dlls/msi/dialog.c:1807] in msi (0x7b92f828) 8 0x7b7f990b msi_dialog_check_messages+0x4b(handle=0x0) [/home/dank/wine-20050830/dlls/msi/dialog.c:1835] in msi (0x7b92f838) 9 0x7b7e79fd ITERATE_Actions(row=0x7a77c6c0, param=0x7b92f898) [/home/dank/wine-20050830/dlls/msi/action.c:683] in msi (0x7b92f850) 10 0x7b806998 MSI_IterateRecords(view=0x7a77c730, count=0x0, func=0x7b7e7998, param=0x7b92f898) [/home/dank/wine-20050830/dlls/msi/msiquery.c:220] in msi (0x7b92f878) 11 0x7b7e7486 ACTION_ProcessExecSequence+0xc6 [/home/dank/wine-20050830/dlls/msi/action.c:744] in msi (0x7b92f8ac) 12 0x7b7ede17 ACTION_ExecuteAction(package=0x7bcc44a8) [/home/dank/wine-20050830/dlls/msi/action.c:3783] in msi (0x7b92f8dc) 13 0x7b7e772d ACTION_HandleStandardAction(rc=0x7b92f920, force=0x1) [/home/dank/wine-20050830/dlls/msi/action.c:817] in msi (0x7b92f90c) 14 0x7b7e78e5 ACTION_PerformUIAction+0x3d(package=0x7bcc44a8, action=0x7bd26018) [/home/dank/wine-20050830/dlls/msi/action.c:887] in msi (0x7b92f930) 15 0x7b7e79f2 ITERATE_Actions(row=0x7bd23690, param=0x7b92f9bc) [/home/dank/wine-20050830/dlls/msi/action.c:677] in msi (0x7b92f94c) 16 0x7b806998 MSI_IterateRecords+0x70(view=0x7bd22d68, count=0x0, func=0x7b7e7998, param=0x7b92f9bc) [/home/dank/wine-20050830/dlls/msi/msiquery.c:220] in msi (0x7b92f974) 17 0x7b7e8035 ACTION_DoTopLevelINSTALL+0x41d(package=0x7bcc44a8, szPackagePath=0x7bcc3c3e, szCommandLine=0x0, msiFilePath=0x7b92fa1c) [/home/dank/wine-20050830/dlls/msi/action.c:773] in msi (0x7b92f9f4) 18 0x7b8043b0 MsiInstallProductW+0x138(szPackagePath=0x7bcc3c3e, szCommandLine=0x0) [/home/dank/wine-20050830/dlls/msi/msi.c:233] in msi (0x7b92fe48) 19 0x7b94cbc4 main(argc=0x3, argv=0x7bc604f8) [/home/dank/wine-20050830/programs/msiexec/msiexec.c:298] in msiexec (0x7b92ff10) 20 0x7b94d785 __wine_spec_exe_entry(peb=0x7beff8c0) [/home/dank/wine-20050830/dlls/winecrt0/exe_entry.c:34] in msiexec (0x7b92ff2c) 21 0x7bbbf827 start_process+0xc3(arg=0x0) [/home/dank/wine-20050830/dlls/kernel/process.c:995] in kernel32 (0x7b92fff4) 22 0xf6fde6a1 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) 0x7bbb0953 MultiByteToWideChar+0x16f [/home/dank/wine-20050830/dlls/kernel/locale.c:1527] in kernel32: repne scasb %es:(%edi) 1527 if (srclen < 0) srclen = strlen(src) + 1; -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

Sept. 11, 2005

Re: OOo2.0beta2 installer crashes wine-20050830 in ACTION_VerifyComponentForAction

by Dan Kegel

Mike McCormack wrote: >> Here's a log of wine-20050830 crashing while running the >> setup.exe in the directory created by unpacking >> OOo_2.0beta2_Win32Intel_install.zip. >> (This is on FC3, with wine-20050830 compiled from source tarball.) > ... > > Could you please try the attached patch, and see if it fixes things for > you? Hey, that got farther, I think. Thanks! I'll post about the new problem in a separate message. - Dan -- Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html

Sept. 11, 2005