September 2005 - Wine-Devel

fixme:win:LockWindowUpdate

by Esko Woudenberg

There are several parts of a C++ Builder app I am working on that try to call the LockWindowUpdate() WIN32 api call it appears to result in a wine crash with the following error: fixme:win:LockWindowUpdate (0x2002a), partial stub! Where do I go to find out who (if anyone) is working on support for that? (Would this be a horrible place for someone COMPLETELY new to wine to start trying to contribute?) Esko __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com

Sept. 27, 2005

Re: build errors

by Marcus Meissner

On Tue, Sep 27, 2005 at 08:32:00AM -0700, Duane Clark wrote: > Michael Stefaniuc wrote: > >Phil Krylov wrote: > >>On Mon, 26 Sep 2005 22:53:18 -0300 > >>Marcelo Duarte <marcelotduarte(a)gmail.com> wrote: > >> > >> > >>>To fix the problem for me, instead of clean, I__d do the folowing > >>>command in wine tree: > >>>rm */*/*.spec.* > >> > >>Thanks, it works. But isn't "make clean" supposed to do this job? > >Yes and it would have worked if you have done the "make clean" before > >the "cvs update". > > > > I know for sure I did "make distclean" a few days ago, and it did not > work. I cannot swear that I tried "make clean", but I think I did. The > problem is specifically with the *.spec.c files that were left around > and needed to be deleted. They were not deleted by "make distclean". Yes, this rm was removed by the cvs update ... Ciao, Marcus

Sept. 27, 2005

Fwd: Re: riched versions... then comdlg

by wino＠piments.com

Hi Andreas, I have just come accross something that looks very similar to my problem. A wine bug that is over a year old reported on a debian installation of wine and posted as a bug on winehq. the bug has had no follow-ups since it was posted a year ago in August. http://www.winehq.org/hypermail/wine-bugs/2004/08/0084.html Seems that there is a strong chance this one is a wine issue rather than the app I am trying to run. Thanks for you comments. ------- Forwarded message ------- From: wino(a)piments.com To: "Andreas Mohr" <andi(a)rhlx01.fht-esslingen.de> Cc: Subject: Re: riched versions... then comdlg Date: Mon, 26 Sep 2005 13:04:32 +0200 Thanks , picking up on the one again having cleared the riched20 issues. the bz2 is the output of: WINEDEBUG=+dll,+file wine natspeak &>/tmp/msvcrt.log I specified msvcrt.dll as native/builtin but it still throws and error version <unspecified> and says it needs 6.?xxxx the end of the file reads: trace:file:append_entry long L"sx96v32.dll"... short L""... mask L"msvcrt.dll" trace:file:match_filename (L"sx96v32.dll"..., L"msvcrt.dll") trace:file:append_entry long L"sx96.ini"... short L""... mask L"msvcrt.dll" trace:file:match_filename (L"sx96.ini"..., L"msvcrt.dll") trace:file:FindNextFileW returning L"msvcrt.dll" (L"") trace:file:RtlDosPathNameToNtPathName_U (L"c:\\windows\\system\\msvcrt.dll",0x7bacee0c,0x7bacee08,(nil)) trace:file:RtlGetFullPathName_U (L"c:\\windows\\system\\msvcrt.dll" 520 0x7baceb50 0x7bacee08) so it seems to have found it but you will surely make more of this output than I can. TIA. On Sun, 25 Sep 2005 22:09:50 +0200, Andreas Mohr <andi(a)rhlx01.fht-esslingen.de> wrote:

Sept. 27, 2005

riched20.dll asserts

by Aric Stewart

Hello, So looking into an issue with IE6 i found the following problem. If I install IE6, and then go to a japanese web site. (for example http://www.mainichi.co.jp) I get given the option to download and install the Japanese Text Display Support. However if i click Download then the download reports as a failure (a message about having to set your security settings from High to Medium, but that is a red herring) The issue is that the assert in riched20/run.c line 115 is being hit during a call to RichEditANSIWndProc for the message EM_LINELENGTH. If i change the assert to instead to return 0, then the certificate dialog is displayed and the download progresses without issue. (there is still an issue with the install but that is not richedit related) Does someone with richedit experience want to help figure out what to do with that assert beyond just changing it to an error trace and returning 0? thanks -aric

Sept. 27, 2005

Re: build errors

by Duane Clark

Michael Stefaniuc wrote: > Phil Krylov wrote: >> On Mon, 26 Sep 2005 22:53:18 -0300 >> Marcelo Duarte <marcelotduarte(a)gmail.com> wrote: >> >> >>> To fix the problem for me, instead of clean, I__d do the folowing command >>> in wine tree: >>> rm */*/*.spec.* >> >> Thanks, it works. But isn't "make clean" supposed to do this job? > Yes and it would have worked if you have done the "make clean" before > the "cvs update". > I know for sure I did "make distclean" a few days ago, and it did not work. I cannot swear that I tried "make clean", but I think I did. The problem is specifically with the *.spec.c files that were left around and needed to be deleted. They were not deleted by "make distclean".

Sept. 27, 2005

Re: Partial solution to the unimplemented API: user32.RealChildWindowFromPoint

by Robert Shearman

Tisheng Chen wrote: >User32.RealChildWindowFromPoint is not implemented >yet. This causes foobar2000 (with foo_ui_columns) to >crash, whenever you right-click on a panel. > >This patch is only a partial solution. It just stop >the crash of programs like foobar2000. But the >functionality is not quite correct. It just uses >ChildWindowFromPointEx to find and return a >childwindow, since I don't really understand the >difference between them. > > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winu… It seems that RealChildWindowFromPoint doesn't recurse into deeper windows, except for HTTRANSPARENT windows, where it recurses deeper than ChildWindowFromPoint to find a window that doesn't return this hit-test (except if it is a static control). What a mess for developers... Two comments on the patch: 1. Please send patches as text attachments. Usually, renaming to .diff or .txt before attaching is enough to make this happen. 2. "+ FIXME("partial stub. HWND: 0x%lx\n", (DWORD) hwndParent);" -> don't cast hwndParent to DWORD, just change the format to %p. Thanks for the patch, >Hope someone else will implement a better one. > > -- Rob Shearman

Sept. 27, 2005

Re: setupapi: implement SetupGetInfFileListW and SetupGetInfInformationW

by Robert Shearman

Steven Edwards wrote: >Hi Rob, > >On 9/24/05, Robert Shearman <rob(a)codeweavers.com> wrote: > > >>Any time a Zero-Width Non-breaking Space is specifically skipped like >>this it is a bug. You should *never* have to do this if you use the >>right functions (isspaceW, etc). Is there some other bug lurking that >>made this change necessary? >> >> > >According to Hervé the *.inf files in the windows/system32/inf folder >had some junk chars in the Unicode header or something like that and >it causes the need for the skipping. > The 'junk' is a valid Unicode character that I describe above. >He was worried that isspaceW >might not handle the junk properly. > #include <stdio.h> #include "wine/unicode.h" int main(int argc, char *argv[]) { int space; space = isspaceW(0xfeff); printf("isspaceW(0xfeff) = %s\n", space ? "yes" : "no"); space = isspaceW('a'); printf("isspaceW('a') = %s\n", space ? "yes" : "no"); return 0; } Output: isspaceW(0xfeff) = yes isspaceW('a') = no >There is a question about the >sizeof WCHAR usage so I will check with him again and send along >another patch later in the week. > Yes, that is another suspect change. If you send the patch again without those two changes it will be perfectly acceptable. >If Alexandre does not like the check >I can also ask him to test it using isspaceW. > Sure. It is possible that the ReactOS implementation is isspaceW is broken for some reason, so I encourage Hervé to use the above simple test program to make sure it works correctly. There may also be some other bug, like not allowing whitespace between a newline separator and the start of a section header. I couldn't see a bug like this in the code, but it is possible. -- Rob Shearman

Sept. 27, 2005

xcursor and wine

by Vijay Kiran Kamuju

Hi all, I any body wants tp implement Xcursor support in wine, for loading color cursors. What should be implemented, how it should be implemented? any details regarding this would be helpful. Thanks, Vijay

Sept. 27, 2005

Re: DDraw: Better flag handling in SetCooperativeLevel

by Alexandre Julliard

Lionel Ulmer <lionel.ulmer(a)free.fr> writes: > On Thu, Sep 08, 2005 at 12:03:52PM +0200, Stefan Dösinger wrote: >> Changelog: >> *Add handling for DDSCL_SETFOCUSWINDOW in SetCooperativeLevel >> *Print a fixme for DDSCL_CREATEDEVICEWINDOW and DDSCL_SETDEVICEWINDOW. > > Alexandre, any reason why this patch (plus the other about the reference > counting) were not applied ? If you were waiting for some DDraw 'guru' to > give his blessing, they both look OK to me :-) I think the reference counting one is suspect, there should be some object that holds the reference, we shouldn't just increment it for no reason. For the other one, the tests fail here: fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdc90d0)->(0x10022,00000008) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdc90d0)->(0x10022,00000080) cooplevels.c:88: Test failed: SetCooperativeLevel(DDSCL_SETFOCUSWINDOW) returned: 80070057 fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdc90d0)->(0x10022,00000080) cooplevels.c:93: Test failed: SetCooperativeLevel(DDSCL_SETFOCUSWINDOW) the secound time returned: 80070057 fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdc90d0)->(0x10022,00000088) cooplevels.c:98: Test failed: SetCooperativeLevel(DDSCL_NORMAL | DDSCL_SETFOCUSWINDOW) returned: 0 fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdc90d0)->(0x10022,00000091) cooplevels.c:102: Test failed: SetCooperativeLevel(DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN | DDSCL_SETFOCUSWINDOW) returned: 0 fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdc90d0)->(0x10022,00000084) cooplevels.c:107: Test failed: SetCooperativeLevel(DDSCL_NOWINDOWCHANGES | DDSCL_SETFOCUSWINDOW) returned: 80070057 fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdc90d0)->(0x10022,00000480) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdc90d0)->(0x10022,00000880) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdc90d0)->(0x10022,00001080) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdc90d0)->(0x10022,00000082) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdc90d0)->(0x10022,000000c0) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdc90d0)->(0x10022,00000100) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdc90d0)->(0x10022,00000108) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdc90d0)->(0x10022,000001d1) cooplevels.c:142: Test failed: SetCooperativeLevel(DDSCL_NORMAL | DDSCL_SETDEVICEWINDOW | DDSCL_SETFOCUSWINDOW) returned: 0 fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdc90d0)->(0x10022,00000010) cooplevels.c:156: Test failed: SetCooperativeLevel(DDSCL_EXCLUSIVE) returned: 0 fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdc90d0)->(0x10022,00000001) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdc90d0)->(0x10022,00000011) fixme:ddraw:Main_DirectDraw_SetCooperativeLevel (0x7fdc90d0)->(0x10022,00000080) cooplevels.c:171: Test failed: SetCooperativeLevel(DDSCL_SETFOCUSWINDOW) returned: 80070057 make: *** [cooplevels.ok] Error 8 -- Alexandre Julliard julliard(a)winehq.org

Sept. 27, 2005

Re: large file support and GetDiskFreeSpace gets wrong info on > 2GB disks

by Marcus Meissner

On Tue, Sep 27, 2005 at 03:32:48PM +0530, Vijay Kiran Kamuju wrote: > Hi Alexander > > We should add the following lines to the configure script to check for > large file support in the kernel. As the GetDiskFreeSpace gets wrong > information regarding the disk space on disks > 2GB. > > dnl This test must come as early as possible after the compiler configuration > dnl tests, because the choice of the file model can (in principle) affect > dnl whether functions and headers are available, whether they work, etc. > AC_SYS_LARGEFILE > > CFLAGS="$CFLAGS -D_FILE_OFFSET_BITS=${ac_cv_sys_file_offset_bits}" > AC_CHECK_SIZEOF(off_t, 64, [ > #include <stdio.h> > #include <sys/types.h> > #include <unistd.h> > ]) AC_SYS_LARGEFILE might be sufficient. Ciao, Marcus

Sept. 27, 2005

large file support and GetDiskFreeSpace gets wrong info on > 2GB disks

by Vijay Kiran Kamuju

Hi Alexander We should add the following lines to the configure script to check for large file support in the kernel. As the GetDiskFreeSpace gets wrong information regarding the disk space on disks > 2GB. dnl This test must come as early as possible after the compiler configuration dnl tests, because the choice of the file model can (in principle) affect dnl whether functions and headers are available, whether they work, etc. AC_SYS_LARGEFILE CFLAGS="$CFLAGS -D_FILE_OFFSET_BITS=${ac_cv_sys_file_offset_bits}" AC_CHECK_SIZEOF(off_t, 64, [ #include <stdio.h> #include <sys/types.h> #include <unistd.h> ]) Thanks Vijay

Sept. 27, 2005

Re: build errors

by Michael Stefaniuc

Phil Krylov wrote: > On Mon, 26 Sep 2005 22:53:18 -0300 > Marcelo Duarte <marcelotduarte(a)gmail.com> wrote: > > >>To fix the problem for me, instead of clean, I__d do the folowing command >>in wine tree: >>rm */*/*.spec.* > > > Thanks, it works. But isn't "make clean" supposed to do this job? Yes and it would have worked if you have done the "make clean" before the "cvs update". bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

Sept. 27, 2005

Re: build errors

by Marcus Meissner

On Tue, Sep 27, 2005 at 01:53:05PM +0400, Phil Krylov wrote: > On Mon, 26 Sep 2005 22:53:18 -0300 > Marcelo Duarte <marcelotduarte(a)gmail.com> wrote: > > > To fix the problem for me, instead of clean, I__d do the folowing command > > in wine tree: > > rm */*/*.spec.* > > Thanks, it works. But isn't "make clean" supposed to do this job? After "cvs update" it no longer new how to clean the tree. make clean cvs up ./configure ... make depend make is the right sequence, and not cvs up ./configure ... make clean make depend make Ciao, Marcus

Sept. 27, 2005

Re: build errors

by Phil Krylov

On Mon, 26 Sep 2005 22:53:18 -0300 Marcelo Duarte <marcelotduarte(a)gmail.com> wrote: > To fix the problem for me, instead of clean, I__d do the folowing command > in wine tree: > rm */*/*.spec.* Thanks, it works. But isn't "make clean" supposed to do this job? -- Ph.

Sept. 27, 2005

Re: MS VisualBasic apps have no minimize/maximise buttons, no taskbar button - RFC, help debugging

by Dmitry Timoshkov

"Alex Villacís Lasso" <a_villacis(a)palosanto.com> wrote: > The following is a problem I have been having with every single > VisualBasic application for some time, and I ask for your help now: > > Every single VisualBasic application I have tried lacks the minimize and > maximize buttons, even when the application is supposed to have them. In > addition, the taskbar button is missing (on Gnome 1.4.x/Metacity 2.10.3 > under Fedora 4), so there is no way to recall the application once the > window is obscured by another application, except by clearing the > desktop. The applications show the buttons on the virtual desktop, and > the problem arises only when the application uses the window manager for > its own window. This problem was confirmed on Metacity and MWM. Please open a bug in bugzilla, attach simple VB app to it and assign it to me, once I have some free time I'll have a look at it. -- Dmitry.

Sept. 27, 2005

Re: Steam broken again

by Ivan Gyurdiev

>Are you talking about the War3 installer or something else? > No...the game no longer runs - it crashes right after you start playing: http://bugs.winehq.org/show_bug.cgi?id=3343

Sept. 27, 2005

Re: msvcrt: portable printf integer conversions

by Mike McCormack

Jesse Allen wrote: > I've read various printf implementation over time. The last one, > ReactOS, seemed to provide support for numbering systems base 2 > through 36. You'll see my version does mimic theirs, but we never do > anything other than 8, 10, and 16. I'm not sure if there is any > printf out there that actually allows you to specify the base. For > this patch it could easily be cut to the 'f' as maximum, except I use > the 'x' digit in the case of the special 0x and 0X prepending cases. > To change that, we just add in a test for the large type there. Generally if something isn't used, then it shouldn't be included. You specified your 'x' as digits[33], and you could easily delete the rest of the alphabet after 'f' and use digits[16] for 'x'. > I will pull up my patch of test cases (never applied) from last time > and see if it will still work against cvs. Somebody (not you, i think) submitted a few test cases before that did something like: printf(buf,"%s %d %c\n", "blah", 10, 'x' ); ok( strlen(buf) == 9, "wrong length\n" ); That doesn't test the code so well, so please make sure to check the output is correct in an unambiguous way. eg. ok( !strcmp(buf,"blah 10 x"), "wrong output\n"); I'd check some combinations of stuff like: ( %I64x %0I64x %1I64d %i64x %i64d %I64D %50I64d %-1I64d %-50I64d etc ) for values: 0, -1, ~1, ~0, 100, -100 Mike

Sept. 27, 2005

Re: msvcrt: portable printf integer conversions

by Jesse Allen

On 9/26/05, Mike McCormack <mike(a)codeweavers.com> wrote: > > Hi Jesse, > > > Code to handle %I64 and %I32 has been missing for a while. Thanks for > looking into this. > > Please make sure to write some test cases, as changing it will probably > break something (or even make some of the current test cases pass). > > If you look at glibc's printf code, you'll realize how messy complete > printf handling is... IMO, it would be better to let glibc handle the > complexities of printf where possible, and work around the differences > as we have done so far. > > Some comments on the patch: > > > + if( flags->Format == 'X' ) > > + digits = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"; > > + else > > + digits = "0123456789abcdefghijklmnopqrstuvwxyz"; > > Do you really need the whole alphabet? Heh, I've read various printf implementation over time. The last one, ReactOS, seemed to provide support for numbering systems base 2 through 36. You'll see my version does mimic theirs, but we never do anything other than 8, 10, and 16. I'm not sure if there is any printf out there that actually allows you to specify the base. For this patch it could easily be cut to the 'f' as maximum, except I use the 'x' digit in the case of the special 0x and 0X prepending cases. To change that, we just add in a test for the large type there. > > > + else if( *(p+1) == '3' && *(p+2) == '2' ) > > + { > > + FIXME("%%I32 unhandled\n"); > > + p += 3; > > + } > > + else > > + { > > + FIXME("%%I unhandled\n"); > > + p++; > > Seems like if you have the code to do %I64, then doing %I32 would be > easy too... Exactly, although we could forward I32 to libc's right? > > I think that you'll find that %I31 is invalid, but again you'll need a > test case to make sure. > > Mike > I believe what happens if you pass a number other that 32 or 64, the conversion stops. Note that I64 floats will be just processed like integers? Not a big deal as we lacked any real function before. I will pull up my patch of test cases (never applied) from last time and see if it will still work against cvs. Jesse

Sept. 27, 2005

Re: setupapi: implement SetupGetInfFileListW and SetupGetInfInformationW

by Steven Edwards

Hi Rob, On 9/24/05, Robert Shearman <rob(a)codeweavers.com> wrote: > >- else err = parse_buffer( file, buffer, (WCHAR *)((char *)buffer + size), error_line ); > >+ else > >+ { > >+ WCHAR *new_buff = (WCHAR *)buffer; > >+ /* Some UNICODE files may start with the UNICODE marker */ > >+ if (*new_buff == 0xfeff) > >+ new_buff++; > >+ err = parse_buffer( file, new_buff, (WCHAR *)((char *)new_buff + size), error_line ); > >+ } > > Any time a Zero-Width Non-breaking Space is specifically skipped like > this it is a bug. You should *never* have to do this if you use the > right functions (isspaceW, etc). Is there some other bug lurking that > made this change necessary? According to Hervé the *.inf files in the windows/system32/inf folder had some junk chars in the Unicode header or something like that and it causes the need for the skipping. He was worried that isspaceW might not handle the junk properly. There is a question about the sizeof WCHAR usage so I will check with him again and send along another patch later in the week. If Alexandre does not like the check I can also ask him to test it using isspaceW. Thanks Steven

Sept. 27, 2005

Re: Documentation volunteer(s) needed

by josephblack

Brian Vincent wrote: > On 9/23/05, josephblack <josephhenryblack(a)yahoo.co.nz> wrote: <snip> >>After some discussion, Jason has confirmed he would like to >>raise an offer of wine-wiki.org and its contents to the Wine project. > First off, there's a lot of useful info in that wiki. It obvious a > lot of time has gone into it. thanks. Since starting, the wiki has collected tips for nearly a year. I have been trying to make time to send drafts to wine docs - such as some of the info about regression testing. > However, I really don't see the point of having that wiki and I think > it has the potential to do more harm than good. If there's one thing > Wine and the rest of the community has proven over and over, it's that > we can't maintain documentation. I'd (almost) argue its best to have > no documentation than completely incorrect docs. > > I realize that wiki came into existence before Wine's own, but now > that we have one I think some of that info needs to migrate to > wiki.winehq.org. <snip> Well, There are two things being offered 1. the domain name 2. the contents I dont mind, nor have much of a preference of whether it is moved over, or both are used by wine. Either way, at least tips from the mailing lists can be stored, saved and later moved to oficial documentation. however while the developer wiki has shown it needs protecting, the unofficial 'end user/beginner' wiki has kept a low profile and carefully allowed open posting. People regularly take advantage of this to add notes or make corrections anon >Furthermore, the wine-wiki.org >has a huge section on applications that's best suited for the AppDB. >The info there directly competes with the AppDB and we shouldn't >attempt to maintain two places with differing info. sure. I had expected all of that to move to the appdb. Applications havent really been my focus - all we wanted was to at least save info for later inclusion or encourage someone to become a maintainer. Curiously one apdb entry has basic installation notes and then uses the wiki for a fairly lengthy & comprehensive troubleshooting suggestions - and recently someone anon added a portuguese(?) translation summary. With those who add a new entry - we have had some success with them then becoming an apdb maintainer and as admin I put a chill on any misguided attempts at competition. The appdb is where that important info belongs but perhaps the appdb should be the subject of a seperate discussion. Joseph Black

Sept. 27, 2005

Re: msvcrt: portable printf integer conversions

by Mike McCormack

Hi Jesse, Jesse Allen wrote: > Here's a patch to start the work on getting our own printf number > conversions done internally. It adds pf_integer_conv, which is > capable of handling d,x,o,u,i. However, a large part of my intent is > to add support for I64 size integers. So I've decided to only foward > I64 sizes to it at this time, and leave the rest intact, as I've only > tested I64. I sent a message to wine-devel last night for comments, > but it seems to have gotten lost. We need to guage how to restructure > the printf code, especially since I've found two bugs in our current > implementation. Code to handle %I64 and %I32 has been missing for a while. Thanks for looking into this. Please make sure to write some test cases, as changing it will probably break something (or even make some of the current test cases pass). If you look at glibc's printf code, you'll realize how messy complete printf handling is... IMO, it would be better to let glibc handle the complexities of printf where possible, and work around the differences as we have done so far. Some comments on the patch: > + if( flags->Format == 'X' ) > + digits = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ"; > + else > + digits = "0123456789abcdefghijklmnopqrstuvwxyz"; Do you really need the whole alphabet? > + else if( *(p+1) == '3' && *(p+2) == '2' ) > + { > + FIXME("%%I32 unhandled\n"); > + p += 3; > + } > + else > + { > + FIXME("%%I unhandled\n"); > + p++; Seems like if you have the code to do %I64, then doing %I32 would be easy too... I think that you'll find that %I31 is invalid, but again you'll need a test case to make sure. Mike

Sept. 27, 2005

Re: Steam broken again

by Jesse Allen

On 9/26/05, Ivan Gyurdiev <ivg2(a)cornell.edu> wrote: that would be useful for hunting down what broke > Warcraft3/Fthrone as well. I'll give it a try over the weekend. > Are you talking about the War3 installer or something else?

Sept. 27, 2005

Re: Wine CVS as of 9/25/2005 Kills Notes

by Kevin DeKorte

> > Ok, if I delete /usr/lib/wine/usp10.dll.so then Notes will start. > > Weird side effect is that the fonts in the menus are anti-aliased, but the > main window of notes is not. If I fall back the the previous version all > the fonts are properly smoothed. So I got Notes Running and then I tried to Save an Attachment (this failed in the 20050825 release) get the same crash and here is the trace back. I did the *****'s in the printout as the not implemented bug crashes Notes. wine nlnotes.exe fixme:ole:CoRegisterMessageFilter stub err:ole:marshal_object couldn't get IPSFactory buffer for interface {00000131-0000-0000-c000-000000000046} 09/26/2005 08:33:29 PM COM1: Error opening modem command file C: \lotus\notes\data\auto.mdm 09/26/2005 08:33:29 PM COM2: Error opening modem command file C: \lotus\notes\data\auto.mdm 09/26/2005 08:33:29 PM COM3: Error opening modem command file C: \lotus\notes\data\auto.mdm 09/26/2005 08:33:29 PM COM4: Error opening modem command file C: \lotus\notes\data\auto.mdm 09/26/2005 08:33:29 PM COM5: Error opening modem command file C: \lotus\notes\data\auto.mdm fixme:system:SystemParametersInfoW Unimplemented action: 8193 (SPI_SETFOREGROUNDLOCKTIMEOUT) err:x11drv:X11DRV_CreateWindow invalid window width -85 err:x11drv:X11DRV_CreateWindow invalid window height -1106180664 err:ole:marshal_object couldn't get IPSFactory buffer for interface {00000131-0000-0000-c000-000000000046} err:ole:marshal_object couldn't get IPSFactory buffer for interface {00000131-0000-0000-c000-000000000046} ******** fixme:commdlg:GetFileName95 Flags 0x00900000 not yet implemented ********* fixme:netapi32:NetUserEnum ((null),20, 0x2,0x4191f2e4,2,0x4191f4ec,0x4191f4f0,0x4191f2dc) stub! fixme:advapi:LookupAccountSidA ((null),sid=0x4191f01c,0x4191e9d4,0x4191edd8 (512),0x4191ebd4,0x4191efe0(512),0x4191efe4): semi-stub fixme:advapi:LookupAccountSidA ((null),sid=0x4191ed2c,0x4191e6e4,0x4191eae8 (512),0x4191e8e4,0x4191ecf0(512),0x4191ecf4): semi-stub fixme:advapi:LookupAccountSidA ((null),sid=0x4191ed2c,0x4191e6e4,0x4191eae8 (512),0x4191e8e4,0x4191ecf0(512),0x4191ecf4): semi-stub fixme:advapi:LookupAccountSidA ((null),sid=0x4191ed2c,0x4191e6e4,0x4191eae8 (512),0x4191e8e4,0x4191ecf0(512),0x4191ecf4): semi-stub -- Get my public GnuPG key from http://keyserver.veridis.com:11371/export?id=7574690260641978351

Sept. 27, 2005

Re: winsock2 header missing function prototypes

by James Hawkins

On 9/26/05, James Hawkins <truiken(a)gmail.com> wrote: > Hey, > > While trying out example code from msdn covering windows sockets, I > ran into a problem with the winsock2.h header. The example only > included winsock2.h and used the socket() function. While compiling > with winelib, gcc complained that socket is not a function. I looked > through winsock2.h and couldn't find the prototype. It turns out the It turns out it's my fault..really silly actually. I didn't realize that I named the variable socket. Sorry about all the noise :) -- James Hawkins

Sept. 27, 2005

Re: Wine CVS as of 9/25/2005 Kills Notes

by Kevin DeKorte

On Monday 26 September 2005 08:11 pm, Troy Rollo wrote: > On Tue, 27 Sep 2005 12:06, Kevin DeKorte wrote: > > Actually I retested with a clean CVS build and setting usp10.dll to be > > native and then running wine nlnotes it crashes with the following > > ... > > > fixme:uniscribe:ScriptCacheGetHeight 0xa60,0x61c0d0f0,0x4190ea8c > > fixme:uniscribe:ScriptCacheGetHeight 0xa60,0x61c0d12e,0x4190c518 > > ... > > It didn't find the native usp10.dll. Ok, if I delete /usr/lib/wine/usp10.dll.so then Notes will start. Weird side effect is that the fonts in the menus are anti-aliased, but the main window of notes is not. If I fall back the the previous version all the fonts are properly smoothed. Kevin -- Get my public GnuPG key from http://keyserver.veridis.com:11371/export?id=7574690260641978351

Sept. 27, 2005