February 2009 - Wine-Devel - list.winehq.org

Re: [1/2]tools/winemaker: add project-file support(try3)
by Francois Gouget Feb. 23, 2009

Feb. 23, 2009

Hi, I had a look at this patch and here are some comments. The case of the filenames in the dsp and dsw files may not match the case of the filenames on the filesystem. So you need to ajsut the names before you put them in the makefile. I believe search_from() can be used for that. I see that you're translating the Visual C++ compiler flags to gcc compiler flags. That's good. But I'm not sure about the following conversion from /GX to -fexceptions. Exception handling is pretty different between windows and Unix. Do you know if /GX is about structured exception handing? I really couldn't tell, but maybe some exception expert will know. I see you're converting the /Zp1 option which is very nice (packing being one of the disagreements between Visual C++ and gcc). But you don't do it for Zp(2|4|8|16). I believe you could do it by simply appending the packing size to the '-fpack-struct=' option. (But maybe I missed something) A bigger issue is that you're putting all the compiler options in CXXEXTRA which only applies to C++ code. But in the dsp file it looks like this applies to both C and C++ code. So it probably should be put in both (except -fexceptions which seems to be on by default in C++, but that's minor). About the commented out call to fix_file_and_directory_names(), I don't think winemaker should go and modify files outside of '.'. So I think it's safe to remove this call entirely. Also I have some questions about a couple of heuristics: if ($has_headers) { push @{@$project_settings[$T_INCLUDE_PATH]},"-I."; } Is this still needed? In source_scan_directory() it was needed because we had no idea what the include path was supposed to look like. But the project file should define it clearly enough for us. However I have a dsp file in a directory with a header file and I don't see a '/I.'. So maybe it is implied? Also this part seems wrong: # Finally if we are building both libraries and programs in # this project, then the programs should be linked with all # the libraries The project file should be explicit enough on this part for us not to have to do any guessing. Also do we really need to worry much about matching source file with a given target? Won't we always have a single target per dsp file? In which case the matching can probably be simplified. The end of source_scan_project_file() looks pretty similar to the end of source_scan_directory(). Maybe some code can be shared. To make the patch smaller you can first submit the dsp parser, then the dsw one, the vcproj one, and finally the sln one. And once that's done, it would be nice to integrate this all with the regular source_scan() function, so that if it detects one of these files in the subdirectories, it invokes the appropriate project parser for that directory and stops recursing. That can be done as a further separate patch. Style issues: The style issues are at least partly my fault as I used two-space indentation and braces on the same line when I first wrote winemaker. Nowadays I'd prefer 4-space indentation with braces on their own line but that's a bit tricky when maintaining a consistent indentation. In any case, in places your code is too incoherent. For instance: } elsif(/^# TARGTYPE/) { if (/[[:space:]]0x0101$/) { # Win32 (x86) Application $prj_target_type=1; This snippet has both 2 and 4 space indentation and it's all new code. There's also an indentation problem there: } } foreach my $source (@sources_misc) { if ($source =~ /^$basename/i) { Personnally I'd recommend to maintain a consistent indentation scheme at least per function (though the policy is more to be consistent per file normally :-/ ). Also, I'd prefer to have a space between 'if' and the prentheseses and braces. You can also simplify a some string concatenations. Replace: $prj_target_cflags=$prj_target_cflags."-D".$1." "; with $prj_target_cflags.="-D$1 "; In any case, thanks for taking this on. I think you're pretty close to the end (even if you don't feel that way after reading the above<g>). -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ If you think the whole world revolves around you, quit staring at the GPS display while driving.

1 0

Re: msctf: add internal function for handling TfClientIds
by James Mckenzie Feb. 23, 2009

Feb. 23, 2009

Alexandre Julliard <julliard(a)winehq.org> wrote on Feb 23: > >Aric Stewart <aric(a)codeweavers.com> writes: > >> + /* If i understand this correctly at most a process should generate >> + * only a handful of these... But in case I am wrong */ >> + if (id_last == 65535) >> + { >> + ERR("TfClientIds generated exceeds USHORT limit\n"); >> + return 0x0; >> + } >> + id_last++; >> + id->id = MAKELONG(id_last, magic); >> + id->data = data; >> + list_add_head(&clientids,&id->entry); > >Using an array index would be cleaner than having to search through the >list everytime you use an id. > Also, aren't linked lists inefficient as well. Searching through them can be very intense, unless they are small (< 5 elements). Anything larger than this and an array would be more efficient. James McKenzie

2 1

Re: [7/7] setupapi/tests: start dialog.c test file with a test for SetupPromptForDiskA
by Paul Vriens Feb. 23, 2009

Feb. 23, 2009

Ricardo Filipe wrote: > > > ------------------------------------------------------------------------ > > Hi, Could you turn that skip() into a win_skip()? Usually it's a good idea to do a SetLastError(0xdeadbeef or something like that) before calling the function, especially because you are relying on that last error for the ok() test. -- Cheers, Paul.

2 1

Re: ole32: change a pointer cast from DWORD to DWORD_PTR
by Rob Shearman Feb. 23, 2009

Feb. 23, 2009

2009/2/22 Austin English <austinenglish(a)gmail.com>: > diff --git a/dlls/ole32/compobj.c b/dlls/ole32/compobj.c > index b8ddba8..7360f66 100644 > --- a/dlls/ole32/compobj.c > +++ b/dlls/ole32/compobj.c > @@ -2007,7 +2007,7 @@ HRESULT WINAPI CoRegisterClassObject( > * Use the address of the chain node as the cookie since we are sure it's > * unique. FIXME: not on 64-bit platforms. > */ > - newClass->dwCookie = (DWORD)newClass; > + newClass->dwCookie = (DWORD_PTR)newClass; > > /* > * Since we're making a copy of the object pointer, we have to increase its Since dwCookie is of type DWORD this is just hiding the problem. The correct solution is to store a process-wide index and then to increase this every time a class object is registered and use it for the cookie. CoRevokeClassObject already looks through the list of registered classes to find the cookie so this doesn't need to be changed. -- Rob Shearman

1 0

Re: Win to Lin Library Wrapper
by King InuYasha Feb. 23, 2009

Feb. 23, 2009

On Mon, Feb 16, 2009 at 1:26 PM, Chris Robinson <chris.kcat(a)gmail.com>wrote: > On Monday 16 February 2009 9:38:19 am Seth Shelnutt wrote: > > I had an interesting thought the other day, and that is to having some > > built in support for forwarding windows dlls to linux .so's. > > IIRC, this kind of thing is generally discouraged, except in cases where > needed (eg. opengl32). Part of the problem is internal differences.. for > example, what would a Linux .so do if it's given a Win32 filename path? > Other > problems would be if the Linux equivalent wants a Window for a function > argument and the DLL wants an HWND instead, or if the DLL has > more/different > functions (eg. CUDA on Win32 has functions for dealing with D3D objects; > CUDA > on Linux doesn't, and it wouldn't be straight forward to even implement > them > through wined3d). > > Something like OpenGL, and even OpenAL to some degree, would directly > benefit > from having the DLLs forwarded to their host equivalents as it provides > better > access to the hardware and better integration with the host system. > Something > like zlib or ogg/vorbis and stuff wouldn't though, since the code should > largely be the same, and save for some bugs/inefficiencies in Wine (which > should be fixed), would work identically. > > > Does Wine yet have the capability to interface with HAL for Win32 hardware access similar to NT? It looks like it doesn't from all this talk of forwarding DLLs. What we should do instead of trying to forward DLLs, which is asking for more trouble than its worth, is try to get the NT layer to connect to UNIX HAL so that DLLs can link directly to HAL and operate the hardware.

6 11

Re: msctf: add internal function for handling TfClientIds
by Alexandre Julliard Feb. 23, 2009

Feb. 23, 2009

Aric Stewart <aric(a)codeweavers.com> writes: > + /* If i understand this correctly at most a process should generate > + * only a handful of these... But in case I am wrong */ > + if (id_last == 65535) > + { > + ERR("TfClientIds generated exceeds USHORT limit\n"); > + return 0x0; > + } > + id_last++; > + id->id = MAKELONG(id_last, magic); > + id->data = data; > + list_add_head(&clientids,&id->entry); Using an array index would be cleaner than having to search through the list everytime you use an id. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: d3d8: some 64-bit fixes
by Henri Verbeet Feb. 23, 2009

Feb. 23, 2009

2009/2/23 Austin English <austinenglish(a)gmail.com>: > + STDMETHOD(ApplyStateBlock)(THIS_ DWORD_PTR Token) PURE; > + STDMETHOD(CaptureStateBlock)(THIS_ DWORD_PTR Token) PURE; > + STDMETHOD(DeleteStateBlock)(THIS_ DWORD_PTR Token) PURE; > + STDMETHOD(CreateStateBlock)(THIS_ D3DSTATEBLOCKTYPE Type,DWORD_PTR * pToken) PURE; Which version of the DXSDK does this match?

2 2

Re: user32: change a pointer cast from DWORD to DWORD_PTR
by Austin English Feb. 23, 2009

Feb. 23, 2009

2009/2/22 Austin English <austinenglish(a)gmail.com>: > -- > -Austin > Ignore this patch please. -- -Austin

1 0

Greatings
by Piotr Skólski Feb. 22, 2009

Feb. 22, 2009

Hi. I want help you. I know c glibc and svn. I don't know git(but i'm leraning) and winapi(i don't know how learn without windows). Where my skils will be usefull. I have StarCraft and i want help you with dib engine but my skils are still too low (i don't know how patch my git tree with max dib engine). Bye. Piotr Skólski (SQLek) <sql7(a)wp.pl>

2 1

Wine download page usability problem
by Dan Kegel Feb. 22, 2009

Feb. 22, 2009

I got email from a friend who complained how hard it was to install wine. Turns out he assumed he had to go to winehq.org and follow the download instructions there, when all he needed to do was do Applications / Add/Remove and pick Wine. Can we add in a line at the top saying "Stable version 1.0.1 of Wine can usually be installed just like any other Linux application using your package manager (e.g. in Ubuntu, do Applications / Add/Remove, select Wine, and click Apply Changes). If that doesn't work, or if you need a newer version of Wine, here's how to get it." ? I know, that clutters things even more. Suggestions for achieving the same thing more concisely would be welcome. I think we should also move the text "This endorsement is the primary recognition that CodeWeavers has requested in exchange for hosting the Wine web site." to the bottom of the page, and change it to read "Thanks to CodeWeavers for hosting WineHQ.org". - Dan

17 30

Jaunty and pulseaudio
by Dan Kegel Feb. 22, 2009

Feb. 22, 2009

https://lists.ubuntu.com/archives/ubuntu-devel-discuss/2009-February/007108… says the pulseaudio daemon will autorestart, so anyone who's been relying on killing it might want to test with fresh jaunty to see if they've fixed the problems...

1 0

Re: opengl: wglMakeCurrent should call glflush before proceeding
by Chris Robinson Feb. 22, 2009

Feb. 22, 2009

On Saturday 21 February 2009 2:00:26 pm Jérôme Gardou wrote: > according to > http://msdn.microsoft.com/en-us/library/dd374387(VS.85).aspx, > wglMakeCurrent proceeds a flush before switching. glXMakeCurrent also forces a flush: http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/glx/xm… If it needs a wglFlush, it should call X11DRV_wglFlush (and only if there's a current context; you can't call gl* functions without one set). It can be an exceptionally costly call though, especially if it's going to be flushed again immediately after, so unless it's needed to fix some bug, I'd recommend not flushing explicitly.

2 1

Re: Icehamster?
by Shlomi Fish Feb. 22, 2009

Feb. 22, 2009

Hi Seth! On Fri, Jan 23, 2009 at 4:46 AM, Seth <seth.goldy(a)gmail.com> wrote: > ..or possibly Winapt. I read through your documentation and i am quite > interested in your idea. I'm not much of a programmer, but i have a > need knowledge of windows, registry, what dlls are doing, how to find > dependencies, and who knows what else. I've been around windows since the > age of 9 with windows 3.1 I've recently come to grips with the value of > open source software and the superiority of the Linux operating system (ie.\ > the reason why it's more secure, not just the fact that it is). I'm mostly > curious if you're still actively pursuing this project, I didn't assume that > i would be needed as a contributor to this project. > I never really started pursuing Winapt. Most I got to was the initial planning documentation: http://svn.berlios.de/svnroot/repos/winapt/winapt/trunk/docs/design/ Anyway, it is my intention to start working on this soon. I have a few loose ends to sort out before that with my other open-source endeavours. Regards, -- Shlomi Fish > > > -seth -- ------------------------------------------ Shlomi Fish http://www.shlomifish.org/ Electrical Engineering studies. In the Technion. Been there. Done that. Forgot a lot. Remember too much.

2 1

Re: Status of USB driver support?
by emiliano esposito Feb. 21, 2009

Feb. 21, 2009

Alexander Morozov ha scritto: >> git clone git://source.winehq.org/git/wine.git ~/wine-git >> git-am 0001... >> git-am 0002... >> > > You should run tools/make_makefiles before configuring. Thanks. I redid it from scratch, and imported the relevant keys directly from windows. Now this is what I get after launching the program: fixme:ntoskrnl:KeInitializeSpinLock stub: 0x129824 wine: Call from 0x7ee2e8b0 to unimplemented function usbd.sys.USBD_GetUSBDIVersion, aborting wine: Unimplemented function usbd.sys.USBD_GetUSBDIVersion called at address 0x7ee2e8b0 (thread 0022), starting debugger... Unhandled exception: unimplemented function usbd.sys.USBD_GetUSBDIVersion called in 32-bit code (0x7ee2e923) Then a lot of debug info follows, register dumps and so on. After that, the program continues normally. Don't know if it would be worth posting, please let me know.

3 4

Re: fusion/tests: Do not use a fixed path to the assembly
by James Hawkins Feb. 21, 2009

Feb. 21, 2009

On Thu, Feb 19, 2009 at 4:14 PM, Detlef Riekenberg <wine.dev(a)web.de> wrote: > > James: A fixed path is broken by design. > A "Thanks for spending weeks of your time laboriously testing and implementing fusion" would have sufficed. -- James Hawkins

3 2

Problem cross compiling after adding tests for inet_ntop
by Jeff Latimer Feb. 21, 2009

Feb. 21, 2009

I have been writing some tests for InetNtop/inet_ntop and placed them in dlls/ws2_32/tests/sock.c (snip of the code is below) but when I cross compile I get: make crosstest i386-mingw32-gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -o sock.cross.o sock.c i386-mingw32-gcc protocol.cross.o sock.cross.o testlist.cross.o -o ws2_32_crosstest.exe -L../../../dlls ../../../libs/port/libwine_port.a -L../../../dlls/ws2_32 -L../../../dlls/kernel32 -lws2_32 -lkernel32 sock.cross.o: In function `test_inet_addr': /wing/dlls/ws2_32/tests/sock.c:2013: undefined reference to `_inet_ntop(a)16' /wing/dlls/ws2_32/tests/sock.c:2025: undefined reference to `_inet_ntop(a)16' /wing/dlls/ws2_32/tests/sock.c:2029: undefined reference to `_inet_ntop(a)16' /wing/dlls/ws2_32/tests/sock.c:2032: undefined reference to `_inet_ntop(a)16' collect2: ld returned 1 exit status make: *** [ws2_32_crosstest.exe] Error 1 I am using unmodified winsock.spec and ws2_32.spec files. It does not look like inet_ntop has been used in tests previously. Any ideas on what I need to do to get crosstest to work? ---- dlls/ws2_32/tests/sock.c static void test_inet_addr(void) { u_long addr; char dst[16]; char dst6[64]; u_char ip6_addr[16] = {0x20,0x30,0xa4,0xb1}; const char * pdst; struct in_addr in; struct in6_addr in6; u_long addr0_Num = 0x00000000; PCSTR addr0_Str = "0.0.0.0"; u_long addr1_Num = 0x20201015; PCSTR addr1_Str = "21.16.32.32"; u_char addr2_Num[16] = {0,0,0,0,0,0,0,0,0,0,0xff,0xfe,0xcC,0x98,0xbd,0x74}; PCSTR addr2_Str = "::fffe:cc98:bd74"; addr = inet_addr(NULL); in.S_un.S_addr = addr; trace("addr=%ld\n",addr); ok(addr == INADDR_NONE, "inet_addr succeeded unexpectedly\n"); in.S_un.S_addr = addr0_Num; pdst = InetNtop(AF_INET,(void*)&in.S_un.S_addr,dst,sizeof(dst)); ok(strcmp(pdst, addr1_Str),"Address %s != %s\n", pdst, addr0_Str); ok(pdst != NULL, "InetNtop failed %s\n", dst); pdst = inet_ntoa(*((struct in_addr*)&in.s_addr)); ok(pdst != NULL, "InetNtop succeeded unexpectedly %s\n", dst); ok(!strcmp(pdst, addr1_Str),"Address %s != %s\n", pdst, addr0_Str); trace ("addr=%s\n",pdst); in.S_un.S_addr = addr1_Num; pdst = inet_ntoa(*((struct in_addr*)&in.s_addr)); ok(pdst != NULL, "inet_ntoa succeeded unexpectedly %s\n", dst); ok(!strcmp(pdst, addr1_Str),"Address %s != %s\n", pdst, addr1_Str); trace ("addr=%s\n",pdst); pdst = InetNtop(AF_INET6,(void*)&in.S_un.S_addr,dst,sizeof(dst)); trace ("addr=%s\n",pdst); ok(pdst != NULL, "InetNtop failed %s\n", dst); memcpy(in6.s6_addr,ip6_addr,sizeof(ip6_addr)); pdst = InetNtop(AF_INET6,(void*)&in6.s6_addr,dst6,sizeof(dst6)); ok(pdst != NULL, "InetNtop failed %s\n", dst6); memcpy(in6.u.Byte,addr2_Num,sizeof(addr2_Num)); pdst = InetNtop(AF_INET6,(void*)&in6.s6_addr,dst6,sizeof(dst6)); ok(pdst != NULL, "InetNtop failed %s\n", dst6); ok(!strcmp(pdst, addr2_Str),"Address %s != %s\n", pdst, addr2_Str); }

1 1

Closing fixed bugs
by Dan Kegel Feb. 21, 2009

Feb. 21, 2009

A few months ago, Alexandre started including lists of fixed bugs in his release announcements. See e.g. http://www.winehq.org/announce/1.1.15, which says Bugs fixed in 1.1.15: 5694 Lionhead Black & White 2 demo crashes 7014 Unhandled page fault when exiting Commandos - BEL 7297 MIDI in/out fails, ports recognized ... I rather like those lists. He generates them by simply querying for open but fixed bugs right when he does the release; he then closes the bugs. They're good for PR if nothing else. For this to work, we have to let Alexandre be the only person to close fixed bugs. (Of course, it's ok for other people to mark bugs fixed, and it's ok for anyone to close invalid or dup bugs.) If anybody else closes a fixed bug, it won't show up in the list of fixed bugs for any release. A corner case is when a bug is marked fixed sometime after release. I think it's ok to leave it for Alexandre to close; that way it shows up in at least one release announcement. Even if it shows up a few releases late, that's better than not showing up at all. Sound reasonable? I ask because Vitaliy closed http://bugs.winehq.org/show_bug.cgi?id=10923 even after I tried to explain this to him, so I figured it needed a wider discussion. - Dan

4 4

Re: Wine download page usability problem
by Remco Feb. 21, 2009

Feb. 21, 2009

And now also to the list: On Fri, Feb 20, 2009 at 9:32 PM, Remco <remco47(a)gmail.com> wrote: > On Fri, Feb 20, 2009 at 9:28 PM, Dan Kegel <dank(a)kegel.com> wrote: >> >> Please try again, and paste the entire output page, I've added more info. >> >> Thanks! >> > > Firefox 3 on an unknown distribution Linux! > > userAgent Mozilla/5.0 (X11; U; Linux x86_64; en; rv:1.9.0.6) > Gecko/20080528 Epiphany/2.22 Firefox/3.0 > > I don't think you're gonna be able to get the distribution name out of > that... a problem with Epiphany I guess. > > Remco >

3 4

Possible to run arbitrary PHP code on pipermail server
by Remco Feb. 20, 2009

Feb. 20, 2009

I read the following e-mail on pipermail: http://www.winehq.org/pipermail/wine-devel/2009-February/073428.html Try downloading the PHP attachment from there; it will actually execute and give you an HTML page. This could easily be abused! Remco

2 1

Re: user32: implement support for HBMENU_POPUP_* magic menu bitmaps and use them to decorate the system menu
by Austin English Feb. 20, 2009

Feb. 20, 2009

2009/2/20 Rein Klazes <wijn(a)online.nl>: > Hi, > > See subject. > > Rein. > > > > A testcase would be helpful. -- -Austin

1 0

Re: user32: implement support for HBMENU_POPUP_* magic menu bitmaps and use them to decorate the system menu
by Peter Oberndorfer Feb. 20, 2009

Feb. 20, 2009

On Freitag 20 Februar 2009, Rein Klazes wrote: > Hi, > > See subject. > > Rein. > Hi, mostly minor code style comments. > if( hMenu ) { > + MENUINFO minfo; > + MENUITEMINFOW miteminfo; > POPUPMENU* menu = MENU_GetMenu(hMenu); > menu->wFlags |= MF_SYSMENU | MF_POPUP; > SetMenuDefaultItem(hMenu, SC_CLOSE, FALSE); > + > + minfo.cbSize = sizeof( MENUINFO); > + minfo.dwStyle = MNS_CHECKORBMP; > + minfo.fMask = MIM_STYLE; > + SetMenuInfo( hMenu, &minfo); > + > + miteminfo.cbSize = sizeof( MENUITEMINFOW); > + miteminfo.fMask = MIIM_BITMAP; > + miteminfo.hbmpItem = HBMMENU_POPUP_CLOSE; > + SetMenuItemInfoW( hMenu, SC_CLOSE, FALSE, &miteminfo); > + miteminfo.hbmpItem = HBMMENU_POPUP_RESTORE; > + SetMenuItemInfoW( hMenu, SC_RESTORE, FALSE, &miteminfo); > + miteminfo.hbmpItem = HBMMENU_POPUP_MAXIMIZE; > + SetMenuItemInfoW( hMenu, SC_MAXIMIZE, FALSE, &miteminfo); > + miteminfo.hbmpItem = HBMMENU_POPUP_MINIMIZE; > + SetMenuItemInfoW( hMenu, SC_MINIMIZE, FALSE, &miteminfo); > } I think this part deserves a bit more spacing to be readable. Something like the above looks better IMO. Also there is some inconsistent spacing around the beginning and end ()/{} which does not match the rest of the file. > + logfont.lfHeight = min( h, w) - 2 ; > + TextOutW( hdc, rect->left, rect->top, bmchr, 1); double space after '=' and ',' > case (INT_PTR)HBMMENU_POPUP_CLOSE: > + bmchr[0] = 0x72; > + break; > case (INT_PTR)HBMMENU_POPUP_RESTORE: > + bmchr[0] = 0x32; > + break; > case (INT_PTR)HBMMENU_POPUP_MAXIMIZE: > + bmchr[0] = 0x31; > + break; > case (INT_PTR)HBMMENU_POPUP_MINIMIZE: > + bmchr[0] = 0x30; > + break; The constants seem to be equal to DFCS_CAPTION... I just tried to use DrawFrameControl but it seems to always draw a border around the images. And i did not find the right parameters for not drawing a border. It could save some code for font setup but i guess it is not usable for this :-( > + TRACE(" height %d rect %s\n", logfont.lfHeight, wine_dbgstr_rect( rect)); leftover from debugging or is it still needed? Greetings Peter

1 0

Re: msi: begin support for finding network last sources in find_published_source
by James Hawkins Feb. 20, 2009

Feb. 20, 2009

On Thu, Feb 19, 2009 at 12:28 PM, Aric Stewart <aric(a)codeweavers.com> wrote: > > Fix for office 2007 sp 1 install. > --- > dlls/msi/media.c | 33 +++++++++++++++++++++++++++++++++ > 1 files changed, 33 insertions(+), 0 deletions(-) > I believe you're going down the wrong road with respect to the Office 2007 SP1 installer. None of the files installed/patched by SP1 need access to the original media, or stored local copies of the cab archives. With the fullfile install (which I'm not sure there's another version), you should be able to remove the original media, erase the stored cab files, and successfully install SP1. The fact that our implementation tries to access those cabs or the original media is the bug. There are many conditions and variables that factor in to whether a file should be reinstalled or not, and most of them have been fixed, but this patch is hiding all of the rest of the bugs. I'm not sure if you got the email I sent Jer about this problem, but the real bug is that we aren't handling the REINSTALL variable correctly (or REINSTALLMODE for that matter.) Can you please describe the exact case for why this patch is needed? -- James Hawkins

2 4

Re: Wine download page usability problem
by James Mckenzie Feb. 20, 2009

Feb. 20, 2009

Austin English <austinenglish(a)gmail.com> wrote: >Sent: Feb 20, 2009 10:32 AM >To: Dan Kegel <dank(a)kegel.com> >Cc: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> >Subject: Re: Wine download page usability problem > >On Fri, Feb 20, 2009 at 11:24 AM, Dan Kegel <dank(a)kegel.com> wrote: >> >> Can we add in a line at the top saying >> "Stable version 1.0.1 of Wine can usually be installed >> just like any other Linux application using your >> package manager (e.g. in Ubuntu, do Applications / Add/Remove, >> select Wine, and click Apply Changes). > >Nitpick, but instead of 'Linux', use 'native'. FreeBSD's ports >contains wine, as well as NetBSD's. Please exclude MacOSX which does not include Wine and I doubt it ever will. > >> I think we should also move the text >> "This endorsement is the primary recognition that CodeWeavers has >> requested in exchange for hosting the Wine web site." >> to the bottom of the page, and change it to read >> "Thanks to CodeWeavers for hosting WineHQ.org". > >+1 > ++1 James McKenzie

2 1

Re: msadp32.acm, winemp3.acm: Removed compiler warning
by Ricardo Filipe Feb. 20, 2009

Feb. 20, 2009

you should send one patch per email, dan should have told you that :P good to see you guys on the project :) 2009/2/20 Adam Stoelting <astoelting(a)ucla.edu> > Hello, > > These are my first patches. I am graduate student at UCLA and am trying to > help with porting Wine to 64 bit. I haven't seen any Microsoft source code > or done any dll dissasembly on my own. > > Change Log: > Removed the compiler pointer cast warning for dlls/msadp32.acm/msadp32.c > and > dlls/winemp3.acm/mpegl3.c. > > Thanks, > Adam > > > >

1 0

Re: [12/13] fusion: Sort the list of assemblies built during enumeration.
by James Hawkins Feb. 20, 2009

Feb. 20, 2009

On Thu, Feb 19, 2009 at 5:06 AM, Hans Leidekker <hans(a)codeweavers.com> wrote: > > This hopefully fixes the test failures on Alexandre's machine. > This isn't how it's done on Windows. On Windows, the order is based solely on directory enumeration, which we don't try to match in Wine. The fix is to check for all N results N times, where N is the number of assemblies enumerated. -- James Hawkins

3 6

Re: revert of a6c07ffba4b2b37d01affb4c39f032bb5f8d34bf
by Francois Gouget Feb. 20, 2009

Feb. 20, 2009

A little bit of explanation would be nice... -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ La terre est une bêta...

2 3

Re: fusion/tests: Do not use a fixed path to the assembly
by Nicolas Le Cam Feb. 20, 2009

Feb. 20, 2009

2009/2/20 Detlef Riekenberg <wine.dev(a)web.de>: > James: A fixed path is broken by design. > > This fix the remaining failure on w2k. > > The asmcache has more failures on win9x, but a fix for that > failures conflict with the patchset from Hans. > > > -- > > By by ... Detlef > > > > Hi Detlef, I've already sent a similar patch, see http://www.winehq.org/pipermail/wine-patches/2009-February/069647.html

1 0

Re: [13/13] fusion: Add tests for the IAssemblyEnum interface.
by Paul Vriens Feb. 19, 2009

Feb. 19, 2009

Hans Leidekker wrote: > -Hans > > > ------------------------------------------------------------------------ > > Hi Hans, These tests crash on Vista with .NET 3.5 (not sure about other platforms/.NET versions yet). The enum_gac_assemblies function relies on the fact that ffd.cFileName contains 2 underscores. On Vista however I see some assemblies with a different format for the cFileName like: 6.0.0.0_en_31bf3856ad364e35 This explains the (first) crash as we dereference a pointer. So doing something like this fixes that piece: else if (depth == 1) { - ptr = strstr(ffd.cFileName, "__"); + CHAR version[MAX_PATH]; + + lstrcpyA(version, ffd.cFileName); + ptr = strstr(version, "_"); *ptr = '\0'; - ptr += 2; + ptr = strrchr(ffd.cFileName, '_'); + ptr += 1; sprintf(buf, "Version=%s, Culture=neutral, PublicKeyToken=%s", - ffd.cFileName, ptr); + version, ptr); This seems to work fine but than it crashes again while trying to free the memory "HeapFree(GetProcessHeap(), 0, asmname->data);" in test_enumerate. Just ignoring those HeapFree's doesn't fix it as we crash again later on. -- Cheers, Paul.

2 3

Re: [4/5] dxgi: Convert DXGI_FORMAT values to WINED3DFORMAT values.
by Stefan Dösinger Feb. 19, 2009

Feb. 19, 2009

Am Donnerstag, 19. Februar 2009 17:03:37 schrieb Henri Verbeet: I haven't looked at all the different formats yet, just a general question: Why did you choose to keep the WINED3D formats and not use the DXGI formats in wined3d? I'm not saying that there's anything wrong with that, I'm just curious what lead to that decision. I was inclined to do it the other way around, mostly because of the generic and specific(ie SINT, UINT, SRGB) formats in DXGI.

2 1

Re: msctf/tests: Don't import uuid library cause it could break crosstest
by Austin English Feb. 19, 2009

Feb. 19, 2009

On Thu, Feb 19, 2009 at 9:21 AM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Changelog: > - Don't import uuid library cause it could break crosstest > > >From 26890998dc20bd31c2d23b8b59dfaf664ca98dc0 Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Thu, 19 Feb 2009 10:20:32 -0500 > Subject: Don't import uuid library cause it could break crosstest > > --- > dlls/msctf/tests/Makefile.in | 2 +- > dlls/msctf/tests/inputprocessor.c | 1 + > 2 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/msctf/tests/Makefile.in b/dlls/msctf/tests/Makefile.in > index 669f5a1..0d7aba8 100644 > --- a/dlls/msctf/tests/Makefile.in > +++ b/dlls/msctf/tests/Makefile.in > @@ -3,7 +3,7 @@ TOPOBJDIR = ../../.. > SRCDIR = @srcdir@ > VPATH = @srcdir@ > TESTDLL = msctf.dll > -IMPORTS = uuid ole32 user32 kernel32 > +IMPORTS = ole32 user32 kernel32 > > CTESTS = \ > inputprocessor.c > diff --git a/dlls/msctf/tests/inputprocessor.c b/dlls/msctf/tests/inputprocessor.c > index 200a0d4..2e71eec 100644 > --- a/dlls/msctf/tests/inputprocessor.c > +++ b/dlls/msctf/tests/inputprocessor.c > @@ -33,6 +33,7 @@ static ITfInputProcessorProfiles* g_ipp; > static LANGID gLangid; > > DEFINE_GUID(CLSID_FakeService, 0xEDE1A7AD,0x66DE,0x47E0,0xB6,0x20,0x3E,0x92,0xF8,0x24,0x6B,0xF3); > +DEFINE_GUID(CLSID_TF_InputProcessorProfiles, 0x33c53a50,0xf456,0x4884,0xb0,0x49,0x85,0xfd,0x64,0x3e,0xcf,0xed); > > static HRESULT initialize(void) > { > -- > 1.5.6.5 > > > > > AJ beat you to it: http://source.winehq.org/git/wine.git/?a=commitdiff;h=cd656fa7f68bc86f78be2… -- -Austin

2 1

Re: msctf/tests: Don't import uuid library cause it could break crosstest
by Paul Vriens Feb. 19, 2009

Feb. 19, 2009

Nikolay Sivov wrote: > Changelog: > - Don't import uuid library cause it could break crosstest > >>From 26890998dc20bd31c2d23b8b59dfaf664ca98dc0 Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Thu, 19 Feb 2009 10:20:32 -0500 > Subject: Don't import uuid library cause it could break crosstest > > --- > dlls/msctf/tests/Makefile.in | 2 +- > dlls/msctf/tests/inputprocessor.c | 1 + > 2 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/dlls/msctf/tests/Makefile.in b/dlls/msctf/tests/Makefile.in > index 669f5a1..0d7aba8 100644 > --- a/dlls/msctf/tests/Makefile.in > +++ b/dlls/msctf/tests/Makefile.in > @@ -3,7 +3,7 @@ TOPOBJDIR = ../../.. > SRCDIR = @srcdir@ > VPATH = @srcdir@ > TESTDLL = msctf.dll > -IMPORTS = uuid ole32 user32 kernel32 > +IMPORTS = ole32 user32 kernel32 > > CTESTS = \ > inputprocessor.c > diff --git a/dlls/msctf/tests/inputprocessor.c b/dlls/msctf/tests/inputprocessor.c > index 200a0d4..2e71eec 100644 > --- a/dlls/msctf/tests/inputprocessor.c > +++ b/dlls/msctf/tests/inputprocessor.c > @@ -33,6 +33,7 @@ static ITfInputProcessorProfiles* g_ipp; > static LANGID gLangid; > > DEFINE_GUID(CLSID_FakeService, 0xEDE1A7AD,0x66DE,0x47E0,0xB6,0x20,0x3E,0x92,0xF8,0x24,0x6B,0xF3); > +DEFINE_GUID(CLSID_TF_InputProcessorProfiles, 0x33c53a50,0xf456,0x4884,0xb0,0x49,0x85,0xfd,0x64,0x3e,0xcf,0xed); > > static HRESULT initialize(void) > { Hi Already fixed in Git: http://source.winehq.org/git/wine.git/?a=commit;h=cd656fa7f68bc86f78be21c67… -- Cheers, Paul.

1 0

Re: msctf crosstest build failed
by Nicolas Le Cam Feb. 19, 2009

Feb. 19, 2009

2009/2/19 Nikolay Sivov <bunglehead(a)gmail.com>: > Nicolas Le Cam wrote: >> >> 2009/2/18 Nikolay Sivov <bunglehead(a)gmail.com>: >> >>> >>> Building today crosstests I've got: >>> >>> i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include >>> -g -O2 -o inputprocessor.cross.o inputprocessor.c >>> i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include >>> -g -O2 -o testlist.cross.o testlist.c >>> i586-mingw32msvc-gcc inputprocessor.cross.o testlist.cross.o -o >>> msctf_crosstest.exe -L../../../dlls -L../../../dlls/uuid >>> -L../../../dlls/ole32 -L../../../dlls/user32 -L../../../dlls/kernel32 >>> -luuid -lole32 -luser32 -lkernel32 >>> inputprocessor.cross.o: In function `initialize': >>> /home/mrlarch/wine-git/dlls/msctf/tests/inputprocessor.c:41: undefined >>> reference to `_CLSID_TF_InputProcessorProfiles' >>> collect2: ld returned 1 exit status >>> make[2]: *** [msctf_crosstest.exe] Error 1 >>> make[2]: Leaving directory `/home/mrlarch/wine-git/dlls/msctf/tests' >>> make[1]: *** [msctf/tests/__crosstest__] Error 2 >>> make[1]: Leaving directory `/home/mrlarch/wine-git/dlls' >>> make: *** [dlls/__crosstest__] Error 2 >>> >>> This outputs after: >>> make clean >>> ./configure >>> make depend && make >>> make crosstest >>> >>> What seems to be a problem? >>> >>> >>> >>> >> >> Same here. Can't find a solution. >> Perhaps it's because libuuid exports the CLSID as >> CLSID_TF_InputProcessorProfiles instead of >> _CLSID_TF_InputProcessorProfiles but I don't know how to fix. >> > > It's normal, is a kind of naming convention, don't know how to call it > right, but it's ok. >> >> Does building it with winegcc instead of ar / ranlib could fix the problem >> ? >> > > Native test builds without any problem. What do you mean? > As I checked uuid isn't imported anywhere else in test suite, inline guid > definitions used instead. > So if nobody knows why this happens I propose to patch msctf/tests not to > use uuid. > Now I'm setting up a system with rather fresh Lenny, so you could send this > patch. > > Just found that Alexandre committed something related to that last year. It seems to be a problem with MingW, see [1]. I will send a fix this evening. [1] http://source.winehq.org/git/wine.git/?a=commit;h=79c64acc7b5f9f9de07592fec…

2 1

msctf crosstest build failed
by Nikolay Sivov Feb. 19, 2009

Feb. 19, 2009

Building today crosstests I've got: i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -o inputprocessor.cross.o inputprocessor.c i586-mingw32msvc-gcc -c -I. -I. -I../../../include -I../../../include -g -O2 -o testlist.cross.o testlist.c i586-mingw32msvc-gcc inputprocessor.cross.o testlist.cross.o -o msctf_crosstest.exe -L../../../dlls -L../../../dlls/uuid -L../../../dlls/ole32 -L../../../dlls/user32 -L../../../dlls/kernel32 -luuid -lole32 -luser32 -lkernel32 inputprocessor.cross.o: In function `initialize': /home/mrlarch/wine-git/dlls/msctf/tests/inputprocessor.c:41: undefined reference to `_CLSID_TF_InputProcessorProfiles' collect2: ld returned 1 exit status make[2]: *** [msctf_crosstest.exe] Error 1 make[2]: Leaving directory `/home/mrlarch/wine-git/dlls/msctf/tests' make[1]: *** [msctf/tests/__crosstest__] Error 2 make[1]: Leaving directory `/home/mrlarch/wine-git/dlls' make: *** [dlls/__crosstest__] Error 2 This outputs after: make clean ./configure make depend && make make crosstest What seems to be a problem?

3 4

Need help on couple of patches
by Igor Tarasov Feb. 19, 2009

Feb. 19, 2009

Hello! I've written 2 patches, and I need advice on both of them. First one is here: http://www.winehq.org/pipermail/wine-patches/2009-February/069463.html It's a single-line patch that adds forwarding notification that was omitted in wine code. This fix looks pretty simple, but it included lots of reading/testing/debugging, and here is what I came with. And as I told there it fixes one wine bugzilla bug. But as I see, it was not comitted, so I am asking for advice: what could I do in order to make it go through? Another patch is here: http://bugs.winehq.org/show_bug.cgi?id=12701 The patch adresses 3 problems that all together fix that bug. My question there was if I should send it in one patch or in several. But it seems that no one have noticed that post. Any help and advice is appreciated. Thanks.

5 10

Re: [8/9] setupapi: implement SetupPromptForDiskA by wrapping around W version
by Juan Lang Feb. 19, 2009

Feb. 19, 2009

Hi Ricardo, + DialogTitleW = MultiByteToUnicode(DialogTitle, CP_UTF8); You should be using CP_ACP here, not CP_UTF8. Same applies to remaining character conversions. In fact, you could use strdupAtoW instead. --Juan

2 1

Wine & viruses
by Martin Hinner Feb. 19, 2009

Feb. 19, 2009

Hi, I will start one more hot discussion. Sorry if it was discussed earlier, I am not regular reader of this mailing-list. I tried to search google, found several discussions, but no real result: http://www.linux.com/feature/42031 http://www.vnunet.com/vnunet/news/2116150/linux-experts-wine-virus https://bugs.launchpad.net/ubuntu/+source/wine/+bug/256880 wine-devel mailing list google results The problem is that some (almost all?) distributions simply execute .exe file when you click on it. I was amazed when testing JTAGTest on Linux! This is in my opinion quite big issue as ordinary users do not have problem clicking on "New folder.exe" on their flashdisk etc. It's good that wine is so compatible that it runs even viruses, but I think there should be some (optional) protection. The biggest problem seem to be removable media, in many distributions mounted under /mnt or /media. Please think about this twice before writing "problem is in Microsoft not in Wine", "it's not a bug but feature", etc. It's too childish IMO. - What about creating a configurable list of directories, where wine would first ask if you really want to execute the program? It would be up to distribution what is set-up by default. - It's long time I have been interested in viruses, but I think that 90% of most common virus infected/trojan .exe files can be pretty easily identified. Almost every modern virus is trying to connect to the internet either by opening socket or using few standard DLL functions. What about adding some checks to Wine that would check the calling function code sample against some small database to see if this is a virus and ask user? Or adding some "API" functions to allow someone to write such program? I have done quite a lot of work with PE loading and code modification and I think it could be moved to level when it works without crashing anything. I understand, that none of this is system solution. But are anti-viruses system solution? They solve real world problem. Regarding API I have mentioned above I mean some hookdll() function that would re-direct GetProcAddress() or PE loader for defined functions, i.e.: http://www.codeguru.com/cpp/w-p/dll/hooking/article.php/c3639 http://www.codeguru.com/cpp/w-p/dll/hooking/article.php/c127 Obviously this would have to be global for wine (libwine.so?), not as a PE exported API function. Pre-loaded "antivirus" would be able to hook Winsock functions + some other important stuff and then check if the binary code is not on the list. Martin

9 13

Re: [1/9] setupapi: add header information for SetupPromptForDisk
by Juan Lang Feb. 19, 2009

Feb. 19, 2009

Hi Ricardo, > dlls/setupapi/setupapi_private.h | 11 +++++++++++ > include/setupapi.h | 14 +++++++++----- I'd suggest you have the changes to setupapi.h as one patch on their own. The changes to setupapi_private.h can be combined with the changes to the .rc file (patch 2 in your series), along with your patch to create the new dialog.c file (patch 3 in your series), and your patch to create a do-nothing dialog (patch 4 in your series.) In this way, each patch has a single functional change. If you do it as I suggest, patch 1 will change the public header file. Patch 2 will introduce a new dialog. The remaning patches seem split appropriately, so you'd end up with a 7 patch series. --Juan

1 0

Re: Wine64 - msvcrt dll test fix
by Ricardo Filipe Feb. 19, 2009

Feb. 19, 2009

this was commited already today. :) http://source.winehq.org/git/wine.git/?a=shortlog 2009/2/18 Juan M. Navarro <juan.m.navarro(a)gmail.com> > Resending as plain text. > > Thanks, > Juan > > On Tue, Feb 17, 2009 at 12:19 PM, Juan M. Navarro > <juan.m.navarro(a)gmail.com> wrote: > > Hello all! > > > > This is my first patch ever, and first open source contribution ever. > > > > The strlen function returns a size_t that represents an unsigned int in > > 32-bit environments, and an unsigned long in 64-bit environments. The > strlen > > function call has been changed to an lstrlen function call, which always > > returns an integer. > > > > I am a grad student at UCLA that has just started working on porting Wine > to > > 64-bit environments. > > > > I attest to not having seen any Microsoft source, or dissasembling > > Microsoft's DLL's. > > > > Thanks, > > > > Juan > > > >

1 0

Re: Status of USB driver support?
by emiliano esposito Feb. 18, 2009

Feb. 18, 2009

Alexander Morozov wrote: >> If that USB Key is not of a supportable kind, then I apologize for >> asking. >> > > I think you should try. > Thanks. I tried this way: git clone git://source.winehq.org/git/wine.git ~/wine-git git-am 0001... git-am 0002... ./tools/wineinstall When launching a Wine application, I get some errors, I think this is the important one: err:winedevice:ServiceMain driver L"Usbhub" failed to load I have installed the Key driver but not yet added the registry keys. Should I do that or something else first? Thanks.

1 0

Status of USB driver support?
by Dan Kegel Feb. 18, 2009

Feb. 18, 2009

Is http://wiki.winehq.org/USB up to date? I could have sworn that Alexander Morozov had submitted a new version of his patch, but I can't find it.

5 7

re: WINEGATE.DLL: Wine gateway to native Unix libraries
by Dan Kegel Feb. 18, 2009

Feb. 18, 2009

Very interesting. I'd been suggesting to ISVs that they create a single winelib dll and conditionally load that if present, but winegate.dll might be an appealing alternative. I don't think this really brings up any security considerations but it is a reminder that Windows programs under Wine have access to the entire Linux system just like Linux programs do. btw nice name, but it pulls up 7 million hits for me, not sure what you mean by "google doesn't reveal any other uses of the name". - Dan

8 17

Re: ntdll: Replace malloc() with RtlAllocateHeap()
by Rob Shearman Feb. 18, 2009

Feb. 18, 2009

2009/2/17 Andrew Talbot <andrew.talbot(a)talbotville.com>: > Changelog: > ntdll: Replace malloc() with RtlAllocateHeap(). > > diff --git a/dlls/ntdll/server.c b/dlls/ntdll/server.c > index 145540f..0cade3f 100644 > --- a/dlls/ntdll/server.c > +++ b/dlls/ntdll/server.c > @@ -743,13 +743,13 @@ static void setup_config_dir(void) > struct stat st; > char *tmp_dir; > > - if (!(tmp_dir = malloc( p + 1 - config_dir ))) fatal_error( "out of memory\n" ); > + if (!(tmp_dir = RtlAllocateHeap( GetProcessHeap(), 0, p + 1 - config_dir ))) fatal_error( "out of memory\n" ); > memcpy( tmp_dir, config_dir, p - config_dir ); > tmp_dir[p - config_dir] = 0; > if (!stat( tmp_dir, &st ) && st.st_uid != getuid()) > fatal_error( "'%s' is not owned by you, refusing to create a configuration directory there\n", > tmp_dir ); > - free( tmp_dir ); > + RtlFreeHeap( GetProcessHeap(), 0, tmp_dir ); > } I'd be surprised if this worked, since setup_config_dir is called very early in the ntdll execution sequence, and RtlAllocateHeap itself will depend on server calls (NtAllocateVirtualMemory, NtCreateMutex, etc.) that depend on the server having started (i.e. after this function having already executed). -- Rob Shearman

1 0

Re: winetest: Annotate xmalloc() and xrealloc() with allocation size attribute.
by Steven Edwards Feb. 18, 2009

Feb. 18, 2009

On Tue, Feb 17, 2009 at 12:51 PM, Francois Gouget <fgouget(a)free.fr> wrote: > --- > > I moved them after the windows.h include though in practice the needed > winnt.h has already been included by the time we include winetest.h. So > maybe windows.h should be nuked altogether... Conversely maybe using windows.h usage should be fixed and used more often. Wine is an oddball when it comes to win32 program with the excessive lengths it goes to, to avoid using windows.h. I am starting to think even avoiding it internally like we do causes more harm than good as far as being source compatible with MSVC. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

3 6

Re: [02/12] fusion: Add tests for the IAssemblyEnum interface.
by Alexandre Julliard Feb. 18, 2009

Feb. 18, 2009

Hans Leidekker <hans(a)codeweavers.com> writes: > Some tests in James' original patch failed here, which I have fixed. I still see failures: ../../../tools/runtest -q -P wine -M fusion.dll -T ../../.. -p fusion_test.exe.so asmenum.c && touch asmenum.ok asmenum.c:430: Test failed: Expected "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=123456789abcdef0" or "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d", got "wine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d" asmenum.c:573: Test failed: Expected "wine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d", got "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=123456789abcdef0" asmenum.c:586: Test failed: Expected "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=123456789abcdef0" or "wine, Version=1.0.1.2, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d", got "wine, Version=1.0.0.0, Culture=neutral, PublicKeyToken=16a3fcd171e93a8d" make[2]: *** [asmenum.ok] Error 3 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [5/6]wininet: handle cookie expiration
by Alexandre Julliard Feb. 18, 2009

Feb. 18, 2009

Aric Stewart <aric(a)codeweavers.com> writes: > + LPCWSTR ptr,ptr2; > + SYSTEMTIME tm; > + int i; > + > + memset(&tm,0,sizeof(tm)); > + > + ptr = expiry; > + for (i = 0; i < 7; i++) > + { > + if (strncmpiW(day[i],ptr,3)==0) > + { > + tm.wDayOfWeek = i; > + break; > + } > + } > + ptr += 5; > + tm.wDay = strtolW(ptr,(LPWSTR*)&ptr2,10); > + ptr = ptr2+1; You should handle the various possible parsing errors, not just assume that you have a well-formatted string. -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: oleaut32(2/3): Implement VarDecFix
by Dmitry Timoshkov Feb. 18, 2009

Feb. 18, 2009

"Juan Lang" <juan.lang(a)gmail.com> wrote: > + hr = VarR8FromDec((DECIMAL *)pDecIn, &dbl); According to PSDK VarR8FromDec() takes a const pointer to the 1st parameter, to it should be fixed instead of casting const out. Same for VarDecInt() patch. -- Dmitry.

1 0

Re: kernel32: add tests for recasing files
by Dmitry Timoshkov Feb. 18, 2009

Feb. 18, 2009

"Austin English" <austinenglish(a)gmail.com> wrote: > + /* create a temporary file */ > + uUnique = GetTempFileNameA(tempdir, "pfx", 0, source); > + ok(uUnique != 0, "GetTempFileNameA error %d\n", GetLastError()); > + > + /* get the same filename as above with upper case > + prefix and without creating any file */ > + ret = GetTempFileNameA(tempdir, "PFX", uUnique, dest); > + ok(ret != 0, "GetTempFileNameA error %d\n", GetLastError()); > + > + /* MoveFile should be able to change the case of the letters */ > + ret = MoveFileA(source, dest); > + todo_wine { > + ok(ret, "MoveFileA: failed, error %d\n", GetLastError()); > + } The comment above about expected MoveFile behaviour is incorrect since the test doesn't test what it implies. What most likely happens is that MoveFile should be a noop if source and destination file names are the same, and in that case 'MoveFileA(source, source);' is enough to test. -- Dmitry.

1 0

Re: advapi32: GetNamedSecurityInfoExA Stub
by Dmitry Timoshkov Feb. 18, 2009

Feb. 18, 2009

"Paul Bryan Roberts" <pbronline-wine(a)yahoo.co.uk> wrote: > I guess this stub falls in to the 'not obviously correct' category. > > I could do with some feedback on what might be an acceptable patch. It appears that GetNamedSecurityInfoExA signature doesn't match the MSDN/PSDK one. Also it's a common practice to simultaneously add both A and W versions, and add prototypes to an appropriate .h file. -- Dmitry.

3 5

Re: kernel32: Free profile before reloading
by Michael Karcher Feb. 17, 2009

Feb. 17, 2009

Am Dienstag, den 17.02.2009, 09:19 +0100 schrieb Michael Karcher: > Should fix bug #17050 Doesn't do. Please ignore.

1 0

Re: GSoC 2009 coming up
by Kai Blin Feb. 17, 2009

Feb. 17, 2009

On Tuesday 17 February 2009 04:41:11 Brian Vincent wrote: > On Sat, Feb 14, 2009 at 2:39 AM, Kai Blin <kai.blin(a)gmail.com> wrote: > > We should also investigate possible changes to the requirements (weekly > > reports to the mailing list come to mind). Maarten, any comments? > > My gut instinct was weekly reports would be a bad idea for students - of > course they're just going to procrastinate until the last month and then do > all the work at once. Yes, Kai, I realize you were the exception to that > rule. That's not going to work anyway. There's a mid-term evaluation you're going to get failed at if you didn't produce anything until the mid-term. :) > Then my second thought was: "Hey, if this was the real world their manager > would certainly be expecting progress reports. Therefore mentors should > too." And, it makes for simple updates to include for WWN issues. I > think it'd be interesting to weekly or bi-weekly reports, but I think > mentors will need to apply a little tactful pressure in order to get the > status report updates. My biggest motivation for requiring weekly status updates is that in the past years I had a hard time following the GSoC projects I was not involved with directly. At WorldForge, we required weekly reports to the mentor at first and then decided that the weekly reports should go to the developer mailing list. That kept everybody informed what was going on. Also, if the weekly reports don't only include "that's what I did last week" but also "this is my plan for the next week", students can get early feedback if whatever they're planning to do next looks like a bad idea to some other developer. It also helps integrating the students in the community, as they're not only talking to their mentor. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

2 1