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

winebrowser winelib application

by Chris Morgan

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 creates a key with the defaults if no key exists. Thanks, Chris

Jan. 3, 2004

WWN #203

by Tom

Bein' A Playa In Da Hood :-) Tom

Jan. 3, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Alexandre Julliard

Juan Lang <juan_lang(a)yahoo.com> 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 message modes on the fly, or some of the blocking conditions. -- Alexandre Julliard julliard(a)winehq.com

Jan. 3, 2004

Re: Winetest progress bar

by Jakob Eriksson

Ferenc Wagner wrote: > >Comments are welcome. Find the programs/winetest directory >enclosed. A cross-compiled binary is also available at ><http://afavant.elte.hu/~wferi/wine>. > > I UPX-packed the binary and put it up here: http://vmlinux.org/jakov/winetest.exe It went down from 2 megs to 600 k. regards, Jakob

Jan. 3, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Gregory M. Turner

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

Jan. 3, 2004

Re: netapi32: implement NetServerEnum and NetShareEnum

by Juan Lang

--- Alexandre Julliard <julliard(a)winehq.com> 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 don't? It may be clear to you, but it isn't to me. --Juan __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Jan. 3, 2004

Re: #3 - shell32/systray.c

by Jakob Eriksson

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 of Total Commander. regards, Jakob

Jan. 3, 2004

Re: PATCH: Fix DLL constructors on OpenBSD

by Wim Lewis

In <87r7yg4n69.fsf(a)mail.wine.dyndns.org>, julliard(a)winehq.org 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 think neither of these would be issues on OpenBSD ... > Anyway, that constructor stuff is going to change [...]. I'm working on a > patch to do that, which will hopefully solve your problem at the same > time. ... but this seems like a better idea. I'll wait for your patch and see how it goes. :-)

Jan. 3, 2004

Re: #3 - shell32/systray.c

by Steven Edwards

--- Mike Hearn <mike(a)theoretic.com> 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 also try building it as a Winelib app. Martin has provided a Winelib Makefile so you can just checkout the source for explorer and build it under Linux. 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 Thanks Steven __________________________________ Do you Yahoo!? Find out what made the Top Yahoo! Searches of 2003 http://search.yahoo.com/top2003

Jan. 3, 2004

Re: Winex cvs

by Peter Hartshorn

freshmeat.net. Searched for winex from the main page. All the urls (excl the Changelog) point to sourceforge.net

Jan. 3, 2004

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

Re: netapi32: implement NetServerEnum and NetShareEnum

by Dimitrie O. Paun

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 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... -- Dimi.

Jan. 3, 2004

Re: Lostwages

by Dimitrie O. Paun

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 updates. So the idea is to: 1. Use cvsup to duplicate the entire repository on your box (cvsup is very smart about keeping this up to date) 2. Check out your local copy from this private repository. You just need to monitor the wine-cvs list (which all developers should do anyway) for when to run cvsup to update your local repository. -- Dimi.

Jan. 3, 2004

Re: ntdll / kernel32: #40

by Alexandre Julliard

Eric Pouech <pouech-eric(a)wanadoo.fr> 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 problem. -- Alexandre Julliard julliard(a)winehq.com

Jan. 3, 2004

Re: DMUSIC: my latest work

by Alexandre Julliard

Rok Mandeljc <rok.mandeljc(a)email.si> 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. Dlls should not depend on one other this way. The best way is to duplicate the few things you need in each dll. > And I believe shared private header you had in mind was dmusic_common.h; > I didn't know it was forbidden to do it since you didn't say anything > when I included dmusic_private.h in dmime_private.h last time. I missed it when reading the patch; you may notice I have fixed it since then... -- Alexandre Julliard julliard(a)winehq.com

Jan. 3, 2004

Re: Lostwages

by Lionel Ulmer

> 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), having a local copy of the whole repository may be good. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Jan. 3, 2004