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

Re: Start DDE interface from Explorer Process. Add DDE stubs.
by Dmitry Timoshkov Feb. 15, 2009

Feb. 15, 2009

"Jeremiah Flerchinger" <jeremiah.flerchinger(a)gmail.com> wrote: > Explorer.exe now calls ShellDdeInit. Progman stubs will now be started/used in Shell32. > Amazingly any apps with a Progman DDE interface will also be called. Shell32 can handle > all major functionality, but a running progman.exe (for example) will be able to > synchronize internal values with changes made by Shell32. This patch just adds a lot of confusion and mess. As I suggested you should start with a simple test app and see how it really supposed to work. -- Dmitry.

2 1

Re: [2/3] WineD3D: Add a debug function for surface locations
by Henri Verbeet Feb. 15, 2009

Feb. 15, 2009

2009/2/14 Stefan Dösinger <stefan(a)codeweavers.com>: > +const char *debug_surflocation(DWORD flag) { > + switch(flag & SFLAG_LOCATIONS) { > + case SFLAG_INSYSMEM: return "SFLAG_INSYSMEM"; > + case SFLAG_INDRAWABLE: return "SFLAG_INDRAWABLE"; > + case SFLAG_INTEXTURE: return "SFLAG_INTEXTURE"; > + case SFLAG_INSRGBTEX: return "SFLAG_INSRGBTEX"; > + > + case SFLAG_INSYSMEM | SFLAG_INDRAWABLE: return "SFLAG_INSYSMEM | SFLAG_INDRAWABLE"; > + case SFLAG_INSYSMEM | SFLAG_INTEXTURE: return "SFLAG_INSYSMEM | SFLAG_INTEXTURE"; > + case SFLAG_INSYSMEM | SFLAG_INSRGBTEX: return "SFLAG_INSYSMEM | SFLAG_INSRGBTEX"; > + > + case SFLAG_INDRAWABLE | SFLAG_INTEXTURE: return "SFLAG_INDRAWABLE | SFLAG_INTEXTURE"; > + case SFLAG_INDRAWABLE | SFLAG_INSRGBTEX: return "SFLAG_INDRAWABLE | SFLAG_INSRGBTEX"; > + > + case SFLAG_INTEXTURE | SFLAG_INSRGBTEX: return "SFLAG_INTEXTURE | SFLAG_INSRGBTEX"; > + > + case SFLAG_INSYSMEM | SFLAG_INDRAWABLE | SFLAG_INTEXTURE: > + return "SFLAG_INSYSMEM | SFLAG_INDRAWABLE | SFLAG_INTEXTURE"; > + case SFLAG_INSYSMEM | SFLAG_INDRAWABLE | SFLAG_INSRGBTEX: > + return "SFLAG_INSYSMEM | SFLAG_INDRAWABLE | SFLAG_INSRGBTEX"; > + case SFLAG_INSYSMEM | SFLAG_INTEXTURE | SFLAG_INSRGBTEX: > + return "SFLAG_INSYSMEM | SFLAG_INTEXTURE | SFLAG_INSRGBTEX"; > + case SFLAG_INDRAWABLE | SFLAG_INTEXTURE | SFLAG_INSRGBTEX: > + return "SFLAG_INDRAWABLE | SFLAG_INTEXTURE | SFLAG_INSRGBTEX"; > + > + case SFLAG_INSYSMEM | SFLAG_INDRAWABLE | SFLAG_INTEXTURE | SFLAG_INSRGBTEX: > + return "SFLAG_INSYSMEM | SFLAG_INDRAWABLE | SFLAG_INTEXTURE | SFLAG_INSRGBTEX"; > + > + default: return "Unknown location flag combination"; > + } > +} I think using wine_dbg_sprintf() would be a lot more practical.

1 0

[patch] review requested: message-mode named pipes
by Luke Kenneth Casson Leighton Feb. 15, 2009

Feb. 15, 2009

http://bugs.winehq.org/attachment.cgi?id=19477 * functionality of non-message-mode (byte type) is preserved. * putting too many messages into the queue runs wineserver out of file descriptors, but the solutions to that are too much work for this revision, to be included, so - tough. * research indicates that message-mode is supposed to block when resources are low, but that would require a per-file mutex. again - too much work for this revision. l.

1 0

[patch but not quite ready] NamedPipes messagemode
by Luke Kenneth Casson Leighton Feb. 15, 2009

Feb. 15, 2009

http://bugs.winehq.org/show_bug.cgi?id=17195 with only one significant bug - some memory corruption - the semantics are now correct in the namedpipe messagemode patch. i drew a diagram outlining the data structures / design http://bugs.winehq.org/attachment.cgi?id=19449 because it's so horrendous that even i want to throw up. assistance in finding the memory corruption would be really helpful. an assert is thrown after more than 4 short reads are performed on the same namedpipe, with this straaaange error: ead: file.c:631: server_get_named_pipe_fd: Assertion `wine_server_ptr_handle(fd_handle) == handle' failed. ead: server.c:628: server_get_unix_fd: Assertion `wine_server_ptr_handle(fd_handle) == handle' failed. wine: Assertion failed at address 0xf7ca8d7f (thread 000f), starting debugger... err:ntdll:RtlpWaitForCriticalSection section 0x7bc99ee0 "server.c: fd_cache_section" wait timed out in thread 000f, blocked by 0014, retrying (60 sec) i'll try to write a simplified test because that's the "threadread" test on which this occurs. i can't quite believe that all 5 tests can be passed [by reducing the number of short reads to less than 4]. it's been a bit of a "drunken walk" development style, i'm afraid :) notes: * in order to preserve message-mode semantics correctly, each message gets ITS OWN socketpair. the socketpair is used EXCLUSIVELY for that one message and is NOT re-used by the other end. so if it's client writing to server, one message, that's one socketpair. if it's server writing to client, one message, that's another socketpair. if client writes 20 messages to server, that's 20 new socketpairs, if at same time server writes 25 messages to client, and nobody's done any reading yet, that's a total of 45 outstanding socketpairs - 90 filedescriptors. this is not a hoax. it's the only way i could think of that preserves messagemode semantics correctly. * for each end - client and server - to be able to "block", waiting at any time, there MUST be at LEAST one socketpair in each of the queues. so, initially, that's what's done: one pair of socketpairs are created, one for the client, one for the server. on the FIRST write (to server, or to client), this initial "empty" socketpair must be written to; subsequent writes (to server or to client, each) must have a NEW socketpair created. * on a read, a socketpair must "hang about" - MUST not be shut down - until there is a new one created (which happens only on a new write). in this way, multiple threads will always have a filedescriptor to block on. * when a read has read all available data, the socketpair is marked as "finished" but is NOT shut down. * on each write, if a new socketpair is created, then and ONLY then can "old" marked socketpairs be shut down. * shutdown of read-sockets, on which [potentially many] reader[s] are waiting will result in an EPIPE. this is an ACCEPTABLE error IFF no data has been read yet, i.e. at the start of a new message. what happens, basically, is that the "old" socketpair - even though it had been used already by the previous reader - is what the thread "blocks" on (because you have to block on _something_). and on the _very_ first message, of course, you block on the specially-prepared initial socketpair, the one that had to be created and marked as "as-yet unwritten to". * you can see at line 872 of ntdlls/file.c (after patch is applied) that oh whoopsie, EPIPE occurred, but we've not read any data at all, just grab another filedescriptor from wineserver and try again. in this way, wineserver hands out the next available message from the filedescriptor queue. if yet _another_ EPIPE occurs, then all that means is that another thread "got there first", wow big deal, around you go again. * indicating that data has been read is performed using a special wineserver message "NAMED_PIPE_SUB_AVAILDATA" using server_set_named_pipe_info(). this horrible hack passes information to wineserver telling it to subtract the amount of data read in userspace from the filedescriptor data structure (fdqueue) representing that socketpair. * indicating that data _will_ be available is performed again using server_set_named_pipe_info(), this time using a message "NAMED_PIPE_SET_AVAILDATA". the set is performed BEFORE the actual write, otherwise a reader will "unblock" and potentially try to set the available data to negative!!! this would be baaad. * a critical section is performed around all uses of server_set_named_pipe_info() and server_get_named_pipe_fd(). this is NOT the same critical section as server_get_handle_fd(). i don't know if this makes any difference. things that cannot be done: * you cannot do the read or the write inside wineserver (server_named_pipe_read() will be deleted, later). the reason is complex to describe, but boils down to "blocking in userspace on the socket in order to wait for a message" and "non-blocking read on the same socket in order to get the data" are unfortunately mutually incompatible. one screws up the other if you set or clear O_NONBLOCK. * you cannot send the length as a 4-byte "header" down the socket, to be read as a length and then that much data read out. if you have multiple readers blocking on the same filedescriptor, how do you make sure that only one of them reads the length?? they're all blocking on the same socket! send the length multiple times?? how do you know how many readers there are?? short answer: you can't. so - scratch that idea. [ok - maybe you could do a critical section, but you'd have to do one per file, and i'm not ready or willing to add an array of per-file-handle critical sections to ntdll without further discussion] issues: * multiple readers of the same socket, when reading data amounts that are larger than the SO_RCVBUF and/or SO_SNDBUF, could potentially end up corrupting the data because of overlaps in the reads. given that this is _already_ a problem, in the existing Wine code, i am not going to be dealing with this issue, in this iteration. particularly as solutions involve having to do per-file critical sections and YES that's a generic problem even on standard files not just pipes not just messagemode pipes ALL files. * running out of socketpairs; protecting the message queue length. i believe there's a default message queue length in NT, but even so, the number of file descriptors this [necessary] design uses up is _horrendous_. one pair per message! but - tough luck. the options are pretty limited and constrained by the requirements. so: if anyone says to me, "no this cannot work, you cannot _possibly_ have got correct messagemode semantics purely in userspace and without sending length fields, you _must_ do the reads and writes inside wineserver", then... well... that will be a good way to get me to unsubscribe from wine-devel. if anyone can think of any other ideas, or implementations, or optimisations, then... well... unless they're _really_ good ideas, they'll have to wait :) ideas such as using a separate socketpair for communicating "length" messages are welcome, if accompanied by well-laid-out explanations, because my brain is turning to jelly with this stuff and i could do with some light reading instead of working it out myself :) l.

2 4

Re: AppDB new design: Top 10s still look ugly
by André Hentschel Feb. 15, 2009

Feb. 15, 2009

Ricardo Filipe schrieb: > 2009/2/15 André Hentschel <nerv(a)dawncrow.de <mailto:nerv(a)dawncrow.de>> > > Ricardo Filipe schrieb: > > hi andré, > > alex didn't apply your patch. he just fixed the .css to give it the > > same style as it had before. > > > > 2009/2/15 André Hentschel <nerv(a)dawncrow.de > <mailto:nerv(a)dawncrow.de> <mailto:nerv(a)dawncrow.de > <mailto:nerv(a)dawncrow.de>>> > > > > Hello, > > Bug #16466 is declared as fixed. but it isnt. my patch should do > > something else. > > I wanted let each top 10 in its own color(platin, gold or > bronce) and > > not to have the platin-look for all. > > anything went wrong while using my patch. maybe the other patch > > went in, > > too? > > It should be this style: > http://www.funplugged.bplaced.net/appdb/ > > > > > > > Hi Ricardo, > but its not the same as before, look at my attachment in bug > #16466, do > you see something else then me? > > > it's not bug #16466 for sure :P > i don't really remember how it was before, and i'm not too fond of > having gold and silver apps with the white too, but it serves it's > function fine... > you'd better talk to alex on that to be sure what's the objective. sorry, it was #16442

1 0

AppDB new design: Top 10s still look ugly
by André Hentschel Feb. 15, 2009

Feb. 15, 2009

Hello, Bug #16466 is declared as fixed. but it isnt. my patch should do something else. I wanted let each top 10 in its own color(platin, gold or bronce) and not to have the platin-look for all. anything went wrong while using my patch. maybe the other patch went in, too? It should be this style: http://www.funplugged.bplaced.net/appdb/

2 2

Re: mshtml: Correctly test to see if PutProperty_CLASSIDPROP is called
by Alistair Leslie-Hughes Feb. 15, 2009

Feb. 15, 2009

Ignore this, the subject is wrong. "Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> wrote in message news:4997DB01.1000602(a)hotmail.com... > Hi, > > Changelog: > mshtml: Correctly test to see if PutProperty_CLASSIDPROP is called. > > Best Regards > Alistair Leslie-Hughes > > > > -------------------------------------------------------------------------------- > From 14267df8f532c7acc7cc184c3c1e020639ca8702 Mon Sep 17 00:00:00 2001 > From: Alistair Leslie-Hughes <leslie_alistair(a)hotmail.com> > Date: Fri, 6 Feb 2009 20:03:47 +1100 > Subject: [PATCH] Corrected tests > To: wine-patches <wine-patches(a)winehq.org> > > --- > dlls/urlmon/tests/url.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/dlls/urlmon/tests/url.c b/dlls/urlmon/tests/url.c > index c062cf8..e5895c4 100644 > --- a/dlls/urlmon/tests/url.c > +++ b/dlls/urlmon/tests/url.c > @@ -313,7 +313,7 @@ static DWORD WINAPI thread_proc(PVOID arg) > CHECK_CALLED(Obj_OnProgress_BEGINSYNCOPERATION); > CHECK_CALLED(CreateInstance); > CHECK_CALLED(PutProperty_MIMETYPEPROP); > - CLEAR_CALLED(PutProperty_CLASSIDPROP); > + CHECK_CALLED(PutProperty_CLASSIDPROP); > CHECK_CALLED(Load); > CHECK_CALLED(Obj_OnProgress_ENDSYNCOPERATION); > CHECK_CALLED(OnObjectAvailable); > @@ -612,7 +612,7 @@ static HRESULT WINAPI Protocol_Start(IInternetProtocol > *iface, LPCWSTR szUrl, > CHECK_CALLED(Obj_OnProgress_BEGINSYNCOPERATION); > CHECK_CALLED(CreateInstance); > CHECK_CALLED(PutProperty_MIMETYPEPROP); > - CLEAR_CALLED(PutProperty_CLASSIDPROP); > + CHECK_CALLED(PutProperty_CLASSIDPROP); > CHECK_CALLED(Load); > CHECK_CALLED(Obj_OnProgress_ENDSYNCOPERATION); > CHECK_CALLED(OnObjectAvailable); > -- > 1.5.4.3 > > -------------------------------------------------------------------------------- > >

1 0

Proposal: put Winetricks into Wine menu
by Dan Kegel Feb. 15, 2009

Feb. 15, 2009

I know, when I wrote Winetricks, I meant it as a developers' tool only. But... then... people started using it, and it made sense to provide it as a way to download missing visual C++ runtimes etc. for average users. Quite a few newbies trip over the fact that it needs cabextract installed. Let's make it easy for folks, actually package it up along with Wine (SuSE does this already), and put it in the Wine menu right beneath "Uninstall Windows Software". What do people think? It might make life easier for a lot of folks. (And, come to think of it, we should include some documentation in that menu. "man wine" just doesn't cut it for the average gui user, and "wine manual page" in the gnome help browser is a broken link. But that's a separate issue.) - Dan

3 4

Wine desktop integration: current directory of app launched with doubleclick?
by Dan Kegel Feb. 15, 2009

Feb. 15, 2009

I *almost* have a great success story to report; the only thing keeping it from being a success story is the current directory chosen by Nautilus when double-clicking on .exe files. My wife hurt a finger trying to impersonate a Sampsonite Luggage gorilla, and had to go to a hand doctor. Along the way her hand got x-rayed, and the doctor handed her a cd-rom with the x-ray pictures on it. The disc has an autorun.inf on it that should start ViewSel.exe. I don't know if that's supposed to work with Wine and Nautilus, but probably doubleclicking on ViewSel.exe does the same thing. ViewSel.exe puts up two big buttons: low res (which launches a web browser on an html file), and high res (which launches a DICOM viewer). If you cd to the root of the cd-rom drive and run ViewSel, it works. If the current directory is anything else, it doesn't work. If you start the autorun app via Nautilus, those buttons don't work, so presumably it sets the current directory to something other than the root of the drive. To see, I created a wrapper shell script, ~/bin/mywine, containing #!/bin/sh pwd > /tmp/log and used "Start with" to launch ViewSel.exe with ~/bin/mywine. This showed that the current directory was $HOME. I had a look at the gnome code to see how it decided, but it was a bit hard to follow. (See gnome_vfs_mime_application_launch_with_env.) So I tried a little shell magic. I created a new wrapper shell script that assumes the argument is a path to a file, and sets the current directory to the directory containing that file: #!/bin/sh DIR=`dirname "$1"` DIR=`cd "$DIR"; pwd` cd "$DIR" wine "$@" That worked better; it let ViewSel.exe launch the DICOM viewer. So... I suppose the next step is to look at the debian/ubuntu packages for wine and see if that little wrapper script could be incorporated into the default way file browsers start wine? It sure would be nice if apps that expected the current directory to behave like this (it's not uncommon!) Just Worked. - Dan

4 9

Re: [Bug 17104] Drives in winecfg can not be set correctly for paths containing non-latin (probably multibyte) characters. [utf-8]
by Austin English Feb. 14, 2009

Feb. 14, 2009

On Sat, Feb 14, 2009 at 5:59 PM, <wine-bugs(a)winehq.org> wrote: > http://bugs.winehq.org/show_bug.cgi?id=17104 > > > Vitaliy Margolen <vitaliy(a)kievinfo.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|RESOLVED |CLOSED > > > > > --- Comment #10 from Vitaliy Margolen <vitaliy(a)kievinfo.com> 2009-02-14 17:59:35 --- > Confirming fixed. > > Closing bug fixed in wine-1.1.15. > > > -- > Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email > Do not reply to this email, post in Bugzilla using the > above URL to reply. > ------- You are receiving this mail because: ------- > You are on the CC list for the bug. > Perhaps we should wait for bugs to be closed by AJ in the next release, even if they were fixed in a previous release? That way, they should up in the release notes. Dan brought it up on another bug, and I agree...but figured it should be brought up here. Thoughts? -- -Austin

2 1

Re: mshtml: allow REG_EXPAND_SZ values for GeckoCabDir
by Juan Lang Feb. 14, 2009

Feb. 14, 2009

Hi Christoph, - /* @@ Wine registry key: HKCU\Software\Wine\MSHTML */ - res = RegOpenKeyW(HKEY_CURRENT_USER, mshtml_keyW, &hkey); - if(res != ERROR_SUCCESS) - return FALSE; - file_name = heap_alloc(size+sizeof(GECKO_FILE_NAME)); - res = RegQueryValueExA(hkey, "GeckoCabDir", NULL, &type, (PBYTE)file_name, &size); + /* @@ Wine registry key: HKCU\Software\Wine\MSHTML */ + res = RegGetValueA(HKEY_CURRENT_USER, mshtml_keyA, "GeckoCabDir", RRF_RT_ANY, &type, (PBYTE)file_name, &size); This change is unrelated to the subject. One change per patch, please. + if(res != ERROR_SUCCESS || (type != REG_SZ && type != REG_EXPAND_SZ)) { heap_free(file_name); return FALSE; } If you're allowing REG_EXPAND_SZ, oughtn't you call ExpandEnvironmentVariablesA as well? --Juan

2 2

Re: Proposal: put Winetricks into Wine menu
by Dan Kegel Feb. 14, 2009

Feb. 14, 2009

So, for people packaging wine, here's a proposed plan: 0. See http://wiki.winehq.org/winetricks if you're not familiar with winetricks 1. Download http://www.kegel.com/wine/winetricks (or get it via svn, see http://code.google.com/p/winezeug ) It's a monolithic shell script, so you don't need to compile it or anything. 2. Move it to /usr/bin and do chmod +x /usr/bin/winetricks 3. Add a dependecy on cabextract, sha1sum, and wget or curl. 4. In your package's changelog, note which version of Winetricks you pulled down. You'll want to pull down a fresh one every time you package Wine, as it contains download URLs that occasionally go stale. (In particular, I need to update the gecko URL for wine-1.1.5, I'll do that today.) The Suse packages already do all the above steps, I think; you might ask Marcus Meissner if you want to confirm the details. Here's the part that I don't think anybody does yet: 5. Add a menu item under Applications / Wine that runs /usr/bin/winetricks. In Ubuntu, the existing menu items are Programs Browse C: Drive Configure Wine Uninstall Wine Software Assuming we name the menu item Winetricks, the menu would then look like Programs Browse C: Drive Configure Wine Uninstall Wine Software Winetricks Now, at some point we should come up with a better menu item name than Winetricks, but I have no idea how to sum it up properly. winetricks has a fair bit of name recognition, and requires no localization, so let's run with that name until we figure out what it should really be called, and what the GUI really should look like in the end. (We also need a menu item there for "Help Using Wine", but nobody's written that yet. It can't just be links to the FAQ, since it has to work while offline.) Sound good? - Dan

3 3

GSoC 2009 coming up
by Kai Blin Feb. 14, 2009

Feb. 14, 2009

Hi folks, the organization application period for GSoC 2009 is starting on March 9th, so it's time to get our http://wiki.winehq.org/SummerOfCode wiki page in shape again. Detlef Riekenberg and Roderick Colenbrander made a good start, so if the rest of you could check and make sure that all the projects on there still make sense? We should also investigate possible changes to the requirements (weekly reports to the mailing list come to mind). Maarten, any comments? 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

Re: Firefox 3 runs faster on Linux+Wine than on Linux -- comparative to running on Windows
by Susan Cragin Feb. 14, 2009

Feb. 14, 2009

>Hi, > >For those not monitoring slashdot [1], there is an article [2] that is >comparing the Google V8 benchmark on Windows and Linux versions of >Firefox 3. > >The result of this is that the Windows and Wine runs are pretty close >(241 vs 227) when compared to the Linux run (181) and Opera (155). > >I wonder what the results are like on Firefox 3.1 with tracemonkey >enabled on Windows, Wine and Linux. > >[1] http://tech.slashdot.org/article.pl?sid=09/02/13/0058251 >[2] http://www.tuxradar.com/content/browser-benchmarks-2-even-wine-beats-linux-… > >- Reece One thing that interested me... one person wrote that Linux/Firefox compiled with msvc was faster than gcc, because msvc is better at optimization. Has anyone tried compiling wine with msvc? Susan

3 2

msvcrt:file test failures under wine and winetest
by Austin Lund Feb. 13, 2009

Feb. 13, 2009

I've been playing around with the odd failure that occurs on some platforms for the msvcrt:file tests. http://test.winehq.org/data/6a1537c4b5037be5253c33021fda3a02430533f7/#group… I am able to recreate it on my computer running ubuntu 8.10. (tag: apl-u810-dell630) I was trying to nail down what exactly problem was when I found the following: $ ./programs/winetest/winetest -o out -c msvcrt:file 2> /dev/null && tail -n 8 out Test output: msvcrt:file start dlls/msvcrt/tests/file.c - file: 3 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 5 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 5 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 462 tests executed (0 marked as todo, 0 failures), 0 skipped. msvcrt:file done (0) It seemed to succeed when it was the only test run. I played around for a bit with this and found the combination of tests which causes the failure: $ ./programs/winetest/winetest -o out -c msvcrtd:debug msvcrt:file 2> /dev/null && tail -n 13 out Test output: msvcrtd:debug start dlls/msvcrtd/tests/debug.c - debug: 2 tests executed (0 marked as todo, 0 failures), 0 skipped. msvcrtd:debug done (0) msvcrt:file start dlls/msvcrt/tests/file.c - file: 3 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 1 tests executed (0 marked as todo, 0 failures), 0 skipped. file.c:1057: Test failed: fstat(stdin) failed: errno=2 file.c:1066: Tests skipped: stdin is not a char device? st_mode=100666 file: 5 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 5 tests executed (0 marked as todo, 0 failures), 0 skipped. file: 458 tests executed (0 marked as todo, 1 failure), 1 skipped. msvcrt:file done (1) Also of note is that when doing "make test" this failure never occurs. So whatever is going on, it is a strange interaction between msvcrtd:debug msvcrt:file tests and winetest. Another point to make is that the error that corresponds to errno=2 is "No such file or directory", which is an odd message for a filedes which is meant to be stdin. Does anyone have any tips on what to look at to nail this one down?

1 0

Firefox 3 runs faster on Linux+Wine than on Linux -- comparative to running on Windows
by Reece Dunn Feb. 13, 2009

Feb. 13, 2009

Hi, For those not monitoring slashdot [1], there is an article [2] that is comparing the Google V8 benchmark on Windows and Linux versions of Firefox 3. The result of this is that the Windows and Wine runs are pretty close (241 vs 227) when compared to the Linux run (181) and Opera (155). I wonder what the results are like on Firefox 3.1 with tracemonkey enabled on Windows, Wine and Linux. [1] http://tech.slashdot.org/article.pl?sid=09/02/13/0058251 [2] http://www.tuxradar.com/content/browser-benchmarks-2-even-wine-beats-linux-… - Reece

3 3

Re: atmlib: add stub dll
by Nikolay Sivov Feb. 13, 2009

Feb. 13, 2009

Austin English wrote: > Needed by photoshop cs4. See bug 16385. > > diff --git a/dlls/atmlib/atmlib_main.c b/dlls/atmlib/atmlib_main.c > new file mode 100644 > index 0000000..bb17989 > --- /dev/null > +++ b/dlls/atmlib/atmlib_main.c > @@ -0,0 +1,45 @@ > +/* > + * MSSIGN32 implementation > + * > + * Copyright 2009 Austin English > + * > Hi, Austin, not mssign32 ).

2 2

Re: wintrust(3/3): Fix a couple tests on a variety of systems
by Ge van Geldorp Feb. 13, 2009

Feb. 13, 2009

> From: Alexandre Julliard <julliard(a)winehq.org> > > Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > > > I sent out an email earlier to ask if we should include more > > information in the header of the report. We could use that > > information, if this change will be accepted by AJ, to > > limit the reporting only to boxes were we have admin rights. > > > > As soon as all boxes have zero failures (yeah, right) we > > can remove that limit. > > Yes, we will want to fix these tests eventually, since we > will some day support multi-user setups where normal users > won't have admin rights, and we will need tests to make sure > we fail the right way. But in the meantime we can certainly > block these reports and concentrate on the more meaningful failures. I'll take that as a hint to switch my test machines to full admin. Should result in quite a bit more green. Ge.

1 0

Re: [sane.ds try2 1/3] Get resolution from sane, instead of hard coding -1.
by Juan Lang Feb. 13, 2009

Feb. 13, 2009

Hi Jeremy, a couple comments: - pImageInfo->XResolution.Whole = -1; + if (sane_option_get_int(activeDS.deviceHandle, "resolution", &resolution) == SANE_STATUS_GOOD) + pImageInfo->XResolution.Whole = pImageInfo->YResolution.Whole = resolution; (snip) +/* Option functions */ +#ifdef SONAME_LIBSANE +SANE_Status sane_option_get_int(SANE_Handle h, const char *option_name, SANE_Int *val); +#endif With this change, sane.ds will not compile unless SONAME_LIBSANE is defined. Is this intended? More likely not, and you need to provide a version of sane_option_get_int when it isn't defined, or use an #ifdef at the call site (ick.) The other comment is, is adding a new file (option.c) really necessary? If you're planning to expand it a lot, perhaps, but just for this one small function it looks like overkill to me. --Juan

2 2

RFC: patch to advapi32's cred tests
by Juan Lang Feb. 13, 2009

Feb. 13, 2009

Hi all, I've written a patch which should fix the failing advapi32 cred tests that mirrors the skips in the existing tests: diff --git a/dlls/advapi32/tests/cred.c b/dlls/advapi32/tests/cred.c index 58103c6..bb6935b 100644 --- a/dlls/advapi32/tests/cred.c +++ b/dlls/advapi32/tests/cred.c @@ -238,7 +238,13 @@ static void test_generic(void) new_cred.UserName = (char *)"winetest"; ret = pCredWriteA(&new_cred, 0); - ok(ret, "CredWriteA failed with error %d\n", GetLastError()); + ok(ret || broken(GetLastError() == ERROR_NO_SUCH_LOGON_SESSION), + "CredWriteA failed with error %d\n", GetLastError()); + if (!ret) + { + skip("couldn't write generic credentials, skipping tests\n"); + return; + } ret = pCredEnumerateA(NULL, 0, &count, &creds); ok(ret, "CredEnumerateA failed with error %d\n", GetLastError()); I'm wondering whether a better patch would be to change the persist type from CRED_PERSIST_ENTERPRISE to CRED_PERSIST_LOCAL_MACHINE. Rob, this is particularly aimed at you since you wrote the original tests: is there a good reason to use CRED_PERSIST_ENTERPRISE here? --Juan

2 2

How to get more info on timed out/crashed tests?
by Juan Lang Feb. 13, 2009

Feb. 13, 2009

Hi all, there are a number of tests at test.winehq.org that indicate that they're timed out or crashed. The difficulty is, I have no access to machines running the version of Windows on which the test is timing out or failing, and the data about the crash are not helpful in pinpointing the failing test. How can we get more information about these timeouts/crashes? --Juan

3 3

RE: [1/2] gdiplus/tests: Some tests for Image raw format value
by Nikolay Sivov Feb. 13, 2009

Feb. 13, 2009

Anything wrong with that? http://www.winehq.org/pipermail/wine-patches/2009-February/069267.html http://www.winehq.org/pipermail/wine-patches/2009-February/069273.html

1 0

Re: wintrust(3/3): Fix a couple tests on a variety of systems
by Paul Vriens Feb. 13, 2009

Feb. 13, 2009

Juan Lang wrote: > --Juan > > > ------------------------------------------------------------------------ > > This is of course on boxes where people dont' run winetest as a administrator. I'm not sure if ERROR_ACCESS_DENIED is thus actually an acceptable failure. In other tests we have used skip() for this. -- Cheers, Paul.

4 5

Proposed goal for website: happily usable at 800x600?
by Dan Kegel Feb. 13, 2009

Feb. 13, 2009

What with netbooks with small screens abounding, it might make sense to review our web site and make sure its most important parts are usable in an 800x600 screen (easy to simulate, just resize your browser until xwininfo says it's 800x550, those gnome top and bottom bars chew 25 pixels each). That's asking a lot, I suppose... - Dan

7 9

Re: [PATCH] comdlg32: check for lfs NULL ptr (Coverity)
by Alexandre Julliard Feb. 13, 2009

Feb. 13, 2009

Marcus Meissner <marcus(a)jet.franken.de> writes: > CID 119, 188, resubmit with working patch from earlier round. > > I guess we could also just let it crash if this happens, but > I am not feeling comfortable. These are internal functions, it doesn't make sense to call them with NULL. -- Alexandre Julliard julliard(a)winehq.org

1 0