wine-devel

wine-devel@winehq.org

2 participants
84469 discussions

Start a nNew thread

my first go at syncing opengl spec
by Tom 04 Feb '05

04 Feb '05

This is my first attempt at syncing the opengl spec. Is this close to what needs to be done? Tom

2 1

Re: [d3d9/device.c] IDirect3DDevice9Impl_GetDepthStencilSurface problem
by Ann and Jason Edmeades 04 Feb '05

04 Feb '05

Well yes and no. The 'problem' is most of this code isn't implemented yet... Try Olivers large patch and see if things are any better, or wait a while while a whole load of code gets into cvs. Basically d3d9 shouldn't have any of the code relating to the stencil buffers - that will be in wine3d. I am pretty certain Olivers patch did that, and he is working on splitting it up to get cvs in sync with his local tree. Jason

6 13

my first try at opengl spec sync
by Tom 04 Feb '05

04 Feb '05

Hello, This is the first time ive ever tried to sync with the SGI spec am I close to what needs to be done ? Tom

1 0

PRESS: run windows viruses with wine ...
by Marcus Meissner 04 Feb '05

04 Feb '05

Hi, Fun article ... author tests various viruses with WINE. http://os.newsforge.com/article.pl?sid=05/01/25/1430222&from=rss Ciao, Marcus

8 12

Re: Re: Newest winrash problems?
by Chris Morgan 04 Feb '05

04 Feb '05

There was a bug introduced in 0010 where I was fgets()'ing and checking for feof() on file opened with "wb". Thus the debug file was growing out of control. I released 0011 to fix this issue and I'm hoping that people get the upgrade when their PC's restart. Chris > > From: Paul Vriens <Paul.Vriens(a)xs4all.nl> > Date: 2005/02/04 Fri AM 03:36:56 EST > To: cmorgan(a)alum.wpi.edu > CC: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> > Subject: Re: Newest winrash problems? > > On Thu, 2005-02-03 at 16:21, Chris Morgan wrote: > > I'm not actually installing winsock2, just popping up a dialog during the installer mentioning that you need winsock2 if you are running on a win95 machine. What I *should* do is somehow get the nsis installer script to check for the winsock2 dlls and actually run the installer, but thats a bit more difficult than just displaying a dialog with text and a web link. > > > > Chris > Hi Chris, > > maybe you could have that one be de-selected on default? The number of > win95 running winrash seem to be outnumbered by the others. > > > > I had some problems with Winrash bailing out on 2 of my win98 systems. > > > Apparently this was because a new winrash was available and it tried to > > > install that? > > > After uninstalling winrash 0009 and installing 0010 it works again. One > > > of the main differences is that winrash 0010 has an extra winsock2 > > > install, could this be the cause? > > > > I saw there's now even a 0011. The following problems where observed by > me while the automatic upgrade took place: > > - for some reason the previous TAG was not used anymore. If you look at > http://test.winehq.org/data/200502031000/ you will see a load of > IDWASEMPTY's. (more than usual) > - On my WinNT4 box, the debug log file grew to 2GB! > > Both of the above where solved by un-installing what was there and > installing the latest. I do think there's something wrong in the > automatic upgrade of winrash. > > Cheers, > > Paul. > >

1 0

Re: appdb/ ./appview.php ./screenshots.php admin/a ...
by tony_lambregts＠telusplanet.net 04 Feb '05

04 Feb '05

WineHQ wrote: > ChangeSet ID: 15925 > CVSROOT: /opt/cvs-commit > Module name: appdb > Changes by: wineowner(a)wine.codeweavers.com 2005/02/03 20:55:50 > > Modified files: > . : appview.php screenshots.php > admin : adminAppDataQueue.php editAppFamily.php > editAppVersion.php > include : screenshot.php user.php > tables : appdb_tables.sql > > Log message: > Jonathan Ernst <Jonathan(a)ernstfamily.ch> > - no more appId in appData as appVersion implies an appId* > - screenshot class has been reworked to remove need of appId > - screenshot class has been improved to send e-mails so that email handling can be removed from other scripts > > Patch: http://cvs.winehq.org/patch.py?id=15925 > > Old revision New revision Changes Path > 1.47 1.48 +7 -18 appdb/appview.php > 1.25 1.26 +30 -91 appdb/screenshots.php > 1.10 1.11 +80 -107 appdb/admin/adminAppDataQueue.php > 1.25 1.26 +0 -131 appdb/admin/editAppFamily.php > 1.20 1.21 +3 -10 appdb/admin/editAppVersion.php > 1.8 1.9 +237 -46 appdb/include/screenshot.php > 1.34 1.35 +38 -17 appdb/include/user.php > 1.18 1.19 +0 -2 appdb/tables/appdb_tables.sql > > > Bah! How are extra links in the appfamily suposed to work? Of course you seem to think that these are not important so you simply removed them from edit appfamily &%@#!. This is wrong ! -- Tony Lambregts

1 0

Re: Software Freedom Law Center
by gslink 04 Feb '05

04 Feb '05

Here is something else to consider. With respect to property taxes, who owns a piece of software and who is liable for the taxes on it? Some of the current licenses may well make the software seller and not the buyer liable in some states.

1 0

BUG: text alignment in editboxes
by George Ginden 04 Feb '05

04 Feb '05

It looks like text alignement is not implented or working correctly. Just run calc.exe in Windows then in Wine. Pay attention at where the digits are shown... I can also provide a simple C program to be used as testbed. See bug : 2698 Regards.

1 0

RICHEDIT again
by Krzysztof Foltman 04 Feb '05

04 Feb '05

It seems that I already have something useful. I've added multilevel undo/redo, GetCharFormat/SetCharFormat (very incomplete) and modify flag, and cleaned up the code a lot. The source code is downloadable from here: http://foltman.com/richtext-20050204.tar.gz I'll try to add handlers for basic editing messages (like WM_SETTEXT) and maybe notifications too, DLLize it and then make a Wine patch out of it. Is that OK ? It's not like everything is done the way it should be (for instance, coordinate system is still pixel-based and not twips-based), but in this stage the risk of having to constantly rewrite everyone else's code is much lower. Krzysztof

2 1

Re: [user32/tests/sysparams.c] Add an extra trace
by Paul Vriens 04 Feb '05

04 Feb '05

On Fri, 2005-02-04 at 09:58, Paul Vriens wrote: > Hi, > > winrash just ran on my win98 box and the sysparams test didn't complain > about SPI_GETICONTITLEWRAP not being implemented. If I however run the > test manually (with an extra trace) win98 tells me it's not > implemented!! > > So to have some more input about this, I added an extra trace. It could > be that ERROR_INVALID_SPI_VALUE has something to do with this. > > Changelog > extra tracing for SPI_GETICONTITLEWRAP > > Cheers, > > Paul This needs more investigation. Some extra testing showed that LastError is not always set by the calls (all?). I added traces to all the calls and suddenly nothing was implemented anymore. Then I added a SetLastError(0) before every call and the output was totally different again. The only thing not implemented anymore on my win98 box was SystemParametersInfoW. So what's the best approach: - add a SetLastError(0) in every test-routine before we do something? - add a trace after each SystemParametersInfo call? - find out which call sets LastError and which calls don't? Cheers, Paul.

1 0

Re: Newest winrash problems?
by Chris Morgan 04 Feb '05

04 Feb '05

I'm not actually installing winsock2, just popping up a dialog during the installer mentioning that you need winsock2 if you are running on a win95 machine. What I *should* do is somehow get the nsis installer script to check for the winsock2 dlls and actually run the installer, but thats a bit more difficult than just displaying a dialog with text and a web link. Chris > > From: Paul Vriens <Paul.Vriens(a)xs4all.nl> > Date: 2005/02/03 Thu AM 03:19:52 EST > To: "wine-devel(a)winehq.org" <wine-devel(a)winehq.org> > Subject: Newest winrash problems? > > Hi, > > I had some problems with Winrash bailing out on 2 of my win98 systems. > Apparently this was because a new winrash was available and it tried to > install that? > After uninstalling winrash 0009 and installing 0010 it works again. One > of the main differences is that winrash 0010 has an extra winsock2 > install, could this be the cause? > > Cheers, > > Paul. > > >

2 1

Last change to wine/dlls/comctl32/header.c caused regression in Shareaza (downloadable source)
by Tony Lambregts 03 Feb '05

03 Feb '05

According to bug 2659 http://bugs.winehq.org/show_bug.cgi?id=2659 This patch http://www.winehq.org/hypermail/wine-cvs/2005/01/0232.html causes a regression in Shareaza. http://www.shareaza.com/?id=download I have tested this myself and it is definitely this patch. Backing out this change with current cvs allows Sharaza to work. The the source code for this program is available at http://sourceforge.net/project/showfiles.php?group_id=110672&package_id=119… -- Tony lambregts

1 0

Re: [variant] partial support for nulls + emptys converted to numbers.
by Marcus Meissner 03 Feb '05

03 Feb '05

On Thu, Feb 03, 2005 at 02:28:03PM +0000, Oliver Stieber wrote: > Hi, > I've had this lurking around in my tree for a while, > the patch starts to support mixing nulls or emptys > with integers (basically null == 0 and empty == 0) The patch does not match your description. It looks like some huge D3D diff instead ... Ciao, Marcus

1 0

Wine pthread_detach problem
by Sergey Efimoff 03 Feb '05

03 Feb '05

Hi All, While doing experiments with winegcc/wineg++ I have compiled my application which uses complex multi-threaded library. Wine made shell wrapper script for me and the application itself with the extension .exe.so. I tried to run this application: FIXME:pthread_detach FIXME:pthread_detach Bad system call (core dumped) or, as another option: FIXME:pthread_detach wine: Unhandled exception (thread 000a), starting debugger... How can I handle this failure? //Sergey.

1 0

Re: GDI: implement color management functions
by Alexandre Julliard 03 Feb '05

03 Feb '05

Hans Leidekker <hans(a)it.vu.nl> writes: > This patch doesn't go as far as allocating and initializing a color > space on DC creation. It simply creates (a dummy) one when asked for, > to avoid any impact on performance. It also doesn't fully implement > color space handles, instead it simply casts a pointer to a handle > and back. This cannot possibly work, the pointer won't remain valid. If you don't want to implement proper handles then return something like 0xdeadbeef and print a FIXME so that it's at least obvious that something's not working right. Your approach will only lead to mysterious crashes. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [shlwapi/tests/shreg.c #6] More verbosity
by Alexandre Julliard 03 Feb '05

03 Feb '05

Paul Vriens <Paul.Vriens(a)xs4all.nl> writes: > This patch add more verbosity. I also changed some of the ok(0,) into a > trace. I don't think we want to do that, this is just hiding problems. If a test cannot run this should be flagged as an error. -- Alexandre Julliard julliard(a)winehq.org

1 0

x11drv regression?
by Oliver Stieber 03 Feb '05

03 Feb '05

Hi, I've just synced with CVS and the following code and I can no longer get an x11 window ID using (Window)GetPropA(HWND,"__wine_x11_client_window" ); I've had a look at X11DRV and there have been a few changes reciently, should I be using something else? ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com

7 9

Re: [user32/tests/sysparams.c] Check for availability of SPI_GETICONTITLEWRAP
by jchevrier＠nexicom.net 03 Feb '05

03 Feb '05

> Hi, > > SPI_{GET,SET}ICONTITLEWRAP is not implemented on a standard Win98 SE. > > Changelog > Check for availability of SPI_GETICONTITLEWRAP > > Cheers, > > Paul. Hi Paul, I agree we definately should not be leaving keys/values in user's registries that weren't there originally after the test has been run. Ideally all should be returned to exactly the way it was before the test was run. Unfortunately this patch won't correct the issue. This patch implies that SPI_{GET,SET}ICONTITLEWRAP is not a supported call on Win98 which it is. As a result it will always pass and the registry will still get a new value added. Try the following patch. It was just put together quickly and only covers this one test, but testing here shows it does stop a new value from being added if it did not exist to begin with. I would like to create something that covers the entire sysparams suite of tests to stop this across the board. Thanks for the heads up on this! Justin

3 6

Newest winrash problems?
by Paul Vriens 03 Feb '05

03 Feb '05

Hi, I had some problems with Winrash bailing out on 2 of my win98 systems. Apparently this was because a new winrash was available and it tried to install that? After uninstalling winrash 0009 and installing 0010 it works again. One of the main differences is that winrash 0010 has an extra winsock2 install, could this be the cause? Cheers, Paul.

1 0

Re: RESEND: Enable GCOV Code Coverage
by Daniel Kegel 03 Feb '05

03 Feb '05

Alexandre wrote: > The changes may be small but they are ugly IMO. I don't think we need > a configure option for that, it should be possible to simply do a > 'make CFLAGS=xxx' with the appropriate options. We used a configure option by analogy with --disable-debug, I guess, and because it seems to be the standard way to do it (a quick search shows that at least ImageMagick, PlaylistManager, oprofile, xfce, gstreamer, dbus, plt-scheme, matchbox, KDE-Darwin, lsh, and many others do it with --enable-gcov). We'd be happy to rework it any way you like, if you think following existing practice by using --enable-gcov is a bad idea. We have a very small follow-on patch which adds lcov support. lcov is a nice postprocessor for gcov that makes a pretty HTML report for all of wine showing how well the Wine test suite covers the code. We also have an enhancement to lcov pending which lets you see which lines of Wine are exercized by an application but not by Wine's regression test suite. - Dan

1 0

Re: [winecfg] Clean up about dialog
by Mike Hearn 02 Feb '05

02 Feb '05

On Wed, 02 Feb 2005 21:34:00 +0100, Paul van Schayck wrote: > Changelog: > Clean up about dialog. Remove groupbox, position logo correctly. Cool! If you want to do some winecfg hacking integrating the drive detection with wineprefixcreate is like a 5 minute job.

1 0

Re: [OLE #62] Rework the RPC dispatch layer
by Alexandre Julliard 02 Feb '05

02 Feb '05

Mike Hearn <mh(a)codeweavers.com> writes: > ChangeLog: > - Rework RPC dispatch layer to be simpler and not get confused by > server/client duality > - Make threads shut down at the right time and not access freed > memory after apartment destruction > - Rename stub_dispatch_thread to client_dispatch_thread > - Add some more tracing This badly breaks the regression tests, apparently triggering a bug in the named pipe handling on the server side. I'm afraid I can't apply the patch until this is fixed. -- Alexandre Julliard julliard(a)winehq.org

3 4

Re: RESEND: Enable GCOV Code Coverage
by Robert Shearman 02 Feb '05

02 Feb '05

Aaron Arvey wrote: >This is the third or fourth resend... anything I'm unaware of? > > > >We're using gcov and lcov to measure how well the Wine test suite >covers the wine source tree. Here's our first cut at making it easy >to run wine compiled for coverage testing, and view the results >using the simple text interface of gcov. A seperate patch for >lcov will be released soon. > > I think the issue with this patch is that it isn't it doesn't appear to be useful for a significant number of people and could be maintained as an external patch by the people who do think it's useful. Maybe you could try to persuade us as to why everyone should be using gcov? Rob

3 3

Wine desktop properties ?
by George Ginden 02 Feb '05

02 Feb '05

Hi all, before I try and go through the code, is there any config option or registry entry to set the Wine's Desktop Background with an image or a different color ? Thanks.

2 1

advapi32:registry.c tests failing
by Aaron Arvey 02 Feb '05

02 Feb '05

I noticed that advapi32:registry was failing on my windows xp machine 28 times, but succeeding in my wine regression test runs. I investigated what lines were causing failures and changed some the values so that the errors wouldn't exist on the windows test run. This now causes wine test runs to fail. I looked through test.winehq.org and found the following: Here it works (last time it worked) http://test.winehq.org/data/200411101000/ Here it fails 28 times (first time it looks like it failed) http://test.winehq.org/data/200411201000/ Here it also fails 28 times (most recent) http://test.winehq.org/data/200502011000/ I wanted to know if there was something I'm misunderstanding or missing. If not I'm going to change the registry.c tests to work on Windows XP and thus fail on Wine. Thanks for the information. Aaron

3 2

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