- Wine-Devel - list.winehq.org

Re: Wine fixes
by Dimitrie O. Paun April 16, 2004

April 16, 2004

On April 16, 2004 12:16 am, Dimitrie O. Paun wrote: > IMO should just nuke some of these useless includes. > How can we test that they are really needed? Oops, sorry folks, this message was meant for the AbiWord guys! :) -- Dimi.

1 0

Re: abnt2 keyboard patch
by Rafael Ávila de Espíndola April 16, 2004

April 16, 2004

> I still see problems with your patch. > > 1. You are using 'keysym == 0x2C' for comma, but what happens if NumLock > is on, and you press comma on the main keyboard, not on the keypad? > Shouldn't X11 send XK_KP_xxx event in that case (something like XK_KP_Decimal)? The file /usr/include/X11/keysymdef.h has the line #define XK_KP_Separator 0xFFAC /* separator, often comma */ This appears to be appropriate. But X11 is not sending it in debian (sid) or fedora. The output from xev when, with the numlock initially off, I press comma, kp_comma, numlock, comma and kp_comma is: KeyPress event, serial 22, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69979707, (124,72), root:(364,205), state 0x0, keycode 59 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69979799, (124,72), root:(364,205), state 0x0, keycode 59 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyPress event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69980420, (124,72), root:(364,205), state 0x0, keycode 91 (keysym 0xff9f, KP_Delete), same_screen YES, XLookupString gives 0 bytes: "" KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69980521, (124,72), root:(364,205), state 0x0, keycode 91 (keysym 0xff9f, KP_Delete), same_screen YES, XLookupString gives 0 bytes: "" KeyPress event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69980955, (124,72), root:(364,205), state 0x0, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES, XLookupString gives 0 bytes: "" KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69981057, (124,72), root:(364,205), state 0x10, keycode 77 (keysym 0xff7f, Num_Lock), same_screen YES, XLookupString gives 0 bytes: "" KeyPress event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69981755, (124,72), root:(364,205), state 0x10, keycode 59 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69981850, (124,72), root:(364,205), state 0x10, keycode 59 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyPress event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69982436, (124,72), root:(364,205), state 0x10, keycode 91 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," KeyRelease event, serial 27, synthetic NO, window 0x2c00001, root 0x3f, subw 0x0, time 69982535, (124,72), root:(364,205), state 0x10, keycode 91 (keysym 0x2c, comma), same_screen YES, XLookupString gives 1 bytes: "," > 2. Please generate unified diffs, 'using diff -u' for patches. Sorry. I am really embarrassed. An unified diff is attached. > > -- > Dmitry. Rafael

2 1

Re: dlls/kernel/console.c::SetConsoleCtrlHandler() cleanup/fixup
by Dimitrie O. Paun April 16, 2004

April 16, 2004

On April 15, 2004 11:18 am, Peter Riocreux wrote: > * This doesn't yet matter, since these handlers are not yet called...! > + * > + * Peter Riocreux (par(a)silistix.com) 2004-04-15 > + * Added error checking and now uses SetLastError() > */ One more thing: please don't add this sort of thing, it belongs in the CVS log, not in the source code. -- Dimi.

1 0

Re: [D3D8] Add support for vertex shader (using ARB_vertex_program extension)
by Christian Costa April 15, 2004

April 15, 2004

Maxime Bellengé wrote: >Hi Christian > >Are you looking for someone to test the patch on an NVIDIA card ? >If you tell me how to test or the game to run, I can give you a >feedback. > >a+ > >Max > > > Hi Maxime, You can try the vertexblend, vertexshader & dolphinvs demos from the DX8 SDK. You can switch between HAL to REF devices to see the difference. Thanks for testing! :-) Bye, Christian

1 0

RE: More serial access issues
by Geoffrey Hausheer April 15, 2004

April 15, 2004

Well, after tracing the events through wineserver, I see 'serial_queue_event' gets called, serial_get_poll_events returns 'POLLOUT', async_notify gets called (but async->thread->wait is 0, so it doesn't do anything besides setting the status to STATUS_ALERTED. The secod serial_get_poll_events returns 0 (due to the status no longer being STATUS_PENDING), but this doesn't really matter as the 'register_async' call doesn't create a reply. Back in my application, __register_async does not reset u.Status (since 'ret' is 0), which means that 'finish_async' never gets called, which appears to be the only way that FILE_AsyncWriteService can be called (which actually does the write) ,and no data is written to the serial port. It all seems to operate as the code dictates, so I'm not sure what the right fix is. It would seem to me that something is not working right in __register_async. Perhaps finish_async should not be gated by 'u.Status'? Or u.Status should unconditionally be set equal to 'ret'? The second seems more likely to me, as that is the only way the WriteFile could return TRUE (in fact I see no way that WriteFile could return true in today's code, regardless of what the server does (since u.Status can only be changed from STATUS_PENDING if ret != 0 (and STATUS_SUCCESS == 0), so u.Status can never equal STATUS_SUCCESS. I am having a lot of difficulty understanding exactly what the server call is doing (I think it is checking that it is clear to write to the Serial port, though it seems to be awfully complex if that is all). Also, I don't know what the conditions are under which finish_async should be called. I changed the code to unconditionally set u.Status = ret, and WriteFile is no longer returning an error, but this didn't help (I'm never seeing FILE_AsyncWriteService get called, because call completion is disabled). So it looks like there are several points that are preventing FILE_AsyncWriteService from being called, and maybe I'm barking up the wrong tree. I can see a few possibilities: (1) some other routine is supposed to do the write, and I'm missing it, or (2) the server is supposed to do the write (perhaps via asyncy_notify?), in which case I don't see any place where the write buffer is passed to the server, or (c) the server is supposed to tell the client to do the write (again by async_notify?), in which case, I'm not seeing how that works. This code seems to run around in circles to me. .Geoff -----Original Message----- From: Geoffrey Hausheer Sent: Wednesday, April 14, 2004 2:05 PM Subject: More serial access issues Well, I broke down and pulled out the oscope and rs232 breakout box to try to figure out why my app isn't able to communicate with the device. turns out that Rein's patch is correctly deasserting DSR, however, I am not getting any data over the Tx pin. And after I checked the output of WriteFile, it is failing. GetLastError doesn't return anything useful (a value of 997 which FormatMessage() can't do anything with). But some debugging led me to determine that NtWriteFile is returning 0x103 which is STATUS_PENDING. After that I'm somewhat lost as to what is going on. Obvioulsy, 'register_new_async' is returning this status, which apparently happens when wine_server_call returns 0 or STATUS_PENDING (not sure if the second is even possible). But about here I am getting completely confused as to what we are trying to accomplish. The file is opened via: CreateFile("COM1", 0, NULL, OPEN_EXISTING, 0, NULL) so we're not in overlapped mode. SetCommTimeout is called with the COMMTIMEOUTS structure containing all 0s. All flow control is disabled using SetCommState. Before a write, we always call 'PurgeComm' and ClearCommError. In Windows, this combination results in a write always occurring when WriteFile is called, regardless of whether there is anything connected to the serial port. Wine appears to be waiting for something, and I'm not sure what. If anyone has any ideas how I might proceed, i'd be glad to hear them. Thanks, .Geoff

1 0

Compiling MFC with latest CVS checkout.
by Manjunath Sripadarao April 15, 2004

April 15, 2004

I am trying to compile MFC with latest CVS checout, I copied the source from the windows MFC dir and also the include dir (both for MFC and the VC98 include dir). I ran winemaker --interactive . and specified the -I paths. I got a couple of makefiles. Now if I do a make I get this error. [manju(a)manju MSVS]$ make make[1]: Entering directory `/home/manju/MSVS/mfc/src' wineg++ -mwindows -mno-cygwin -o mfcdb.so mfcdb.res mfcdb.dbg.o -lodbc32 -lole32 -loleaut32 -lwinspool -luuid mfcdb.exe-ueIUVp.spec.c:451: error: invalid conversion from `void (*)()' to ` void*' winegcc: gcc failed. make[1]: *** [mfcdb.so] Error 2 make[1]: Leaving directory `/home/manju/MSVS/mfc/src' make: *** [mfc/src] Error 2 Any ideas/tips. Am I even following the correct procedure ? There doesn't seem to be any document detailing this process. Any tips/instructions/suggestions would be greatly appreciated. I am doing this on a fedora core 1 (with prelink fixed and stuff, wine runs well), with a 2 Ghz P4 machine. If any other info is needed please feel free. Thanks in advance, Manju

3 3

wine/tools wineinstall
by Saulius Krasuckas April 15, 2004

April 15, 2004

> Log message: > Only create the device symlinks the first time around. <skipped /> > + # Check if dosdevices exists and create it if necessary > + if [ ! -d ~/.wine/dosdevices ] > + then > + mkdir ~/.wine/dosdevices > + ln -s /mnt/fd0 ~/.wine/dosdevices/a: > + ln -s $CROOT ~/.wine/dosdevices/c: Alexandre, what about the case when ~/.wine/dosdevices exists but is empty? PS eghm, should it be bad for wineinstall and winecfg to share common code for creating links in dosdevices/ ?

2 1

help fixing up SetConsoleCtrlHandler()
by Peter Riocreux April 15, 2004

April 15, 2004

Having seen a lot of messages like: ----------------- fixme:console:SetConsoleCtrlHandler (0x41a8af,1) - no error checking or testing yet ----------------- lately, I thought I would actually see if I could fix it up and remove the FIXME. It is in dlls/kernel/console.c, and the MSDN reference is at <http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba…>. I think it is obvious enough that even I, a Wine newbie could do it, except for a couple of things that, as a newbie, are not obvious to me. Please point me at docs if this is covered somewhere - it is hard getting into a new project .... 1) If I am using SetLastError, it is not obvious to me what error values I should be using there. I assume there is a generic couldnt-allocate-on-heap error, but other causes of error are specific to the function, and I cannot find any documentation. Should I just use a non-zero error number and put FIXMEs in for any number I had to invent? 2) Can I assume that Rtl{Enter,Leave}CriticalSection(), HeapFree(), ERR() and WARN() cannot fail (the latter two are presumably macros). 3) The docs say that it behaves eeeeeeever so slightly differently in ME/98/95 than in others. In this case it is simply that one of the arguments may not be NULL. Should I, either in general, or in this case in particular, detect which Windows version is being used and behave appropriately, or implement the more flexible approach and assume that people writing for the more restricted OS will not have used that case. If I shoudl detect, how does one go about this? Peter

3 6

Re: winegcc: use CC to compile the .spec.c file
by Alexandre Julliard April 15, 2004

April 15, 2004

"Dimitrie O. Paun" <dimi(a)intelliware.ca> writes: > ChangeLog > Dimitrie O. Paun <dpaun(a)rogers.com> > Always use CC to compile the .spec.c file. Doesn't compile_to_object() do this already? -- Alexandre Julliard julliard(a)winehq.org

3 2

Re: Who's who - Blowing my own horn.
by Kevin Koltzau April 15, 2004

April 15, 2004

On Wednesday 14 April 2004 10:48 pm, Tony Lambregts wrote: > Blowing my own horn. ... > + <td width="300">Location: St. Albert, Alberta, Canada </td> > + <td>IRC Nick: tindalos</td></tr> Thats my IRC nick :)

1 0