June 2003 - Wine-devel - list.winehq.org

03 Jun '03

Hello, I am working on another Status page update and here is a list of Component's that currently dont have a primary worker asighned. If you are a worker on any of these Component's can you let me know and I will add you in as the worker. Also if you are aware of a Status % work done on any of these can you let me know. I am aware that some Component's are not being worked on at all times... I would just like to get all workers in place. Also if your listed as a worker and your not the current worker or don't plan to work on a Component in the future I will remove you if you wish. Thanks Tom ----------------- Wine Status - Core : http://www.winehq.org/?page=status_wine Registry handling X11 display/window driver Clipboard handling Standard Windows Controls VxDs CPU emulation Multi-user support Initial registry contents Initial directory structure Initial INI files Wine Status DLL's : http://www.winehq.org/?page=status_dlls comdlg32: Common Dialogs riched32: Rich Text Control tapi32: Telephony API (TAPI) rasapi32: Dial-Up Networking (DUN) and Remote Access Service (RAS) quartz: DirectShow core wing: WinG 16-bit game library olecli32: OLE client library olesvr32: OLE server library oledlg: OLE user interface odbc32: ODBC Database Manager wnaspi32: Advanced SCSI Peripheral Interface

3 2

Re: Merge of WineX's (LGPL licensed) wininet.dll code
by Robert Shearman 02 Jun '03

02 Jun '03

> Subject: Re: Merge of WineX's (LGPL licensed) wininet.dll code > From: Mike Hearn <m.hearn(a)signal.qinetiq.com> > To: wine-devel(a)winehq.org > Cc: wine-patches <wine-patches(a)winehq.com>, david(a)transgaming.com > Organization: QinetiQ - Malvern Technology Center > Date: 02 Jun 2003 14:32:42 +0100 > Just thought I'd let people know (while we're on the WinInet topic) that I'm working on the UrlCache functions there, leading to implementing the UrlMon functions properly. Rob

1 0

Re: Merge of WineX's (LGPL licensed) wininet.dll code
by Mike Hearn 02 Jun '03

02 Jun '03

Well, I'm spending my fun afternoon trying to get IE to install in Wine (it breaks in a new and interesting way every time I try this). Before the patch, it didn't work, couldn't contact download sites. After the patch, it still doesn't work, and I get this fixme: fixme:wininet:InternetReadFile This shouldn't be here! We don't support this kind of connection anymore. Must use NETCON functions, especially if using SSL Which seems a bit of a bummer, if IE6 setup needs that type of connection I think we should still support it really...... I think the problem might be lack of proxy workingness. Am investigating now. Would be nice to lift proxy details from the http_proxy variable in future.... One last thing, the patch seemed to have a lot of whitespace no-ops, running diff with -bB should eliminate some. thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

2 1

Re: kernel32 file operations and wildcard filenames
by Pouech Eric DMI AEI CAEN 02 Jun '03

02 Jun '03

> Under Windows (2K) all functions such as DeleteFile, CopyFile, MoveFile, > CreateDirectory and such do return FALSE and normally set the last error > to ERROR_INVALID_NAME (123) if one of the filenames passed in contains a > wildcard (*?). > > Wines kernel32 behaves somewhat different. Apart from returning different > last errors in most cases such as: > > DeleteFile: ERROR_FILE_NOT_FOUND (2) > CopyFile: ERROR_BAD_PATHNAME (161) > MoveFile: ERROR_FILE_NOT_FOUND (2) when source contains wildcards > > which all wouldn't really be a to big issue, there is one thing which > seems not right at all to me: > > MoveFile with a valid existing source and a target with wildcards > will create a file on disk containing wildcards in its name. This > certainly can't be the intention! > > So according to Win2K it would be probably useful to check in all those > functions for existence of wildcards in the input file paths and refuse > them properly. > > I took a look at the kernel32 file.c functions and saw that they usually > all call DOSFS_GetFullName which is supposed to check for valid filenames > and such. Problem is this function is also used in many other places and > I can't get a good idea if those might need to accept wildcards in file > names. > > Is there anyone more familiar with the kernel32 implementation in Wine > who could maybe give me some insight if an according change to > DOSFS_GetFullName would be useful or rather cause possible regressions? > > Otherwise the best thing to do would probably be to add explicit wildcard > tests to all those file function and refuse with an according last error > set. If I do not get any reactions this is probably what I will do as I'm > somewhat weary to change an internal low level function such as > DOSFS_GetFullName without some third party encouragement. those functions are likely to be rewritten RSN (and DOSFS_GetFullName may even disappear) So I'd suggest rather starting by writing test cases for those functions so we could use those tests when the rewrite is going to take place A+

3 2

Wierd random spew to the terminal
by Mike Hearn 02 Jun '03

02 Jun '03

Hmm, I think quite a few of us have seen this now. Well, it just happened again so this time I attached gdb and tried to get a backtrace to see what was going on. I found a very curious thing.... the stack trace was huge, in fact, it had 3162 frames. As you might expect it was recursive. It looked like this: #3141 <signal handler called> #3142 0x4009e977 in rwlock_real_init (rwlock=0x42126020) at ../../include/winbase.h:1932 #3143 0x4009ea48 in __pthread_rwlock_rdlock (rwlock=0x42126020) at ../../scheduler/pthread.c:547 #3144 0x4202365a in __dcigettext () from /lib/i686/libc.so.6 #3145 0x42022ed5 in dcgettext () from /lib/i686/libc.so.6 #3146 0x4207a4b7 in strerror_r () from /lib/i686/libc.so.6 #3147 0x4206148b in perror () from /lib/i686/libc.so.6 #3148 0x40099259 in server_protocol_perror (err=0x400bdc31 "read") at ../../scheduler/client.c:134 #3149 0x40099388 in read_reply_data (buffer=0x405ca5a4, size=64) at ../../scheduler/client.c:195 #3150 0x400993de in wine_server_call (req_ptr=0x405ca5a4) at ../../scheduler/client.c:209 #3151 0x400a8653 in send_debug_event (rec=0x405ca6a8, first_chance=1, context=0x405ca71c) at exception.c:137 #3152 0x400a87fa in EXC_RtlRaiseException (rec=0x405ca6a8, context=0x405ca71c) at exception.c:195 #3153 0x400b6e48 in do_segv (context=0x405ca71c, trap_code=14, cr2=0x18, err_code=4) at signal_i386.c:814 #3154 0x400b7324 in segv_handler (__signal=11, __context= {sc_gs = 143, __gsh = 0, sc_fs = 143, __fsh = 0, sc_es = 43, __esh = 0, sc_ds = 43, __dsh = 0, sc_edi = 1108452444, sc_esi = 1108500512, sc_ebp = 1079815400, sc_esp = 1079815380, sc_ebx = 1074654520, sc_edx = 1108500512, sc_ecx = 1108481382, sc_eax = 0, sc_trapno = 14, sc_err = 4, sc_eip = 1074391415, sc_cs = 35, __csh = 0, sc_eflags = 66050, esp_at_signal = 1079815380, sc_ss = 43, __ssh = 0, i387 = 0, oldmask = 2415929859, cr2 = 24}) at signal_i386.c:436 #3155 <signal handler called> So it would appear that there is a crash in the exception handler which just goes round and round, and clearly at some point garbage is written to stdout/stderr. Unfortunately my code-fu is not strong in areas related to threading/exception handling, so I don't really know what's going wrong, except that it seems there is a problem in rwlock_real_init (in fact the line number it gives is in GetProcessHeap()). Well, I thought somebody may find it useful. BTW, after I attached to wine (ie stopped it) something was still typing out letter by letter "xtermxtermxterm" over and over again.... wake up neo :) thanks -mike -- Mike Hearn <m.hearn(a)signal.qinetiq.com> QinetiQ - Malvern Technology Center

4 4

Re: Bidi B2 - GetCharacterPlacement order array
by Dimitrie O. Paun 02 Jun '03

02 Jun '03

On May 31, 2003 05:45 am, Shachar Shemesh wrote: > + /* Treat the case where no special handling was requested in a > fastpath way */ + /* copy will do if the GCP_REORDER flag is not set > */ > + if (lpResults->lpOutString) > + for (i = 0; i < nSet && lpString[i] != 0; ++i) > + lpResults->lpOutString[i] = lpString[i]; What about a strncpy here: + if (lpResults->lpOutString) + strncpyW(lpResults->lpOutString, lpString, nSet); -- Dimi.

5 7

Re: Wine packages
by puoti 02 Jun '03

02 Jun '03

Hem, after trying to find out what was wrong with my dns configuration, I discovered that the icu url you sent me was wrong, the correct link is http://oss.software.ibm.com/icu/ regards, Ivan.

1 0

Re: Application crash
by biggun from the sun 02 Jun '03

02 Jun '03

>Run it with "--dll ole32=n". Should work just fine. Doesn't work better :( Stephan _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail

2 1

Re: Wine packages
by Shachar Shemesh 02 Jun '03

02 Jun '03

puoti wrote: >Hi, >I've read the wwn n° 171, I'm the one that builds the sourceforge wine packages >for Mandrake, I just want to ask if you can please let me know when you add bidi >support to wine, what headers I must install, and if I have to add any explicit >options to configure, so I can build wine rpms with bidi support, best regards, >Ivan. > > Hi Ivan, First, I'm forwarding your email to the list. I hope you don't mind. I think other people may find it useful. I have to say that these weekly news are doing their job great! I have already sent in the patches. They were not included, mostly because Alexander is away. When they are included, you will need any fairly recent ICU installed locally on your machine. You can get the sources for the library at http://oss.ibm.com/icu/. I would go for their latest released version (2.5), rather than the beta. Unfortunetly (and this has been a major consideration against using it, but other factors were stronger), ICU has no packages for platforms other than Debian. You don't have to give configure any explicit option (well, assuming Alexander doesn't change anything, that is). Notice that you actually need to compile ICU, however. Merely adding the headers is not enough, as it is STATICALLY linked to gdi. On the bright side, this doesn't add any difficult dependancies to wine. Hope this helps, Shachar -- Shachar Shemesh Open Source integration consultant Home page & resume - http://www.shemesh.biz/

1 0

wine exception handling
by Martin Fuchs 01 Jun '03

01 Jun '03

Hi, I have problems running an application with wine. At startup it tries to read its config file. But it catches up in an endless loop of exceptions. The attached trace is generated using --debugmsg +msvcrt,+seh,+file,+dosfs. I send only the interesting part of the full trace. However there is a: fixme:seh:EXC_RtlRaiseException call to unimplemented function msvcrt.dll.localeconv But why does there happen an excpeption anyways? Any clue, whats wrong here? -- Martin Fuchs martin-fuchs(a)gmx.net

2 2