wine-devel

wine-devel@winehq.org

5 participants
84465 discussions

Installing Internet Explorer without windows
by Boris 04 Dec '02

04 Dec '02

I just tried installing IE 5.5 from setup.exe and it never seems to install properly without windows being installed or modifying files. It would be nice to install Internet Explorer without patching anything. I hope more people work towards that.

3 2

HTML Help and IWebBrowser status
by Ender 04 Dec '02

04 Dec '02

Hi all, I'm just posting a quick update on my various WINE work for those intrested. I currently have a working HTML Help viewer, which seems to work pretty well on everything I've tested so far. It does however need some more work to conform to the way the real HTML Help system works in Windows (eg, I havn't written an ActiveX control for it yet). Currently the HTML Help viewer requires an IWebBrowser interface, and only really works with an Internet Explorer installation - so I don't believe it should be commited into WINE proper yet. We don't want applications in our own CVS that require native dlls :) That brings me to my other WIP, de-QT'ing KHTML and turning it into a working browser implementation for WINE. So far this is actually coming along quite well, and besides a few points it definatly makes an effective browser and IE compatability seems to generally be good enough to keep the majority of IWebBrowser using applications happy. I've since abandoned my earlier hopes to keep the changes minor (in order to make it easier to backport fixes from the main KDE cvs), simply because it was making the code quite messy. Hopefully I'll have some beta code ready in a week or two, depending on how my free time goes. I have a few questions however, mostly I'd like to hear from Alexandre on whether he'll consider accepting this into CVS. A working IWebBrowser implementation is, in my opinion, a must - and my HTML Help work does require it - but there are a few points to consider: - It is C++. So far, all of WINEs dlls are plain C. Is this really a rule, or just a result of the current areas of focus? I can't really de-C++ khtml and co, but I'm unsure as to whether it's okay to add a requirement for a working C++ compile environment on core dll's. - It is somewhat big, several megabytes of new code. Hopefully I can chop it down after removing a lot of the unneeded KDE and QT code I currently have #ifdef'ed and commented out. Cheers, Ender

6 5

Reducing the header maze (warning: long, unsuitable for children)
by Greg Turner 04 Dec '02

04 Dec '02

I'm working on Ove's comhdr1 & comhdr2 patches. So far, so good, btw -- I have it compiling against yesterday's CVS (recent commits are not folded in yet). I'll submit after I kick the tires a bit and make sure everything seems to be working (otherwise, I'll probably post it here and ask for help). Anyhow, this project has served to remind me just how deep, and how confusing, the maze of wine headers can really be. It's clear to me that lots of header inclusions are just historical remnants, that no longer serve any purpose, and, conversely, that many implicit header dependencies exist that happen to be hidden, and missing (i.e., X.h needs Y.h, but all references to X.h happen to occur after Y.h was already included, so there's no compile failure). A third kind of unnecessary (but arguably correct, in many cases) dependency is created when an include file is pulled in that is already pulled in by some prior include... This negatively affects wine development because (a) it's hard to change things, the headers break too easily, and (b) the make process rebuilds stuff that doesn't need rebuilding when things change (unavoidable, to an extent, of course, but perhaps it's too much right now). Now, here's my question: couldn't we build a script to automatically fix some of these problems? Imagine this pseudocode as a bash script, makefile, or something along those lines: o gather and create a table of all .c -> .h and .h -> .h dependencies o for each file: o one by one, try removing each reference to a header, and see if the affected units still compile. If they all do, permanently remove that reference, but remember it was there at this point we should have approximately the minimum number of header references in the code to compile wine. But some of the header references we eliminated were probably legitimate dependencies, event though we compiled OK, as mentioned above... so now we: o for each header, try to compile a "Hello World" which includes just that header file. If it fails (or even generates warnings): o for each header reference that was eliminated, try putting it back in. If still failing, try different combinations (this could become a really nasty computation with all kinds of permutations possible, but if certain simple tricks don't work, we can just give up). o if we couldn't find any way to fix it, mark the header for human review. This should ensure that each header can actually be run through the compiler all by itself -- that is, that it #include's any headers it relies on to compile. Finally... o A human picks up the pieces and fixes the breakages o The whole heuristic can start over, now, until the results start to look repetitive or trivial... I can think of some reasons this might not work out so well as I might hope, but... what do you guys think? is such a test meaningful? Is there some tool that already automates this type of investigation, or some better way to achieve the same thing? Would it be, in your opinion, too much work for too little benefit? FWIW, I can probably think of more enjoyable tasks to spend my time on... but OTOH I am really tired of waiting for wine to build on my aging pc -- anything that could speed up the build process would probably save me some from some discomfort, and others too. (At least there's no C++ in there; I'm rebuilding my system lately (I killed it over the holidays messing with glibc), and building stuff like KDE, mozilla, sun-java, and openoffice makes wine look pretty darn svelte! g++ 3.2.1 just crawls; the more "object oriented" the source is, the longer it seems to take to compile... :( ) Just "thinking out loud," probably a terrible idea, but let me know what you think, anyways... -- gmt p.s., I was kidding about unsuitable for children... but then, not sure why children should want to read this -- or adults, for that matter :P

4 4

Re: Fwd: Re: [putty]Winelib support + patch
by Alexandre Julliard 04 Dec '02

04 Dec '02

Francois Gouget <fgouget(a)free.fr> writes: > I am not sure but I suspect the compiler generates indirect accesses for > these. I'm not sure what gcc does for variables exported from another > library. It seems like it has to be doing something similar. So if we > could get access to that indirection we may be able to make things work. Yes, it would be possible to resolve imports directly through the ELF tables and avoid our own separate import mechanism; basically this would be a PE-aware ld.so. It's quite a bit of work though, and portability is an issue. In any case it's for after 1.0 IMO. -- Alexandre Julliard julliard(a)winehq.com

2 2

Re: Fwd: Re: [putty]Winelib support + patch
by Dan Kegel 04 Dec '02

04 Dec '02

Alexandre Julliard wrote: > Francois Gouget <fgouget(a)free.fr> writes: > >> I am not sure but I suspect the compiler generates indirect accesses for >> these. I'm not sure what gcc does for variables exported from another >> library. It seems like it has to be doing something similar. So if we >> could get access to that indirection we may be able to make things work. > > Yes, it would be possible to resolve imports directly through the ELF > tables and avoid our own separate import mechanism; basically this > would be a PE-aware ld.so. It's quite a bit of work though, and > portability is an issue. In any case it's for after 1.0 IMO. Portability to NetBSD shouldn't be an issue, as they seem to have already implemented it :-) See http://chiharu.haun.org/peace/ http://groups.google.com/groups?selm=20020516061929.5DA943C110%40gabi-n.hau… et seq. http://www.freebsd.org/cgi/man.cgi?query=compat_pecoff&manpath=NetBSD+1.6 - Dan

3 5

RE: Compiling out the debug messages
by Medland, Bill 03 Dec '02

03 Dec '02

> -----Original Message----- > From: Jeff Smith [mailto:whydoubt@hotmail.com] > Sent: Tuesday, December 03, 2002 2:13 PM > To: Bill.Medland(a)accpac.com; wine-devel(a)winehq.com > Subject: Re: Compiling out the debug messages > > > Bill, > > Unless I missed the whole point, you gave the answer before asking the > question. > > ./configure > > should have been > > ./configure --disable-debug You are correct; I made a right fist of writing the email. I did actually remember the --disable-debug. > > -- Jeff S > > _________________________________________________________________ > MSN 8 with e-mail virus protection service: 2 months FREE* > http://join.msn.com/?page=features/virus >

1 0

Re: Compiling out the debug messages
by Jeff Smith 03 Dec '02

03 Dec '02

Bill, Unless I missed the whole point, you gave the answer before asking the question. ./configure should have been ./configure --disable-debug -- Jeff S _________________________________________________________________ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus

1 0

Compiling out the debug messages
by Medland, Bill 03 Dec '02

03 Dec '02

I know I don't know what I am doing, but.. The documentation says that to compile out the trace, warning and fixme messages I should specify --disable-debug when running configure. So I try ./configure make depend make <build an rpm and install it on another machine> <run wine> <stare at the fixme messages, swear etc.> I presume that if I look for example in the dlls/user/Makefile at this stage I should see NO_DEBUG_MSGS and NO_TRACE_MSGS somewhere, but I don't. Please can someone explain how this is supposed to work and where I have probably gone wrong. (e.g. where should I see the NO_DEBUG_MSGS) Bill Medland

2 1

Re: wtypes.idl patch
by Alexandre Julliard 03 Dec '02

03 Dec '02

Ove Kaaven <ovehk(a)ping.uio.no> writes: > You need to regenerate wtypes.h (and it's best to apply my latest widl > patch first). Should regenerated .h files be part of submitted patches in > the future? For me that's not necessary; maybe for others who would like to review the patch, but I doubt many people are going to review the auto-generated stuff anyway. Just do what's easiest for you. -- Alexandre Julliard julliard(a)winehq.com

1 0

Direct3D8 regression/bug
by Roderick Colenbrander 03 Dec '02

03 Dec '02

Hi, Just to see how well Wine's Direct3D8 support is working, I played with some some simple d3d8 demos. (that are the tutorial examples Jason Edmeades used when he started Wine's Direct3D8 implementation) A few weeks ago all those demo's worked. Perhaps some things where not rendered correctly but they worked. A few days ago I rechecked those demo's but now all d3d8 apps I try crash. Immedeately winedbg is launched. The app seems to crash in libGL.so.1. Here's the error with a backtrace: Unhandled exception: page fault on read access to 0x00000008 in 32-bit code (0x40bf4a06). In 32-bit mode. 0x40bf4a06 (_end+0xf6a9a in libGL.so.1): movl 0x8(%eax),%eax Wine-dbg>bt Backtrace: =>0 0x40bf4a06 (_end+0xf6a9a in libGL.so.1) (ebp=00000001) Lionel suggested that his OpenGL patches may have caused this problem. He had the same crashes on his pc. I reversed his patches but it still had problems. (perhaps I made some misstakes somewhere ..) Perhaps the problem is related to the OpenGL drivers. I'm using Nvidia's OpenGL drivers (1.0-3123). I hope this helps a bit, Roderick Colenbrander

2 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