wine-devel

wine-devel@winehq.org

9 participants
84397 discussions

FYI: ControlSpy has stopped working
by Guy L. Albertelli 10 Jun '01

10 Jun '01

Using the current CVS (6/9), certain ControlSpy modules (REBAR and COMBOBOXEX) no longer seem to work, even with the native versions of COMCTL32. The internal child windows in the left pane are no longer drawn. Seems to have occured sometime since 6/1. I will look into it tomorrow after some rest. Strange. Guy Albertelli <<galberte(a)neo.lrun.com>>

2 1

Re: FYI: ControlSpy has stopped working
by Gerard Patel 10 Jun '01

10 Jun '01

At 11:56 PM 09/06/2001 -0400, you wrote: >Using the current CVS (6/9), certain ControlSpy modules (REBAR and >COMBOBOXEX) no longer seem to work, even with the native versions of >COMCTL32. The internal child windows in the left pane are no longer drawn. >Seems to have occured sometime since 6/1. I will look into it tomorrow after >some rest. Strange. Strange ??? After this patch : ChangeSet ID: 991691718458116964902729 CVSROOT: /opt/cvs-commit Module name: wine Changes by: julliard@wine2. 01/06/04 17:55:18 (...) Log message: Create an X window for every window, including children. I see a lot of problems in most of my test apps after the implementation of this evil scheme. I have already sent several patches to work around some of these problems, two have been applied, one has been ignored so far, but even with this last Wine's status is beyond the usual breakage level. Gerard

2 1

Help needed
by Renukaprasad, MR 09 Jun '01

09 Jun '01

Hi, We are planning to port wine onto Tru64 Unix. I have some basic Questions. Can you tell me how to go about it. How do we start. How big is the task and how to start about it.. Thanks And Regards, Renuka

1 0

Re: VirtualProtect() fixup
by Alexandre Julliard 08 Jun '01

08 Jun '01

520053692817-0001(a)t-online.de (Andreas Mohr) writes: > (you do know that I disagree on these things, right ? after all Wine emulates > *Windows*, and if Windows does it that way, then we should do it, too, for > heaven's sake, especially if it's not really painful) There is no such thing as "Windows", there are multiple versions that do different things, and we have to choose what we emulate. In this case it's clear that it makes more sense to emulate the NT behavior, since this is what is documented. Of course we could do a winver check, but if we do this for every single difference between Win98 and NT, we'll end up with a mess of spaghetti code with more version checks than actual code. So winver checks must be limited to cases where they are demonstrably necessary for a real-world application. -- Alexandre Julliard julliard(a)winehq.com

1 0

Re: VirtualProtect() fixup
by Alexandre Julliard 08 Jun '01

08 Jun '01

520053692817-0001(a)t-online.de (Andreas Mohr) writes: > What isn't the case ? Both fixups ? Or only one of these ? The return value: NT returns a BOOL, 0 or 1. I haven't checked the old protection behavior; but anyway this doesn't belong in VirtualProtect, if we have to ignore the execute permission it must be done consistently throughout the code. > Well, to be exact, no application. > I just found this out by accident. That's what I suspected ;-) > IMHO the probability that some applications exist that are too lazy > to supply their own old_prot variable and that check the return value instead > is rather high, so I think that patch is necessary. We can't start breaking things based only on your suspicion that someone somewhere will have used a feature that isn't documented at all (plus there is a documented way of doing exactly the same thing). If you have an app that needs it sure, otherwise we'll just keep returning a BOOL, as the function is documented to do. > Maybe we should add a winver check, though. No thanks. -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: wcmd fix
by Francois Gouget 08 Jun '01

08 Jun '01

On Fri, 8 Jun 2001, Andreas Mohr wrote: > Hi all, > > file_size.XXXPart should be file_size.s.XXXPart. > > Thanks to Lasse Melsaeter for spotting this. That's the 'Dummy struct name problem in wcmd' I sent this morning. But actually whether there should an 's.' depends on the compiler (for Winelib applications) so you should test for NONAMELESSSTRUCT as I did in my patch. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ If it stinks, it's chemistry. If it moves, it's biology. If it does not work, It's computer science.

1 0

Re: VirtualProtect() fixup
by Alexandre Julliard 08 Jun '01

08 Jun '01

Andreas Mohr <a.mohr(a)mailto.de> writes: > VirtualProtect had two big problems: > > - undocumented return value > - should return protection flags only instead of whole flag setting This isn't the case under NT. Which application depends on that? -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Fwd: Re: WINE fix for HOMM3 [bluefire@zauberwald.net]
by Uwe Bonnes 07 Jun '01

07 Jun '01

>>>>> "BlueFire" == BlueFire <bluefire(a)zauberwald.net> writes: BlueFire> Now with the missing diff..... sorry... On Thu, 07 Jun 2001 BlueFire> 11:37:14 BlueFire wrote: >> This is messed up (totally unreadable) formatting. Anyway, how about >> doing a diff -u of your change, and then submitting that patch (in >> more readable form) either to Debian's BTS, or directly to >> wine-patches(a)winehq.com? BlueFire> Sorry, I'm not familiar with either diff or the debian BlueFire> bts. That's why I tried mailing the stuff to you (and to BlueFire> wine-patches). I did a BlueFire> diff /tmp/dos_fs.c dos_fs.c > dos_fs.c.diff Hallo, find some help at http://www.winehq.com/dev.shtml BlueFire> diff -u is preferred due to it's better readability. Appending the plain file makes it easier for others to read your patch. But don't " cut and paste", as that will ofter reformat and make the patch a pain to apply. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Question about the new window design
by Gerard Patel 07 Jun '01

07 Jun '01

Since the patch of 4 June, all windows are created as X windows. This makes one of my test apps to crash; it's creating a child window in the WM_NCCREATE event handling of a window. When the child window is created, X bombs because the X window parent does not exist yet - Wine is trying to call XCreateWindow with parent = 0. What is the best way of fixing this ? Gerard

1 0

Re: stack limit
by Alexandre Julliard 06 Jun '01

06 Jun '01

Stephen Crowley <stephenc(a)placemark.com> writes: > Works like a charm! Thanks. I'm curious though.. I set the stack size > to 64 megs and the application immediately uses up that much ram. Is > that the default behaviour on windows? What stops it from behaving > like a normal stack and just allocating what's needed from the heap? The ram isn't actually used, it's only reserved from the address space with an anonymous mapping. Only the pages that are really accessed will use physical memory/swap, so it doesn't use any more ram than a normal stack. -- Alexandre Julliard julliard(a)winehq.com

1 0

Jump to page:

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