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

Re: Explorer

by Dimitrie O. Paun

On January 31, 2003 01:44 pm, Steven Edwards wrote: > If the WINE project is going to start a implementation of explorer.exe then > we will work off of that. Having a Wine-explorer would be a useful addition I think. It would give us a nice browser (people coming from Windows will appreciate it), and a good test for our shell32 and listview stuff. Having just a wrapper around whatever we have now is not that useful. But again, this is more a project for Wine 1.0 or beyond, not 0.9. I'll add it to my Fun Projects page. -- Dimi.

Jan. 31, 2003

Re: Guess who's back, back again... :)

by Dimitrie O. Paun

On January 31, 2003 11:57 am, Shachar Shemesh wrote: > If your'e now a freelancer with less free time, does that not mean you > are now a freelancer making more money? That is, generally speaking, a > good thing. Well, yeah... :) > Good luck, either way. Same to you. It's really just a matter of obsession how much time you spend on Wine, irrespective of full-time or contract :) -- Dimi.

Jan. 31, 2003

Re: PATCH - wineserver sock.c porting fix

by Dan Kegel

Steven Edwards wrote: > Working on building wineserver on mingw Please batch your changes... one patch a day for all #ifdef HAVE_foo_H patches would be perfect. -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Jan. 31, 2003

Re: PATCH: Get rid of superfluous dup() and close() calls.

by Alexandre Julliard

Martin Wilck <Martin.Wilck(a)fujitsu-siemens.com> writes: > The dup() in wine_server_handle_to_fd() requires dozens of close() > calls spread over the wine code. I think this is confusing and error-prone > (close() calls are easily forgotten, leading to rapid fd leak - actually, > when looking through the code, I found a number of functions where I > had expected a close(), but it was lacking). > Moreover, I can't see why that dup() is necessary (any more). I think it's cleaner to return a dup of the fd instead of relying on the fact that the fd is cached internally. This may not always be the case, and it's better to risk an fd leak than to risk invalidating the cached value in case someone closes the fd when they shouldn't. -- Alexandre Julliard julliard(a)winehq.com

Jan. 31, 2003

Re: Stdole2 / Stdole32 (RESEND)

by Alexandre Julliard

"Robert Shearman" <R.J.Shearman(a)warwick.ac.uk> writes: > There are a couple of things to note about this patch. > The first is that this only really provides the stdole2.tlb resource data > since it is just an alias for oleaut32.dll and there can be only one > resource of each type for a given id, so I am not 100% sure at the moment > whether it will work properly for those apps wanting stdole32. Looks like it has to be made a separate dll then, since that's how Windows does it. Also we need a way to generate that file, I'm not going to put the compiled binary file into CVS. -- Alexandre Julliard julliard(a)winehq.com

Jan. 31, 2003

Started playing with Wineserver on mingw/cygwin again

by Steven Edwards

well I made it serial.c before I had to run to work. I'm having good luck getting alot of the objects to compile so far I've only had to kill file.c, ptrace.c, request.c and select.c. Getting this to build and run on Windows is going to be a bitch =) gettimeofday, fork and all of fd and networking is going to be the hard part. I've started a tempory header to see what will need to be implemented in libwine if we want to get wineserver up and running on Windows without cygwin. Cygwin still really needed get/setthreadcontext (hint, hint) Thanks Steven /* I kill'd file.c, ptrace.c, request.c, select.c * * get/set thread context still needs to be done for Mingw and Cygwin * * main.c needs a lot of work */ /* object.h and async.h */ struct timeval{ int tv_sec; int tv_usec; }; /* debugger.c */ #define SIGTRAP NULL /* file.c - doesnt work */ #define O_NONBLOCK 0 #define POLLIN 0 #define POLLOUT 0 #define POLLIN 0 #define POLLOUT 0 /* main.c */ #define SIGPIPE NULL #define SIGHUP NULL #define SIGQUIT NULL /* named_pipe.c */ #define PF_UNIX NULL #define SOCK_STREAM NULL /* object.c */ #define POLLERR 0 #define POLLHUP 0 __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com

Jan. 31, 2003

Winelib and <io.h>

by Hans Christian Studt

Using (pached) winemaker I still have problems with <io.h> sed -e 's,@bindir\@,/usr/local/bin,g' -e 's,@winelibdir\@,.,g' ./wineapploader.in >wineapploader || rm -f wineapploader make[1]: Entering directory `/user/home/hcs/Wine/winelib/compile/bb4win/blackbox' LD_LIBRARY_PATH=":$LD_LIBRARY_PATH" /usr/local/bin/wrc -J -m -I. -I/usr/local/include/wine/windows -o Blackbox.res Blackbox.rc /usr/local/bin/wineg++ -c -I. -I/usr/local/include/wine/windows -g -O2 -fpermissive -fno-for-scope -D_REENTRANT -o BBApi.o BBApi.cpp In file included from BBApi.cpp:34: Menu/MenuMaker.h:53:16: io.h: Ingen sådan fil eller filkatalog There was a discussion on a subject related to io.h started on this list 9. january 2003. What exactly were the outcome ??? Is there a resolution or a workaround ??? I can still try out Ming/Cygwin but how would that change the <io.h> problem ??? -- Hans Christian Studt : http://hc.studt.dk mailto:hc(a)studt.dk .dk og W3C standarder : http://w3c.studt.dk

Jan. 31, 2003

Re: RPC marshalling patch

by Sylvain Petreolle

notice that the most common anonftp passwords are mozillauser@, IE4USER@ and joe(a). what a useful log :) > In any case they wanted a log of who was downloading stuff, but they > said at the time that the email addresses wouldn't be used for other > purposes. I've certainly never received junk mail from them. > > I suspect the log (like the ones from anon ftp passwords) is of > little use to anyone. ===== Sylvain Petreolle spetreolle(a)users.sourceforge.net Fight against Spam ! http://www.euro.cauce.org/en/index.html ICQ #170597259 "Don't think you are. Know you are." Morpheus, in "Matrix". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Jan. 31, 2003

Re: Winelib project

by Hans Christian Studt

Dimitrie O. Paun wrote: > On Fri, 31 Jan 2003, Hans Christian Studt wrote: > >>The question is should we support source-three >>or >>should we get rid of >>:$WINE_ROOT/tools/wrc:$WINE_ROOT/tools/winebuild >>from WINE_TOOL_PATH > > Getting winegcc and winewrap work off of the source > tree is not supported at the moment, as I said in an > earlier email. It will take a lot more than pointing > an environment variable, and it will not happen any > time soon. Only after it stabilizes a bit should we > consider modifying it to work from the tree. > > So for now, if you want to play with Winelib, you > have to make install it, and use it like it's meant > to be used. Fine -- Hans Christian Studt : http://hc.studt.dk mailto:hc(a)studt.dk .dk og W3C standarder : http://w3c.studt.dk

Jan. 31, 2003

Re: Winelib project

by Hans Christian Studt

Hans Christian Studt wrote: > Hans Christian Studt wrote: > >> Dimitrie O. Paun wrote: >> >>> Yes, it's just a symbolic link: >> >> Be sure someone fix that in the CVS. > > No fix needed - It is correct in /usr/local/bin - sorry I the current winemaker perl script the variable is used WINE_TOOL_PATH="$WINE_ROOT:$WINE_ROOT/bin:$WINE_ROOT/tools/wrc:$WINE_ROOT/tools/winebuild" which support running of the source-three where tools/wrc exists as well as off the /usr/local/bin-three as long as gcc is used. Now when we want to use the winegcc and wineg++ the source-three will not work. In order to make it work we need to add $WINE_ROOT/tools to WINE_TOOL_PATH and to create a symbolic link between winegcc and wineg++ in the source-three. The question is should we support source-three or should we get rid of :$WINE_ROOT/tools/wrc:$WINE_ROOT/tools/winebuild from WINE_TOOL_PATH -- Hans Christian Studt : http://hc.studt.dk mailto:hc(a)studt.dk .dk og W3C standarder : http://w3c.studt.dk

Jan. 31, 2003