--- Dan Kegel <[EMAIL PROTECTED]> wrote:
> My goodness. I didn't know that document existed.
> Thanks for
> the link! Is there a complete list anywhere of
> Win32 APIs
> that have been documented by opengroup.org?
My pleasure. Don't know of one, but check out the
references section of Chris He
"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 f
--- 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 supporte
I was planning to add the audio driver as a configuration option in winecfg
but had a few questions.
Does anyone use the directsound options? If so it probably makes sense to
have an "Audio" tab in winecfg with the audio driver and the dsound options.
If not then it might make sense to put t
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 create
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 socket pairs, for instance
switching between byte and
On Saturday 03 January 2004 05:13 pm, Juan Lang wrote:
> having RPC be able to talk to a
> remote RPC server (running on Windows) ...
> That requires named pipes.
or tcp support
-gmt
--- 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 i
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, sinc
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 instead
--- 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 ca
freshmeat.net. Searched for winex from the main page.
All the urls (excl the Changelog) point to sourceforge.net
[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 a
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 nam
On Sat, 2004-01-03 at 23:13, Juan Lang wrote:
> 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 requi
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 c
--- Alexandre Julliard <[EMAIL PROTECTED]> wrote:
> I think it's reasonable to require people who want
> SMB file access to
> upgrade their kernel. It's not like it's a widely
> requested feature,
> we haven't had it for 10 years and nobody
> complained...
Yeah, but what about RPC? Maybe all the
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 not
"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 w
Jakob Eriksson <[EMAIL PROTECTED]> writes:
> And what if there are not a few things, but many?
>
> (Not much use looking for duplicated code if patches will not be accepted.)
>
> Is there no other way of sharing code? Is using include files with
> code in them acceptable?
Usually not. The point
Hi list, just upgraded to 2.6.0 and the NVIDIA driver from minion.de
and now I get this error when compiling wine:
directx.c: In function `IDirect3D8Impl_GetDeviceCaps':
directx.c:639: `GL_MAX_VERTEX_UNITS_ARB' undeclared (first use in this
function)
My X11/include/GL/ headers date, 2001-2002.
--- 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 (spetreolle_at_users_dot_
On January 3, 2004 01:35 pm, Alexandre Julliard wrote:
> Oops, I agree this is confusing. In this case I mean the Linux kernel,
> this stuff cannot be done efficiently in user space.
Of course this stuff should be in the kernel (ideally, we should get
the entire wine server in the kernel :)), but
On January 3, 2004 02:52 pm, Mike Hearn wrote:
> I thought cvsup copied the entire repository, not just the source tree.
> Wouldn't that be even more huge?
Well, initially it will be a lot more, yes, but if you plan to do
any work (cvs diff, cvs log, etc), cvsup it's a _lot_ faster/smarter
on upda
Eric Pouech <[EMAIL PROTECTED]> writes:
> So, if I follow you, you would suggest to:
> 1/ pass the unix codepage (or its table) along the ansi & oem cp
Yes.
> 2/ allow, in ntdll.wine_init_codepage, to make further initialization
> (which could depend on the various codepages)
Sure, that's not a
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 separat
> I thought cvsup copied the entire repository, not just the source tree.
> Wouldn't that be even more huge?
Well, if you just use CVS to get a recent version of Wine, plain CVS is just
fine. But if you use more advanced features of CVS often (like getting
histories of files and stuff like that),
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 t
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
> 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 include/
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]
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 s
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 supp
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
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 Julli
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 in
[EMAIL PROTECTED] (Wim Lewis) writes:
> There *is* a section named .init, but any code placed there will
> be linked after the C function __init() in crtbeginS.c, and will not be
> executed because that C function returns normally. But the only
> thing that __init() does is invoke the functions po
"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 compiler's options as parameters?
No, how could it? There's no
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
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
On January 3, 2004 07:42 am, Jakob Eriksson wrote:
> Isn't there a bug with some CVS clients or servers with the use of ANY
> -z but 0?
Indeed, for older CVS clients. That's why the patch points out that
you need CVS 1.11.5 or greater to use that feature.
However, I think the patch is missing the
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 with
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
Juan Lang wrote:
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.
I'm happy to work with you (or even do most of the work) to put named
pipes and mailslots in
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 winex.
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 ve
> "P. Christeas" <[EMAIL PROTECTED]> writes:
> > On my configuration, the 'artsc-config' script outputs '-pthread' along
> > with the '-Isth' entries. That broke the 'makedep' procedure.
> > It's trivial. The following patch handles this.
>
> The right fix is to get rid of that option at configure
(for wine-devel readers: this is about the port of Wine DLLs to ReactOS
and the problems we're having since a lot of the DLLs have a separate
version.rc.)
> From: Filip Navara
>
> Not really. The actual problem is that binutils supports only one
> resource file. Previously it linked correctly the
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 version is
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
On January 2, 2004 06:47 pm, Ferenc Wagner wrote:
>Hi,
>
> I put together a feedback window for winetest. The code is
> somewhat inside-out to make it less intrusive, and the
> dialog is ugly. Where can one find a dialog editor?
Nice! A few suggestions about the dialog:
-- The
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
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
53 matches
Mail list logo
