wine-devel

wine-devel@winehq.org

2 participants
84488 discussions

New user/developer has questions ...
by Crispen Scott 16 Aug '02

16 Aug '02

I have just RPMed wine-20020512-1.i386.rpm and attempted to run several WIN programs (to wit: sol.exe and a proprietary package). Both fail. I am including the entire run/error message from my attempt to run sol.exe below. Being new to WINE, I have no idea where to begin to find the problem. I have annotated the error message with notes. All notes are separated by a <NOTE - TEXT> then a CR and follows the line(s) that the NOTE applies to. [root@localhost root]# wine /mnt/windows/windows/system32/sol.exe <NOTE - This is the command line entry > err:reg:_convert_win95_registry_to_wine_format unable to load native win95 registry file C:\WINDOWS\system.dat: unknown signature. err:reg:_convert_win95_registry_to_wine_format Unable to load native win95 registry file C:\WINDOWS\system.dat. err:reg:_convert_win95_registry_to_wine_format Please report to a.mohr(a)mailto.de. err:reg:_convert_win95_registry_to_wine_format Make a backup of the file, run a good reg cleaner program and try again! <NOTE - The SYSTEM.DAT file located in the windows SUBDIR was exported from regedit.exe. This is from a WIN2K OS > fixme:win32:PE_CreateModule Security directory ignored <NOTE - I assume this is a FIXME in the SRC> err:font:AddFontFileToList Unable to load font file "/mnt/windows/windows/Fonts/desktop.ini" err = 55 <NOTE - This file exists in the proper location so what is the error?> err:font:AddFontFileToList Already loaded font L"Garamond" L"Bold" err:font:AddFontFileToList Already loaded font L"Garamond" L"Italic" err:font:AddFontFileToList Already loaded font L"Garamond" L"Regular" err:font:AddFontFileToList Unable to load font file "/mnt/windows/windows/Fonts/modern.fon" err = 2 err:font:AddFontFileToList Unable to load font file "/mnt/windows/windows/Fonts/mtsorts.ttf" err = 2 err:font:AddFontFileToList Unable to load font file "/mnt/windows/windows/Fonts/roman.fon" err = 2 err:font:AddFontFileToList Unable to load font file "/mnt/windows/windows/Fonts/script.fon" err = 2 <NOTE - These files exist so why are they able to be loaded?> X Error of failed request: XF86DGANoDirectVideoMode Major opcode of failed request: 136 (XFree86-DGA) Minor opcode of failed request: 22 (XDGAOpenFramebuffer) Serial number of failed request: 181 Current serial number in output stream: 181 <NOTE - What does this indicate?> I am trying to come up to speed on the use of WINE but, as everyone knows, the documentation is a little light as is the commenting of the source code. If someone could please head me in the right direction, I would greatly appreciate it. Once I have gained some additional expertise in WINE I will use my 15+ years of Windows development experience and knowledge to try and resolve some of the issues and bugs that are reported. This may take me several more weeks. I am also intending to write a technical book on WINE so will submit chapters for review to the community as the become available. Much of the information will deal with the issues the I, as a newbie, am encountering. I await the response. Crispen Scott BTW: I downloaded the source for 20020804 and, after fixing several build related problems (incorrect build order, root objections, & eliminating programs with build problems I couldn't readily resolve, i.e. widl), I had even worse problems with trying to get that version of wine to run. That is why I reverted to the latest RPM version. Some of the problems with the 20020804 build might be resolved after I see the answers to the problems I stated above. I am excited about becoming an integral part of this community but need some start-up help! Thanks! -- Crispen Scott Engineer - Software Astronautics.com 4115 Teutonia Road Milwaukee, WI 53209 Tel: 414-447-8200 x4434 C.Scott(a)Astronautics.com

2 1

RE: what's with WS_OVERLAPPED?
by Rolf Kalbermatter 16 Aug '02

16 Aug '02

On Thu, 15 Aug 2002 "Medland, Bill" <Bill.Medland(a)accpac.com> wrote > >> On Wednesday, August 14, 2002 Ove Kaaven [mailto:ovehk@ping.uio.no] wrote: <snip> >> WS_OVERLAPPED is in practice considered the absence of the >> WS_POPUP and >> WS_CHILD flags, I believe. > >Thanks Ove; that'll do for a working hypothesis. (I wish Microsoft would be >consistant) > >Just for the record it is clearly more complex than that. I guess since >Microsoft wrote it we can trust Spy++ a little. I have seen spy++ declare >that a "tooltips" class window (style 0x84800000/00000088) has style >WS_OVERLAPPED whereas a "tooltips_class32" class window (style >0x84800003/00000088) doesn't. Hmm, this is just a wild guess but couldn't it be that the WS_OVERLAPPED style applies only to the lower word of the windows style. Windows coming from 16bit DOS it wouldn't be surprising if the original windows style was 16 bit only as well. Either that or Spy++ has a bug, even though you trust it so much ;-). Rolf Kalbermatter mailto:rolf.kalbermatter@citeng.com

1 0

Re: wine/ dlls/gdi/Makefile.in dlls/gdi/bidi16.c d ...
by Dimitrie O. Paun 16 Aug '02

16 Aug '02

On August 15, 2002 08:42 pm, Alexandre Julliard wrote: [...] > Log message: > Moved a large number of 16-bit functions to a separate gdi16.c file. This is a great idea that I've been advocating for a loooong time now <g>. I think moving 16 bit code into separate files is cool: -- runtime efficiency: If 16 bit code is not invoked, it's not going to be paged in during execution -- code neatness: developers working on the 32-bit code (which is _the_ code in Wine) will not get distracted by silly 16-to-32-to-16 bit conversions. -- helps correctness: 16-bit code is in general a simple: 16-to-32 bit conversion call the 32-bit equivalent function 32-to-16 bit conversion Which means there is a lot of repetition, template-like coding. Any departure from the usual pattern is a *lot* more easily spotted by the naked eye if it's present in a file that does just that. -- 16-to-32 bit: we can more easily see (and fix) cases where 32 bit code calls 16 bit code. For all these reasons, I think we should have _all_ 16-bit code into separate files. Always. Who knows, maybe we can have makefiles done such a way that we can avoid compiling 16 bit code altogether! :) Even if only as a simple check that no 32 bit code calls down to 16 bit... And again, the _same_ rationale applies to xxxW & xxxA functions, but I'll not pursue this point for now ;). -- Dimi.

1 0

Re: window parent/owner handling
by Dmitry Timoshkov 16 Aug '02

16 Aug '02

"Medland, Bill" <Bill.Medland(a)accpac.com> wrote: > Includes my previous patch for SetWindowLong (for Bug 825) Seems that your investigations are correct, at least test succeeds under win2000. I would suggest to apply tiny patch (attached) to catch some additional problems. -- Dmitry.

1 0

RE: Some observations on window parentage etc.
by Medland, Bill 15 Aug '02

15 Aug '02

> -----Original Message----- > From: Medland, Bill [mailto:Bill.Medland@accpac.com] > Sent: Thursday, August 15, 2002 8:59 AM > To: Wine devel (E-mail) > Subject: Some observations on window parentage etc. > > > Here are some observations with regard to Window > parentage/ownership etc. snip > > More to follow. > > Bill > OK guys; who can justify the claim in the server (set_window_owner) that the owner and the window must have the same parent? I think it is untrue, but I don't know what it should be. I believe we need to extend the WIN_SetOwner to return the previous owner. Should we take that out of the structure on the user side or should we modify the server reply to return it? I guess modifying the server reply is the safer option and should have no performance penalty. So here is what I am looking at doing. (I'd prefer comments here rather than after I submit the patch) 1. Modify the set_window_owner reply to return both the new full handle and the previous full handle. (p.s. what is this full handle anyway? Why is it different from the one passed in the request?) 2. Modify the set_window_owner handler to fill in the reply and also remove the parent test (or replace it with anything you guys think makes sense) 3. Modify WIN_SetOwner to return the value 4. Leave GetParent as it is 5. Modify GetWindowLong (GWL_HWNDPARENT to return the parent if a WS_CHILD and the owner otherwise (even if not a WS_POPUP) 6. Modify GetAncestor (GA_ROOTWINDOW) to return the same as recursing on GetParent. 7. Write a test set. Comments? Bill

1 0

RE: Re:can windows be reparented?
by Medland, Bill 15 Aug '02

15 Aug '02

> -----Original Message----- > From: Dmitry Timoshkov [mailto:dmitry@baikal.ru] > Sent: Thursday, August 15, 2002 10:00 AM > To: Medland, Bill > Cc: wine-devel(a)winehq.com > Subject: Re: Re:can windows be reparented? > > > "Medland, Bill" <Bill.Medland(a)accpac.com> wrote: > > > (Do you want the test case code?) > > Why not? :-) > > -- > Dmitry. > > > First is without WS_POPUP, second is with

1 0

RE: Re:can windows be reparented?
by Medland, Bill 15 Aug '02

15 Aug '02

> -----Original Message----- > From: Dmitry Timoshkov [mailto:dmitry@baikal.ru] > Sent: Thursday, August 15, 2002 9:17 AM > To: Medland, Bill > Cc: wine-devel(a)winehq.com > Subject: Re: Re:can windows be reparented? > > > "Medland, Bill" <Bill.Medland(a)accpac.com> wrote: > > > Honest question : how do you know the parent is changing? > by calling > > GetWindowLong (GWL_HWNDPARENT)? > > Yes, and verifying the result in Spy++. (As discussed in my other email) I guess Spy++ is displaying the result of GetWindowLong > > > I believe that it is the owner that is changing and the > parent (as returned > > by getAncestor (GA_PARENT) willl be unchanged. > > Hmm, I didn't try GetAncestor(), only GetWindowLong() and GetParent(). (Do you want the test case code?) > > -- > Dmitry. > > >

2 1

RE: Re:can windows be reparented?
by Medland, Bill 15 Aug '02

15 Aug '02

> -----Original Message----- > From: Dmitry Timoshkov [mailto:dmitry@baikal.ru] > Sent: Tuesday, August 13, 2002 6:33 PM > To: us(a)the-edmeades.demon.co.uk > Cc: wine-devel(a)winehq.com > Subject: Re: Re:can windows be reparented? > snip > Could you please test patch posted by Bill Medland to > wine-patches today? It's > not entirely correct though. My tests show that > SetWindowLong(GWL_HWNDPARENT) > call changes simultaneously both parent and owner for top > level windows and > returns old value (not sure old owner or parent it is). Honest question : how do you know the parent is changing? by calling GetWindowLong (GWL_HWNDPARENT)? I believe that it is the owner that is changing and the parent (as returned by getAncestor (GA_PARENT) willl be unchanged. snip Bill

2 1

Some observations on window parentage etc.
by Medland, Bill 15 Aug '02

15 Aug '02

Here are some observations with regard to Window parentage/ownership etc. Clearlt Microsoft documentation is quite out of date and contradictory on the subject these days so we are going to have to experiment and find out what actually happens. We also are going to have to be careful about terminology and not jumping to conclusions. I mean what ther heck are we supposed to think when Spy++ shows a window as a top-level window (by which I mean just below the desktop in the listview that Spy++ uses), tells us that its parent is its owner (a different top-level window) but that "parent" says it has no children. So. 1. GetParent does not necessarily return the same value as GetWindowLong (GWL_HWNDPARENT). I have seen GetParent returning 0 while GetWindowLong returns the same non zero value as GetWindow (GW_OWNER). 2. GetAncestor (GA_PARENT) seems to be the best way to get the "true parent". 3. WIN_CreateWindowEx is currently slightly wrong. I know MSDN says don't mix WS_POPUP and WS_CHILD but if you do then the result is wrong, I believe. However I am loth to fix it and submit the patch because that really messes everything else up so I guess we need a bigger patch first. (Heck, even under windows 98 you can get the kernel to fall over rather easily this way). 4. I don't like the look of GetAncestor (GA_ROOTOWNER). The MSDN documentation suggests that it should return the result of recursively calling GetParent (or should it be recursively calling GetWindowLong (GWL_HWNDPARENT) whereas GetAncestor (GA_ROOT) should return the result of recursively calling GetAncestor (GA_PARENT) (each stopping just before the desktop, of course). (And of course that is definition, not necessarily mechanism) More to follow. Bill

1 0

RE: what's with WS_OVERLAPPED?
by Medland, Bill 15 Aug '02

15 Aug '02

> -----Original Message----- > From: Ove Kaaven [mailto:ovehk@ping.uio.no] > Sent: Wednesday, August 14, 2002 11:08 AM > To: Medland, Bill > Cc: Wine devel (E-mail) > Subject: Re: what's with WS_OVERLAPPED? > > > > On Wed, 14 Aug 2002, Medland, Bill wrote: > > > (Regarding the whole issue of windows reparenting) > > > > MSDN keeps going on about windows with the WS_OVERLAPPED > style. However > > surely (since WS_OVERLAPPED=0) every window has such a > style these days. > > > > Is there something I don't understand? > > WS_OVERLAPPED is in practice considered the absence of the > WS_POPUP and > WS_CHILD flags, I believe. > Thanks Ove; that'll do for a working hypothesis. (I wish Microsoft would be consistant) Just for the record it is clearly more complex than that. I guess since Microsoft wrote it we can trust Spy++ a little. I have seen spy++ declare that a "tooltips" class window (style 0x84800000/00000088) has style WS_OVERLAPPED whereas a "tooltips_class32" class window (style 0x84800003/00000088) doesn't. Bill

1 0

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