All the news that fits, we print.
This week, 121 posts consumed 422 K. There were 34 different contributors. 25 (73%) posted more than once. 21 (61%) posted last week too. The top 5 posters of the week were:
|
Code review | 06 Nov 2000 00:00:00 -0800 | Archive |
---|---|---|
Joerg Mayer started the task to reduce the number of warnings
generated by compiling Wine with -Wall -W flags (currently Wine is
built with -Wall only).
He started working in the tools subdirectory. Fix tries gave the
following results:
Earlier this evening there were 3260 warnings (2357 unused params, 864
signed/unsigned comparison, 39 others). I'm trying to take up the task
to reduce that number and reveal some bug in doing so :-) So if you
don't agree with what I'm doing and how I'm doing it: Now is the best
time to let me know.
Alexandre Julliard didn't like some of the type casts added (for
example between a char*
and a unsigned
char*
):There may be a few cases where a type
cast may actually make a difference; but when the only difference is
the warning I consider the type cast unnecessary. And if the choice is
between having warnings with -W or having type casts all over the
place, I prefer the warnings.
Joerg furnished a patch according to Alexandre wishes.
|
Wine without X | 06 Nov 2000 00:00:00 -0800 | Archive |
---|---|---|
Donnchadh ó Donnabháin wrote:
We use Microsoft Visual SourceSafe as our Version Control system here
and I use Wine (20001026) to run the command line tool (win32 console
app) under Linux (The GUI also runs but hangs on some operations). I
would like to get the latest version of on project using VSS from
within an automated build script, but would prefer not to have to
install/run X on the build server. ./configuring wine without the X
libraries indicates that wine can be built without X but that it
doesn't work yet.
What needs to be done to get wine working without X?
Patrik Stridvall answered that console applications should work
without X under Wine. However, GUI applications don't work under Wine
without X (Patrik did some hacks some months ago and add some simple
applications working in text mode (windows were drawn in text mode)).
Donnchadh didn't investigate too hard after the Wine configure message:
which turned out to be a completely wrong message.
Later on, Donnchadh reported success.
|
Win(e)file | 06 Nov 2000 00:00:00 -0800 | Archive |
---|---|---|
Martin Fuchs announced: Some time ago I started to program a file manager replacement for Wine. If I look at the time stamps, it seems, I didn't change anything in the last 6 months. ;-) So if some one wants to continue the work... I've put the current source code archive at my HP: http://private.addcom.de/M.Fuchs/tools.html So, if some of you want(s) to take over this development, just go for it!! |
More configuration discussions | 08 Nov 2000 00:00:00 -0800 | Archive |
---|---|---|
Jeremy reopened the freshly closed discussion on Wine configuration
(see <kcref>previous issue</kcref> for more
details):
Why do we have the -rpath option on by default?
It creates a serious problem for us. Say we build a Winelib
application for customer Y. By default, that app is built with
-rpath=/usr/lib/wine
.
However, that app relies on specific library versions of Wine. Even if
I start my app with
LD_LIBRARY_PATH=/opt/x/wine/lib
, the Y application will
actually use the /usr/lib/wine shared objects.
Jeremy would have liked to remove the -rpath option. Eric Pouech would
have seen it done the other way around (add an option to remove -rpath
use).
Jeremy also posted some Alexandre Julliard saying:
So if I get this right, what you do is that you don't set -rpath at
all? I'm beginning to think this should actually be the standard
behavior; setting rpath is broken because it takes precedence over
LD_LIBRARY_PATH. How about submitting a patch that removes rpath
completely, and start a nice flame^H^H^H^H^Hdiscussion on wine-devel?
However, Ove Kaaven noted:
There's no sense in aiming for ultraclean rpath solutions... as I
understand, neither rpath, LD_LIBRARY_PATH, nor ld.so.conf
modifications will be required in Wine 1.0 anyway, because by then we
should have Alexandre's perfect DLL separation with import system that
makes ELF dependencies a thing of the past. The problem that rpath,
ld.so.conf modifications, etc, aims to solve won't exist anymore once
Alexandre finishes his work. I'd just go for rpath without relocation
until then.
Ove also added that putting away from the standard .so load path the
Wine's DLL would help solving file name collisions (like the one Wine
had with Gnumeric' libole32.so).
Alexandre agreed, but added we won't have the problem
with dlls, but we'll still need a way to locate libwine.so and
libwine_unicode.so and suggested that in order to start Wine,
the best approach IMO is to use LD_LIBRARY_PATH in a
wrapper script like winelauncher. But of course this only works if we
never set rpath.
|
Some Wine help removed | 07 Nov 2000 00:00:00 -0800 | Archive |
---|---|---|
In a middle of some discussion around Wine documentation, Joerg Mayer
noted that one of Alexandre latest change broke the --debugmsg
help
feature (this allowed to list all the known debug channels
which give some feedback of what Wine's doing).
For the insiders, this patch moved the definition of the debug
channels from the Wine core to every DLL (in fact, each DLL is able to
define its own set of debug channels), which of course is a better
open approach, but kills the centralized listing of the defined
channels.
Joerg asked for some possible solutions. Alexandre Julliard gave a
rough answer:not do anything ;-) The whole point of
the patch is to avoid having a centralized list of debug channels;
this way any dll/app can add its own channels when loaded. So of
course this also means you have no way of printing the complete
list. I'm not convinced that such a list is really useful anyway; you
still need to read the code to see what debug channels are useful for
debugging a given problem.
Some people, like Petr Tomasek, found the end result too harsh and
requested at least some better documentation on the matter.
|
Wine and Solaris 7 | 08 Nov 2000 00:00:00 -0800 | Archive |
---|---|---|
John Wehle tried to have Wine working on his Solaris 7 box. He posted
a traceback, and some explanations:
Wine uses _lwp_create on Solaris which has the following note:
|
Windows and Processes | 09 Nov 2000 00:00:00 -0800 | Archive |
---|---|---|
Joerg Mayer while trying to fix some programs, found out that current
Wine's code for FindWindow didn't check other processes Windows after
search in current process' windows failed. Joerg was also astonished
that no fixme was emitted.
Gérard Patel gave some explanation on the situation:
That's a following of the address space separation. Although the Wine
processes are separated, the windows handles are still generated by
each Wine process through a local mechanism based on memory
allocation. The Wine server does not generate them, and as such these
handles have no meaning for another process.
For example, it can happen that 2 windows of different processes have
the same handle. So it does not make sense to do a FindWindow for a
window in another process in current Wine.
However, this is not Windows's behavior (a Window handle is unique
across the system).
Gérard went further:
>From what I have seen in existing apps, Interprocess FindWindow is
used for 2 goals:
|
DLLs get separated | 12 Nov 2000 00:00:00 -0800 | Archive |
---|---|---|
Alexandre Julliard committed a patch that implements a decent DLL
scheme into Wine (see
<kcref>WWN 11</kcref>,
<kcref>WWN 24</kcref>,
<kcref>WWN 49</kcref> for previous articles on
this matter).
Basically, Wine was missing the following feature: as the DLL which
contains the implementation of a function can be either a native (from
Windows) or builtin (from Wine) DLL, it would be neat to have, in
another part a the code, a single way to call such a function. Before
the patch, the only doable way was to get the handle of the
destination DLL, and get, by hand, the function address thru
GetProcAddress.
This was a painful process, because:
in the shell32.spec.c file. The loader will store the actual address
of InitCommonControlsEx into (imports+20) at load-time, no matter
whether the builtin or native comctl32 was loaded. This means you can
use InitCommonControlsEx() in your code just like if you were using
ELF libraries exclusively; the redirection to the native dll will be
completely transparent.
The things to consider is that any dll using this mechanism must be
linked with -Bsymbolic to make sure the assembly stubs do not override
the real function definitions, and that it should only call functions
that are exported by the dll (which is the main reason why not all
dlls can use this yet).
Also, this mechanism takes precedence over normal ELF linking, so for
instance if you import crtdll you can no longer call libc functions
since they will be redirected to crtdll (of course crtdll itself will
call libc, so it will still work).
Marcus Meissner started to report some issues:
|
All Kernel Cousin issues and summaries are copyright their original authors, and distributed
under the terms of the
GNU General Public License,
version 2.0.