July 2003 - Wine-Devel - list.winehq.org

Re: [patch] documentation patches

by Peter Hanecak

Hello, On 22 Jul 2003, Vincent [ISO-8859-1] Béron wrote: > Le mar 22/07/2003 ŕ 12:43, Peter Hanecak a écrit : > > > > while building Wine on "RedHat 8"-like system I encountered two typos in > > Wine documentation which prevented me from "compiling" documentation with > > jade (openjade-1.3.1-9). > > I'm interested in how exactly it prevented you to compile them, as I > didn't have any problem to do so (although some other errors have caused > the compilation to fail in the past). > > Special more strict switch? Docbook validator? maybe this is what's "the cause": $ nice make doc docbook2html -d ./default.dsl -o wine-devel wine-devel.sgml Using catalogs: /etc/sgml/sgml-docbook-3.1-1.0-14.cat [...] There are then two things I have to solve: 1) patch to build.sgml: I was quite hasty and sent it before final test so it is incomplete - I'll send verified and hopefully complete patch soon. 2) I have more sgml-docbook-*.cat in /etc/sgml: sgml-docbook-3.0-1.0-14.cat sgml-docbook-3.1-1.0-14.cat sgml-docbook-4.0-1.0-14.cat sgml-docbook-4.1-1.0-14.cat sgml-docbook-4.2-1.0-14.cat And none of them is part of any RPM package so I wonder how they get there (leftover from some older quite "broken" package?). But that's not related to Wine I assume. Sincerely Peter -- ======================================================== Peter Hanecak <hanecak(a)megaloman.sk> GPG pub.key: http://www.megaloman.sk/gpg/hanecak.txt ========================================================

July 25, 2003

Focus Bug

by Dimitrie O. Paun

Summary: Clicking on the caption of a manage window does not move the focus as it should. This results in ugly artifacts. Steps to reproduce: 1. Fire up Notepad 2. Open the "Open" dialog (File | Open) 3. Expand the "Look in" dropdown (the one at the top, with the drives) 4. Click on the dialog caption, and drag it away Result: The dropdown does not close, and remains on the spot. Any way to know that the WM has now the focus, so we can release it? -- Dimi.

July 25, 2003

Re: Child's OninitDialog and Parent's OnKillFocus

by Dmitry Timoshkov

"Omer Sahin (Link Bilgisayar)" <osahin(a)linkbilgisayar.com.tr> wrote: > In a CFormView , I create and display a CToolbarDialog. I use DoModal to > display the dialog. > A control (in Parent Windows) 's OnKillFocus event is called AFTER the > child dialog's OninitDialog. > This seems meaningfull to me, but in my Windows 2000 professional machine, > child's OninitDialog is > called BEFORE parent control's OnKillFocus. What should be done to correct > this problem? If you could create a really small test case (no MFC, pure Win32 API) and post it here, somebody would have a look. -- Dmitry.

July 25, 2003

Re: Is wine a debugger?

by Alex Pasadyn

Dan Timis wrote: > I am trying to load a security Windows dll that does not run under a > debugger. When I load the dll I get a SIGTRAP, and then wine breaks in > its debugger. > > My understanding is that if I run wine as opposed to winedbg I am not > running under a debugger. But, if there is a crash or some other > exception wine will start a debugger. > > I sent some memory dumps to the developer of the security dll, and he > said that it behaves like it was running under a debugger. He's > question was something like does wine have an always "on" debugger? > I have seen this kind of thing before. I had a program that was doing this, and to get around it I changed the "Windows version" for Wine from one of the "DOS-based" ones to one of the "NT-based" ones. This may or may not work for you. It depends on what exactly the program is trying to do to detect a debugger. I just tried setting the version to NT because I figured that the things it allowed were closer to what would be allowed on Linux, and it happened to be that whatever it tried to do on NT gave the "correct" answer on Wine. But yes, the Wine debugger loads as a new process only after a crash is detected. What is happening is the program is poking around in memory somewhere and seeing something different from what it expects. Cheers, -ajp

July 25, 2003

Still problmes about building winelib dll using winemaker and winedump

by dd jj

Hello everyone, Sorry to bother if there are lots of repeated comments with my original posts... So far, I failed to use winelib dll generated by wine tools: 1)winemaker: I copied all windows source codes (.h .c .dll .dsp files which are used to build natives dll under visual studio) into one directory, then execute: %winemaker --lower-uppercase -nomfc . %./configure --with-wine-includes=/usr/local/inlcude/wine/windows %make When I run wine ./ping.exe it shows the error then terminate: err:module:import_dll Loading module (file) pingdll.dll (which is needed by C:\ping\ping.exe) failed (error -1073741595) (Sorry, I forgot to mention this last time) 2)winedump: I generated a stub dll which fowarded all the requst to native dll, but I can't figure it out where I can put the exported function codes to the stub dll, cause I need reimplement windows dll to be a local shared library. Could anyone give me some comments on what I should solve these? I really got headache on this... Thanks a lot. -Lechun --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software

July 25, 2003

Re: Status_Wine #2 -- lostwages

by Tom

Brian Vincent C wrote: > > >> So, may I ask if either of you plan to volunteer to write a *official* > >> History/Time line page ? > > > >Im no writer, really, so no, I don't plan on working on this. > >Hopefully a better word craftsman will volunteer soon... > > Pencil me in on this. I already have the makings of it. > Hmmm.. Add me in as well ill work as a helper if you wish along with Dustin & Joel. Dimi, since you have been here for a very long time i'm sure you could help on factiual accounts ;) (proof reader) Just let me know where to start.... Tom > --------------- > Brian Vincent > Copper Mountain Telecom > vincentb(a)coppercolorado.com >

July 25, 2003

Is wine a debugger?

by Dan Timis

I am trying to load a security Windows dll that does not run under a debugger. When I load the dll I get a SIGTRAP, and then wine breaks in its debugger. My understanding is that if I run wine as opposed to winedbg I am not running under a debugger. But, if there is a crash or some other exception wine will start a debugger. I sent some memory dumps to the developer of the security dll, and he said that it behaves like it was running under a debugger. He's question was something like does wine have an always "on" debugger? I would appreciate any help. Thanks, Dan Timis Muse Research, Inc.

July 25, 2003

Re: Make aclocal.m4:WINE_GET_SONAME more flexible

by Alexandre Julliard

Todd Vierling <tv(a)pobox.com> writes: > Nor is there a guarantee that the non-full path is ABI compatible on other > systems, which was the point of allowing the full path (for system > libraries, mind you, not Wine's own) through. I don't see why it wouldn't be ABI compatible; that's the whole point of finding the soname, so that we get the proper version of the library. The full path is completely irrelevant; when you dynamically link an app the linker doesn't store the full path to the system libraries either, just the soname. That's exactly what we are doing here. -- Alexandre Julliard julliard(a)winehq.com

July 24, 2003

Re: Make aclocal.m4:WINE_GET_SONAME more flexible

by Todd Vierling

On Thu, 24 Jul 2003, Alexandre Julliard wrote: : I don't think that's a good idea. There is no guarantee that the full : path is valid on other systems, Nor is there a guarantee that the non-full path is ABI compatible on other systems, which was the point of allowing the full path (for system libraries, mind you, not Wine's own) through. Hm. I can remake the patch with a path strip expression, if that would suit you. -- -- Todd Vierling <tv(a)pobox.com>

July 24, 2003

Re: Make aclocal.m4:WINE_GET_SONAME more flexible

by Alexandre Julliard

Todd Vierling <tv(a)pobox.com> writes: > The following patch to aclocal.m4 (will require a run of "autoconf" after > changing to pick up the change) will make WINE_GET_SONAME work on NetBSD, > and likely the other *BSDs. It is still Linux compatible -- in fact, this > new incarnation returns the fully qualified path to the shared object, > eliminating fears of runtime linking path searches. I don't think that's a good idea. There is no guarantee that the full path is valid on other systems, and we don't want to bypass the user's LD_LIBRARY_PATH settings. -- Alexandre Julliard julliard(a)winehq.com

July 24, 2003