October 2003 - Wine-Devel - list.winehq.org

Re: UI bugs hampering porting effort for shaped window

by Rein Klazes

On Thu, 30 Oct 2003 10:59:40 -0800, you wrote: > > Hi Mike, > > bug 1541 is still *not* fixed correctly. See when passing in NULL in windows > to gethostbyname, it is guarenteed to return a list of local IP addresses > mapped on the box. However, with WINE, passing NULL causes gethostname to be > passed into gethostbyname and does *not* always return back the list of > local IP addresses on the box. When I implemented the case that name == NULL ( another call for help, I wasn't aware of your bug report, sorry), the only reference I could find was this: | If null is provided in the name parameter, the returned string is the same | as the string returned by a successful gethostname function call. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/wi… Small detail: gethostbyname does not return a string, but this is what I guessed the intention of the writer was. Can you point to any documentation where this guarantee is specified? Rein. -- Rein Klazes rklazes(a)xs4all.nl

Oct. 31, 2003

Re: New tarball of valgrind for WINE available

by Adam Gundy

At 23:26 29/10/2003 -0500, Dimitrie O. Paun wrote: >On October 29, 2003 08:44 am, Adam Gundy wrote: >> A new tarball of valgrind modified to work with WINE is available from the >> valgrind home page: >> >> http://developer.kde.org/~sewardj/ >> http://developer.kde.org/~sewardj/valgrind-20031012-wine.tar.bz2 >> >> this is based on the latest stable valgrind release. > >Any chance this will be merge into mainline valgrind? that looks unlikely at the moment :-( Seeya, Adam -- Real Programmers don't comment their code. If it was hard to write, it should be hard to read, and even harder to modify. These are all my own opinions.

Oct. 31, 2003

RE: bug 1541 (was: UI bugs hampering porting effort for shaped window)

by Mike Hearn

On Fri, 2003-10-31 at 00:51, Dan Kegel wrote: > getifaddrs() is indeed the right beast, though who knows, maybe you'll > have to filter out 127.0.0.1. Hitch is, Linux doesn't provide it. I think it does as of the latest glibc, at least it's marked as "done" on their TODO list. thanks -mike

Oct. 31, 2003

VirtualAllocEx

by Peter Hartshorn

Has there been any work on VirtualAllocEx for allocating memory to other processes? I would like to get this going to allow me to run mta:vc and blow away other people in gta vice city (I believe that is a noble cause). To get me started I have a question. Is there a mechanism for one wine process (thread?) to send a message to another process (thread?) and receive a response, ie a pointer? Or, can I use the wineserver as a mediator that passess messages between two wine processes? For example: app1 sends a message "allocate 1MB of virtual memory in app2" to the wineserver. The wineserver then tells app2 to "allocate 1MB of virtual memory". App2 replys to the wineserver the virtual location of the allocated memory. Wineserver replys to app1 giving the location. App1 can then use the result in WriteProcessMemory.

Oct. 31, 2003

Re: Using Serial Port COM1

by Uwe Bonnes

>>>>> "Orlando" == Orlando Feitosa <orlandof(a)novadutra.com.br> writes: Orlando> Hello Friends, I'm trying to use an application that access the Orlando> serial Port COM1 (which has a printer connected) Orlando> when application tries to communicate with the port I receive Orlando> the following message error "Privileged Instruction" Orlando> Here is the dump... (wine 20031016 - RedHat 9.0) Orlando> __________________________________________________________________________ Orlando> fixme:commctrl:FlatSB_SetScrollProp stub Do more debugging. Leasrn about --debugmsg and try to find out more. Start with --debugmsg +relay,+comm. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Oct. 31, 2003

Re: Misc wine debugging questions

by Gregory M. Turner

On Thursday 30 October 2003 04:16 pm, Mike Hearn wrote: > ncalrpc? The preferred transport for local-to-self RPC/DCOM communications. In NT it's implemented on top of "NT Ports" (see Undocumented NT), the advantge being that this is fast. This RPC transport (but not the NT ports themselves) is simulated using named pipes in wine. For example, see http://msdn.microsoft.com/library/default.asp?url=/library/en-us/midl/midl/… The whole family is nicely summarized here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/st… Sheesh, so much to do... it's enough to make me want to finish my cabinet work rather than confront it ;) BTW, note that transports like http, tcp, etc, could allow wine to do DCOM without resolving the "priveleged ports" issue (at least for fixed endpoints).... of course, our wire protocol is way off and will need fixing before that's possible... luckily I have archived the spec (enclosed for your amusement), which AFAIK fell off the 'net. Older revisions are available by searching (<a href="http://www.brassroots.org/google.html">do not Google!</a>) the 'net; the enclosed version was linked to by Don Box's delicious blog back when it existed at http://www.globecom.net/ietf/draft/draft-brown-dcom-v1-spec-03.html. -- gmt "To take from one, because it is thought his own industry and that of his fathers has acquired too much, in order to spare to others, who, or whose fathers, have not exercised equal industry and skill, is to violate arbitrarily the first principle of association, the guarantee to everyone the free exercise of his industry and the fruits acquired by it." --Thomas Jefferson

Oct. 31, 2003

Re: UI bugs hampering porting effort for shaped window

by Jerry Jenkins

Rob wrote: > Jerry's patch *does* fix the UI issues actually - B1 through B4 - any idea > why it isn't applied to the CVS tree? We have the version out of CVS, which > definately has issues with B1-B4. > I know it fixes B1, B2, and partially B4, but I'm not so sure about B3. WINAMP still has issue B4 even with my patch applied. The patch is a little tricky :-). I intended to place a button on the taskbar for a popup window. M$'s document says application windows and popup windows which not owned will be displayed on the taskbar - When I open the web page today, I found it says a button is placed on the taskbar for a windows that isn't owned without mentioning that it has WS_POPUP style, seems my mistake. As I happened to know that a managed window on WINE is displayed on the taskbar and noticed that WINDOWS wouldn't change a popup window's style to have it displayed on the taskbar, I changed these windows' managed state. But I am not sure that it is the right way to get things work.

Oct. 31, 2003

crossover office mentioned in current "HP World"

by Dan Kegel

HP World is HP's house rag, sent out free to everyone who buys anything from HP or attends their "HP World" show. Several times now they have used the Crossover Office that comes with SuSE Linux during a review of some product. On page 20 of the Nov 2003 issue, for instance, titled "POPping Up Terrabytes", they reviewed FIA's POPnetserver NAS 4600 model 720, and said in part "Configuration ... is about as simple as humanly possible. There is, however, one minor annoyance for a system designed to be experienced as an applince: All of the management software is designed to run on Windows, and only Windows. ... we were able to run -- albeit not completely-- POPassist on SuSE Linux Desktop with the help of CrossOver Office. The only glitch comes in actually fiding the POPnetserver. That function would not work, which left us manually inputting the new address e discovered with LiSA and My Network Places." - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Oct. 31, 2003

Using Serial Port COM1

by Orlando Feitosa

Hello Friends, I'm trying to use an application that access the serial Port COM1 (which has a printer connected) when application tries to communicate with the port I receive the following message error "Privileged Instruction" Here is the dump... (wine 20031016 - RedHat 9.0) __________________________________________________________________________ fixme:commctrl:FlatSB_SetScrollProp stub trace:comm:GetCommState handle 0x84, ptr 0x40851bac trace:comm:GetCommState OK trace:comm:GetCommState bytesize 8 baudrate 9600 fParity 1 Parity 0 stopbits 1 trace:comm:GetCommState IXON IXOFF trace:comm:GetCommState CRTSCTS trace:comm:SetCommState handle 0x84, ptr 0x40851bac trace:comm:SetCommState bytesize 8 baudrate 9600 fParity 1 Parity 0 stopbits 1 trace:comm:SetCommState IXON IXOFF trace:comm:SetCommState CRTSCTS trace:comm:SetCommTimeouts (0x84,0x10034a40) fixme:comm:SetupComm insize 2048 outsize 1024 unimplemented stub fixme:imm:ImmGetContext (0x4005e): stub ____________________________________________________________________________ Please, someone have idea how to solve the problem ? Bests Regards, Orlando

Oct. 31, 2003

RE: bug 1541 (was: UI bugs hampering porting effort for shaped window)

by Dan Kegel

Mike Hearn (mike_at_theoretic.com) wrote: > On Thu, 2003-10-30 at 18:59, Rob wrote: >> bug 1541 is still *not* fixed correctly. See when passing in NULL in windows >> to gethostbyname, it is guarenteed to return a list of local IP addresses >> mapped on the box. However, with WINE, passing NULL causes gethostname to be >> passed into gethostbyname and does *not* always return back the list of >> local IP addresses on the box. This may work on some boxes, and not others, >> depending on how the machine is configured and if the DNS lookup on the host >> name resolves to the local IP addresses. > > Ah OK, sorry about that, I reopened the bug. Would getifaddrs() do the > trick here? I've not done much work in our winsock code so I can't > really help here. > >> whereas if (!name) should use SIOCGIFCONF - SIOCGIFADDR or something... > > Could you write a patch perhaps, as you seen to know what needs to be > done. getifaddrs() is indeed the right beast, though who knows, maybe you'll have to filter out 127.0.0.1. Hitch is, Linux doesn't provide it. Here's an implementation I've used with good results that tries to be portable (I've only tested it on linux, but it claims to handle Solaris): http://kegel.com/dkftpbench/dkftpbench-0.45/getifaddrs.h http://kegel.com/dkftpbench/dkftpbench-0.45/getifaddrs.c Wish I had time to code a patch for you, too, but at least this might help. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Oct. 31, 2003