wine-devel

wine-devel@winehq.org

7 participants
84405 discussions

Re: RESEND: Handle shortened *optval arg. in WS_setsockopt / WS_SO_RCVTIMEO
by Greg Turner 25 Sep '02

25 Sep '02

hmm, somehow this failed to make it through to the list.... Trying again... ---- awesome, thanks for your input Rein! I am no unix sockets guru (nor, obviously, am I a winsock guru ;) so this is really helpful, I'll try and submit a revision to my revision (which is apparently already in wine). That explains the time value out I was seeing of 10,000! 3 hours sounded like an awfully long time to me so I probably should have guessed those were mili's :). Basically, from your advice, I see two options. One, the obvious one, which I'll implement for now, is to convert miliseconds-> <seconds,miliseconds> and be done with it. The other would be a "correct" solution that actually works -- judging by your post, just converting the arguments won't, and I'll need to learn a little bit more about wine-winsock to make it do the right thing. I'll do the easy thing, post it to patches, then look into do_block and get back to the list if I find that this is all beyond my abilities (a quite probable scenario ;) Thanks again for the hand-holding, keep it coming, please, as I may be somewhat "out of my league" here, and I don't want to screw up wine out of ignorance. -- Greg Turner <gmturner007(a)ameritech.net> "Waiting periods are only a step. Registration is only a step. The prohibition of private firearms is the goal." -U.S. Attorney General Janet Reno, December 1993 Rein Klazes wrote: >On Tue, 24 Sep 2002 16:10:43 -0500, you wrote: > > > > >>+ if (level == SOL_SOCKET && optname == SO_RCVTIMEO && optlen < sizeof(struct timeval)) { >>+ if (optlen == sizeof(time_t)) { >>+ /* Apparently WinSock will accept a shortened struct timeval. >> >> > >In Unix the arg optval points to a struct timeval, in windows to a >(32bit) int, no mystery here. The latter is the timeout in >milliseconds. Further a non-zero timeout less then 500 (msec) is taken >as 500 msec. > > > >>+ FIXME: should we do the same for SO_SNDTIMEO? */ >> >> > >Of course, its the same issue. > > > >>+ WARN("Short struct timeval in SO_RCVTIMEO: assuming time_t\n"); >>+ tval.tv_sec = *(time_t*)optval; >>+ tval.tv_usec = 0; >> >> > >You will need to convert from milliseconds here. > > >Unfortunately this does not work (a recv timing out). The socket in >wine is non-blocking internally, any blocking will be done in the >function do_block() using a select(). SO_RCVTMO has no effect there. > >Rein. > -- Greg Turner <gmturner007(a)ameritech.net> "Waiting periods are only a step. Registration is only a step. The prohibition of private firearms is the goal." -U.S. Attorney General Janet Reno, December 1993

1 0

ToDo's
by Thomas Wickline 25 Sep '02

25 Sep '02

Thanks to everyone who has gave feedback on this. Here is a draft of eveything up to today. As always in need of feedback ;) Tom Wine ToDo's as of 9/25/02 Contact : twickline2(a)triad.rr.com Wine ToDo OverView Window management: * Window management needs proper inter-process handling of activation, focus, repaint. National Language Support: * ASCII function work Winsock: * Winsock1 calls,in particular select(),use direct system calls instead of using related wine APIs * More unit tests need to be written * Make sure OOB data is handled properly. Check client-size blocking. * WS2: "provider" interface * WS2: Support other kind of services, like IrDA. * Fix stubs left in ws2_32.spec. DirectSound: * Make the latency configurable (tunable). * More intelligent prebuffering. * Complete support for hardware secondary buffers through the HAL (for a future ALSA multimedia wave audio driver). * 3D sound buffers. * Sound capture (recording). Sound drivers: * Alsa driver (on final 0.9 interface) Video: * Implement native codecs (RLE...) * DIB engine to do 32-bit graphics manipulation DDE: * Enhance memory management issues (interprocess sending) Wineconsole: * Add a (n)curse backend so that we can run CUI programs without using USER32 (and X11 behind) Native programs: * Winhelp: fix invocation thru WinHelp * Winedbg: make winedbg use dbghelp DLL File management: * Implement NT file namespace * UNC support * Allow flexibility in FS "mounting" (for example, SMB shares) TrueType fonts: * Libfontconfig support Tools: * Wine installation process should install and configure wine * Winemaker fixes * Run C regression tests on Windows with MSVC * Compile Wine with -DSTRICT * Work on WRC as it does not find system headers Instructions: * Write a proper Users Guide Introduction * Documentation updates Aspect or Component: * More DLL Separation * BiDi support * Review of Wine Server Protocol * Finalize Server Protocol * PAM (Pluggable Authentication Modules) * Visual C++'s native COM support * Add DWARF2 support * Speed up PDB support * Create replacement of browser component (Internet Explorer/I Porting issues for Mingw/Cygwin/MS_VC * Better seperation of win16/32 code. * Remove/rewite win16/9x api dependancy on newer code * Remove/rewrite wineisms from code * Documentation fixes low priority items: * VxD support with dynamic loading Add links to: Tasklets: http://bugs.winehq.com/buglist.cgi?keywords=tasklet tasklist: http://bugs.winehq.com/buglist.cgi?keywords=tasklist For a full list of .9/1.0 task's

3 3

Re: ToDo's
by Steven Edwards 25 Sep '02

25 Sep '02

Eric POUECH wrote: >>Here is the status of what I have so far on the ToDo's. >>I am not sure what section to put alot of this in so I just made >>Tools , Instructions & Aspect or Component for now. >>As much feedback as possiable is welcomed . >> >> > >here's some feedback: > >Sound drivers >- Alsa driver (on final 0.9 interface) > >Video: >- implement native codecs (RLE...) > >DDE: >- enhance memory management issues (interprocess sending) > >wineconsole: >- add a (n)curse backend so that we can run CUI programs without using USER32 (and X11 behind) > >file management: >- implement NT file namespace >- UNC support >- allow flexibility in FS "mounting" (for example, SMB shares) >(NB: I think we should make that clearer and not keep it shadowed in the Aspect/component list) > >(native) programs: >- winhelp: fix invocation thru WinHelp >- winedbg: make winedbg use dbghelp DLL (and implement it of course) > >--8<--------- >remove the Multimedia wave audio section >SEH support has been lately enhanced, is there still known issues ? >IMO, Dwarf2 support should not be added to winedbg. use of gdb proxy should be required instead. (even if it means adding PDB support to gdb, but that'd be a better investment) > >we should make clear what the low priority items are (VxD support with dynamic loading for example) > >A+ > > I dont know if any of these are in any of the TODOs but here goes. all of these would go under porting issues for Mingw/Cygwin/MS_VC - Better seperation of win16/32 code. - remove/rewite win16/9x api dependancy on newer code - remove/rewrite wineisms from code - documentation fixes I think all of this is high priortity but I am biased =) Thanks Steven

2 2

Hand Cursor
by Gustavo Junior Alves 25 Sep '02

25 Sep '02

The "hand cursor" hotspot is in wrong position (lower-right instead in the finger). Where I find information abou how I can fix it? Thanks, Gustavo

2 1

Re: RESEND: Handle shortened *optval arg. in WS_setsockopt / WS_SO_RCVTIMEO
by Rein Klazes 25 Sep '02

25 Sep '02

On Tue, 24 Sep 2002 16:10:43 -0500, you wrote: > + if (level == SOL_SOCKET && optname == SO_RCVTIMEO && optlen < sizeof(struct timeval)) { > + if (optlen == sizeof(time_t)) { > + /* Apparently WinSock will accept a shortened struct timeval. In Unix the arg optval points to a struct timeval, in windows to a (32bit) int, no mystery here. The latter is the timeout in milliseconds. Further a non-zero timeout less then 500 (msec) is taken as 500 msec. > + FIXME: should we do the same for SO_SNDTIMEO? */ Of course, its the same issue. > + WARN("Short struct timeval in SO_RCVTIMEO: assuming time_t\n"); > + tval.tv_sec = *(time_t*)optval; > + tval.tv_usec = 0; You will need to convert from milliseconds here. Unfortunately this does not work (a recv timing out). The socket in wine is non-blocking internally, any blocking will be done in the function do_block() using a select(). SO_RCVTMO has no effect there. Rein. -- Rein Klazes rklazes(a)xs4all.nl

2 1

Re: WineLib and DLLs (Winedump)
by steve.lustbader＠philips.com 25 Sep '02

25 Sep '02

>>> Does it matter that the dll is exporting C++ classes, not straight C >>> functions? >> >>That could make things slightly more complicated, since MS and gcc use >>different name mangling systems. if you declare functions with extern "C" >>linkage you should be OK. However there are differences in how gcc and MS >>call methods on objects (and in the vtable layout etc), so in general its not >>advised to mix win32 c++ dlls with a winelib exe and vice versa (i.e you >>should implement mydll.dll as a real wine dll rather than as just a stub for >>linking). > >Actually, it's a win32 c++ app with lots of win32 c++ dlls and one winelib >c++ dll. The winelib dll depends on two other win32 c++ dlls, which the app >also depends on. I'm trying to avoid turning those other dlls into winelib >dlls, since one of them uses ATL. Am I trying to do something that can't >really be done? Is it possible to make the stub dll that winelib generates I mean take the stub that _winedump_ generates and have it forward the calls >forward calls to the win32 dll (ie, give it both the gcc mangled name and the >msvc mangled name)? > >-Steve

1 0

Re: WineLib and DLLs (Winedump)
by steve.lustbader＠philips.com 25 Sep '02

25 Sep '02

>> Does it matter that the dll is exporting C++ classes, not straight C >> functions? > >That could make things slightly more complicated, since MS and gcc use >different name mangling systems. if you declare functions with extern "C" >linkage you should be OK. However there are differences in how gcc and MS >call methods on objects (and in the vtable layout etc), so in general its not >advised to mix win32 c++ dlls with a winelib exe and vice versa (i.e you >should implement mydll.dll as a real wine dll rather than as just a stub for >linking). Actually, it's a win32 c++ app with lots of win32 c++ dlls and one winelib c++ dll. The winelib dll depends on two other win32 c++ dlls, which the app also depends on. I'm trying to avoid turning those other dlls into winelib dlls, since one of them uses ATL. Am I trying to do something that can't really be done? Is it possible to make the stub dll that winelib generates forward calls to the win32 dll (ie, give it both the gcc mangled name and the msvc mangled name)? -Steve

1 0

Re: d3d8 header patch.
by Dimitrie O. Paun 25 Sep '02

25 Sep '02

On September 25, 2002 09:13 am, Yong Chi wrote: > I gave a .txt extension this time to make sure that the attachment got > treated as a text file. =) Excellent. But you didn't send it in the right format. Do cvs diff -u include/d3d8.h You should add diff -u to your .cvsrc file. -- Dimi.

2 1

another MZ_Exec() problem...
by chrismorgan＠rcn.com 25 Sep '02

25 Sep '02

Inside of MZ_Exec() I call out to CreateProcessA() if the executable is PE. I've set the lpEnvironment parameter of CreateProcessA() to null to have it inherit the environment of the caller but this isn't working correctly. The path and other environment variables aren't being inherited. Ideas on how to either get CreateProcessA() to inherit properly or where I can find the environment settings? I noticed the env_ptr in the parmeter block but I'm unsure if this is what I'm looking for or where to find more information about it. Thanks, Chris

3 2

Re: d3d8 header patch.
by Uwe Bonnes 25 Sep '02

25 Sep '02

>Hello! >I gave a .txt extension this time to make sure that the attachment got > treated as a text file. =) Now again as a unified diff (diff -u), and everybody is hapy :-) Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel