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

Re: winex11.drv: Map Super_L, Super_R, and Menu keys correctly.
by Rob Shearman Feb. 16, 2009

Feb. 16, 2009

2009/2/13 GerbilSoft <gerbilsoft(a)verizon.net>: > --- keyboard.c.orig 2009-02-12 11:50:28.110457529 -0500 > +++ keyboard.c 2009-02-12 11:52:06.061206978 -0500 You need to generate the patch from the top of the wine directory. You also need to use your real name for copyright-tracking purposes. -- Rob Shearman

1 0

[Fwd: Windows on Linux App of the Year]
by Jeremy White Feb. 16, 2009

Feb. 16, 2009

We've won the 'Windows on Linux' award of the year on LinuxQuestions.org again (by quite a large margin, I might add). Woohoo! Cheers, Jeremy

2 1

1.1.15 failing to build -- what changed?
by Scott Ritchie Feb. 15, 2009

Feb. 15, 2009

1.1.15 fails to build using an identical layout to 1.1.14, which means something has changed with either the build dependencies or the way configure is working. Here's the build failure I'm getting on amd64, but it fails on all arches: http://launchpadlibrarian.net/22606029/buildlog_ubuntu-intrepid-amd64.wine_… I'm going to sleep now, but hopefully I'll figure this out Valentine's day. In the meanwhile, 1.1.15 won't be available in Ubuntu packages just yet. Thanks, Scott Ritchie

5 12

Updated cebit presentation. Looking for ideas...
by Dan Kegel Feb. 15, 2009

Feb. 15, 2009

I've been slowly finishing my cebit presentation. The current draft is at http://kegel.com/cebit/ It now talks briefly about winetricks, and uses firefox and safari as examples of installing and running platinum and bronze apps. It also talks more about support, since a windows admin I showed it to said windows admins were generally scared of trying to support open source apps. If anyone has suggestions for how to make this presentation more appealing/informative/convincing to newbies who are only familiar with windows, please let me know. Also, if anyone can tell my why firefox doesn't show the Windows logo until you refresh sometimes, I'd be grateful. Maybe it's because the same image is used twice in the same page? - Dan

4 6

WINEGATE.DLL: Wine gateway to native Unix libraries
by Martin Hinner Feb. 15, 2009

Feb. 15, 2009

Hello, I have created a small library to allow Win32 applications running under Wine to load native Unix shared libraries (.so). First (one-hour hack) version is available at http://martin.hinner.info/tmp/winegate.tar.gz ; Please consider inclusion in WINE tree (dll/ directory). Please note that Makefile.in as well as configure scripts will likely need some changes. Purpose of this Wine DLL is to allow Windows applications to use directly Unix library functions. This is useful for example for applications which talk to specific drivers and it's not efficient/possible to create system native DLL for such driver or library. Win32 app. vendor is required only to detect execution under Wine and load proper native library. WinGate.DLL exports dlopen/dlsym/dlclose/dlerror functions which allow Windows app to load additional libraries and use them. This library should export all functions that are required to load additional libraries and detect type & version of system we're running on. I believe that NO additional functions are required as you can always import uname() and call it to obtain more information on the running system, so dlopen/dlsym/dlclose is enough. Maybe some 'getwineversion' function should be included - waiting for your comments. I am sure there will be a lot of people arguing that Win32 application SHOULD NOT be modified to behave differently in Wine. I agree that in most cases it's better to fix Wine than applications, but there are real world problems that cannot be efficiently solved outside the application. One good example is when Win32 app has to talk to custom hardware. In many cases there are native Linux drivers that have different API/etc and it is very very difficult to create wrapper library between Windows-style and Linux/Unix-style drivers. In such cases it's much easier to modify source code of Windows app to use either Linux or Windows drivers/DLLs/etc. Example how to use WINEGATE.DLL is in winesupp.zip (please note this is quite silly example). If you want to see real world application which uses this library, go to http://www.jtagtest.com I have chosen name Wingate because google did not reveal any other use of such name and I think it fits it's purpose. Feel free to suggest any other names or just rename the library. Martin

6 14

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