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

manual patch tracking system for ntdll
by thomas.mertes＠gmx.at 15 Apr '03

15 Apr '03

Hello Since I am following the ntdll development, I noticed some not applied patches: - Ntdll atom stuff: http://www.winehq.com/hypermail/wine-patches/2003/04/0064.html - Ntdll atom tests. http://www.winehq.com/hypermail/wine-patches/2003/04/0065.html The tests where verified by Dmitry Timoshkov in this mail: http://www.winehq.com/hypermail/wine-devel/2003/04/0192.html - Resend: Implement some ACE functions http://www.winehq.com/hypermail/wine-patches/2003/04/0129.html IMHO, if a patch is correct (can be verified by tests) it should be applied, even if no application needs this functions (at the moment). If this functions are needed later, some implementation (with FIXMEs) is already there as base for further development. This is easier than looking for a (possibly outdated) patch in the archieves. I see the wine source also as a information repository, which is easier to access, than a patch archive. In the worst case it should be possible that a function is accepted but deactivated with #ifdef. Greetings Thomas Mertes -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage!

3 2

Re: Fall back to ttydrv
by Dimitrie O. Paun 15 Apr '03

15 Apr '03

On April 14, 2003 06:11 pm, Uwe Bonnes wrote: > + MESSAGE( "Falling back to ttydrv\n"); Again, I'd say this message is not appropriate, especially now that the user has to enable this configurations. For people using command line tools under Wine will be just pure spam. -- Dimi.

5 6

Cross compiling tests
by Hans Leidekker 15 Apr '03

15 Apr '03

Hi, I'm trying to cross compile the regression tests using MinGW as a cross compiler (i.e. I have installed the MinGW cross compiler on Linux and run 'make crosstest'). First problem I encountered was that my versions of the compiler and dlltool weren't detected at configure stage. Mine are called i386-mingw-gcc and i386-mingw-dlltool, whereas configure looks for i586-mingw32msvc-gcc and i586-mingw32msvc-dlltool. I've sent a patch to wine-patches that adds the former names to the configure check. Second major problem happens at the build stage. The Makefile for a test specifies -L$(DLLDIR) when linking the test executables, which is where the *Wine* libraries reside. I think this is wrong, we should link against the target platform libraries (MinGW in this case) when cross compiling. Removing -L$(DLLDIR) from the Makefile also solves a conflict that arises from the fact that both MinGW and Wine have an implementation of the C runtime: make crosstest i386-mingw32-gcc generated.cross.o testlist.cross.o -o urlmon_crosstest.exe -L../../../dlls -lurlmon -lm ../../../dlls/libmsvcrt.a(ds00443.o)(.text+0x0): multiple definition of `atexit' /usr/local/lib/gcc-lib/i386-mingw32/3.2.2/../../../../i386-mingw32/lib/crt2.o(.text+0x230):/usr/src/redhat/BUILD/mingw-2.4/mingw-runtime-2.4/crt1.c:266: first defined here ../../../dlls/libmsvcrt.a(ds00319.o)(.text+0x0): multiple definition of `_onexit' /usr/local/lib/gcc-lib/i386-mingw32/3.2.2/../../../../i386-mingw32/lib/crt2.o(.text+0x250):/usr/src/redhat/BUILD/mingw-2.4/mingw-runtime-2.4/crt1.c:274: first defined here Patch sent to wine-patches. Now most tests happily compile ;-). I have two tests left that have problems linking. It appears that they use symbols that are not available in any import library (not even Wine's): i386-mingw32-gcc dsound.cross.o testlist.cross.o -o dsound_crosstest.exe -ldsound -luser32 -lkernel32 -lm dsound.cross.o(.text+0x1656): In function `dsenum_callback': /usr/local/src/wine-cvs/wine/dlls/dsound/tests/dsound.c:403: undefined reference to `wine_dbgstr_guid' dsound.cross.o(.text+0x24dd): In function `dscenum_callback': /usr/local/src/wine-cvs/wine/dlls/dsound/tests/dsound.c:649: undefined reference to `wine_dbgstr_guid' make: *** [dsound_crosstest.exe] Error 1 The wine_ prefix suggests that this is a Wine internal function, so it will never be avaliable on Windows/MinGW. Can these be removed? Or is there an alternative that works on all platforms? This is the other one that fails: i386-mingw32-gcc safearray.cross.o vartest.cross.o testlist.cross.o -o oleaut32_crosstest.exe -loleaut32 -lm safearray.cross.o(.text+0x1496): In function `func_safearray': /usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:277: undefined reference to `IID_IUnknown' safearray.cross.o(.text+0x14d1):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:278: undefined reference to `IID_IUnknown' safearray.cross.o(.text+0x150e):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:281: undefined reference to `IID_IDispatch' safearray.cross.o(.text+0x1549):/usr/local/src/wine-cvs/wine/dlls/oleaut32/tests/safearray.c:282: undefined reference to `IID_IDispatch' make: *** [oleaut32_crosstest.exe] Error 1 Same problem I guess. Any suggestion as to how this one might be fixed is welcome. -Hans

3 10

mouse_event()
by Brad Campbell 15 Apr '03

15 Apr '03

G'day all, I have been doing some testing of the mouse_event call in windows and wine. There is only one incompatibility that I can see. In windows 95, a call to mouse_event does not _move_ the mouse pointer, whereas in wine, the mouse pointer follows the mouse. In windows, I have to make a call to mouse_event then another call to setcursorpos() to make the pointer follow the mouse. When using a touchscreen for input, we use a setcursorpos() call to move the mouse pointer off the screen, and then just feed windows mouse_event calls with the position and button state. This works under wine, but of course the pointer follows the mouse_event. It looks like this would be difficult to fix as from what I can see the pointer movement seems to be pretty closely tied to the mouse position. Any ideas? -- Brad.... /"\ \ / ASCII RIBBON CAMPAIGN X AGAINST HTML MAIL / \

1 0

Re: Better fix for named pipe problem.
by Gregory M. Turner 14 Apr '03

14 Apr '03

FYI fixing the linewraps in the patch and applying does indeed stop the wineserver from crashing using the experimental pipe.c, and runs fine against CVS's pipe.c. However, also FWIW, using the experimental pipe.c from Bill, I still get a pipe.ok when I shouldn't doing make test... -- gmt "Democracy is the theory that holds that the common people know what they want, and deserve to get it good and hard." HL Mencken

1 0

re: Is it possible to call DLL functions from a Linux program?
by Dan Kegel 14 Apr '03

14 Apr '03

Eloy wrote: > Now, I want to run this program natively under Linux - I mean, I don't > want to run wcmd because that requires an X server. I suggest just running your little Windows program under Wine. Don't use wcmd, you don't need it. For instance, in my ~/bin, I have a shell script winword which just contains wine -- "c:\\Program Files\\Microsoft Office\\Office\\winword.exe" "$@" That more or less lets me run microsoft word from the commandline. You can configure wine to not require X. I've done it on some commandline Windows programs I wanted to use in shell scripts on Linux. It was and is a pain, I believe, because so few of the Wine developers use commandline Windows programs without X, but it is doable. (And maybe it's easier than it used to be; I don't know.) - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

3 6

Bug: "Type" = "cdrom" allows writing !!
by Sylvain Petreolle 14 Apr '03

14 Apr '03

Trying to run "dir >test" in a drive set to "Type" = "Cdrom" will create a test file containing the directory listing. Test case: [Drive W] "Path" = "/home/wine" "Type" = "cdrom" "Label" = "WineSrc" "Filesystem" = "win95" [syl(a)snoop wine]$ ls -l z ls: z: No such file or directory [syl(a)snoop wine]$ wcmd fixme:keyboard:X11DRV_KEYBOARD_DetectLayout Your keyboard layout was not found! Using closest match instead (French keyboard layout) for scancode mapping. Please define your layout in windows/x11drv/keyboard.c and submit them to us for inclusion into future Wine releases. See the Wine User Guide, chapter "Keyboard" for more information. WCMD Version 0.17 W:\>dir >z W:\>exit [syl(a)snoop wine]$ ls -l z -rw-r--r-- 1 syl wine 2413 Apr 14 23:59 z ===== 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

1 0

Re: OLE storage SetFilePointer fix
by Dimitrie O. Paun 14 Apr '03

14 Apr '03

On Sat, 12 Apr 2003, Andreas Mohr wrote: > P.S.: Alexandre, I'd REALLY like you to finally put a patch status > tracking system in place. The number of people submitting patches > for the second, third, bazillionth time is astonishing (I speak > from my very own experience, too!). I really don't know how many very > valuable Wine patches got lost due to not getting applied without any > status reply whatsoever... > (particularly the ones from "foreigners") > Someone recently said (in WWN) that patch management was perfect or > something to that extent. I better don't comment on that statement, > you know my hot temper ;) > OK, it's definitely not awful, but I guess it could be better. First off, I don't think the current system is bad. Second, I was the one this in the WWN (so sue me :P). Any system that we would put in place would have to work with email just like the current one. Other suck big time, see the SF one. Once you notice that, you realize that the problem is not the system, but rather that Alexandre needs to reply to patches he rejects, wether through email/web based form/what have you. Don't get me wrong -- I've been multiple times at the rejecting end of this, and it's frustrating. But in retrospective, it's all for a better Wine, and I'd be hard pressed to produce a patch which got rejected by Alexandre, and which I still think should be applied. Also, your assesment that 'very many valuable Wine patches got lost' is a gross exageration. In fact, please produce 3 such patches that got lost in the last year (heck, in the last 3 years for that matter). I think you'll have a hard time finding a single such patch in the last X years (choose X as you may) that match your description. There is good reason for this: people put work into their patches, and if they don't get apply, they ask why. This is where I don't understand Alexandre: he will eventually have to reply to such questions, why not do it proactively, it's the same amount of work, me thinks. But I'm not the one putting in the time and effort to sort through the patches, so I may be missing many things. -- Dimi.

4 4

patch tracking system redux
by Dan Kegel 14 Apr '03

14 Apr '03

Steven Edwards (steven_ed4153(a)yahoo.com) wrote: > --- Dominik Strasser <Dominik.Strasser(a)t-online.de> wrote: >> The attached patch implements proxies in wininet to an extent that at >> least IE6 install works behind a firewall. >> >> ChangeLog: >> partially implement proxy support in wininet >> >> This is the third time I am sending this patch. Is anything wrong with it ? > > I think we are starting to see we need a patch tracking system =) I think Alexandre feels differently. Have you read http://www.winehq.com/hypermail/wine-devel/2003/04/0384.html ? I do know of one patch tracking system that works well (http://www.kernel.org/pub/linux/kernel/people/rusty/trivial/) It's restricted to "trivial" patches, and wouldn't handle the wininet proxy change, but might still be useful for Wine. I dunno. Alexandre silently ignored several of my patches recently, but that's just fine with me. They needed more work, and it was pretty obvious to me which direction I needed to go in to make him happy. Since I care about them, I will keep plugging away until they meet his criteria. - Dan

1 0

Re: lostwages/templates/en todo_lists.template
by Vincent Béron 14 Apr '03

14 Apr '03

Jeremy Newman a écrit: > ChangeSet ID: 7866 > CVSROOT: /opt/cvs-commit > Module name: lostwages > Changes by: jnewman(a)wine.codeweavers.com 2003/04/14 11:03:55 > > Modified files: > templates/en : todo_lists.template > > Log message: > Dimitrie O. Paun <dpaun(a)rogers.com> > Update TODO Lists to Wine 0.9 TODO v0.8 from: > Â http://www.dssd.ca/wine/Wine-0.9-TODO-0.8.html > > Patch: http://cvs.winehq.com/patch.py?id=7866 > > Old revision New revision Changes Path > 1.4 1.5 +281 -258 lostwages/templates/en/todo_lists.template It would be nice if my last name (and maybe other people's names) wouldn't be mangled. This is due to the <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> in the header of the page, but with the use of UTF-8 chars in the body. On Dimi's site it looks fine (same header, but use of iso-8859-1 chars in the body). It might be in the transfer that the characters get transformed (had to chase something akin to that yesterday with a text attachment in Evolution). Vincent

1 0