On January 2, 2004 07:16 pm, Ralf Juengling wrote:
I tried this today, (adding /local/lib to /etc/ld.so.conf)
but it didn't make a difference.
I then looked into winegcc.c and winewrap.c to find out
what winwgcc is actually doing. It is creating a shared
library (dll) and a little wrapper
On January 2, 2004 05:13 pm, Dan Timis wrote:
Thanks Dimi, and La multi ani (Happy new year).
Hey, La Multi Ani! to you too :)))
I'm new to this so please bear with me.
First I edited the Makefile and replaced gcc with winegcc. When I run
make I get this error when it tries to link:
Robert Shearman a crit :
After the automatic glibc detection changes the Wine debugger stopped
loading symbols correctly, making it harder to debug programs. I only
recently noticed this due to lack of disk space and not compiling and
installing the whole tree on a cvs update.
We should no longer
Mike Hearn wrote:
On Sat, 2004-01-03 at 09:29, Dimitrie O. Paun wrote:
1. If compiled with Winelib, the dialog stays on screen
after the main thread finishes with the tests; under
Windows, it disappears at once.
This is a bug in Wine, don't worry about it for now. Having
a Winelib
I know that this is off topic, but I decided to see how the winex cvs compared
to wine cvs. I done a checkout of winex from sourceforge.net and I noticed
that the directories containing the d3d8 and 9 code had been removed from
cvs. This prevented all of my games (gta3) from running under
Alexandre Julliard writes:
The dll init routine needs to be in the .init section in order to be
called first,
Isn't that what attribute((constructor)) does? It places a call to the
routine in the .so's initialization section, whatever that section is,
so that the routine gets invoked during
Andreas Mohr wrote:
4)Tell users of slow connections to use z9, as they probably have more processor
power than bandwidth.
People should NOT use -z9 (we've been through this before), since it places
an abnormally sane (normally insane? :) burden on the CVS server.
Isn't there a bug
I found some time over the holidays to run several game demos under Wine to
see if there was more debugging fodder to be found. All the games come from
Shrapnel Games (www.shrapnelgames.com) - I went through their demos looking
for the magic words DirectX and OpenGL. They're not technically
Juan Lang [EMAIL PROTECTED] writes:
File I/O, fine. But how about named pipes?
Mailslots? They are implemented with nearly the same
SMBs, and belong in kernel32 or ntdll. netapi32 needs
'em too, for these two functions.
They should go in the kernel too. Anything that does I/O needs to be
They should go in the kernel too. Anything that does I/O needs to be
there, because it can't be done reliably in the client process, and it
can't be done efficiently in the wine server.
Alexandre,
when you write kernel, do you mean kernel32 or the kernel32/ntdll pair ?
(IMO, it should rather be
Eric Pouech [EMAIL PROTECTED] writes:
when you write kernel, do you mean kernel32 or the kernel32/ntdll pair ?
(IMO, it should rather be in ntdll)
Oops, I agree this is confusing. In this case I mean the Linux kernel,
this stuff cannot be done efficiently in user space.
--
Alexandre Julliard
On Sat, Jan 03, 2004 at 10:02:10AM -0800, Alexandre Julliard wrote:
P. Christeas [EMAIL PROTECTED] writes:
I thought of that when I was trying to see why the make had been broken.
Unfortunately, the artsc-config script is not within our reach. Isn't the
makedep utility supposed to have
Hi Peter,
I'm guessing that you are probably using the sourceforge cvs - which it
looks like we accidentally imported rewind into. That would explain why
there is no d3d8 / d3d9. I'll remove the rewind import from sourceforge
in a tick.
Out of curiosity, where did you go that directed you to
Joerg Mayer [EMAIL PROTECTED] writes:
Wouldn't it make more sense to ask the authors of the artsc-config script
to fix it?
We can do that too, but it won't help for existing installations, so
we need a fix anyway.
--
Alexandre Julliard
[EMAIL PROTECTED]
Eric Pouech [EMAIL PROTECTED] writes:
This patch allows to use the UNIX code page inside of ntdll.
The full change log:
- moved code page NLS resources from kernel32 to ntdll
- moved locale initialisation from kernel32 to ntdll
- created unix code page handling in ntdll
- made use of this
The dmusic_common.c thing is wrong, you can't use the same source file
in multiple dlls, this won't build properly. Also you should not
include private header files from other dlls, if definitions really
have to be shared they should be in a common header somewhere in
include/ or
I don't think I agree with that. IMO the locale stuff should remain in
kernel32. We can simply set the unix codepage in ntdll the same way we
set the other codepages.
the only issue I have here is that most of the code needed for
initialisation in has to be called after the unix codepage has been
On Sat, 2004-01-03 at 17:16, Dimitrie O. Paun wrote:
We'd better explain how to setup cvsup instead. I've described my
setup sometime ago, and Brian included it as a story in WWN, if
anyone is interested... ;)
I thought cvsup copied the entire repository, not just the source tree.
Wouldn't
Rok Mandeljc [EMAIL PROTECTED] writes:
I can't see how sharing dmusic_common.c would mess up building (it
builds and works fine for me), but then again you have more experiences
on this matter. Do you have any suggestions what should I do about it?
It breaks parallel makes and dll separation.
--- Tom [EMAIL PROTECTED] a écrit :
Comments, Suggestions?
Tom
ALSA multimedia driver:
* Mixer Support
* MiDi inn Support
* Check for 1.0 correctness
winealsa now has mixer support since Dec 11 2003 (thanks to Christian)
=
Sylvain Petreolle
Dimitrie O. Paun [EMAIL PROTECTED] writes:
Of course this stuff should be in the kernel (ideally, we should get
the entire wine server in the kernel :)), but what about a fallback
for boxes that don't have that in there? Even if we do the work now
(to push things into the kernel), it will be
Juan Lang [EMAIL PROTECTED] writes:
Yeah, but what about RPC? Maybe all the RPC bugs in
Wine are well known and people just don't want to work
on them, but I figured having RPC be able to talk to a
remote RPC server (running on Windows) would help
discover RPC bugs. That requires named
Alexandre Julliard wrote:
It breaks parallel makes and dll separation. Dlls should not depend on
one other this way. The best way is to duplicate the few things you
need in each dll.
And what if there are not a few things, but many?
(Not much use looking for duplicated code if patches will
Alexandre Julliard [EMAIL PROTECTED] writes:
The way it normally works is that the _init() function is built from
the contents of the .init section, so if you add code in .init it's
supposed to show up in _init().
Ah, right. This doesn't work on OBSD because __init() is fully
defined in
[EMAIL PROTECTED] (Wim Lewis) writes:
What is it that _init() does on Linux, that the DLL init code needs
to run first? I'd be interested in trying to write an autoconf test
or something, if possible.
I believe there was a problem with constructors being called in
reverse link order. Also any
freshmeat.net. Searched for winex from the main page.
All the urls (excl the Changelog) point to sourceforge.net
--- Mike Hearn [EMAIL PROTECTED] wrote:
Could you send me an EXE of that, if it's convenient? I have no idea
how
easy/hard it is to build ReactOS but I doubt it's a configure, make,
make install :)
I am having trouble running the latest build under WINE but you are
welcome to try. You can
Steven Edwards wrote:
Here is his site that provides the CVS information:
http://www.sky.franken.de/explorer/
And here is a Win32 binary:
http://mail.gleneagle.net/sedwards/explorer.exe
Cool! I had no idea it is so complete. Works wonderfully in Windows XP.
I'm thinking about using it
--- Alexandre Julliard [EMAIL PROTECTED] wrote:
discover RPC bugs. That requires named pipes. Do
they have to upgrade their kernel for that, too?
Most likely yes. In fact we'll probably need some
kernel support even
for local named pipes.
Why? What problems will we run into if we
In [EMAIL PROTECTED], [EMAIL PROTECTED] wrote:
I believe there was a problem with constructors being called in
reverse link order. Also any object file of the dll can potentially
have a .init section which would then break badly.
I guess configure could test the constructor semantics, since I
Alexandre wanted winebrowser implemented as a winelib application and also to
be more easily configured. Here is the winebrowser winelib application. It
uses a registry key(I'm not sure if this is the correct path for the key
since I didn't see any other config keys in the registry) and
--- Alexandre Julliard [EMAIL PROTECTED] wrote:
Juan Lang [EMAIL PROTECTED] writes:
Why? What problems will we run into if we don't?
It
may be clear to you, but it isn't to me.
Mike can probably give you more details, but there
are some features
that cannot be supported on standard
Ge van Geldorp [EMAIL PROTECTED] wrote:
Changelog:
Don't destroy heap during unload, as other DLLs which haven't unloaded
yet may still depend on it (DPA* callers)
The patch is wrong. A more correct way to fix this is to simply
use process heap in DPA (and MRU) APIs. Perhaps even go further
33 matches
Mail list logo
