January 2004 - Wine-Devel - list.winehq.org

Re: PATCH: Fix DLL constructors on OpenBSD

by Alexandre Julliard

wiml(a)underhill.hhhh.org (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 object file of the dll can potentially have a .init section which would then break badly. Anyway, that constructor stuff is going to change, because we need to intercept constructors and run them from the dll entry point. I'm working on a patch to do that, which will hopefully solve your problem at the same time. -- Alexandre Julliard julliard(a)winehq.com

Jan. 3, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Mike Hearn

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 requires named pipes. Do > they have to upgrade their kernel for that, too? We are so far from being wire compatible it's not even funny. If/when we go for that, we'll all be running Linux 8.2 anyway :)

Jan. 3, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Alexandre Julliard

Juan Lang <juan_lang(a)yahoo.com> 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 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. -- Alexandre Julliard julliard(a)winehq.com

Jan. 3, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Juan Lang

--- Alexandre Julliard <julliard(a)winehq.com> 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 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 pipes. Do they have to upgrade their kernel for that, too? --Juan __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Jan. 3, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Alexandre Julliard

"Dimitrie O. Paun" <dpaun(a)rogers.com> 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 a few years before we > can expect people to have it available on their boxes... 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... -- Alexandre Julliard julliard(a)winehq.com

Jan. 3, 2004

Re: DMUSIC: my latest work

by Alexandre Julliard

Jakob Eriksson <jakov(a)vmlinux.org> 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 is that if a lot of code needs to be shared, then there is normally a way to do it with the exported APIs. If there's no way to do that, then it's probably a sign that we are not implementing it the right way. -- Alexandre Julliard julliard(a)winehq.com

Jan. 3, 2004

Direct3D8 - OpenGL header problem

by Thomas Brix Larsen

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. Greetings, --Thomas _________________ My worst enemy gave me a copy of Windows...

Jan. 3, 2004

Re: PATCH: Fix DLL constructors on OpenBSD

by wiml＠underhill.hhhh.org

Alexandre Julliard <julliard(a)winehq.org> 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 crtbeginS.c, instead of being split between crtbegin and crtend as in most gcc targets, so code added to .init is not executed. > [....] So there are two separate mechanisms, and > the constructors are built on top of the .init stuff. In our case we > need to be in .init because the constructors are normally called after > the rest of the .init code. It doesn't appear that the .init code on OpenBSD does anything before calling the functions listed in .ctors. (Well, that's not quite true: it sets a flag before calling the ctors.) As long as the foo.spec.o file is listed early on the linker's command line, its constructor(s) should be called before any others. The .so's destructors are called in the reverse order. 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. Wim.

Jan. 3, 2004

Re: DMUSIC: my latest work

by Jakob Eriksson

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 be accepted.) Is there no other way of sharing code? Is using include files with code in them acceptable? Jakob

Jan. 3, 2004

Re: Status ToDo's #2

by Sylvain Petreolle

--- Tom <twickline(a)skybest.com> 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_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". _________________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 3, 2004