wine-devel

wine-devel@winehq.org

84463 discussions

RE: runtest: new option -M for testing current module as builtin
by Patrik Stridvall 23 Jan '02

23 Jan '02

> On Wed, 23 Jan 2002, Patrik Stridvall wrote: > [...] > > BEGIN { > > require wine; > > &wine::module_native("wininet"); > > &wine::module_builtin("imm32", "msacm32"); > > } > > I am not sure any test should require the native version > of any dll. > > We cannot ship native dlls with Wine for obvious reasons, so requiring > the native dll would force Wine developpers to have a Windows > partition > installation around, and one configured for use in the tests. > Otherwise > they would not be able to run the tests, would they? > > I don't think that's good. Of course it shouldn't require it. It should simply skip parts of the test if the native version is not available. if(&wine::is_native("wininet")) { # Do native wininet tests } > Choosing to use a native dll is more up to the developper > to debug a > test. And then modifying the configuration file, as we usually do to > debug applications, should be simple and familiar enough. > > But maybe I misunderstood something. Well it allows us to automatically test a non-developer Windows installation directly under Linux without requiring him to reboot. Even developers make find it useful to quickly be able to modify the loadorder without having to modify his configuration. Sometimes what you want to test is quite subtle, like you have a function A in module B that calls function C in module D. Perhaps you want to test the robustness of Wines implementation of function A by testing it both with the native and the builtin version of D. If you have many such tests it would be a lot of unnessary manual work to switch D between native and builtin while testing B as builtin. Then perhaps somebody else have some use I haven't even though of. The main use will be I think to force tests to as the default test the builtin version since if you type "make test" in a directory you really expect to test the files in THAT directory, not the native version even if your ~/.wine/config specifies that.

1 0

Re: runtest: new option -M for testing current module as builtin
by Francois Gouget 23 Jan '02

23 Jan '02

On Wed, 23 Jan 2002, Patrik Stridvall wrote: [...] > BEGIN { > require wine; > &wine::module_native("wininet"); > &wine::module_builtin("imm32", "msacm32"); > } I am not sure any test should require the native version of any dll. We cannot ship native dlls with Wine for obvious reasons, so requiring the native dll would force Wine developpers to have a Windows partition installation around, and one configured for use in the tests. Otherwise they would not be able to run the tests, would they? I don't think that's good. Choosing to use a native dll is more up to the developper to debug a test. And then modifying the configuration file, as we usually do to debug applications, should be simple and familiar enough. But maybe I misunderstood something. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

1 0

Re: wine/windows dialog.c
by Uwe Bonnes 23 Jan '02

23 Jan '02

>>>>> "Alexandre" == Alexandre Julliard <julliard(a)winehq.com> writes: Alexandre> ChangeSet ID: 1011730184150795614346862 CVSROOT: Alexandre> /opt/cvs-commit Module name: wine Changes by: Alexandre> julliard@wine2. 02/01/22 15:09:44 Alexandre> Modified files: windows : dialog.c Alexandre> Log message: Removed no longer used average width Alexandre> calculation. Well, for the encarta 99 setup this gives the same bad result as before. I have attached a gif of the dialog in question. The manual calculation with the corrections in my resent patch gave better results. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

2 1

Microsoft's version of "WINE"
by Sander Wichers 23 Jan '02

23 Jan '02

Hi, Maybe you guys already seen this, and it's old news for you... but i'll post this anyway in case you didn't know. It can be a good thing to learn from. I do not own a SUN or a HP-UX system. But I was just interested how microsoft implemented IE 4 / IE 5 on HP-UX and SUN. So I extracted their installation files to disk. It seems that microsoft made their own version of wine. It's amazing that they didn't modified IE to run on unix. Instead they made the choice to emulate all the windows functionality. And compile IE on that. Microsoft is ready to run their applications on linux. They have a complete "system" libary full of ported functionality to SUN and HP-UX... all the libaries are there, libkernel32.so etc.... It's also nice to see how they seperated the resources from the binaries. and let the kernel deal with these resource files. Has any one of you looked into these system libaries? Is this information relevant to anyone? bye, Sander Wichers

1 0

Verbose tests ?
by Sylvain Petreolle 23 Jan '02

23 Jan '02

Hi, running programs/winetest/runtest -v -v -v -v -v tests/wine.pl or programs/winetest/runtest -vvvvv only reports : tests/wine.pl: 22 tests executed, 2 marked as todo, 0 failures. Is this the normal behavior or have I made something wrong ? ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Courrier : http://courrier.yahoo.fr

2 1

Open Letter to DOJ re Microsoft Settlement
by Dan Kegel 22 Jan '02

22 Jan '02

The proposed settlement in the Microsoft antitrust trial will probably be accepted by the judge unless a lot of people complain soon, even though it lacks any useful enforcement provisions and fails to prohibit many of Microsoft's anticompetitive practices. I've drafted an open letter to the Department of Justice to explain why the proposed settlement should not be accepted; it's at http://www.kegel.com/remedy/letter.html I'd be honored if you would read it, and consider signing it with me, or submitting your own comment to the DOJ. Either way, the federal deadline for public comment is Monday the 28th. For more information, see http://www.kegel.com/remedy/ See also Jeremy White's page http://www.codeweavers.com/~jwhite/tunney.html Sincerely, Dan Kegel

2 2

sparc solaris build
by Srdjan Matovina -- Customer Engineering 22 Jan '02

22 Jan '02

Hi, I've built wine-20011226 on sparc with the only one issue left open: The resource compiler wrc core dumps when hit the bitmap (BINRES) part of .rc file. There is an alignment problem inside convert_bitmap() in newstruc.c file. The alignment problem came out from BITMAPINFOHEADER struct. But this was just the beginning! I've commented out body of convert_bitmap() just to see what will happen when run libtest/hello test case. After running wineserver, the libtest/hello core with the same problem: Program terminated by signal BUS (invalid address alignment). This time at different place: RtlSecondsSince1970ToTime from ntdll.so (time.c) struct FILETIME. Obviously I'll have an alignment problem with every structure in general. Is there any guideline for this kind of problem? Thanks Srdjan

2 1

Re: [PATCH] Overlapped recv(), WSARecv()
by Martin Wilck 22 Jan '02

22 Jan '02

As you may see from the different email address, I am currently off work - I'll look deeper into your traces next week. Many thanks for generating them, anyway. >From a first glance, it seems that the app doesn't do overlapped recv(). (lpOverlapped & completion_func are always NULL), so there should actually be no difference (well I'm now using recvmsg() instead of recv(), and the overhead for 16 bit Winsock apps is definitely larger, but I cannot see why that should slow everything down that much). Perhaps I screwed up the blocking semantics of non-overlapped IO. Have you generated the traces under exactly the same conditions? Can you explain what exactly you did? Martin

3 7

Article about WINE on DesktopLinux.com
by Roland 22 Jan '02

22 Jan '02

Hello, I found a very interesting article about WINE there: http://www.desktoplinux.com/articles/AT5502857506.html I have to fully agree with that author, I think he is a real genius! :))) Roland

1 0

Re: Decorationless managed windows again
by Alexandre Julliard 21 Jan '02

21 Jan '02

Ove Kaaven <ovehk(a)ping.uio.no> writes: > The logic in this patch is now somewhat revised according to Alexandre's > comments. I did not make this configurable, though, thinking that if the > user's WM really is too old to support them, then he probably wouldn't > mind getting more top-level windows managed anyway... Top-level windows maybe not, but menus and tooltips with wm decorations are pretty annoying... so I applied it, but without the is_window_managed changes, we will need a better algorithm there. -- Alexandre Julliard julliard(a)winehq.com

2 4

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