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

Internet Explorer regressions
by Mike Hearn 29 Jun '03

29 Jun '03

Back to the real thing now, is anybody else seeing big regressions in IE? Rendering speed has dropped through the floor, I can watch it paint the web page in chunks. Fonts seem a bit off, and I need a load of native DLLs otherwise it freezes, seemingly spinning - but when I attach in winedbg and take a look, it seems all the threads are simply blocking on NtWaitForMultipleObjectsEx. I'm wondering if I broke my setup somewhere along the way, or if the latest round of checkins b0rked IE. this is frustrating.... so close to our app working!! :/ ta -mike

4 8

[RFC] Wine 0.9 TODO v0.9
by Dimitrie O. Paun 09 Jun '03

09 Jun '03

Hi folks, A new version (v0.9) of the Wine 0.9 TODO is available for your viewing pleasure at: http://63.138.153.104/wine/Wine-0.9-TODO-0.9.html The work-in-progress one is available at: http://63.138.153.104/wine/Wine-0.9-TODO.html Most important changes in this one is that a bunch of stuff was moved over to the Wine 1.0 TODO: http://63.138.153.104/wine/Wine-1.0-TODO.html Any feedback concerning this (rather large) changes is more than welcomed. Note: I had problems with my dssd.ca domain as of late, I'll try to fix them soon. Meanwhile, the IP should do. -- Dimi.

3 2

Re: winsock: use iphlpapi
by Dimitrie O. Paun 08 Jun '03

08 Jun '03

On Thu, 8 May 2003, Juan Lang wrote: > Sylvain was right, I screwed up the last patch. Here > 'tis again. Juan, Your patches are hard to review, as you compress them. Please include them in your message as plain text if you can do it without line wraps, if not attach them as plain text files. Here are some tips on sending patches: http://www.winehq.org/?page=sending_patches Thanks! -- Dimi.

3 3

Re: iphlpapi.dll (take 3)
by Alexandre Julliard 08 Jun '03

08 Jun '03

Juan Lang <juan_lang(a)yahoo.com> writes: > ChangeLog: Adds an implementation of iphlpapi.dll; > most Get* functions introduced through Win98 are > included. I've applied the dll (with some changes), but not the test, it will require some more fixes. The main problem is that you shouldn't check the Windows version, you should call whatever functions are available independently of what GetVersion() returns. Also the test must not print anything to stdout, it should use the trace() macro instead. -- Alexandre Julliard julliard(a)winehq.com

2 1

Agent crashes when accessing attachments
by Oliver Sampson 06 Jun '03

06 Jun '03

Howdy, I just reinstalled my Linux system (HD crash), and at the same time moved to a RH9.0 distro. I read about the problems with the NPTL threading, and I have the latest CVS running (with the --with-nptl). Now when I have Agent running (which in all other respects seems fine) every time I go to add an attachment or save an attachment Agent crashes. Is this a known problem? Or should I start getting a backtrace and providing some more information? Thanks, -- Oliver Sampson olsam(a)quickaudio.com http://www.oliversampson.com

2 2

Re: Re: msdos/int21 CREAT special cases
by Pouech Eric DMI AEI CAEN 03 Jun '03

03 Jun '03

please stop using krnl386.exe export when possible (especially for dos emulation which is going out of kernel32/krnl386.exe combo). So, if CreateFile can do, please use it (ditto for any other krnl386 file related functions) this is needed for proper DLL separation > Hmm, and is there a reason to not do it in _lcreat16() instead? > Or is _lcreat16() really "clever" enough to handle volume labels > "properly" if called directly? > Somehow I doubt it... ;) > Or in fact you could walk further up the chain and maybe find that even > _lcreat() should be the function to have that check instead... > (or, for that matter, even CreateFileA and thus CreateFileW...) > > So my rough guess is that this should probably be prevented in CreateFileW > instead even.

3 4

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

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

Alsa driver status
by Sylvain Petreolle 01 Jun '03

01 Jun '03

Since Alsa has released a 0.9 version, I think we could write a more complete driver. (midi output, recording, channel control...) Eric and Marco, are you still working on it ? ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

4 6

Re: [dmusic-01] some stubs implementation
by Rok Mandeljc 01 Jun '03

01 Jun '03

Na 1054375053, 2003-05-31 ob 11:57, je Raphaël Junqueira napisal(a): > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi folks, > > I'm trying to get Unreal2 working, with no sound it continue to access some > dmusic stubs and crash. With this it crash later than befor (in dmusic too). > If anyone can help to really improve dmusic support as we need a real > implementation of IDirectMusicPerformance8 I'm working on it but I'd really appreciate any help... > Else, anyone know how to force an application to not use dmusic (saying that > it's not supported) ? Sure, just go into /usr/lib/wine and delete or rename dm*.dll.so :) > Changelog: > - some implementation of dmusic stubs > > Regards, > Raphael > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.2 (GNU/Linux) > > iD8DBQE+2HyRp7NA3AmQTU4RAphSAJ4k6JEXzMWTk2YkgZe64x24AcNOAwCdHC1g > EbX3xX1cR1a7fnTzDteoI0Q= > =z3AZ > -----END PGP SIGNATURE-----

3 2