wine-devel November 2004

wine-devel@winehq.org

141 participants
248 discussions

WSARecv not calling CompletionRoutine on socket close
by Geoff K. Hart 02 Nov '04

02 Nov '04

I've tried to search the mailing list archives (is their a searchable archive someplace?) for some reference to this problem. but found none. Forgive me if I didn't search hard enough. The Problem: we register a callback (lpCompletionRoutine) in our WSARecv call. This callback works fine for normal incoming messages. However, on socketclose, it does NOT get called. This behavior doesn't match what we see on Windows. Is there some configuration option we are missing? We see this same behavior for .exe's built on Windows and run under Wine - and with source code brought to Linux and built with WineLib. thanks, Geoff

1 0

[shellpath.c]: minor fix to Rolf's patch
by Rolf Kalbermatter 02 Nov '04

02 Nov '04

<menard.fabrice(a)wanadoo.fr> wrote: >The latest patch from Rolf Kalbermatter on shellpath.c was breaking the installation of wine.inf. > > wine rundll32 setupapi.dll,InstallHinfSection DefaultInstall 128 d:\\wine.inf > >was returning errors about being unable to create some dirs. In facts these errors was concerning >already existing directories in SHGetFolderPathW. I believe this patch is not fully correct. I noticed these errors too after the patch was applied, but did a little more investigation. SHCreateDirectoryEx should never be called if the directory already exists since this is explicitedly tested before the call to the function with PathFileExistsW(). Also inside the SHCreateDirectoryEx function I saw that the first call to CreateDirectory fails since intermediate directories are missing and then in the recursive call to CreateDirectory every single call returns ERROR_ALREAY_EXISTS on my system in spite of that it actually creates the last two or three directories in there. My investigations showed that in spite of that some of the the top level directories do not exist, the function NtCreateFile() which is ultimately called does seem to return an according NT status when called from SHGetFolderPath() but does create the directory nevertheless. Strange thing is that I can't reproduce this behaviour when calling SHCreateDirectoryEx() with many different parameters from an extended test in tests/shfileop.c So I believe the root cause really seems somewhere else, namely NTCreateFile or maybe wineserver itself, but I hadn't time to further go into details. >I think it is not necessary to care about that in this function so I added a check on the >type of error returned by SHCreateDirectoryExW. ShCreateDirectory should fail with that error if the directory really already existed. Rolf Kalbermatter

2 2

Can't debug mingw compiled program
by Vitaly Lipatov 02 Nov '04

02 Nov '04

During program debugging I have some trouble with winedbg use. Simple test program with error on write access to constant: #include <string.h> int main(int argc, char **argv) { char * str = "test"; _strupr(str); return (0); } I try debug it: $ winedbg 3.exe Can't attach process 3: error 87 WineDbg starting on pid 0xa In 32 bit mode. Wine-dbg>c First chance exception: page fault on write access to 0x00404000 in 32-bit code (0x00935d20). ... Backtrace: =>1 0x00935d20 _memccpy+0x595 in msvcrt (0x0090fec8) 2 0x00401330wine-kthread: stabs.c:246: stabs_find_ref: Assertion `filenr <= cu_include_stk_idx' failed. I see some bug in stubs handling. Versions: i386-mingw32msvc-gcc-3.3.3 wine from last CVS Any suggestions? -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

2 1

RFC: yield on Waits
by Jeremy White 02 Nov '04

02 Nov '04

Hi folks, Due to my new found belief that all of the flaws in Wine are timing problems, I have found what appears to be a gaping hole in Wine's timing behavior. Specifically, it appears as though any style of Waitxxx is supposed to yield the processor. This seems a bit difficult for me to believe, even though we had earlier discovered that Wine was never yielding on a Sleep(0). I've attached the test program I used to discover this. If you run sleep2 -1 0w the program will start 2 threads, one which spin loops (-1), and one which does a wait on an object for 0 seconds. You'll see in the results that the Wait(...,0) thread gets far fewer loops, and thus must be yielding. Further, changing that to a 0ws (or even 5ws), which means we're waiting on a signalled object, doesn't change the behavior. This leads me to suggest the attached patch. I would appreciate review from other folks, because this seems like a drastic change to me, and it strikes me as equally likely that I've done something stupid. Cheers, Jeremy

1 1

Re: Test Drive failure
by Dimitrie O. Paun 02 Nov '04

02 Nov '04

On Tue, Nov 02, 2004 at 06:40:57PM +0200, Dagan Shai wrote: > Thanks. > > Here they are. Winemaker is buggy, the generated Makefile has a small problem. Here's the fix: --- Makefile.orig 2004-11-02 09:52:59.000000000 -0500 +++ Makefile 2004-11-02 11:52:57.451738280 -0500 @@ -58,7 +58,7 @@ ### Generic targets -all: $(SUBDIRS) $(DLLS:%=%.so) $(EXES:%=%.so) +all: $(SUBDIRS) $(DLLS:%=%.so) $(EXES) ### Build rules @@ -106,7 +106,7 @@ $(helloworld_exe_MODULE).dbg.c: $(helloworld_exe_C_SRCS) $(helloworld_exe_CXX_SRCS) $(WINEBUILD) -o $@ --debug -C$(SRCDIR) $(helloworld_exe_C_SRCS) $(helloworld_exe_CXX_SRCS) -$(helloworld_exe_MODULE).so: $(helloworld_exe_MODULE).dbg.o $(helloworld_exe_OBJS) +$(helloworld_exe_MODULE): $(helloworld_exe_MODULE).dbg.o $(helloworld_exe_OBJS) $(CXX) $(helloworld_exe_LDFLAGS) -o $@ $(helloworld_exe_OBJS) $(helloworld_exe_MODULE).dbg.o $(helloworld_exe_LIBRARY_PATH) $(LIBRARY_PATH) $(helloworld_exe_DLLS:%=-l%) $(helloworld_exe_LIBRARIES:%=-l%) -- Dimi.

1 0

Correct time stamps on x11 events
by Jeremy White 02 Nov '04

02 Nov '04

Log message: Fix x11 event timing so that we correctly correlate x11 timing and Wine timing and dynamically adjust it as we go.

1 0

RE: Test Drive failure
by Dagan Shai 02 Nov '04

02 Nov '04

It only generated the helloworld.exe.so file, and no others. This is the only file defined in the makefile generated by winemaker. It is listed as part of the EXES macro and not the DLLS, which is why I thought it to be an executable. Could there be some reason that no executable is generated? Shai Dagan -----Original Message----- From: Dimitrie O. Paun [mailto:dpaun@rogers.com] Sent: Tuesday, November 02, 2004 6:14 PM To: Dagan Shai Cc: wine-devel(a)winehq.org Subject: Re: Test Drive failure On Tue, Nov 02, 2004 at 05:53:11PM +0200, Dagan Shai wrote: > Hi, > I'm new to WINELIB. As a test drive I tried to port the Hello World > application, just to see that the environment is functioning. > I called: > winemaker --console --lower-uppercase . > In the source directory. Then I called: > make > A helloworld.exe.so file was successfully created as a result (no errors > or warnings). It should have also generated a helloworld executable file, and you should be running it as: # ./helloworld -- Dimi. ______________________________________________________________________ This email message has been scanned by PineApp Mail-Secure and has been found clean.

3 2

Re: Fix for metafile test
by Juan Lang 02 Nov '04

02 Nov '04

Dmitry wrote: > The question is what makes the tests create invisible windows? Does > winetest run as a service on a not visible desktop? Anything else? I believe this is the reason. The shellpath tests fail on WinXP, I believe because HKCU doesn't exist because the service doesn't interact with the desktop. --Juan __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

1 0

Re: COM / InstallShield status
by Mike Hearn 02 Nov '04

02 Nov '04

> Likewise, what's the current status of Installshield support, > and how much work would it be to fully support > Installshield-based installers? I don't see any > open Installshield bug reports, maybe I should file > one against the apps I have that don't install at > the moment. (Or would that be overkill?) Rob and I did some work on InstallShield for iTunes a few months ago, since then AFAIK no work has been done. Status back then was that the InstallShield 7/MSI hybrid installers worked pretty well, the bug I chased for nearly a week was refcounting related (the backend wasn't shutting down) and since that was fixed I believe it works pretty well. The other main problems I'm aware of are: - needs stdole32.tlb, we have a program to generate this in CrossOver and it needs to be pulled upstream as previously discussed. - Painting problems. I've not investigated this deeply but I'm 99% sure I know what the problem is. I've even written a patch to fix it as part of investigating iTunes, but I never tried the patch with an InstallShield that shows the issue. Apart from those two there are mostly just generic issues - InstallShield contains its own scripting language which heavily exercises the variant APIs, so it sometimes shows up problems with them. I believe Marcus found an issue with them thanks to InstallShield recently. In other words, InstallShield *should* work though it might not be pretty. There may be installers out there which don't work, I'd like to start nailing them once I get back to Wine hacking. I don't know if I'll get time however. Also, Murphy continues to smack me down w.r.t internet connection, the ISP sent me the wrong type of modem and yesterday I discovered the phone socket I was going to connect the modem to doesn't actually work :( thanks -mike

1 0

Re: wineps: better pattern brushes
by Jakob Eriksson 02 Nov '04

02 Nov '04

Isn't 300 a bit low? Almost all lasers do 600 dpi. Huw D M Davies wrote: > Huw Davies <huw(a)codeweavers.com> > Scale the patterns so that they're rendered at 300dpi > Create the image dictionary once, rather than every time the PaintProc > is called - should speed printing up somewhat. > > >

2 1

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 November 2004