November 2007 - Wine-Devel - list.winehq.org

winetest.exe broken
by Stefan Leichter Nov. 9, 2007

Nov. 9, 2007

Hello, as you all may have noticed winetest.exe does not longer build (see http://quisquiliae.physics.gla.ac.uk/crossbuild-logs/20071109-11:05.txt ). The patch: 65d865d96313d96889bf8cbe88c931b5e1e9bb74 is first bad commit commit 65d865d96313d96889bf8cbe88c931b5e1e9bb74 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Thu Nov 8 12:21:10 2007 +0100 libwine: Refuse to use a WINEPREFIX dir owned by a different user. :040000 040000 1bf2b5da793741040732f222ce4a90ebd3f54b74 ee36bfdcf5d65ec8bb1c8ee478e74e0af8679039 M libs broke the build. Can someone please fix this. Thanks Stefan

3 2

Re: [6/15] WineD3D: Replace the position fixup mul-add-add with a MAD
by Mirek Slugeň Nov. 9, 2007

Nov. 9, 2007

3 3

notepad crashes in VNC @ 16bpp
by Francois Gouget Nov. 9, 2007

Nov. 9, 2007

So if I start a VNC server with the following command: vncserver :1 -depth 16 -geometry 1024x768 Then notepad crashes on startup while initializing OpenGL. More precisely the crash happens in X11DRV_WineGL_InitOpenglInfo() on line 304 of winex11.drv/opengl.c. The reason for the crash is an OpenGL/X11 assertion: glxcmds.c:343: CreateContext: Assertion "mode != ((void *)0)" failed This seems like a VNC/OpenGL/X11 bug because Wine works fine if VNC is started in 15bpp or 24bpp. Still, the problem is that as this is part of the winex11 initialization it impacts all applications (including the DIB conformance tests). Does anyone see a way to avoid the crash? (maybe detect VNC before that call, but how?) Note: I'm using VNC 4.1.1+X4.3.0-2. Here's the xdpyinfo output in that mode: name of display: :1.0 version number: 11.0 vendor string: The XFree86 Project, Inc vendor release number: 40300000 XFree86 version: 4.3.0 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 2 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 keycode range: minimum 8, maximum 255 focus: window 0x400013, revert to Parent number of extensions: 23 BIG-REQUESTS DEC-XTRAP DOUBLE-BUFFER Extended-Visual-Information FontCache GLX LBX MIT-SCREEN-SAVER MIT-SHM MIT-SUNDRY-NONSTANDARD RECORD SECURITY SGI-GLX SHAPE SYNC TOG-CUP VNC-EXTENSION X-Resource XC-APPGROUP XC-MISC XFree86-Bigfont XTEST XVideo default screen number: 0 number of screens: 1 screen #0: dimensions: 1024x768 pixels (260x195 millimeters) resolution: 100x100 dots per inch depths (2): 1, 16 root window id: 0x2e depth of root window: 16 planes number of colormaps: minimum 1, maximum 1 default colormap: 0x21 default number of colormap cells: 64 preallocated pixels: black 0, white 65535 options: backing-store YES, save-unders YES largest cursor: 1024x768 current input event mask: 0xd83f3f KeyPressMask KeyReleaseMask ButtonPressMask ButtonReleaseMask EnterWindowMask LeaveWindowMask Button1MotionMask Button2MotionMask Button3MotionMask Button4MotionMask Button5MotionMask ButtonMotionMask SubstructureNotifyMask SubstructureRedirectMask PropertyChangeMask ColormapChangeMask number of visuals: 8 default visual id: 0x24 visual: visual id: 0x24 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0xf800, 0x7e0, 0x1f significant bits in color specification: 8 bits visual: visual id: 0x25 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0x3f, 0x7c0, 0xf800 significant bits in color specification: 8 bits visual: visual id: 0x26 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0x3f, 0x7c0, 0xf800 significant bits in color specification: 8 bits visual: visual id: 0x27 class: TrueColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0x3f, 0x7c0, 0xf800 significant bits in color specification: 8 bits visual: visual id: 0x28 class: DirectColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0x3f, 0x7c0, 0xf800 significant bits in color specification: 8 bits visual: visual id: 0x29 class: DirectColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0x3f, 0x7c0, 0xf800 significant bits in color specification: 8 bits visual: visual id: 0x2a class: DirectColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0x3f, 0x7c0, 0xf800 significant bits in color specification: 8 bits visual: visual id: 0x2b class: DirectColor depth: 16 planes available colormap entries: 64 per subfield red, green, blue masks: 0x3f, 0x7c0, 0xf800 significant bits in color specification: 8 bits -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

1 0

Re: wininet: make a test pass on all versions of windows
by Alexandre Julliard Nov. 9, 2007

Nov. 9, 2007

"Lei Zhang" <thestig(a)google.com> writes: > + > + { > + OSVERSIONINFOEX foo; > + BOOL r; > + memset(&foo, 0, sizeof(foo)); > + foo.dwOSVersionInfoSize = sizeof(foo); > + r = GetVersionEx((OSVERSIONINFO *) &foo); > + if (!r) > + { > + skip("could not get windows version\n"); > + return; > + } > + > + is_sp1 = -1; > + if (foo.dwMajorVersion > 5) > + is_sp1 = 1; > + else if (foo.dwMajorVersion == 5) > + { > + if (foo.dwMinorVersion > 1) > + is_sp1 = 1; > + else if (foo.dwMinorVersion == 1) > + { > + if (foo.wServicePackMajor > 1) > + is_sp1 = 1; > + else if (foo.wServicePackMajor == 1) > + is_sp1 = 0; > + } > + } Please don't add version checks in tests. -- Alexandre Julliard julliard(a)winehq.org

2 2

None
by Colin M Inglis Nov. 9, 2007

Nov. 9, 2007

Hi! I'm trying to install Wine for a client, a Mac house, who run some software only supported under Windows or Classic. With the recent introduction of Intel Macs (that no longer support Classic) into the business, the Windows version is, unfortunately, their only upgrade path. I have C development experience and am familiar with compiling C applications under unix, although that was some years ago and processes seem to have changed somewhat. In particular, I am unfamiliar with the 'configure' executable described in your installation manual, which is raising an error. Could you please look briefly at the attached config.log? I would be interested to know if this is an issue to which I can attend, or whether it is a deficiency in the configuration process itself. I would also appreciate a workaround, if possible. Thanks in anticipation of your assistance. Regards, ////////// // // / / Colin M Inglis BInfoTech&Comm //////////// // // / / Software Application Development /// //\//\\ infinite 15 Jasmine St, Strathpine, Q, Australia // // // // Snailmail PO Box 2188 Strathpine Q 4500 /// \\//\// interface email manager(a)infinitei.com.au ///////// // // / / web http://www.infinitei.com.au ////// // // / / Ph/Fax +61 7 3881 3494 ABN: 40 030 880 342 Mobile +61 414 388 134 "infinite interface programmes programmes users use"

5 4

Valgrind results for Oct 8: lots of hangs?!
by Dan Kegel Nov. 9, 2007

Nov. 9, 2007

Data online at http://kegel.com/wine/valgrind/20071108/ For some reason, today I had to do 'wineserver -k' about five times (yesterday and the day before only once). And one of those times was during a d3d9 test which took over / hung the screen; not even ctl-alt-backspace helped, I actually had to reboot (I didn't try ssh'ing in). Running the tests was like pulling teeth. That said, here are the changes in the list of bad tests; - means test didn't show any valgrind errors today but did yesterday, + means it did show valgrind errors today but not yesterday. -vg-d3d9_visual.txt (might be one I had to reboot for) -vg-iphlpapi_iphlpapi.txt -vg-mlang_mlang.txt +vg-mshtml_dom.txt +vg-mshtml_htmldoc.txt +vg-shdocvw_webbrowser.txt -vg-wininet_ftp.txt -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

re: #winehq admin troubles
by Dan Kegel Nov. 9, 2007

Nov. 9, 2007

Luke Bratch wrote: > After seeing Vitamin deal with people for a long time > now, I can say I totally agree with how he does > things. Technically, he's spot on. It's his bedside manner that is broken. We really don't want him on the front line of support, somebody else should do that. But once the newbies are filtered out, he's great. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

5 5

Re: wininet: check the return value from HeapAlloc in a test
by Alexandre Julliard Nov. 9, 2007

Nov. 9, 2007

"Lei Zhang" <thestig(a)google.com> writes: > We should skip a test if HeapAlloc() fails. There's no need to clutter up the tests with allocations checks, if we are out of memory pretty much everything in the test is going to fail anyway. -- Alexandre Julliard julliard(a)winehq.org

1 0

valgrind results updated
by Dan Kegel Nov. 9, 2007

Nov. 9, 2007

I've updated http://kegel.com/wine/valgrind/ Today's results are at http://kegel.com/wine/valgrind/20071103/ The only difference from yesterday is I've added suppressions for the most common memory leaks, on the theory that it's easier to see the module-specific leaks that way. (I haven't looked to see if they're false positives, so I named them todo* to remind us to look at them again later.) As always, there are leaks and uninitialized memory references aplenty! Step right up, no waiting...

2 2

Successful Virtualization startup looking for engineers with system level Windows and Linux experience
by Richard Offer Nov. 9, 2007

Nov. 9, 2007

We are a well-funded software startup in the virtualization space that is looking to hire several engineers with system level experience in Windows and Linux - ideally in combination. I can't tell you what you'd be doing but you can be re-assured that since we are long-term open source supporters any modifications to Wine or WineLib that you make will, of course, be contributed back to the community. We are particularly interested in experiences in the areas of * Registry modification, manipulation and creation * Windows internals or system level user-space. Device drivers aren't very interesting to us. * Reverse engineering skills * Installable file systems * Windows server technologies such as IIS, AD, 2003, Longhorn etc * Virtualization technologies such as VMware, AppStream, Softricity and Xen. If you or anyone you know have an interest and are eligible for working an a small but rapidly growing company in Silicon Valley on things that are novel and technically challenging, please send a current resume to engr-jobs(a)fastscale.com - including WSE in the subject line of any emails. For more information on the company, our technology and shipping products please visit us at http://www.fastscale.com/ Yours truly, Richard Offer

1 0

Re: wininet: skip strcmp() in a test if the returned len is wrong
by Dmitry Timoshkov Nov. 9, 2007

Nov. 9, 2007

"Lei Zhang" <thestig(a)google.com> wrote: > We'll skip doing strcmp() on a potentially uninitialized buffer if the > returned length is wrong. > - todo_wine ok(!strcmp(useragent,buffer),"Got wrong user agent string %s instead of %s\n",buffer,useragent); > - todo_wine ok(len == strlen(useragent),"Got wrong user agent length %d instead of %d\n",len,lstrlenA(useragent)); > + len_ok = (len == strlen(useragent)); > + todo_wine ok(len_ok,"Got wrong user agent length %d instead of %d\n",len,lstrlenA(useragent)); > + if (len_ok) > + todo_wine ok(!strcmp(useragent,buffer),"Got wrong user agent string %s instead of %s\n",buffer,useragent); Probably a better solution would be to actually check the return value of InternetQueryOption before touching the returned buffers. -- Dmitry.

1 0

valgrind/urlmon & http/variable question
by Misha Koshelev Nov. 9, 2007

Nov. 9, 2007

> Hi Dan et al., > > So I just wanted to let you know that I have looked somewhat at one (the only as far as I saw) of the valgrind results related to HttpProtocol in urlmon, and basically it involves passing a pointer to a PROTOCOLDATA from a local variable inside a function to the ProtocolSink call which ends up > sending a message with this pointer. When this pointer is processed later, since it is a pointer to a local variable which (presumably) exists only on the stack, it is not really valid. > > Now this is quite easy to "fix" with a five-line patch that HeapAlloc's the proper structures. However, I was trying to figure out how native does this to copy it, and kind of ran into a dilemma. Namely, doing a simple patch like shown below (this probably won't really be a diff as I copy/pasted it > into WebMail which will probably mess it up, but it should give a general idea) and then doing a WINEDLLOVERRIDES with native urlmon and wininet and +relay WINEDEBUG I can see that the the PROTOCOLDATA pointers are pointing to stuff like 0x7d7ad790 and 0x7d7ad820. Now, much to my suprise, these > addresses, nor addresses in the proximate range (approximate) to that address don't seem to be part of any other relay calls, including any calls to any sort of allocation functions. Now this leaves me a little stumped ,as I can only see a few ways to properly implement these PROTOCOLDATA pointers > (without a memory leak): > > 1. A static PROTOCOLDATA variable (local or global). In this case, the address I see for native should never change I believe, but also this would not be correct as potentially you could have more than one HttpProtocol using the same structure. > > 2. Dynamic allocation of the PROTOCOLDATA structure. This seems like the best option to me, but native either does not seem to be using it or allocates it in some way in which the address or even partial versions of the address does not appear in any allocation functions (or really anywhere) in the > +relay log. Any ideas on what allocation functions I could be missing here? > > 3. Have one PROTOCOLDATA structure per IInternetProtocol implementation of http. This seems reasonable too, except I am also printing out the address of the IInternetProtocol structure and clearly PROTOCOLDATA is not in an address range anywhere near this structure, and it is never allocated so it > can't be a pointer within that structure. > > So anyhow I am a little stuck on the "proper" fix for this. Any suggestiosn would be appreciated. > > Thanks, > > Misha Hmm... so it looks like upon investigation the address ranges for PROTOCOLDATA with antive dlls are actually suspiciously similar to those I see in the current local variable implementation... which makes me think that the implementation is dissimilar (and thus leaky) in the downstream ProtocolSink implementation in binding.c, which will be a little harder to test... Misha

1 0

Problem with client manually starting services
by Roy Shea Nov. 8, 2007

Nov. 8, 2007

Howdy All, I'm developing missing services in Wine and am running into problems with how Wine starts services. In Windows a service can be started using "net start <service name>", assuming that the service is properly added to the registry. In Wine it appears that the user must manually start the service before calling "net start <service name>", or the service fails to start. This is blocking me from developing an svchost wrapped DLL. I guess its not surprising that the work around of first manually starting a service fails for a DLL with no main function :-) Dan Kegel mentioned a recollection of a known bug in Wine along these lines where, as a work around, clients are manually starting servers. Anyone know more details on this problem? Any pointers to old emails or knowledge of this problem would be a big help I start digging through WINEDEBUG logs. Thanks! -Roy

2 4

Re: [1/6] WineD3D: Only glBindAttribLocation used attributes
by Mirek Slugeň Nov. 8, 2007

Nov. 8, 2007

2 6

Re: WineD3D: flush gl buffers are blt to drawable [attempt2]
by Stefan Dösinger Nov. 8, 2007

Nov. 8, 2007

Am Donnerstag, 8. November 2007 23:40:18 schrieb Roderick Colenbrander: > Hi, > > This patch makes sure the gl buffer is flushed after blitting to the > screen. This fixes bug 9826 where traces of old frames appeared due to > this. You really shouldn't do this unconditionally, it is only needed if two contexts are drawing to the same drawable. A suggestion would be to mark the first use of a 2nd thread in a device in FindContext, and call the glFlush only if happened. The same glFlush is needed in all other places that draw something to the drawable: drawprim, clear and BltOverride come to my mind.

1 0

Typing Chinese Online On FireFox
by Jiang,Yi Nov. 8, 2007

Nov. 8, 2007

I developped a site for Typing Chinese Online: http://www.typingChinese.com. It works on FireFox, IE, Mac. On test, I found FireFox is the fastest and used much less memory! Regards to all, Jiang,Yi

1 0

Develop .h for Wine by looking Microsoft Platform SDK
by Pau Garcia i Quiles Nov. 8, 2007

Nov. 8, 2007

Hello, How legal (if at all) would be to develop a header file by looking reading the corresponding header file from the Microsoft Platform SDK and adapting it to gcc (removing MSVC stuff, etc)? I'm interested in supporting annotations[*] and before I start deducting everything from MSDN documentation, I'd like to know if there is a fast track. [*] More information: http://msdn2.microsoft.com/en-us/library/aa383701.aspx http://msdn2.microsoft.com/en-us/library/ms235402(VS.80).aspx Thank you. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer)

4 4

valgrind/urlmon & http/variable question
by Koshelev, Misha Vladislavo Nov. 8, 2007

Nov. 8, 2007

Hi Dan et al., So I just wanted to let you know that I have looked somewhat at one (the only as far as I saw) of the valgrind results related to HttpProtocol in urlmon, and basically it involves passing a pointer to a PROTOCOLDATA from a local variable inside a function to the ProtocolSink call which ends up sending a message with this pointer. When this pointer is processed later, since it is a pointer to a local variable which (presumably) exists only on the stack, it is not really valid. Now this is quite easy to "fix" with a five-line patch that HeapAlloc's the proper structures. However, I was trying to figure out how native does this to copy it, and kind of ran into a dilemma. Namely, doing a simple patch like shown below (this probably won't really be a diff as I copy/pasted it into WebMail which will probably mess it up, but it should give a general idea) and then doing a WINEDLLOVERRIDES with native urlmon and wininet and +relay WINEDEBUG I can see that the the PROTOCOLDATA pointers are pointing to stuff like 0x7d7ad790 and 0x7d7ad820. Now, much to my suprise, these addresses, nor addresses in the proximate range (approximate) to that address don't seem to be part of any other relay calls, including any calls to any sort of allocation functions. Now this leaves me a little stumped ,as I can only see a few ways to properly implement these PROTOCOLDATA pointers (without a memory leak): 1. A static PROTOCOLDATA variable (local or global). In this case, the address I see for native should never change I believe, but also this would not be correct as potentially you could have more than one HttpProtocol using the same structure. 2. Dynamic allocation of the PROTOCOLDATA structure. This seems like the best option to me, but native either does not seem to be using it or allocates it in some way in which the address or even partial versions of the address does not appear in any allocation functions (or really anywhere) in the +relay log. Any ideas on what allocation functions I could be missing here? 3. Have one PROTOCOLDATA structure per IInternetProtocol implementation of http. This seems reasonable too, except I am also printing out the address of the IInternetProtocol structure and clearly PROTOCOLDATA is not in an address range anywhere near this structure, and it is never allocated so it can't be a pointer within that structure. So anyhow I am a little stuck on the "proper" fix for this. Any suggestiosn would be appreciated. Thanks, Misha --- diff --git a/dlls/urlmon/tests/protocol.c b/dlls/urlmon/tests/protocol.c index 00335b3..5b3579b 100644 --- a/dlls/urlmon/tests/protocol.c +++ b/dlls/urlmon/tests/protocol.c @@ -295,7 +295,9 @@ static HRESULT WINAPI ProtocolSink_Switch(IInternetProtocolSink *iface, PROTOCOL } SET_EXPECT(ReportData); + printf("!!! Continue %p -->\n", pProtocolData); hres = IInternetProtocol_Continue(http_protocol, pProtocolData); + printf("!!! Continue <--\n"); ok(hres == S_OK, "Continue failed: %08x\n", hres); CHECK_CALLED(ReportData); @@ -1255,6 +1257,7 @@ static void test_http_protocol_url(LPCWSTR url, BOOL is_first) hres = IClassFactory_CreateInstance(factory, NULL, &IID_IInternetProtocol, (void**)&http_protocol); ok(hres == S_OK, "Could not get IInternetProtocol: %08x\n", hres); + printf("!!! IInternetProtocol: %p %p\n", http_protocol, http_protocol+sizeof(IInternetProtocol)); if(SUCCEEDED(hres)) { BYTE buf[3600]; DWORD cb;

1 0

Re: d3dxof: return correct value for IDirectXFileDataImpl_GetType
by Roderick Colenbrander Nov. 8, 2007

Nov. 8, 2007

> IDirectXFileDataImpl_GetType should return DXFILEERR_BADVALUE on failure, > not S_FALSE > > This patch fixes bug 10355 > > http://msdn2.microsoft.com/en-us/library/bb174490.aspx > Sure this could fix that bug but it not a real fix. D3dxof.dll is mostly a stub and its real functionality (loading and parsing of .x files) is missing. This GetType function is also related to the parsing of the .x file. In short this file contains data and some 'templates' for describing the data. This function returns the guid of that template. Returning a failure is not really an option in my opion as it won't get the app working. For the time being you should a native d3dxof.dll should be used or the rest of the .x file parsing should be added. Roderick -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger

2 1

Bugs in dlls/wsock32/socket.c
by Gerald Pfeifer Nov. 8, 2007

Nov. 8, 2007

dlls/wsock32/socket.c has the following code: DWORD routeTableSize, numRoutes, ndx, ret; numRoutes = min(routeTableSize - sizeof(MIB_IPFORWARDTABLE), 0) / sizeof(MIB_IPFORWARDROW) + 1; The problem here is that both routeTableSize and sizeof(...) are of an unsigned type, so their difference is also unsigned. Which means that the minimum between that difference and 0 always will be 0, the result of the division will thus always be zero, and the result of the entire expressions is a constant 1. I have a hunch this is not the intendend purpose of this code, is it? Gerald -- Gerald (Jerry) Pfeifer gerald(a)pfeifer.com http://www.pfeifer.com/gerald/

2 2

Re: #winehq admin troubles
by feba thatl Nov. 8, 2007

Nov. 8, 2007

Tom, you can try to guilt me, but I don't care. There are two sides to this. Either you think that #winehq is a support channel for end users, and should if not cater to them, at least treat them with some respect until they've proved that they deserve none, or you think that #winehq is a channel where people can go for help if some one with an @ isn't in a mood to ban them. If you can honestly say that you fully agree with the latter, and would have no problem getting banned from a random channel when you were seeking help, I don't know what to tell you. If, however, you think the first thing, we're on the same side. I don't think anyone here doesn't want to see #winehq, and the entire project really, become a better place. There might be one or two people exploiting this for personal reasons, but I cannot control that. I posted this in the hopes that #winehq would be made a better place, not for me, but for everyone. Including vitamin and the rest of the ops. I have a question for you, what offends you so much about my comments that you are not only refusing to help me, but also trying to pin me with the blame for your refusal to help others? Is it because you feel that your experience with wine gives you to the right to mistreat users, or because you are offended by what a few other people said in a thread that I started? Do you not want #winehq to be a better place? Or do you not realize the actual point of what I'm saying?

1 0

Re: svchost: Implementation of svchost
by Robert Shearman Nov. 8, 2007

Nov. 8, 2007

Roy Shea wrote: > Changelog: > * Implementation of svchost > You've got a lot of global functions in this patch that should be static. -- Rob Shearman

1 0

Re: wininet: Fully initialize a variable
by Alexandre Julliard Nov. 8, 2007

Nov. 8, 2007

"Juan Lang" <juan.lang(a)gmail.com> writes: > static void COOKIE_crackUrlSimple(LPCWSTR lpszUrl, LPWSTR hostName, int hostNameLen, LPWSTR path, int pathLen) > { > - URL_COMPONENTSW UrlComponents; > + URL_COMPONENTSW UrlComponents = { 0 }; > > - UrlComponents.lpszExtraInfo = NULL; > - UrlComponents.lpszPassword = NULL; > - UrlComponents.lpszScheme = NULL; > UrlComponents.lpszUrlPath = path; > - UrlComponents.lpszUserName = NULL; > UrlComponents.lpszHostName = hostName; > UrlComponents.dwHostNameLength = hostNameLen; > UrlComponents.dwUrlPathLength = pathLen; Please avoid that unportable array initialization syntax, and since the code is already explicitly setting the fields you should simply add the ones that are needed and missing. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wininet: initialize a buffer
by Alexandre Julliard Nov. 8, 2007

Nov. 8, 2007

"Lei Zhang" <thestig(a)google.com> writes: > Valgrind is complaining we are doing strcmp() on the buffer without > initializing it. You should fix the code to not do the strcmp when we don't have a valid buffer, instead of hiding the bug by clearing memory. -- Alexandre Julliard julliard(a)winehq.org

1 0

Wine LivePC
by T.J. Purtell Nov. 7, 2007

Nov. 7, 2007

Hey, I've build a Wine LivePC so that people can take a linux operating system capable of running Windows programs on a USB drive. Its great for carrying a portable work environment with you, providing a container for safely running executables you download from the internet, or making an isolated environment for a family member that they can carry with them. http://www.moka5.com/node/1620 Obviously the LivePC is free, but registration on the site is required to download the free engine for using LivePC (Its based off VMware player). It has the latest version of Wine, so using this is an easy way to check if a particular application is well supported in Wine. Cheers, -T.J.

1 0