wine-devel

wine-devel@winehq.org

12 participants
84488 discussions

MZ_FillPSP() in dlls/winedos/module.c
by chrismorgan＠rcn.com 26 Sep '02

26 Sep '02

I have a script that passes a long argument string when calling a command handler(command.com or other comspec replacement). This code inside of MZ_FillPSP() if(length > 126) { ERR("Command line truncated! (length %d > maximum length 126)\n", length; length = 126; } is breaking my application by truncating the 200+ character argument at 126 characters. Do we still need to truncate at 126? Afaict having more than 126 characters may exceed some command.com default. Can someone shed more light on the historical reasons behind this code and whether more intelligent truncation can be performed? Thanks, Chris

4 5

Problem Saving Template with Word 2000
by Mason Kidd 25 Sep '02

25 Sep '02

Hi, I am using Word 2000 SR-1 on a fake windows install of wine 20020904. It runs fine except for one problem. When I exit the program, it tries to save the Normal.dot file to C:\windows\Application Data\Microsoft\Templates\Normal.dot and fails, with this error: The disk is full or too many files are open. (C:\windows\...\Templates\Normal.dot) If I click on Ok, and then try to save the template to a different location, even on a different partition, it gives the same error. I see this error in my xterm: err:shell:SHGetFileInfoA pidl is null! Is this related? I found bug number 956 that talks about this. Is this where I should start? It would seem to me that this would be a bug that Codeweavers had already dealt with, so do any of you guys know where to point me? Thanks. Mason Kidd

2 3

rfc: 16bit USER function
by Michael Stefaniuc 25 Sep '02

25 Sep '02

Hello, i would like to move USER functions of the type $type WINAPI $function16(@args) { return $function(@args); } from windows/*.c to dlls/user/user16.c but i don't know if that's the right place to put them because there are already some dlls/user/*16.c files. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

2 1

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

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